开发者学堂课程【《实时数仓入门课程》： 实时数仓助力互联网实时决策和精准营销】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/807/detail/13886
实时数仓助力互联网实时决策和精准营销
过去几年数据发展的趋势：
我们看到的数据分析基本上的趋势从批处理向交互式分析再向流计算大致演进的趋势。
在十年前的时候 大数据更多是处理规模的问题通过并行计算的技术处理海量的数据，那时更多是在做数据的清洗，数据模型的设计，对分析的需求并不太多。
但现在今天阶段，我们的大数据团队基本上都变成了数据分析的团队，对数据模型的沉淀对交互试分析的支持能力 对查询响应延迟的支持的效率。
数据分析也并不只是那种数据存下来再分析，也有很多那种计算前置，先有逻辑后有计算的场景就比如说我们在双十一的时候在多少秒成交多少量，这样典型的场景就不是先有交易数据后有计算量的问题，一定是随着交易发生的实时计算结果带动过程。所以交互式分析和流计算几乎是并行前进的过程。
那两种新的场景其实对背后的技术要求也很多不一样，批处理的时候，我们更多讲究的是并行度，在交互式分析领域里面 我们开始有很多的预计算，内存计算索引一些技术，也是推动的大数据技术的演进。
那整个总结下来，我们就说数据分析是越来越多的支撑着一些在线业务。
阿里巴巴典型实时数仓场景：
在阿里巴巴其实有很多是数仓的一些使用场景，就像我们常见双十一的时候大屏GMV，这方面其实只是结论性的数字，我们说多少秒成交了多少量是非常吸引的结果，但是实际上的 对数据分析师而言，工作是刚刚开始，那我们要向下分析是什么产品，在什么样渠道 针对什么样的人群，以样的促销手段达成转化效果，那有哪些转化效果却没有达成，这些分析其实非常非常的细力度，其实是个精细化分析这样的效果。
那分析之后，就会对我们的所有的商品所有的人群都要做一些标签化，通过标签化呢 我可以下一步去指导我们在线的应用 去做推荐，去做分析，去做圈选等等，所以说有很多数据中台的业务也会产生，还有一类业务偏监控类业务，订单突然抖动突然增长，网络质量的抖动，视频直播的一些监控等，这些也是典型的实时数仓的一些场景。
大数据实时数仓体系的“纷繁芜杂”：
从左上角也开始，消息从消息中间件收集，之后呢，最开始的时候一定是离线加工的那，时候我们还没有很多实施的技术 首先要先解决规模的问题，通过离线的加工，我们会把加工的结果集变成小的结果集，存到Mysql和Redis。
这是典型的加工服务二元化的体系，通过把数据变成小数据之后，才能对外提供上层的不管是报表应用还是推荐应用，之后数据分析需要实施化光靠这种T+1的离线加工是不能够满足需求的，我们的数据越实时，越有上下文 价值是越大的，这时就有很多计算前置的技术，我们会采用像Flink技术，通过Flink直接消费Kafka里的事件，通过事件驱动的方式做计算，这种方式，Flink可以是非常分布式的，可扩展性非常好，它可以通过计算前置，通过事件驱动的方式可以把端脑端的延迟呢做到极致，做得非常小。
这里有有处理规模的，有处理速度的，两者看起来表面上都满足一定的需求 其实成本也是不小的，我们看到如果想要计算的足够的快，要把计算前置的，实际上数据模型的灵活度就减少了，因为已经通过Flink把所有的数据给汇聚，变成结果集了，这时，如果有些业务逻辑一开始没有定义好，比如说开始分析的是某三个维度的聚合，这时想分析第四个维度的聚合，那很抱歉如果提前没有计算好，这时就没有办法分析，所以说称为灵活性。
这时，我们会发现，同样一份数据处理，数据分散的三个不同的介质，包括离线处理的介质，进实时处理的介质和种叫全实时处理介质里面去，一个数据分散在三个介质里面去 往往还会有三个团队来维护，三个团队随着时间的发展，人员的人员的变动，数据加工逻辑一定会有多多少少的调整，体现的结果我们会发现，同一个指标通过三个不同渠道计算，结果是不一致的，这个几乎每公司都一定会发生。那还是只是表面的问题 那对于分析师来说就很痛苦，他要使用不同的数据，要访问不同的系统，那他要学习不同的接口，甚至是有不同的反应控制机制，就非常不方便，有很多公司都要搭一套所谓的数据中台，通过中台来屏蔽底下物理引擎上的不同。
联邦计算技术实际上也是过去20多年有很多发展，从最早期的数据信息系统集成到数据虚拟化，技术一直在发展，这个技术是一套数据不移动，计算移动的技术。听起来很美好，但是当我们真正在生产使用的时候会发现，这套系统的查询体验是不可预期的，你不知道这些通过系统查询下去数据是快还是慢，因为他把查询下压下的不同的引擎不同引擎的，比如have我就没那么快，Clickhouse就比较快。说对分析师来说，他就不知道我对系统的预期是什么，叫不可预期性。
这套架构，实际上是运行正常情况下都很好 但是一旦数据质量有问题，数据同步调度场出问题，环环依赖使得整个运维的成本变得非常的高。
我们是怎么管理数据的状态呢？
其实每个程序员要自己写这些状态维护，有的人用文件系统，有的人用文件，光用文件系统，非常离散的，这个维护起来也非常难。因为数据和数据之间是有关系的，这个时候，还有一些网状结构的，这样系统出现了通过一个文件可以跳到另外一部文件去，这个是网络结构 也是管理强 相对比较复杂 因为循环，嵌套等等。
下面还有层级结构，这也是一种数据类型的描述方式。
要自己去管理这些数据状态 其实成本是很高的，今天，我们基本上不会再这么干，因为今天，我们知道所有的状态尽量都存在数据库里，也是因为外形数据库让这件事情，变简单很多，尽管今天没有很多种关心数据库。
实时数仓核心需求：时效性
先脱离开那些技术组件，看一看实时数仓到底有什么样的业务上的需求，针对这家业务需求，可以要求有什么样的数据架构。
什么是实时？
很多人认为实时就是说从数据产生到能够被分析的时间足够的短，就是实时分析，其实这件事只说对了一半。实数仓的有两种实施，一种的就是叫端到端的延迟短，这是一种实时。
另外一种实时的叫准时，就是当你真正分析数据的时候。能够拿到有效的数据，并且能够得出结论，那这就可以叫准时。
如果计算全部前置，你的灵活性会损失，所以这件事是有成本的，那相对来说，如果你是追求的是个准时的系统，就可以把一部分的这个计算逻辑后置，换取的是一个灵活分析的一个场景。这个时候就需要有更多的明细数据能够能够存下来，我们可以做更多的交互式分析，关联分析，探索式分析。所以说，这背后这两套系统最后的需求是不一样的。
实时数仓核心需求：数据质量
多久发现质量问题----数据状态（明细汇总）可检查
多久修正质量问题---- （1）简化数据重刷，数据可更新
（2）减少属于亢余和不一致
其次就是数据指标，那数据质量确实是实时数仓建设很重要的一环。
如果不追求数据质量，只追求时效性的话，一开始通过计算前置加工成一个结果集，这个结果集告诉你，达到了这个一百亿。你敢相信这个数字吗？
我觉得绝大部分领导是老板是不敢相信的，因为这100亿背后到底可能数据质量出问题，可能是计算逻辑写错了。所以说，要能够保证数据质量，数据质量分两个方面：一个是多久发现质量问题，以及还有就是多久修正质量问题。
如果你想发现数据质量问题，就需要把计算过程的状态呢能够被持久化，那就希望你的数据仓库引擎里面能够有明细以及汇总数据呢，能够落盘那这些数据，可以被检查这样话到底老板问客户带来的增长，这个时候，你就可以通过这些明细的数据去检查到底是什么。设计质量有问题还是其他逻辑有问题。
所以说，如果让发现问题和修正问题相比较来说，更希望一个系统能够具备修正数据问题的这样能力修正问题，就是说我能够在发现数据这样的时候可以简单的更新这个数据的状态，比如说单行数据的更新，单列数据的更新，批量的更新等等，有很简单的方式做数据的刷新。其次，也是希望数据修正的时候，尽量能够只修正一个系统就好。
实时数仓核心需求：成本优化
开发成本(上线新业务)：
（1）业务与技术解耦，数据资产可复用，业务自助开发
（2）简化链路，减少依赖，减少数据传递
运维成本（集群资源）：
（1）更少的集群，更少的运维工作
（2） 更小的集群，资源充分发挥
（3）托管服务，弹性伸缩
人力成本(学习招聘成本)：
（1）开发接口标准简单，降低学习成本
（2）兼容主流 BI
第三部分呢就是成本的问题，这个成本分三部分，开发成本、运维成本和人力成本。开发成本就是说我们想要业务需求多久能上线，做同一件事，需要11个一个团队的人还是一个人，是需要一周呢还是需要一天。运维成本，运维成本简单翻译过来就是说，过去集群太多，花的钱太多，你要开4套5套集群，反复调度，反复监控，所以说，如果未来有机会 我们重新选行新的数仓的时候，应该考虑怎么把这个成本节省下来。用更少的集群，更少的运为来提供更多的能力。第三个成本就是人力成本，这包括招聘的成本和学习的成本。
第一代实时数仓：数据库阶段
第一代技术，我们叫数据库阶段，这也是典型的这个拉姆达阶段，基本上就是有一个业务需求，就有一套数据链住，然后数据链住的基本分为这个实时和离线两部分。
互相数据有用于产生数据不一致，这都是比较直接，这里更重要的问题就是只有烟囱式的开发，这是最大的问题。最后，会发现这个结果集或者你生成的报表端几百张报表，其中分之 80的部分其实互相呢，是有很大的勇于部分的。
这个业务部门看的是这三个指标，另外一个部门的看的是其中两个指标，那只是中间可能换了一个字段，这是很常发生的事情，就是这个原始数据都是一样的，但是大家统计的字段你多一个我少一个，但是，我就要重新端到端去开发。
这也是一件严重降低开发效率的事情，那绝大部分开发计算任务的互相的都是勇于的，是浪费的。这种烟筒式的开发 是属于上手很快，但实际上呢在运维上不可持续的一件事情。那我们一般怎么解决烟囱是问题，这个时候烟囱是问题，解决方式基本就是把共享的部分要沉淀下来。
怎么沉淀，我们就进入第二个阶段，叫数据仓库的一个阶段.
第二代实时数仓：传统数仓阶段
仓库是很好的概念，就是把那些可被服用的计算的指标沉淀出来，所以出仓里面，我们要想分层，通过层层的沉淀，把共享的部分向下沉 ，把差异的部分的向上移，这样话，减少重复建设这些问题。这也是在这个数仓里面几十年沉淀这条基本的方法，非常的好。
第三代实时数仓：分析服务融合阶段
第三阶段的可能是什么样子，那这个阶段，在阿里内部，实践到这个阶段，在绝大部分外部的公司，还是在这个路上探索，那这个探索你看跟刚才有两个区别：
一个是在服务端统一，不管你是olap系统还是只有点查的系统，用一个系统统一减少这种数据的割裂，减少这种接口的不一致，减少一份数据在不同系统之间传递来传递去，实现统一存储这样一个效果。
这让我们数据状态的检查数据的修正都变得更简单，然后接口上，也都同样一个系统里面，我们的安全法文控制应用开发的接口也都可以一致化。
最后就是组件少了，因为成本也降低了，那对公司来说呢也是省钱了，所以呢，还有很多收益的。
在阿里双十一，其实也就是在这样的方式去做，双十一的时候，更多的时候还是一个吞吐量，确实是几乎是世界最大的。我们看到数据，通过实时通道走消息中间件，首先，一般是点击流数据需要通过 Flink 做一些尾表拉宽的操作，点击流这里面记录的时候是 i d，什么 id 点击了什么样的 sku 那这个时候，我要把这个sku作为表拉宽，把它翻译成是什么商品，什么类别，什么人群点击的，通过什么渠道。那把这些表一表拉宽之后，存在 Hologres 这样一个数据仓库里边。那同时这个Hologres 实时数仓，另外一部分数据会离线啊，定时同步到我们的离线储仓里面去，扮演的是一个历史全局数据的一个概念。
Flink 基本上已成为行业上实施计算的一个标杆，各个行业都在使用。阿里也是这方面的一个领导者，开元技术背后都一家成功的商业公司，阿里也是这家，阿里就是Flink 背后呢这家商业公司。
但是在这个仓库系统的选择上不太容易，就因为选项非常的多， 实时计算的部分很简单，就是 Flink。那有几类系统可以选择，首先分了三类，就事物系统，分析系统和服务系统。事物系统就是产生数据的系统，很多业务系统，能直接做分析吗？
基本上不太容易，因为它的直接分析的时候，你的负载很可能影响在线系统的稳定性，而且性能上也是无法保证，因为这些系统，它是面向随机读写优化的。
所以我们做第一件事，就是事物系统和分析系统的这个分离，我们把这些数据，先做一次同步，同步到分系统里面去，分析系统的是专门为优化做为分析做了很多优化的，我们会采用像列存分布式，汇总构造于一层等等这些建模的方式，把分析的数据模型简化，也包括丰富，然后把数据分析的性能提高，这是一个面向分析师的系统。另外一种系统也是通过数据来驱动的一个场景，更多是支持在线的应用，也有很多的数据高吞吐的更新的那些能力。
所以，会看到数据从源头产生之后，一般有两个出路，一个是进入分析系统，一个是作用服务系统，只是在线应用，那这个时候，会发现数据其实在不同系统里面，就产生了很多的割裂，之后又意味着数据的移动，数据的搬迁，数据的依赖和接口的不一致。
我们开始想办法做创新，第一个创新是在这个边界处做的创新，是不是一个系统既可以做分析又可以做服务呢？挺理想的 在有些场景下确实也是适合的。
这在这些系统的又有一些限制，第一个限制就是这个系统的底线是要保证事物，事物是一件对计算能力开销非常大的一件事情，我们可以看到绝大部分分系统是不能不支持事物的。
另外一端我们看一些创新，是否一个系统既可以支撑分析的场景又可以支持在线服务的场景，支持高并发，支持快速的查询，支持数据的可更新。如果用一个系统可以支持这样两个场景的话，就会让我们数据迁移，数据开发的成本又降低了很多。
同时，这两个系统我们看有很多共性的部分，比如说数据基本以只读为主，基本是没有锁的要求。然后，都需要数据被加工，被抽象，你会看到我这边定义的分析系统和服务系统的，它的共性其实是非常大的，是有机会的做创新的。
绿色的都是有优势的，比如说这个 Mysql 提供很好接口，因为 Mysql 的这个开发比较方便，各种函数也多。但实际上的可扩展性，它数据的灵活性都会差很多，因为Flink+Mysql 就是要把数据变成一个结果集来使用，缺少很多的中间的状态，数据需要搬迁修正的成本是非常高的。
这个时候，开始往前往走了一步，Mysql 扩展性不好，Hbase 扩展性好，Hbase 扩展性确实非常好，可以处理很大的数据的规模的问题，但实际上的数据刷新的能力就比较弱，想随时更新某一行某一列的数据，不太方便，然后数据模型灵活度不太好，但你如果不是按那个k去查，就很不方便。
在之后，我们看 Clickhouse，最近几年也是非常的火，查询速度非常的快，非常适合宽表的场景，但是数据分析的如果只有宽表也是也是可以的，但是往往我们知道，数据分析光靠一张宽表是不够的，那需要很多表的关联，嵌套窗口计算，所以这的这种场景下，对于这个 Clickhouse 就有些勉强。
Clickhouse 在不支持很多的函数，关联操作都不支持，特别数据关联表，关联的场景下性能下降的也是比较明显的，在原数据管理上有很大的局限，它缺少一个分布式的原数据管理这样一个系统，所以在运维上成本还是比较高的。要把性能做的好，需要一定的索引，需要跟查询引擎做足够多的深度的优化。
Hologres 相对来说在数据模型的灵活度，分析的资助性，可扩展性，数据的修正能力上，越维能力上，都是一个不错的这样一个系统。如果你是应用在线的系统，支持上万上十万的这种高科表的响应，它也是可以支持，然后它是一个完全分布式，可扩展的架构，可以随着这种负载变化弹性伸缩。然后，是一个托管的服务，弹性伸缩能力都是通过这种白平化的界面进行操作，所以运维上的是比较简单的，开发上的就是一个标准色扣接口。
所以 Hologres 是具备的前面其他系统的一些优势，那也弥补了过去的一些不足，是比较推荐的实施数仓架构的一个选项。
其次，对象服务的时候，统一的服务的接口，不管你是内部交互试分析的场景还是在线点查的场景，都可以通过一个数据，同样一个数据服务接口输出，输出通过把这两个场景融合在一起，提高我们的开发量效率。
在架构层面上，基本上还是比较灵活的一个架构就是数据，实时介入进来之后，我把加工层能分成两个环节，一个叫明细层加工，一个叫汇聚层加工。
加工层的时候也是做清洗，关联转换，基本通过 Flink 来做这个计算，加工完之后，你就可以把这明细结果直接存下来，很多公司，如果你除了也是订单数据的话，这样基本就可以了，因为订单数据基本数据量在。这个规模是比较多的公司，那这类直接对外提供报表服务。不需要做很多的二次的汇聚加工，在清理加工的过程中的经常会做违本的关联把他拉宽，这类是点查的场景，那也是非常适合的。
如果你的数据基本上订单数据到这就差不多了，如果你是这个交易，是行为数据，点击流数据的话，往往数据量更大 数据的价值度更低。这个时候你全存明细实际上对分析来说，效率上比较低。
这时你可以再去做二次的汇聚加工，加工成一些轻度回总层。有些情况下，你也可以通过数据存到明细数据之后，然后在数据库里边做批量的调度，也是可以再继续做二次的汇聚和加工。
实数数仓场景 1：即席查询
Hologres 这里定义了三种实现的方式，三种实现实行它的方式：第一种的叫继续查询，继续查询就是那种你也不知道查询模式是什么样子，就是先把数据存下来，然后提供尽量多的灵活性的一个场景，所以这个时候，我们就会建议你尽量把操作层经过简单的数据质量的清理关联，把它就存到明细数据就可以，先不要做过多的二次加工汇总，因为这个时候你怎么分析数据都不太明确，你可以通过视图封装的方式对外屏幕服务。
但这个时候，都没有做物化，这样话原始数据有任何的更新，你都可以随时刷新，一层数据就可以，只更新一个地方的数据就可以。你不需要把上面说的汇聚表做更新，因为上面没有汇聚表是汇聚的，是视图。所以，这种兼有计算的是灵活度非常高，但它的查询性能并不是一定是最好的，因为视图计算量是非常大的 每次查视图的时候都要对底下的原始数据做关联做嵌套，所以计算量相对比较大。
实时数仓场景 2：分钟级准实时
那第二种场景分钟级准实施，这种就是像刚才相比，对 qps 要求更高一些，查询的相对更加固化一些，这时就会把刚才那些视图的部分的，我就会把它雾化成一张表，逻辑还是刚才的逻辑，但是变成表了。
变成表之后，是按我的查询的这个数据量，就会小很多，让查询性能上的有一个保证，这个也是比较简单的方式，那大家说这数据不实时的，其实不是的，这个分钟基调的五分钟生成一个批调度，调度批次十分钟一次。
通过这套方式，你的开发方式开发变得非常简单，任何环节，任何数据有错误的时候，你只要调度重新跑下就可以。
当然，还有些场景区对延迟非常敏感，我不能等十分钟，五分钟，他必须数据产生的时候就加工好，这时，我们就是通过叫增量计算的方式，提前通过Flink层层汇聚。
其实在不同场景列为不同选择方式，全实时的，也可以通过增量的方式去做计算，但是更多的时候，其实我们可以通过绩息查询或分钟及准事实的方式提供更好的灵活性，提供更高的运维成本，这也是能够推荐的方式，所以这个绝对不是只有一种检测方法。
例子：
营销活动过去都是提前他一个月做各种规划，这个营销在什么地方投什么的广告，给什么人群投广告，投什么样代金券促销等等。但这件事，在互联网领域里边还有要求会更高的，因为互联网往往是那种一天，比如像双十一促销一样，但实际上对这种实时策略的调整的需求会越来越多，只有双十一这一天的时间 你要实时去了解成交的排行 成交的构成，库存的情况，每个流量通道的转化率，因为你要知道你一开始设计给谁，就比如说你打开一个网页，首页推荐的产品，一开始你要推荐的是它，但是你会发现随着你的这个时间的这个进展，这个商品的转化率非常的低，甚至是可能是产品的质量问题，投诉率很高，退单率很高，这个时候你必须要调整你的营销策略，所以说这种实时营销的场景下，对实时数据分析就要求非常的高，你要实时了解每个渠道，每一类人群每一类商品，转化率，成交率等等来实施调整你的营销的策略，那这样会提高，到最后结果，就是提高的转化率，那成交率在阿里内部，这个计算那大概架构就是这样。
这个架构过去，这是早期的方案，那这样一套架构实际上是这种刚才提到的所有集团逻辑，通过 Kafka 串起来事件加工的方式，然后通过Flink汇总，汇总的结果集存起来，之后有什么局限呢？就是开发效率和资源消耗会变得非常的大。数据分析，分析可能是个N个维度，比如说时间，地域，商品人群。这个类别分一级类别，二级类别，三级类别，对人群也是不同的消费能力，教育程度，地域等等。所以说，过去为什么计算量非常大 ，为我要算 2 的 n 次方种组合才可以把所有可能被分析的角度的都提前算好存下来，这样我们的分析师看报表的时候，不管他选择什么样的维度组合，都可以找到这样的一个计算结果。但这个计算量几乎是个天文数字得2 的 n 次方，所以说不可能有程序员写出这么多的计算，这时怎么办，如果你没有算的话，就没有这个结果集，你一开始算三个维度组合突然老板觉得这三个维度不足以让我判断书这今天发生到底什么事，我想再加一个维度，很抱歉没有提前写这段逻辑，这时候上限数据已经消耗消费完了，没有办法再重新计算出来，重新计算成本必须充满很多很多计算，这个开销非常大。所以这种开发方式是一种开发效率消耗资源非常多的一种方法。
那改革之后是什么样子，改革方式看架构其实没有本质的变化 还是那些加工的逻辑，最大变化在哪里，实际上就刚才提到，它通过视图的方式替代了很多中间加工的这个过程，视图实验是在数据库里面做计算，其实要把计算前置放一部分计算前置的任务，放在计算后置的，原始数据还是通过消息通源键通过 Flink 做解析，然后存着明细数据，在明细数据之上，就不再做很多的二次汇总加工，而是通过很多逻辑视图，你想看三个维度，你想看八个维度，随时可以写到语句里，视图是可以随时上线的，并不影响原始的数据。这样开发效率也会变得非常的高 从过去要计算2的n次方，到现在只存到一张明细之后，针对业务需求场景做一些轻度汇总层dwd和dws的逻辑封装，建视图就可以。最后，运维成本跟架构同比的关系，运维成本是要求这个技术架构，具备很好的弹性伸缩能力，也是 Hologres 具备的能力，在双十一，在流量打十倍的场景下可以随时的弹性，这是非常方便的一点。
所以对它来说收益是非常大的，那过去需要几个很复杂的计算逻辑流程，数据从产生到输出结果需要几个小时的计算过程，这意味着，我过了几个小时才能看几个小时之前的数据，去调整业务逻辑，再看结果，又要等几个小时让我整个业务的灵活性敏捷性就会受打很大的折扣。那使用 Flink+Hologres 这套架构之后，我们可以看到数据，是实施产生，实施分析，所全天，随时可以做业务逻辑决策调整。
我们可以看到他们向大屏开发，大屏里面有几十个不同的指标.
那最后，就是 Hologres 并不是只有一种做法，在公司的数仓建设的不同阶段，Hologres 有不同的使用方式，那我们就探索方式，发展方式和成述方式。Hologres在不同的建设阶段，你可以采用不同的技术，有列存，行存，消息驱动，在不同阶段你可以使用不同技术来适应不同的需求。
首先 Hologres 是一个开发上相对比较简单那个系统，就是你会写 sal 语句，就可以使用那个系统，他对sql几乎没有什么限制，不管是连接操作，窗口操作，都可以支持就是标准的 gdbc，其次，这个系统查询的是足够的快的，写入即可查。
其次，这个大数据生态系统的结合是非常原生的，不管是 MaxCompute 还是的Flink 有很多原生的 connector。
