实时数仓入门训练营:基于Hologres的实时数仓新架构-阿里云开发者社区

开发者社区> 阿里云实时计算Flink> 正文
登录阅读全文

实时数仓入门训练营:基于Hologres的实时数仓新架构

简介: 《实时数仓入门训练营》由阿里云研究员王峰、阿里云高级产品专家刘一鸣等实时计算Flink版和 Hologres 的多名技术/产品一线专家齐上阵,合力搭建此次训练营的课程体系,精心打磨课程内容,直击当下同学们所遇到的痛点问题。由浅入深全方位解析实时数仓的架构、场景、以及实操应用,7 门精品课程帮助你 5 天时间从小白成长为大牛!

本文整理自直播《基于Hologres的实时数仓新架构》
视频链接:https://developer.aliyun.com/learning/course/807/detail/13890

典型业务场景列举

提到实时数仓,我们可以看一下数据业务典型的应用场景。

图片 1.png

如上图所示,第一类场景是实时大屏。如今一般来说,不管是做to C还是to B的业务,或者说给上司看,都喜欢做一个业务大盘,来展现整个业务的运行情况。

第二类场景是BI报表,这类业务是从传统的离线BI报表产生的,只不过随着实时数据、实时业务的需求越来越旺盛,所以实时BI报表的需求也越来越多。

第三类场景是用户画像,不管是做金融还是做推荐,都是做千人千面,希望能够通过历史数据、用户行为数据得到用户的兴趣,来给用户提供更好的服务。

第四类场景是预警监控,或者说是流量监控。不管是做APP的还是做服务器端的监控,最终都是把数据收集上来,以这样大盘的形式进行展现。最终可以在这些预警指标进行报警,来保证监控业务的稳定性。

数据业务无论是离线还是实时,大致可以分为以上这么四类。

传统数据仓库数据处理流程

接下来我们看一下传统离线数仓是怎么样的一个处理流程。

图片 2.png

上方是一个典型的传统离线数仓的数据处理链路。

首先,从业务系统CRM、ERP或者其他数据源把这些业务数据收集上来,然后经过离线数仓的ETL,然后对数据的话进行数据清洗、数据加工。在这个过程中涉及数据建模、数据分层,最终会把加工后的数据,或者是最终要产生BI报表的数据,通过BI工具或者写到数据库里面,推到一个在线系统里面去,最后提供给用户进行访问,这些用户可能包括产品的用户、运营同学或老板。

用户希望能够从这样的数据里面看到,比如整个产品的售卖情况,或者业绩的增长趋势,系统的一些指标等,这就是一个比较典型的离线数仓的处理流程。

批量数据分析流程有以下几个特点:

  • T+1数据接入
    多种数据源接入
  • 定时数据开发与应用
    1)数据提取/数据转换/数据加载
    2)ODS数据处理
    3)DWD标准数据场景
    4)MDM元数据
    5)数据集市应用
  • 核心痛点
    1)ETL计算/存储/时间成本过高
    2)数据处理链路过长
    3)无法支持实时/近实时数据分析

Lambda:割裂的架构,需要变革

为了解决传统数仓的问题,出现了一些新的解决思路。

图片 3.png

首先在2011年之后兴起了Lambda架构,如上图所示。

Lambda的大致思路还是以传统的离线数仓为主,然后引入了实时数据的处理链路。T+1数据还是走传统离线数仓链路,然后再加上一个实时的数据链路,再把这些实时数据和离线数据汇总到一起,然后再通过一个Merge层提供数据服务,对外提供的服务可能是点查询,也可能是做复杂分析,还有可能是做联邦查询。然后在这上面去加数据应用,比如上文提到的BI报表,实时大屏,用户画像等。

从架构的名称Lambda就能够看出来,其实它是在传统离线数仓基础上加了实时,解决传统离线数仓的问题。但其实整个Lambda架构也有一些问题,主要存在的问题是架构复杂、数据同步难、资源消耗大、数据孤岛、人才培养难、开发成本高、不敏捷。

比如,Lambda架构并没有从源头上解决传统离线数仓的问题,而是在传统离线数仓上加了一条链路,这会让整个系统变得更加复杂。

