实时数仓入门训练营:实时数仓助力互联网实时决策和精准营销

Posted 阿里云开发者

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了实时数仓入门训练营:实时数仓助力互联网实时决策和精准营销相关的知识,希望对你有一定的参考价值。

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

本文整理自直播《实时数仓助力互联网实时决策和精准营销-合一》
视频链接:https://developer.aliyun.com/learning/course/807/detail/13886

近年来,实时数仓是互联网的热门话题,主要应用场景主要是在实时决策和营销等领域,这些领域对数据分析的精细度、实时性都有很高的要求,是走在技术前沿的领域。

业务在线化、运营精细化推动数仓实时化、交互化

图片 1.png

我们先看一下过去几年数据分析发展的一些趋势,如上图所示。

可以看到,数据分析基本的趋势是从批处理向交互式分析、流计算的方向演进。在10年前,大数据更多的是处理规模的问题,通过并行计算的技术处理海量的数据,那个时候我们更多的是在做数据的清洗,数据模型的设计,对分析的需求并不太多。

如今,我们的大数据团队基本上都变成了数据分析的团队,对数据模型的沉淀,对交互式分析的支持能力,对查询响应延迟的支持效率,对QPS的要求都会越来越多。数据分析也并不只是数据存下来再分析,也有很多计算前置,先有逻辑后有计算的场景。比如在双11的时候,在多少秒有多少成交量,这样一个典型的场景就不是先有交易数据后有计算量的问题,一定是随着交易而发生实时计算结果的过程。

因此,交互式分析和流计算几乎是一个并行前进的过程,这两种新的场景对背后技术有很多不一样的要求。批处理更多的是讲究并行度,在交互式分析领域里边,我们开始有很多的预计算、内存计算、索引等技术,所以这个也是推动了整个大数据技术的演进。

总结来看,数据分析支撑着越来越多的在线业务,在线业务包括我们任何时候打开手机,手机屏幕里边推荐的产品、展示的广告,这些都是需要在几毫秒之内返回结果,靠数据智能推荐出来,如果不推荐的话点击率、转化率一定非常低。

因此,我们的数据业务在支撑越来越多的在线业务,在线业务对查询延迟、QPS、精细度都有非常高的要求,这也推动着数仓向实时化、交互化方向演进。

阿里巴巴典型实时数仓场景

图片 2.png

在阿里巴巴有很多数仓的使用场景,例如双11的实时GMV大屏。GMV只是一个结论性的数字,实际上对数据分析师而言,这个工作只是刚刚开始。我们要向下分析,是什么产品,在什么渠道,针对什么样的人群,以什么样的促销手段,达成这样的转化效果,有哪些转化效果没有达成,等等一系列分析。这些分析其实非常的细粒度,是精细化分析的效果。

分析之后,就会对所有的商品、人群做一些标签化,通过标签化我们下一步可以去指导在线的应用去做推荐、分析、圈选等等,所以有很多数据中台的业务也会产生。

还有一类业务是偏监控类业务,订单突然抖动、增长,网络质量的抖动,视频直播的一些监控等,这些也是实时数仓典型的应用场景。

大数据实时数仓体系的“纷繁芜杂”

过去我们建设实时数仓的时候参考过很多公司,阿里巴巴也是走过很复杂的一条路线。

图片 3.png

上方是我画的架构图,第一次看的时候挺兴奋的,那个时候自己是个大数据架构师,能够画出这么多个箭头是很体现功力的一件事情。但当真正去做这样一个系统的时候,发现这个系统的开发效率、运维效率非常令人抓狂。

这套系统从左上角演化开始,消息从消息中间件收集,之后是一个离线加工的过程,那个时候我们还没有很多实时的技术,首先要先解决规模的问题。通过离线的加工,我们会把加工的结果集变成小的结果集,存到mysql和Redis,这是一个典型的加工服务二元化的体系。

通过把数据变成小数据之后,才能对外提供上层的应用,包括报表应用、推荐应用等。之后数据分析需要实时化,光靠这种“T+1”的离线加工不能够满足需求,数据越实时越有上下文,价值越大。这个时候就有很多计算前置的技术被采用,例如Flink。通过Flink直接消费Kafka里的事件,通过事件驱动的方式做计算,由于Flink是分布式的,因此可扩展性非常好,它可以通过计算前置,通过事件驱动的方式,可以把端到端的延迟做到极致。

然后我们会把结果集也存到一个介质里面,通过Flink加工的结果集是一个非常精简的结构,一般是以kv6结构为主,放在HBase、Cassandra这样的系统,这样的系统对上提供的大屏报表是最快的。比如说双11的大屏,绝对不能等成交几千万、几亿条记录之后再去做统计,否则查询性能一定无法满足。因此,我们一开始都会加工成如以每秒每个渠道为粒度的原始数据集,原始数据集在做大屏分析的时候,就可以从一个很大的数据集变成一个很小的数据集,性能达到极致。

现在我们看到有处理规模,有处理速度,这两者看起来表面上都满足一定需求,但其实成本也是不小的。如果想要计算足够地快,需要把计算前置,这样的话数据模型的灵活度就会减少,因为我们已经通过Flink把所有的数据汇聚成一个结果集了。

例如,如果有些业务逻辑一开始没有定义好,比如刚开始分析的是某三个维度的聚合,如果后续想分析第四个维度的聚合,由于提前没有计算好,因此无法进行分析,所以这里牺牲了灵活性。

此时就有一些相比HBase更灵活,又比Hive实时性更好的技术会被采用,例如ClickHouse、Druid。数据可以实时写入,写入之后也提供一定的交互式分析、自助式分析的能力。

