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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这套系统从左上角演化开始，消息从消息中间件收集，之后是一个离线加工的过程，那个时候我们还没有很多实时的技术，首先要先解决规模的问题。通过离线的加工，我们会把加工的结果集变成小的结果集，存到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年代我们是怎么管理数据的状态？

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

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

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

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

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

我们回过头看一看，脱离这些技术组件，实时数仓到底有什