在架构复杂的基础上,数据可能会存两份或者存多份,实时链路和离线链路数据不统一。除此之外,整个架构维护起来也是非常复杂的,并且开发成本比较高。比如说离线链路用Spark或者Hive,实时用Flink,但其实这些SQL是不太一样的。还有元数据如何管理,数据如何治理,再加上提供服务的时候,Merge层可以用HBase、Redis这样的系统去做,这些API其实都是非常复杂的。对一个小企业,做这种数据开发或者说做这种数据平台,资源是有限的,学习成本非常高的。经常发生的情况是,小公司刚把一批同学培养起来能够熟悉这些系统,然后就被其他公司挖走了,因此人才成本也非常高。

阿里巴巴的整个数据业务也是沿着这条路走过来的,我们思考有没有什么方法来简化这个架构,下面来看一下。

首先一个简单的思路,就是能不能把离线数据和实时数据进行统一。我们首先做的事情是实时/离线一体化,把实时ETL和离线ETL进行统一,整个数据模型进行统一。

图片 4.png

在实时/离线一体化的基础上,分析部分是偏离线的,服务部分是偏在线的,我们思考能否把这两部分也做一个统一,让一份数据既服务于离线又服务于在线。我们把这样的架构叫做分析服务一体化,分析相当于离线分析,服务是提供在线服务。如果真能做到一体化的话,相当于是由传统的OLAP变成了分析服务一体化架构。

思路有了,接下来我们看一下怎么去做这个事情。

阿里业务场景原架构

阿里巴巴原来的业务也是由传统Lambda架构走过来的,下面介绍阿里巴巴一个业务场景:搜索推荐场景。

图片 5.png

如上图所示,最早的时候这个架构就是为了解决实时推荐。大家都清楚阿里巴巴最主要的是电商业务,电商业务以淘宝为核心,打开淘宝会给用户推荐很多内容,其实这些推荐的内容都是一些行为事件,包括在滚屏看到的那些内容都是一条条事件。这些事件会实时写到后台服务里面,然后经过Flink做实时ETL,做实时的模型训练,或者做数据采样,会把这些数据写到HBase或Cassandra里面。

通过在HBase里面做实时的模型训练,再把这些模型推到搜索引擎或者在线服务里面,这样的话就能够完成实时推荐的链路闭环,能够提供点查询的数据服务。

那么我们想对已经存在的数据样本或者数据特征进行分析怎么办?我们引入列式查询的产品,比如ClickHouse或者Druid做分析,然后去接一些报表。如果还需要做数据的离线归档怎么办?可以通过MaxComputer或者Hive去做离线归档。有了实时数据和离线数据,那么就要去做离线/实时的联邦分析,又引入Drill和Presto。我们都清楚,像Drill和Presto这样的系统的话,它整个的性能或者QPS承载的并发非常差的,如果想提高并发怎么办?我们引入了Redis和MySQL去做这样的一个Cache,然后通过非常短周期的调度,从 Drill和Presto去做查询,再把结果写到Redis或MySQL里面去,然后整个数据去对接API服务或者对接报表等。

上方就是阿里巴巴搜索推荐场景原来的业务架构,是一个典型的Lambda架构。绝大部分公司从业务出发的话,也是这么一个架构。

下一代实时数仓如何选型

按照上文的思路,如果我们想去简化这样的架构,把实时/离线一体化,再把分析服务一体化,我们需要一个新的实时数仓,应该怎么去做,考虑哪些问题?

图片 6.png

首先,必须支持实时写入,传统离线T+1肯定是不可以的。除此之外,能够支持非常实时的计算。

第二是能够把实时数据和离线数据存放在一起,做到实时/离线数据一体化,减少数据的移动。

第三是希望平台跟上层的业务能够解耦,意味着平台必须具备一定的通用性,而不是一个定制的产品。

第四是对于上层业务使用的API,我们希望能够拥抱开源生态,并且希望整个系统或者产品是一种云原生的架构,便于云上用户使用。

为了解决上述问题,我们从已有的一些开源产品里面找找灵感,看看它们现在是怎么去做的,每个产品解决哪些问题。

图片 7.png

如上所示,首先一大类是数据库产品,如MySQL、PostgreSQL等,它们比较典型的是支持事务,事务最重要的是支持ACID,做到读写一致性,保证数据的一致性。但是它们有个缺点,就是Scalability往往很难做到PB级别,同时不能做非常复杂的Query分析。