我们会发现,数据处理将同一份数据分散在三个不同的介质,包括离线处理的介质,近实时处理的介质和全实时处理介质。三个介质往往需要三个团队来维护,三个团队随着时间发生人员的变动,数据加工逻辑一定会有多多少少的调整,造成的结果就是,我们会发现同一个指标通过三个不同渠道产生的计算结果不一致,这个事情几乎每个公司都会发生。

这还只是表面的问题,对于分析师来说更痛苦,他需要使用不同的数据,访问不同的系统,学习不同的接口,甚至是有不同的访问控制机制,这对分析师来说就非常不方便。因此,很多公司都要搭一套所谓的数据中台,通过中台来屏蔽底下物理引擎上的不同,这种情况下Presto、Drill这种联邦计算技术就会被采用。

联邦计算技术有着二十多年的发展历史,从最早期的数据信息系统集成到数据虚拟化,技术一直在发展。这个技术是一套数据不移动、计算移动的技术,听起来很美好,但是当真正在生产上使用的时候会发现,这套系统的查询体验是不可预期的,我们不知道通过系统查询下去数据是快还是慢,因为它把查询下压到不同的引擎,如果下压到Hive,就没那么快,要是下压到ClickHouse可能就比较快。所以这对一个分析师来说,他不知道这个系统的预期是什么,叫不可预期性。例如,以前打开报表可能用了5秒钟,另外一次可能用了5分钟,这种情况会让分析师不知道到5分钟的时候是正常还是不正常。如果跑在Hive上,就叫正常,如果跑在Drill上,就叫不正常。不可预期性也让这个系统很难进入生产的领域,所以这个时候我们不得以,还要是通过数据做一次汇聚,变成小的结果集去分析。
我们看到,整个链路实际上是由多个组件层层嵌套、层层依赖组成的,除了刚才提到的不同团队维护会造成数据口径不一致的情况,对数据维护的成本也会变得非常高。

经常遇到的情况有,我们看到报表上某个数字可能是不正确的,比如某天这个指标突然增长或下滑很多,这时没人能确认中间是数据质量出问题,还是加工逻辑出问题,或者是数据同步链路出错了,因为中间链路太长了。数据源头如果修改一个字段,重新补一个数据,那么每一个环节都要重跑,所以说这套架构如果是运行正常就没有问题,但是一旦数据质量有问题或者数据调度上出问题,环环依赖,这让整个运维成本变得非常高。

同时,懂这么多技术的人才难找且贵,经常发生的情况是一个公司辛苦培养出这样的人才,之后就被其他大厂挖走了,这样的人才从招聘到培养都非常困难。

以上是这套架构的现状。

今天大数据的复杂,让人想起60年代

上面这套架构让我想起60年代,那个时候数据库基本还没有诞生,70年代末期才诞生了关系型数据库。
60年代我们是怎么管理数据的状态?

图片 4.png

在60年代,每个程序员要自己写状态维护。有的人用文件系统,但是光用文件系统会非常离散,维护起来也非常难,因为数据之间是有关系的。这个时候还有一些网状结构的系统出现,通过一个文件可以跳到另外一个文件去,但是网络结构管理起来也相对比较复杂,因为循环、嵌套等等。除此之外还有层级结构,也是一种数据类型的描述方式。
所以可以看到,60年代的程序员自己管理数据状态,其实成本很高。

到了80年代,我们基本上不会再这么干了,因为我们知道所有的状态尽量都存在数据库里,也是因为关系型数据库让这件事情变得简单了很多。尽管我们有很多种关系型数据库,但基本都是以SQL接口为主,这让我们整个数据的存储、查询、管理等成本急剧下降。

这件事情在过去20年又发生了一些不少变化,从大数据的时代到NoSQL到NewSQL,诞生了各种各样的技术,如Hadoop、Spark、Redis等,这让数据领域蓬勃发展。

但是我总觉得这个地方隐含了一些问题,可能未来不一定是这样。目前大数据发展蓬勃但不统一,所以我在想未来是不是可以把大数据技术相对收拢一些,用一种更有描述性的方式来解决问题,而不是让每个程序员都去学习不同的组件,学习几十种不同的接口,配置上千个参数。为了提高开发效率,或许在未来我们有必要将这些技术进一步收拢简化。

实时数仓核心需求:时效性

我们回过头看一看,脱离这些技术组件,实时数仓到底有什么业务上的需求,针对这些业务需求可以要求什么样的数据架构。

图片 5.png

什么是实时?很多人认为实时分析就是从数据产生到能够被分析的时间足够短,其实这并不完全准确。我认为实时数仓分为两种实时,一种叫端到端的延迟短,另外一种实时也可以称为准时,就是当我们真正分析数据的时候,能够拿到有效的数据,并且能够得出结论,这就可以叫准时。

第一种实时是偏技术的概念,然而我们的业务一定需要这么低的延迟吗?

通常情况下,业务并不是每秒钟都在做决策,业务当我们打开报表,我们看数那一刻,这一刻我们关心的数据可能是过去的一天,上一个小时,5分钟之前,或者是一秒钟之前的。但经验告诉我们,99%的数据分析如果能做到5分钟的延迟,基本能满足业务上的数据分析需求。在分析场景是这样的,如果是在线服务的场景,这肯定是不够的。

所以大多数公司里也许并不要求那么实时,因为这背后的成本是不一样的。

因为一旦要的是端到端的延迟,就一定需要很多计算前置的业务逻辑,不能等数据都存下来之后再去查询,因为要求延迟非常地短,我们必须要把很多数据提前汇聚、加工、拉宽,才能让数据分析的时候计算量足够小,才可以做到延迟足够地短。

所以如果追求的是端到端的延迟,要做很多计算前置的工作。刚才我们提到,如果计算全部前置,灵活性会有损失,所以这件事是有成本的。相对来说,如果追求的是一个准时的系统,那可以把一部分的计算逻辑后置,换取的是一个灵活分析的场景。

