本文是向大家介绍Hologres是一款实时HSAP产品,隶属阿里自研大数据品牌MaxCompute,兼容 PostgreSQL 生态、支持MaxCompute数据直接查询,支持实时写入实时查询,实时离线联邦分析,低成本、高时效、快速构筑企业实时数据仓库(Real-Time Data Warehouse)。
1. HSAP理念与产品
首先介绍下大数据相关实时业务场景,一般有实时大屏、实时BI报表、用户画像和监控预警等。
- 实时大屏业务,一般用作公司领导层做决策的辅助工具,以及对外成果展示。比如双11实时成交额大屏等场景
- 实时BI报表,是运营和产品经理最常用到的业务场景,适用于大部分的报表分析场景
- 用户画像,常用在广告推荐场景中,通过更详细的算法给用户贴上标签,使营销活动更加 有针对性,更有效地投放给目标人群
- 预警监控大屏,比如对网站、APP进行流量监控,在达到一定阈值的时候可以进行告警
针对上述大数据业务场景,业界在很早之前就开始通过数据仓库的建设来满足这些场景的需求。
1.1. 传统数仓建设与痛点
传统上,我们是如何做数据加工以及数据服务的呢?最常见的方式就是下图所示,数据链路也左向右发展,有加工平台负责加工,结果数据导出到服务平台对外提供服务。离线数据仓库数据流程如下:
这个架构在最开始应用的时候还是比较顺利的,大部分公司里面 90%的场景下是这个架构。但是随着业务越来越多,越来越复杂,每天都有新的报表,每天都有新的业务场景,就会发现每一个业务调整的时候,都要从源头一步步调整,包括表结构,加工脚本,历史数据重刷等等,最后造成整个数据加工的链路会变得数据冗余、成本高、开发周期长、甚至数据不一致。痛点整理如下:
- ETL逻辑复杂,存储、时间成本过高
- 数据处理链路非常长
- 无法支持实时/近实时的数据,只能处理T+1的数据
为了满足大数据实时化需求,从传统数仓上演进出Lambda架构,其思路,在传统离线数仓的基础上再加上一个处理实时数据的层,然后将离线数仓和实时链路产生的数据在Serving层进行Merge,以此实现对离线产生的数据和实时产生的数据进行查询。
典型架构如下:
Lambda架构的问题:
- 一致性难题:2套语义、2套逻辑、2份数据
- 成本高问题:环环相扣、多套系统、运维复杂
- 开发周期长:错误难以诊断和修订、补数周期长
- 业务不敏捷:无法自助实时分析、分析到服务转化周期长
总结:传统大数据开发链路,数据冗余、成本高、开发周期长。
1.2. HSAP与Hologres
参考:《基于Hologres和Flink的实时数据分析方案》
1.2.1. 阿里的HSAP:服务分析一体化方案
基于上述背景,阿里提出了HSAP(Hybrid Serving and Analytical Processing)理念,目标做到服务分析一体化,它既能支持很高QPS场景的查询写入,又能将复杂的分析场景在一套体系里面完成。
1、统一存储:同时存储实时数据和离线数据
2、统一接口:在统一个接口下(比如SQL),支持高QPS的查询、支持复杂的分析以及联邦查询和分析
3、统一数据服务:系统能够直接对接前端应用,例如报表和在线服务等,不需要再额外的导入导出就能即席分析
1.2.2. 基于HSAP的实现:Hologres
基于HSAP的设计理念,诞生了Hologres。
Hologres:Better OLAP+ Better Serving +Cost Reduced
Hologres是一款实时HSAP产品,隶属阿里自研大数据品牌MaxCompute,兼容 PostgreSQL 生态、支持MaxCompute数据直接查询,支持实时写入实时查询,实时离线联邦分析,低成本、高时效、快速构筑企业实时数据仓库(Real-Time Data Warehouse)。具备如下优势:
说明 |
|
分析服务一体化 |
|
以实时为中心设计 |
|
计算存储分离 |
|
丰富生态 |
|
1.2.3. 基于HSAP的架构诉求
根据对传统数仓的痛点,阿里对精细化运营平台提出了如下诉求:架构简化、成本优化、数据统一、学习门槛低、适应业务敏捷、自助式分析趋势,如下:
即将原有复杂的架构简化为以HSAP核心思想的数仓架构。