第二类是现在面向于分析加速或者OLAP这样的系统,比较典型有Presto,ClickHouse,Hive等,这类的特点是大规模数据扫描、过滤、汇总,语义层,分布式,列式存储,面向分析师。

第三类是Serving场景,提供高并发,支持简单快速的查询,比如Cassandra、HBase、Redis等,能够提供非常高的性能。

目前有一种趋势是很多产品在做HTAP,就是把Transaction和Analytics融合,相当于在一个产品里满足这两部分能力,目前有很多产品在一定程度上都能做到,其中有一些隔离性或者数据一致性的问题,但是基本是可解的。这类场景的话往往是Transaction,以TP为主业务基础,然后在TP数据的基础上做一定的分析。针对这种场景,我们对读写一致性没有很高的要求,只要做到最终一致性就好了,更多的是要求能够支持非常高并发的查询和分析。把这两类场景结合到一起的话,我们叫做Hybrid Serving/Analytics Processing(HSAP)。

目前在市场上并没有这样一类产品,我们希望做出这样的产品来解决分析服务一体化。有了架构理念,下面我们看一下如何实现。

新一代技术理念HSAP:分析、服务一体化

Hybrid Serving/Analytical Processing

图片 8.png

我们首先想到是做统一存储,把离线数据和实时数据放到一起做规划处理,然后对统一存储的数据提供统一的数据服务,上层的数据应用如数据报告、数据看板、在线应用等,都直接通过在线的数据服务,提供统一查询出口,就可以解决上文的问题。

有了这样的思路后,我们研发了一个产品——Hologres。

简单介绍一下Hologres这个产品的名字是怎么来的,它是由两个单词拼成的,一个是Holographic,另一个是Postgres。

图片 9.png

Postgres代表PostgresSQL的生态,Holographic来源于物理学。

我们知道,黑洞连光都能够吸进去,但是我们在地球上并没有被黑洞吸进去,是因为我们离这个黑洞足够远,这是否就意味着有这一个临界点,这个临界点之内的都会被黑洞吸进去,临界点之外的能够逃出黑洞引力。

由这个临界点组成的一个面,被证明是个球面,我们把它叫做世界面。有科学家证明黑洞里面的所有信息在世界面上都有投影,意味世界面上包含黑洞的全部信息,也就我们经常提到的3D全息投影技术,全息的英文单词就是Holographic。

Hologres想做的事情是通过产品对数据黑洞做全息展示,全部信息在Hologre能够提供服务的能力,并且数据存在Hologres的数据黑洞里面。

阿里搜索推荐:从N到1,Hologres简化大数据架构

图片 10.png

上图为使用Hologres前后的架构对比图,使用了Hologres之后整个架构就变得非常简单了。

首先,Flink实时写入到Hologres里面,也可以通过Hologres做维表关联。同时,通过实时数据可以归档到MaxCompute里面。这样的架构对于数据服务来说非常简单,离线分析走MaxCompute,数据的点查询、离线加速、联邦分析或交互式分析等可以走Hologres。

整个阿里巴巴的业务架构由左边演变成右边,带来的收益是业务敏捷响应,数据自助分析,避免数据割裂,赋能数据服务,简化运维管理。

下面我们来简单看一下Hologres到底是个什么样的产品。

  • Hologres = Better OLAP + Better Serving + Cost Reduced

Hologres基于HSAP理念,云原生分布式分析引擎,支持对PB级数据进行高并发、低延时的分析,支持实时数仓,大数据交互式分析等场景。

图片 11.png

Hologres的特点是提供分析服务一体化,如点查询景,类HBase、Redis场景。OLAP场景能够提供PB级别复杂查询,毫秒级交互式分析。Hologres以实时为中心设计理念,查询快,实时数据写入快,并且能够支持实时数据、离线数据的快速导入。整个架构是存储计算分离的架构,在云上面跟MaxCompute无缝打通,并且从Hologres这个名字就能看出来,Hologres兼容PG语法,支持PG开发运维工具。

图片 12.png

如上图所示,Hologres是典型的存储计算分离架构,整个数据是在一个共享存储里面,这个共享存储可以是阿里云内部的存储产品盘古,也可以是数据湖的产品,比如OSS、Hive或者MaxCompute这样的存储。