例如双11的时候只是为了追求延时,那我们只会把最后一个GMV存下来,这是一种场景,这事就结束了。但这件事不符合公司要求,公司一定要出详细的报告,需要知道什么时候卖的好,什么时候卖的不好。所以这种情况下,全部提前预计算的方式肯定是不适合的,需要有更多的明细数据能够存下来,我们可以做更多的交互式分析、关联分析、探索式分析,所以说这两套系统背后的需求是不一样的。

相对来说,我觉得绝大部分公司要的其实是个准时的系统,它需要具备计算后置的能力,具备实时写入、写入即可分析的能力,哪怕分析的效率不是那么高,还要具备灵活分析的能力。

实时数仓核心需求:数据质量

数据质量是实时数仓建设里很重要的一环,刚才提到如果不追求数据质量,只追求时效性的话,一开始通过计算前置加工成一个结果集,这个结果集告诉我们GMV达到了100亿,绝大部分老板是不敢相信的,因为这100亿背后可能是数据质量出问题,也可能是计算逻辑写错了,所以说系统要能够保证数据质量。

数据质量分两个方面,一个是多久发现质量问题,另一个是多久修正质量问题,这两个解决思路是不太一样的。

图片 6.png

如果想发现数据质量问题,就需要让计算过程的状态能够被持久化,就希望数据仓库引擎里边能够有明细,以及汇总数据能够落盘,这些数据可以被检查。这样的话,当老板问指标为什么增长这么多,到底是哪个客户带来的增长,你就可以通过这些明细的数据去检查原因,分析数据时如果发现错了能否修正,这也是很关键的问题。

有些系统只能看不能改,这是很多大数据系统的通病。大数据系统在处理规模性问题非常好,但是处理小的问题,如更正数据就特别地难。因为它每次更正都是需要很大的数据块为单位,或者是没有主键,将整个文件替换,所以更新起来确实比较难。

发现问题和修正问题相比,我更希望一个系统能够具备修正数据问题的能力。

修正问题就是在发现数据质量的时候,可以简单地更新数据的状态,比如说单行数据的更新,单列数据的更新,批量的更新等,有很简单的方式做数据的刷新。数据刷新的状态这个事情经常会发生,例如上游数据质量有问题,加工逻辑写错了等,都需要做数据刷新的工作。

其次,我也希望数据修正的时候尽量能够只修正一个系统就好。

刚才我们看到,一份数据的数据源出错了之后,它要在后端4~5个环节反复流转,这意味着一旦数据出错了之后,在4~5个环节里面都要做数据修正的工作,这里面的数据存在大量的冗余和不一致,要修正的话每个环节都要修正,这也是特别复杂的一件事情。所以我们希望数仓的状态尽量只存一个地方,这样话我只修正一处就可以了。

实时数仓核心需求:成本优化

成本分为三部分,分别是开发成本、运维成本和人力成本。

图片 7.png

开发成本表示我们想要业务需求多久能上线。做同样一件事,是需要一个团队还是一个人,是需要一周还是一天,所以开发成本是很多公司很关心的一件事情,如果开发不出来,就意味着很多业务的需求是被压制或者是抑制的。
我们希望IT同学不需要再很疲惫地响应业务团队取数的要求。经常发生的情况是,等数据真正加工完之后,业务团队反馈说数据加工得不对,等IT同学好不容易修正对了之后,业务团队表示活动结束了,想看的数据已经没有意义了。
因此,好的数仓系统一定是技术和业务解耦,技术团队保障数据平台运行的稳定可靠,而业务团队的取数尽量要自助化,自己通过拖拽的方式生成感兴趣的报表,这是我们认为良好的系统。只有通过这样的方式来降低开发的门槛,让更多的人自己去取数,实现数据资产的可复用,业务自助开发。

同时,为了加快开发效率,链路一定要足够短。

就像我们一开始看见的架构图,如果中间四五个环节,任何环节都要配置调度,任何一个环节出错了之后都要监控,那么开发效率上一定是非常沉重的。如果开发链路足够短,数据减少传递,开发效率也会高很多。所以我们要提高开发效率,希望能够做到技术和业务解耦,也能够做到数据链路足够的短。

运维成本简单翻译过来就是说过去集群太多,花的钱太多。

我们要开四五套集群,反复调度与监控。因此,如果未来有机会重新选型新的数仓,应该考虑如何降低成本,用更少的集群,更少的运维来提供更多的能力,包括一些弹性的能力。公司在月底或者促销活动这种对计算量分析量有要求的时候,可以做一些弹性的扩缩容,适应不同的计算负载变化,这也是非常重要的一个能力,可以节省公司的运维成本。

第三个成本就是人力成本,包括招聘成本和学习成本。

大数据是一个相对比较复杂的系统,做过Hadoop技术的应该知道,几千个参数,十几个组件各自互相依赖,任何节点宕掉都可能会引起其他系统的各种各样的问题。

其实学习和运维成本都是比较高的,刚才提到数据库的例子是很好的一个范本。降低开发的成本可以用描述性语言,也就是SQL的方式,通过SQL的方式可以把整个开发门槛急剧降低。绝大部分同学在本科的时候都已经学过数据库这样的课程,所以用SQL的方式比那些需要学习API,需要学习SDK的方式更有效率。这样的话,人才在市场上也更容易找到,也让公司把更多的精力从底层平台运维,向上层数据价值挖掘上转变。

通过标准SQL跟其他系统对接,不管是开发工具还是BI展示工具,都会更加地方便。

以上是从业务需求推导出来的一些技术需求。

第一代实时数仓:数据库阶段

接下来我们看一下,过去的一些实时数仓开发技术是否能够满足以上需求。

图片 8.png

第一代实时数仓技术我们叫数据库阶段,是典型的Lamda阶段。