计算节点都是在容器里面,提供一个Worker,还有一个角色是Frontend,相当于是能够接收用户的SQL。接收完SQL以后进行SQL解析生成AST,然后通过优化器把AST转化成分布式的执行计划,通过Coordinator发给这些Worker去做,每个Worker里面有自己的调度系统,有数据的分片管理,同时还有Cache,然后能够分步式执行。整个计算节点是MPP架构,然后是存储计算分离的。

存储计算分离

下面我们看一下存储计算分离能带来的好处。

图片 13.png

一般来说,现在的大数据产品或者数据库产品,存储计算就几种关系。

第一类是传统Oracle的RAC,它们是Shared Disk/Storage的架构,相当于有单独的计算节点,每个计算节点有自己的本地盘,有自己的内存,然后还有一个存储集群。存储集群相当于是一个管理的磁盘阵列,这些盘对这些节点都是开放的,这些节点能够直接访问存储的数据。

第二类架构是Shared Nothing,开源系统用得比较多的像Clickhouse或者Druid,特点是存储节点不共享。存储节点和计算节点绑定,相当于每个计算节点有自己的一块存储。如果其他的计算节点想读另外节点的存储,必须通过网络请求到计算节点,然后通过计算节点再把这个数据给另外的节点。

这个架构带来的问题是很容易产生数据热点,比如Node2,假如它数据特别多,这个数据也没办法存到其他节点上,这样的架构往往会使整个Scalability受限。

第三类是云原生这种完全存储计算分离的架构,计算节点部署在容器里面或者是单独的服务器ECS,存储是以共享的存储服务或者DFS的方式进行访问。整个架构非常清晰,对于计算节点来说,看到的就是一个非常大的分布式文件系统,计算节点只需要关心到底要访问哪个文件,而不需要知道这个文件到底在哪存的,容错怎么去做。

Hologres就是采用这样的计算存储分离架构,架构带来的好处是可以按需购买,在云上面需要多少计算就买多少计算资源,需要多少存储就买多少存储资源。

流批统一的存储

图片 14.png

有了分析服务一体化的架构,就能把流计算和批计算的结果进行统一。

以前流计算产生的结果写到流计算存储,离线计算的结果写到离线计算存储,引入了Hologres以后,相当于不管是离线计算还是流计算,都写到Hologres里面来,数据的一致性能够得以保证。

图片 15.png

Hologres支持点查询、分析型查询,主要是因为Hologres的存储引擎支持两种文件格式,一种是行存,一种列存。顾名思义,行存就是同一行数据的多个列是连续存放在一起的。如图所示,列存就是相同列存放在一起,带来的好处就是在分析的时候能够提高Cache命中率,并且可以用向量计算做一些加速查询。

整个Hologres存储引擎的架构是类似于LSM-tree架构,数据先写MemTable,写满以后Flush成文件,小文件太多的话合并成大文件然后做管理。

Hologres:为分析服务一体化设计的实时数仓

Hologres的宗旨是做分析服务一体化的实时数仓,简单总结有以下三方面的特点:

  • 云原生:存储计算分离架构
  1. 计算存储资源弹性扩展,按需使用;
  2. 低成本、高可用、高可靠;
  3. 与MaxCompute底层打通,透明加速,实时离线一体。
  • 统一存储:流批统一的存储
  1. 行列共存,列存对分析友好,行存对点查快速;
  2. 高效数据分片、分段、压缩、索引;
  3. LSM-like写友好数据结构,高吞吐数据写入,支持更新,写入即可见。
  • 极致性能:C++ Native执行,引擎+优化器
  1. 向量化、全异步等执行引擎优化;
  2. 轻量级用户态线程调度,同时支持多种查询负载(高并发、复杂统计);
  3. 公平调度算法(CFS),高并发充分利用计算资源。

交互式分析典型应用场景

由于Hologres架构非常简单,因此典型的应用场景也就非常简单,大致可以分为以下三类。

图片 16.png

第一类是替代传统的离线数据做加速查询,可以把传统的离线数据导到Hologres里面来,这样的话就能够变得很快。

第二类是做实时数仓,跟Flink进行配合,把实时的ETL实时数据加工写到Hologres里面,然后在Hologres做实时的数据分析。

第三类是把实时离线一体化,能够把实时/离线数据都写到Hologres,甚至可以通Hologres做联邦查询,直接对其他系统的数据进行查询。

下面举几个业务场景的例子。

阿里客户体验系统(CCO)实时数仓改造

2020双十一活动期间,实时计算 Flink 版 + Hologres为阿里客户体验系统(CCO)构建了集实时化、自动化、系统化于一体的用户体验实时数仓。

以前的阿里客户体验系统(CCO)也是典型的Lambda架构,存储层有MySQL,HBase等,只用Holo去存这种Server数据。

架构升级主要有以下几个业务难点:
1)数据复杂度高,加购、下单、支付、售后全渠道,90%实时数据;
2)数据量大,日志(千万/秒),交易(百万/秒),咨询(万/秒);
3)场景丰富,实时监控大屏,实时交互式分析数据产品,ToC线上应用。

升级后的架构如下所示。

图片 17.png


技术架构:
DataHub + 实时计算 Flink 版 + Hologres + MaxCompute

带来收益:
1)整体硬件资源成本下降30+%;
2)高吞吐实时写入:支持了行存千万/秒,列存几十万/秒写入要求;
3)简化实时链路:面向公共层的开发和复用;
4)统一服务:同时支撑了多维分析和高QPS服务化查询场景;
5)MC-Hologres查询服务:2020双11当天查询latency平均142ms,99.99% 的查询在200ms以内;
6)支撑200+实时数据大屏搭建,为近300+小二提供稳定的数据查询服务。

菜鸟:智能物流

菜鸟智能物流分析引擎是基于搜索架构建设的物流查询平台,日均处理包裹事件几十亿,承载了菜鸟物流数据的大部分处理任务。

需求诉求:
1)HBase的架构下维表数据导入耗时长、资源浪 费严重、成本高;
2)HBase不能同时满足PointQuery和OLAP分析,数据导入导出引发数据孤岛、数据同步负担、冗余存储、运维成本和数据不一致等问题。

图片 18.png

升级后的架构

升级架构后的客户收益:
1)整体硬件资源成本下降60%+;
2)更快的全链路处理速度(2亿记录端到端3分钟);
3)一个系统,满KV和OLAP两个场景,没有数据冗余;
4)解决大维表实时SQL查询需求;
5)强Schema,有效避免潜在错误,节省时间。

友盟+:PB级用户行为交互式分析

友盟+是国内最大的移动应用统计服务商,其统计分析产品U-App&U-Mini & U-Web为开发者提供基本报表统计及自定义用户行为分析服务,支持精细化运营。

业务痛点:
1)业务数据量大,年新增行为数据10PB级,个性化、自定义地交互式用户行为分析强需求;
2)基于MaxCompute提供异步离线的adhoc分析和优化、以及自研引擎开发尝试均无法满足业务需求;
3)导出到MySQL/Hbase方案的二次开发和数据导出链路长、成本高、操作不灵活。

图片 19.png

升级后的架构

客户收益:
1)PB级数据毫秒级查询响应;
2)与MaxCompute深度集成,能够利用Range Cluster索引加速,实时离线联邦查询,同时也可以实现冷热数据混合查询,有利于成本性能平衡;
3)计算资源弹性伸缩,可兼顾扩展性、稳定性、性能、成本。

实时推荐、API as service

实时推荐(特征查询、实时指标计算、 向量检索召回),提高广告留存率, 实时计算 Flink 版+PAI+Hologres with Proxima。

图片 20.png

客户收益:
1)支持2000万日活用户快速向量检索,千万级u2u,i2i 均可以20ms返回 ;
2)通过SQL描述业务逻辑,无需手工编码(select a, b, proxima_distance(c) as distance from table order by distance desc limit k;);
3)加工逻辑简化,无需额外集群(Redis)。

活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动:
99元试用实时计算Flink版(包年包月、10CU)即有机会获得 Flink 独家定制T恤;另包3个月及以上还有85折优惠!
了解活动详情:https://www.aliyun.com/product/bigdata/sc

image.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

一套基于Apache Flink构建的一站式、高性能实时大数据处理平台,广泛适用于流式数据处理、离线数据处理、DataLake计算等场景。

官方博客
最新文章
相关文章
链接