这个架构基本是有一个业务需求,就有一套数据链路,数据链路分为实时和离线两部分。数据收集到消息中间件,一部分走实时,加工结果集,存到MySQL/HBase。另一部分离线通过Hive/Flink,加工结果集,也是存到MySQL/HBase,都是把大数据变成小数据,然后对上提供服务。

这套架构已经有很多人分析过问题了,两套架构互相数据冗余,产生数据不一致,这是比较直接的,但这里更重要的问题是烟囱式的开发。

当业务端提出一个新需求的时候,程序员就要去找这个数据来自于哪个数据源,它应该跟哪些第三方数据源做关联,要做怎么样的汇聚加工,然后生成一个结果集,最后我们会发现这个结果集或者是生成的数百张报表端,其中80%的部分互相有很大的冗余部分。有的业务部门看的是这三个指标,另外一个部门看的是其中两个指标,中间可能只是换了一个字段,这是经常发生的状况。原始数据都是一样的,但是统计的字段你多一个我少一个,但是我们就要重新端到端去开发,严重降低开发效率。运维上也很难,开发了几千张报表,我们不知道这些报表是否有人在使用,我们也不敢轻易下线。

除此之外,一旦任何一个数据源的字段增加或减少,都要去调整、运维、修改,这件事几乎是一个灾难。如果是一个人开发那么问题不大,我们见过很多开发团队,四五个同学每天频繁写脚本,然后这些人员有人离职,有人入职,最后谁也不敢删老同事的代码,最后就变成调度几千个脚本,天天在查纠错,可能是脚本的错,也可能是数据质量的错,这件事让运维成本变得非常的高。

因此,这种烟囱式的开发属于上手很快,但在实际运维上是不可持续的一件事情。我们解决烟囱式问题的方式是把共享的部分沉淀下来,这就进入实时数仓的第二个阶段:传统数仓阶段。

第二代实时数仓:传统数仓阶段

数据仓库是很好的概念,就是把那些可被复用的计算指标沉淀出来,因此数仓里面要分层,有DWD、DWS、ADS三层。通过层层的沉淀,把共享的部分向下沉,把差异的部分向上移,减少重复建设的问题,这也是数仓经过几十年沉淀出来的一套基本的方法论。

图片 9.png

这种方式通过Kafka驱动Flink,Flink在计算过程中做一些维表的关联。维表关联基本上是把Flink关联到一个KeyValue系统上做维表的拉宽,拉宽之后还会把这个结果重新写到Kafka另外一个Topic里面,然后做二次的聚合、汇总,生成一些DWS或者ADS,最后把结果存在OLAP/HBase系统。

为什么这地方结果存储一部分是OLAP系统,一部是HBase系统?

OLAP系统是一个面向数仓分层非常好的表结构,但是这类系统没办法支撑在线的应用。在线应用要求QPS每秒上万的查询,查询模式相对比较简单,但对QPS要求非常高,绝大部分数仓系统是很难满足这个要求,所以这个时候不得不把系统存在HBase,提供毫秒级响应的能力。

这个系统解决了前面烟囱式的问题,但我们看到OLAP/HBase系统里面仍然存在数据冗余。同样一份数据,描述同样一份逻辑,在数仓和KeyValue系统里边仍有冗余。公司业务团队会根据SLA的不同进行选择,如果对延迟非常敏感,就把结果放在HBase里面,如果对延迟不敏感,但对查询灵活性有要求,会放在 OLAP里面。

另一方面, HBase系统在开发上还是不太方便,因为这是一套结果比较简单的KeyValue系统,所有的查询都需要基于Key去访问,然后Value部分是没有Scheme的。一旦业务单位发现数据质量有问题的时候,没有办法很简单地检查看某一个行、某一列的值,不能随时去协调更新它,这是一个Schema Free系统的一些局限,元数据管理起比较不方便。

第三代实时数仓:分析服务融合阶段

实时数仓第三阶段是分析服务融合阶段,这个阶段在阿里内部已经实现,外部绝大部分的公司也在探索的道路。

图片 10.png

这个阶段跟之前的阶段有两个区别,一方面是在服务端的统一,不管是OLAP系统还是点查系统,通过一个系统统一,减少数据的割裂,减少接口的不一致,减少一份数据在不同系统之间来回传递,实现了统一存储的效果,这让我们数据状态的检查、修正都变得更简单。接口上统一到一个系统,安全、访问、控制、应用开发的接口可以一致化,在服务端做了一些优化。

另一方面数据加工链路也做了一定的优化,这里面没有Kafka了。其实有没有卡夫卡是一个可选项,因为有些系统具备了一定的事件驱动能力,比如Hologres,它具备内置的Binlog事件驱动能力,因此可以把Hologres当做一个Kafka来使用。通过Binlog搭配Flink实现了DWD、DWS、ADS层层实时汇聚,这也是一个非常好的能力。
通过这样一个架构,组件只剩下Flink和Hologres,中间没有其他的外部系统,依旧可以通过实时链路驱动起来,数据没有分裂,所有数据都存在数据库。

关键收益是开发链路变短了,让调错成本也变低。其次是数据的明细状态被存储,因为HBase很难存明细状态。如果服务系统里面存下明细之后,数据查错、修错的成本就变得非常低了。除此之外,组件变少,相应地运维成本也降低。

阿里双11实时业务实践

阿里双11就是通过上述方式去做,双11场景下的吞吐量几乎是世界最大的。

图片 11.png

可以看到,数据通过实时通道走消息中间件,首先一般是点击流数据,然后需要通过Flink做一些维表拉宽的操作。点击流里面记录了什么ID点击了什么样的SKU,这个时候要把SKU作为表达宽,把它翻译成是什么商品,什么类别,什么人群,通过什么渠道点击的。把这些维表拉宽之后,存在Hologres里边,Hologres在这里扮演实时数仓的角色,另外一部分数据会离线定时同步到离线数仓MaxCompute,MaxCompute扮演的是一个历史全局数据的概念。我们经常会统计消费者过去一段时间的消费行为变化,这部分数据的加工时效性要求不高,但是数据量非常大,是在MaxCompute里执行的。

在分析的时候,Hologres和MaxCompute通过联邦查询的方式关联在一起,所以并不需要把数据都放在一个地方,用户还是可以通过实时和离线做联邦查询的方式减少数据的冗余。

Apache Flink – 实时计算的行业事实标准

Apache Flink 已成为实时计算的行业事实标准,各个行业都在使用,阿里巴巴是这方面的领导者。开源技术背后都有一家成功的商业公司,Flink 背后这家商业公司正是阿里巴巴。

图片 12.png

实时计算的部分很简单,就是 Flink ,但是在仓库系统的选择上不太容易,因为选项非常的多,主要可以分为三类,分别是事务系统,分析系统和服务系统。

图片 13.png

事务系统就是产生数据的系统,它有很多业务系统,这个系统上不太容易直接做分析。因为直接分析的时候,负载很可能影响在线系统的稳定性,而且性能也无法保证,因为这些系统它是面向随机读写优化的,基本是以行存为主。

对于统计分析类的场景,IO开销非常大,它基本上是给DBA准备的,保证线上系统稳定性。所以我们做的第一件事就是事务系统和分析系统的分离,把这些数据先做一次同步,同步到分析系统里面去。

分析系统专门为分析做了很多优化,我们会采用列存、分布式、汇总、构造语义层等建模的方式,把分析的数据模型简化与丰富,然后提高数据分析的性能,这是面向分析师的系统。

另外一个系统叫Serving系统,过去主要是NoSQL,如今还有HBase、Cassandra、Redis,这类系统我也把它认为是一种类型的分析,也是取数,它只是取数相对比较简单,更多是通过主键进行取数。但是这类系统也是通过数据来驱动的场景,更多是支持在线应用,也有数据高吞吐、更新等能力。

可以看到,数据从源头产生之后,一般有两个出路,一个是进入分析系统,一个是进入服务系统支持在线应用。我们会发现数据其实在不同系统里产生了很多的割裂,之后就意味着数据的移动,数据的搬迁,数据的依赖,接口的不一致,此时我们开始想办法做创新。

图片 14.png

第一个创新是在服务系统和分析系统的边界处,我们思考一个系统是否既可以做分析又可以做服务,这个想法比较理想但在有些场景下确实也是适合的。

但是这样的系统也有一些限制,第一个限制是系统的底线要保证事务。事务是对计算能力开销非常大的一件事情,可以看到绝大部分分析系统不支持事务,因为事务要带来很多的锁,如果有分布式锁的话,开销就会变得更大,所以这类系统具备了一定能力,但也牺牲了一部分的性能,因此在高并发场景下并不太适合。

另一个限制是数据模型上的不适合,在TP上产生的表可能有几百张,但是分析师不愿意去看几百张的表,他更愿意把几百张的表汇聚成几张大的事实表和维度表,这样的方式更符合分析语义层的要求。

综上所述,这个系统很难做到数据模型上既能适合TP系统,又能适合AP系统,所以我觉得HTAP系统的局限性比较大。

另外一端的创新是,我们思考一个系统是否既可以支持分析的场景,查得足够灵活,又可以支持在线服务的场景,支持高并发,支持快速的查询,支持数据的可更新,这也是很重要一个场景。

如果用一个系统支持这两个场景的话,就会让我们数据迁移、数据开发的成本又降低了很多。

我们看到这两个创新系统里很多共性的部分,比如数据基本以只读为主,基本没有锁的要求,都需要数据被加工、抽象,可以看到这里定义的分析系统和服务系统的共性是非常大的,有机会做创新。

常见实时数仓架构选型参考

接下来我们看一下 Flink 和市面上常见其他的数仓技术组合做实时数仓,从各个维度进行性能分析。

图片 15.png

例如MySQL的系统,它提供很好的接口,MySQL开发起来比较方便,支持各种函数也多,但实际上它的可扩展性、数据的灵活性都会差很多。因为Flink加上MySQL就是把数据变成一个结果集来使用,缺少很多的中间状态,数据需要搬迁,修正成本非常高。

我们继续思考,MySQL扩展性不好,HBase扩展性非常好,它可以处理很大数据规模的问题。但HBase数据刷新的能力比较弱,想随时更新某一行/列的数据的话不太方便,模型灵活度不太好,因为它基本上就是KV系统,如果不是按照Key去查就很不方便。

接着是最近几年非常火的ClickHouse,它查询速度非常快,非常适合宽表的场景。数据分析如果只有宽表是可以,但是我们知道数据分析光靠一张宽表往往是不够的,需要很多表的关联、嵌套、窗口计算,所以ClickHouse对于这种场景就有些勉强。ClickHouse不支持标准的SQL,很多的函数、关联操作都不支持,特别在表关联的场景下,性能下降也是比较明显。除此之外,ClickHouse在元数据管理上也有很大的局限,它缺少一个分布式的元数据管理系统,所以在运维上成本还是比较高的。

除此之外还有数据湖的一些技术,Flink 加上Hudi/Iceburg,它给大数据平台提供了一定的数据更新能力,还依旧保持数据规模性的问题。因此我们说它在数据修正问题上表现较好,但在查询性能上,这类系统确实没有做过多的优化,因为要把性能做得好,则需要一定的索引,需要跟查询引擎做足够多的深度优化。Hudi/Iceburg基本还停留在存储层的可更新能力上,更多的还是在元数据管理上的优化,所以在性能上比较一般。

最后是Hologres,相对来说它在数据模型灵活度、分析自助性、可扩展性、数据修正能力、运维能力等方面表现优异,是一个不错的系统。它支持完整表的Scheme,用户可以做任意表的连接/嵌套,也支持秒级的查询响应。

如果是应用在线的系统,要求上万、上十万的高QPS响应,Hologres也是可以支持的。除此之外,它是一个完全分布式可扩展的架构,可以随着负载变化弹性伸缩,数据支持灵活更新,直接使用SQL的Update、Delete做数据的更新。它是一个托管的服务,弹性伸缩能力都是通过白屏化的界面进行操作,所以运维上是比较简单的,开发上就是一个标准SQL接口,所以会写JDBC、ODBC的程序都可以拿来做开发。

综上所述,我觉得Hologres具备了其他系统的优势,也弥补了一些不足,是目前比较推荐的实时数仓架构选型。

下一代大数据数仓理念HSAP:分析、服务一体化

HSAP:Hybrid Serving & Analytical Processing

图片 16.png

Hologres的设计背后一个理念叫HASP,就是同时支持Hybrid Serving和Analytical Processing两种负载,希望做到统一存储,在数据写入的时候,不管是批量写入还是实时写入,用它可以使得写入效率足够的高。

其次,对象服务的时候统一服务接口,不管是内部交互式分析的场景,还是在线点查的场景,都可以通过同样一个数据服务接口输出,通过把这两个场景融合在一起,提高开发效率。

  • Hologres = Better OLAP + Better Serving + Cost Reduced

Hologres,隶属阿里自研大数据品牌MaxCompute,云原生分布式分析引擎,支持对PB 级数据进行高并发、低延时的SQL查询,支持实时数仓,大数据交互式分析等场景。

图片 17.png

在我们的定义中,Hologres是一个更好的OLAP,过去OLAP系统查得足够快、足够灵活等特点,这个系统必须要具备。

其次它是个Better Serving,过去点查系统高吞吐的写入、更新、查询、10万以上的QPS等能力,这个系统也可以支持。

Cost Reduce并不是表示这个系统一定很便宜,而是指我们的学习成本、运维成本通过这个系统可以急剧下降,这些都是我们给系统带来的收益。

云原生实时数仓解决方案:实时计算 Flink 版 + Hologres

图片 18.png

在架构层面上,它是一个比较灵活的架构。

数据实时接入进来之后,把加工层分成两个环节,一个叫明细层加工,一个叫汇聚层加工。

明细层加工的时候也是做清洗、关联、转换,通过Flink来完成计算。加工完之后就可以把明细结果直接存下来,如果处理的是订单数据,这样基本就可以了,因为订单数据的数据量在千万规模的公司已经算是比较大的体量了。

这类明细数据直接对外提供报表服务,不需要做很多的二次汇聚加工。在清理加工的过程中经常会做维表的关联拉宽,这类点查场景在Hologres里边也是非常适合的。过去用HBase/Redis做的事情,在Hologres里边建一张表就可以完成。在明细加工阶段,既可以通过行表做拉宽,又可以用明细数据存下来,一读一写两种场景都可以支撑。

如果是行为数据、点击流数据的话,数据量往往更大,数据价值度更低,这个时候全存明细的话,分析效率比较低,此时可以去做二次的汇聚预加工。加工成一些轻度汇总层,就是轻度加工成DWS层,可以存下来也可以继续加工到ADS层,针对某个业务场景加工成一张最终的ADS结果集,也可以存下来。这类场景变成更小的数据,可以支撑更高的QPS。

因此对上来说,这个数仓系统给我们提供更多的灵活性,做交互式分析尽量存明细,做在线点查的话,就把这个表加工成一个可以按照主键进行查询的一个表即可,这给开发带来很多的灵活性。

加工也并不一定都是通过流计算的方式,有些情况下也可以通过数据存档明细数据,在数据库里边和做批量的调度都可以再继续做二次的汇聚预加工。

实时数仓场景1:即席查询

Hologres里定义了三种实现实时数仓的方式,第一种叫即席查询。

即席查询就是那种不知道查询模式是什么样子,反正先把数据存下来,然后提供尽量多灵活性的场景。

因此,此时我们就会建议,尽量把操作层(ODS层)的数据经过简单的数据质量的清理、关联,然后存到明细数据即可,先不做过多的二次加工汇总。因为此时应该怎么分析数据都不太明确,可以通过视图封装,建很多View的方式,对外提供服务。

图片 19.png

View是对逻辑做很好的封装,把底下表的关联、嵌套等复杂计算提前封装起来,但这个时候没有提前做固化,这样的话原始数据如果有任何的更新,我们随时刷新一层数据,只更新一个地方的数据即可,不需要把上面所有的汇聚表更新,因为上面没有汇聚表,汇聚的是视图。

因此,这种计算的灵活度非常高,但它的查询性能不一定是最好的,因为视图计算量非常大,每次查视图的时候都要对底下的原始数据做关联、嵌套,所以计算量相对比较大,适合对QPS要求不高,对灵活性要求比较高的场景。

实时数仓场景2:分钟级准实时

第二种场景叫分钟级准实时,这种场景跟刚才相比,对QPS要求更高一些,查询相对更加固化。

图片 20.png

此时,我们就会把刚才那些视图的部分,我就会把它物化成一张表,逻辑还是刚才的逻辑,但是变成表了。变成表之后,查询的数据量就会小很多,提升查询性能,这也是比较简单的方式,可以通过DataWorks的调度程序,用分钟级调度也可以实现准实时,5分钟或者10分钟生成一个调度批次,能够满足绝大部分公司的业务场景需求。

通过这套方式,开发变得非常简单,任何环节、任何数据有错误的时候,只要DataWorks调度重新运行就可以,运维也变得非常简单。

实时数仓场景3:增量数据实时统计

还有一些场景对数据延迟非常敏感,数据产生的时候必须就加工好,此时通过增量计算的方式,提前用Flink将明细层、汇总层等层层汇聚,汇聚之后把结果集存下来再对外提供服务,这就是增量计算的方式。

图片 21.png

跟传统增量计算方式不一样的地方是,我们建议把中间的状态也持久化下来,好处是提升后续分析的灵活度,以及修正数据差错的成本会急剧下降。这也是我们看到很多公司在用的方式,以前把数据通过Kafka Topic串起来全实时,一旦中间数据质量有问题的时候,Kafka的数据很难修正,也很难检查哪里的数据有问题,查错成本非常高。

把每一条Topic数据同步到Hologres之后,一旦数据有问题,它在表数据库里边对这个表进行修正,然后在数据库里通过数据进行重刷,实现数据的修正。

Hologres实时数仓场景3个场景选择原则

在实际业务中,我们可以根据不同的情况做选择,Hologres实时数仓场景3个场景选择原则如下:

  • 如果纯离线计算,优先MaxCompute;
  • 如果实时需求简单、数据量不大、只需要增量数据即可统计结果,适合场景3:增量数据实时统计;
  • 如果有实时需求但是实时性要求不是很高,但开发效率优先,优先走分钟级准实时方案,适合场景2:分钟级准实时;
  • 实时要求非常高,即席查询需求,资源较为充足,适合场景1:即席查询。

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

CCO服务运营系统:数字化运行能力决定了消费者和商家的服务体验。

图片 22.png

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

实时数仓经历了数据库->传统数据仓库->实时数据仓库三个阶段。

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

图片 23.png

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

电商营销活动分析

接下来举一个营销的例子。

过去营销活动都是提前一个月做各种规划,包括在什么地方投什么样的广告,给什么人群投广告,投什么样的代金券等,但这件事在互联网领域里有更高的要求。例如双11这类场景,对实时策略的调整需求越来越多,活动可能只有一天的时间,我们要实时地去了解成交排行,成交构成,库存情况,每个流量通道的转化率。比如打开一个网页,一开始要推荐的是某个商品,但是随着时间流逝会发现,商品转化率非常的低,此时我们需要调整营销策略。

图片 24.png

因此,在这种实时营销的场景下,对实时数据分析的要求非常高,需要实时了解每个渠道,每类人群,每类商品转化率/成交率等,根据情况实时调整营销策略,最后提高转化率/成交率。

图片 25.png

阿里内部计算大概架构如上所示,产品搭建使用QuickBI,交互式分析使用Hologres,数据加工的部分通过Flink和MaxCompute,这是一个比较经典的架构。

实时计算 Flink 版 + RDS/KV/OLAP 方案

实时计算 Flink 版 + RDS/KV/OLAP这套架构是早期的方案,所有计算逻辑通过Kafka串起来加工的方式,然后用Flink汇总成结果集存起来,它的局限是开发效率和资源消耗非常大。

图片 26.png

我们知道,数据分析可能是N个维度,例如时间、地域、商品、人群、类别等,其中不同维度还可以进一步做划分,例如类别分一级类别、二级特别、三级类别,人群画像包括消费能力、教育程度、地域等,任何维度组合做关联分析都会产生一定的结论。

因此,我们说过去的计算量非常大是因为要算2 ⁿ种组合,才能把所有可能被分析的角度都提前算好存下来,使得分析师看报表的时候,不管他选择什么维度的组合,都可以找到对应的计算结果,但这个计算量是个天文数字,不可能有程序员写出这么多的计算,如果没有计算则没有结果集。

除此之外,如果我们一开始算三个维度组合,突然老板觉得这三个维度不足以判断出今天发生到底什么事,想再加一个维度。但我们没有提前写这段逻辑,这时候上线数据已经消费完了,没有办法重新计算出来,或者重新计算成本非常大,因此这是资源消耗非常大的一种方法。而且我们开发完之后,计算了几千张中间表,这些结果集/组合关系是否有人使用,我们无法不确定,只能先算出来,放在数据库里面存一张临时表,成本非常大。

实时计算 Flink 版 + Hologres 交互式查询方案

图片 27.png

如上所示,改革之后的架构其实没有本质的变化,还是那些加工的逻辑。最大变化在于通过视图的方式替代了很多中间加工的过程,视图在数据库里面做计算,把一部分计算前置的任务放在了计算后置。

原始数据还是通过消息中间件,通过Flink做解析去重,然后存着明细数据。明细数据不再做很多的二次汇总加工,而是通过很多逻辑视图,无论想看几个维度,可以随时写到SQL语句,视图可以随时上线,它并不影响原始的数据。这样的话,我们想查什么数据它就算什么数据,所有的分析负载没有浪费,开发效率也会变得非常高。从过去要计算2 ⁿ,到现在只存了一张明细,针对业务需求场景做一些轻度汇总层,DWD和DWS的逻辑封装,建视图就可以了,大幅提升开发效率。

运维成本要求架构具备很好的弹性伸缩能力,这也是Hologres具备的能力,在双11流量大十倍的场景下,可以随时弹性扩容,十分方便。

助力业务快速决策调控

图片 28.png

这带来了非常大的收益,过去需要很复杂的计算逻辑流程,数据从产生到输出结果,可能需要几个小时的计算过程,这意味着我们过了几个小时才能判几个小时之前的数据,调整业务逻辑想看结果的话又要等几个小时,整个业务的灵活性大打折扣。

使用Flink + Hologres这套架构之后,数据实时产生、实时分析,随时可以做业务实时决策调控,分析灵活性非常高。例如很多客户反馈,刚开始以为某些商品会卖得很好,结果到晚上发现跟预期完全不一样,爆品反而是预期之外的商品。这些都是在提前计划好的报表上看不出来的问题,真实场景中有很多灵活上线新业务的需求,如果新业务可以在数分钟或者一小时之内上线,就能够解决这些灵活性的场景,这也是Hologres实时数仓带来一大收益。

高效的实时开发体验

图片 29.png

我们可以看到像大屏开发,大屏里边有几十个不同的指标,以前这类系统开发的时候也是比较复杂,要拿不同的数据源做不同的汇聚,通过不同的调度才能够生成这样的数据。

使用Hologres之后,2人日就可以完成开发,因为背后不需要那么多调度,写几条SQL语句即可,大幅提升开发效率。

它单日写入可以支撑500亿条以上记录,峰值写入QPS为100W+/s,查询响应延迟小于1秒,不管是在写入数据量还是分析体验都做得非常不错。

Hologres数仓开发三阶段

Hologres不仅有建实时数仓,有准实时、全实时、增量实时等不同计算方式,在公司数仓建设的不同阶段,Hologres有不同的使用方式,包括探索方式、发展方式和成熟方式。

图片 30.png

探索方式是对灵活分析需求比较多,数据模型也不太固定,分析师不确定想怎么使用数据的场景。因此这个时候数仓建设以明细层的汇聚为主,首先要把公司的数据集中化,数据不集中的话,分析效率无法保障。以ODS建设为主,DWD为辅,给ODS层做一定的质量保障,把数据的清洗、关联、拉宽等基本工作做好,生成一些DWD明细层数据,然后在明细的数据之上直接提供分析,一定要把ADS层做薄,上面不要做很多的调度、汇聚。因为这时候分析数据的方法还不确定,以下层建设为主,在Hologres里可以存明细数据,用列/行存都可以。

第二个阶段叫快速发展阶段,这个时候的主要特征一般是公司开始考虑数据中台,开始储备数据产品经理、数据分析师这样的角色。此时开始沉淀公司的指标体系,沉淀公司可被复用的数据资产, DWD已经不满足了,要继续在DWD之上做一些面向可复用的宽表,一些性能关键的场景还可以做二次加工汇聚变成ADS层表。Hologres有行/列存,可被复用的指标基本是用列存为主,如果需要ADS点查场景,可以继续二次加工变成行存。

第三个阶段进入成熟稳定阶段,此时公司的指标体系相对比较完善,有很多可被复用的指标,就需要从之前按照业务场景的汇聚往下沉淀成DWS可被服用的汇聚层,很多公司的公共指标要变成公司的指标库,这时候以DWS建设为主。
在这个阶段Hologres也提供技术支持,可以看到从DWD到DWS,Hologres支持内置的Binlog驱动可以做持续的汇聚工作。

可以看到,数仓建设分为不同阶段,不同的阶段有不同的建设重点,在不同的建设阶段,可以采用Hologres不同的技术来适应不同的需求。

总结

最后我们总结一下,Hologres是什么?

图片 31.png

首先Hologres是一个开发相对比较简单的系统,会写SQL语句就可以使用,它对SQL几乎没有限制,不管是连接操作、窗口操作都可以支持标准的JDBC。

Hologres采用兼容Postgres接口的方式,所以不管是开发工具还是BI工具,它都可以选择Postgres协议和Holo对接。

Holo里所有的数据结构是基本的表,这个表里有数据类型,有主键,有索引,这都是大家比较熟悉的概念,因此学习成本非常低。

其次,这个系统查询足够快,它具备实时写入、写入即可查,端到端实时是最基本的要求,数据写进去都不需要落盘就可以查。

除此之外,它跟大数据生态系统的结合是非常原生的,不管是Flink还是MaxCompute。Flink有很多原生的Connector,支持Holo原生的Binlog接口,支持最高性能的吞吐。Hologres和MaxCompute在文件系统层面是打通的,所以很多情况下,数据在MaxCompute系统下加工完,不需要导到Hologres系统里面,Hologres可以当做外表去查询它,性能也是比MaxCompute直接查会更好一些。但是如果需要性能更高的话,还是需要把MaxCompute的表导到Hologres里面来。

传统上MaxCompute导到任何其他OLAP系统,基本上都需要比较长的时间,但由于MaxCompute和Hologres底下文件系统打通,所以同步过程并不是把数据读出来再写到另外系统里面去,而是在通过文件系统底层接口直接进行像Copy一样的操作,因此性能可以提高10~100倍。

最重要一点还是开发效率上的提升,大家过去可能要以周为单位来建设系统,如今可以以天为单位建设,我们可以把更多的时间用在数据挖掘上,而不是在数据平台的底层运维上。

运维友好方面也有很多收益。Hologres是一个托管的服务,用户可以很灵活地弹性伸缩容。在扩容的时候,计算节点和存储节点可以独立扩容,当计算节点不够的时候可以单独扩容,并不需要计算和存储同时扩容。

这套技术是在阿里巴巴的场景下被严格验证,这和很多其他技术不太一样,它不是为了做商品进行销售的产品,这套技术在阿里内部经过4年多次双11场景,几十个不同的BU反复验证,我们认为它已经是一个可以被更多用户使用的成熟技术,因此我们把它变成一个云上托管的服务提供给广大用户使用。通过HASP架构,用一套更简单的架构支撑多个场景,实现更优性价比。

原文链接:https://developer.aliyun.com/article/785295?

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

以上是关于实时数仓入门训练营:实时数仓助力互联网实时决策和精准营销的主要内容,如果未能解决你的问题,请参考以下文章

实时数仓入门训练营:实时计算 Flink 版 SQL 实践

实时数仓入门训练营:基于 Apache Flink + Hologres 的实时推荐系统架构解析

实时数仓入门训练营:Hologres 数据导入/导出实践

实时数仓入门训练营:Hologres性能调优实践

实时数仓入门训练营:Hologres性能调优实践

AliExpress基于Flink的广告实时数仓建设