共计 18326 个字符，预计需要花费 46 分钟才能阅读完成。
简介：《实时数仓入门训练营》由阿里云研究员王峰、阿里云高级产品专家刘一鸣等实时计算 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 等，这让数据畛域蓬勃发展。
然而我总感觉这个中央隐含了一些问题，可能将来不肯定是这样。目前大数据倒退蓬勃但不对立，所以我在想将来是不是能够把大数据技术绝对收拢一些，用一种更有描述性的形式来解决问题，而不是让每个程序员都去学习不同的组件，学习几十种不同的接口，配置上千个参数。为了进步开发效率，或者在将来咱们有必要将这些技术进一步收拢简化。
实时数仓外围需要：时效性
咱们回过头看一看，脱离这些技术组件，实时数仓到底有什么业务上的需要，针对这些业务需要能够要求什么样的数据架构。
什么是实时？很多人认为实时剖析就是从数据产生到可能被剖析的工夫足够短，其实这并不齐全精确。我认为实时数仓分为两种实时，一种叫端到端的提早短，另外一种实时也能够称为准时，就是当咱们真正剖析数据的时候，可能拿到无效的数据，并且可能得出结论，这就能够叫准时。
第一种实时是偏技术的概念，然而咱们的业务肯定须要这么低的提早吗？
通常状况下，业务并不是每秒钟都在做决策，业务当咱们关上报表，咱们看数那一刻，这一刻咱们关怀的数据可能是过来的一天，上一个小时，5 分钟之前，或者是一秒钟之前的。但教训通知咱们，99% 的数据分析如果能做到 5 分钟的提早，根本能满足业务上的数据分析需要。在剖析场景是这样的，如果是在线服务的场景，这必定是不够的。
所以大多数公司里兴许并不要求那么实时，因为这背地的老本是不一样的。
因为一旦要的是端到端的提早，就肯定须要很多计算前置的业务逻辑，不能等数据都存下来之后再去查问，因为要求提早十分地短，咱们必须要把很多数据提前汇聚、加工、拉宽，能力让数据分析的时候计算量足够小，才能够做到提早足够地短。
所以如果谋求的是端到端的提早，要做很多计算前置的工作。方才咱们提到，如果计算全副前置，灵活性会有损失，所以这件事是有老本的。相对来说，如果谋求的是一个准时的零碎，那能够把一部分的计算逻辑后置，换取的是一个灵便剖析的场景。
例如双 11 的时候只是为了谋求延时，那咱们只会把最初一个 GMV 存下来，这是一种场景，这事就完结了。但这件事不合乎公司要求，公司肯定要出具体的报告，须要晓得什么时候卖的好，什么时候卖的不好。所以这种状况下，全副提前预计算的形式必定是不适宜的，须要有更多的明细数据可能存下来，咱们能够做更多的交互式剖析、关联剖析、摸索式剖析，所以说这两套零碎背地的需要是不一样的。
相对来说，我感觉绝大部分公司要的其实是个准时的零碎，它须要具备计算后置的能力，具备实时写入、写入即可剖析的能力，哪怕剖析的效率不是那么高，还要具备灵便剖析的能力。
实时数仓外围需要：数据品质
数据品质是实时数仓建设里很重要的一环，方才提到如果不谋求数据品质，只谋求时效性的话，一开始通过计算前置加工成一个后果集，这个后果集通知咱们 GMV 达到了 100 亿，绝大部分老板是不敢相信的，因为这 100 亿背地可能是数据品质出问题，也可能是计算逻辑写错了，所以说零碎要可能保证数据品质。
数据品质分两个方面，一个是多久发现品质问题，另一个是多久修改品质问题，这两个解决思路是不太一样的。
如果想发现数据品质问题，就须要让计算过程的状态可能被长久化，就心愿数据仓库引擎里边可能有明细，以及汇总数据可能落盘，这些数据能够被查看。这样的话，当老板问指标为什么增长这么多，到底是哪个客户带来的增长，你就能够通过这些明细的数据去查看起因，剖析数据时如果发现错了是否修改，这也是很要害的问题。
有些零碎只能看不能改，这是很多大数据系统的通病。大数据系统在解决规模性问题十分好，然而解决小的问题，如更正数据就特地地难。因为它每次更正都是须要很大的数据块为单位，或者是没有主键，将整个文件替换，所以更新起来的确比拟难。
发现问题和修改问题相比，我更心愿一个零碎可能具备修改数据问题的能力。
修改问题就是在发现数据品质的时候，能够简略地更新数据的状态，比如说单行数据的更新，单列数据的更新，批量的更新等，有很简略的形式做数据的刷新。数据刷新的状态这个事件常常会产生，例如上游数据品质有问题，加工逻辑写错了等，都须要做数据刷新的工作。
其次，我也心愿数据修改的时候尽量可能只修改一个零碎就好。
方才咱们看到，一份数据的数据源出错了之后，它要在后端 4~5 个环节重复流转，这意味着一旦数据出错了之后，在 4~5 个环节外面都要做数据修改的工作，这外面的数据存在大量的冗余和不统一，要修改的话每个环节都要修改，这也是特地简单的一件事件。所以咱们心愿数仓的状态尽量只存一个中央，这样话我只修改一处就能够了。
实时数仓外围需要：老本优化
老本分为三局部，别离是开发成本、运维老本和人力老本。
开发成本示意咱们想要业务需要多久能上线。做同样一件事，是须要一个团队还是一个人，是须要一周还是一天，所以开发成本是很多公司很关怀的一件事件，如果开发不进去，就意味着很多业务的需要是被压抑或者是克制的。
咱们心愿 IT 同学不须要再很疲乏地响应业务团队取数的要求。常常产生的状况是，等数据真正加工完之后，业务团队反馈说数据加工得不对，等 IT 同学好不容易修改对了之后，业务团队示意流动完结了，想看的数据曾经没有意义了。
因而，好的数仓零碎肯定是技术和业务解耦，技术团队保障数据平台运行的稳固牢靠，而业务团队的取数尽量要自助化，本人通过拖拽的形式生成感兴趣的报表，这是咱们认为良好的零碎。只有通过这样的形式来升高开发的门槛，让更多的人本人去取数，实现数据资产的可复用，业务自助开发。
同时，为了放慢开发效率，链路肯定要足够短。
就像咱们一开始看见的架构图，如果两头四五个环节，任何环节都要配置调度，任何一个环节出错了之后都要监控，那么开发效率上肯定是十分惨重的。如果开发链路足够短，数据缩小传递，开发效率也会高很多。所以咱们要进步开发效率，心愿可能做到技术和业务解耦，也可能做到数据链路足够的短。
运维老本简略翻译过去就是说过来集群太多，花的钱太多。
咱们要开四五套集群，重复调度与监控。因而，如果将来有机会从新选型新的数仓，应该思考如何降低成本，用更少的集群，更少的运维来提供更多的能力，包含一些弹性的能力。公司在月底或者促销流动这种对计算量分析量有要求的时候，能够做一些弹性的扩缩容，适应不同的计算负载变动，这也是十分重要的一个能力，能够节俭公司的运维老本。
第三个老本就是人力老本，包含招聘老本和学习老本。
大数据是一个绝对比较复杂的零碎，做过 Hadoop 技术的应该晓得，几千个参数，十几个组件各自相互依赖，任何节点宕掉都可能会引起其余零碎的各种各样的问题。
其实学习和运维老本都是比拟高的，方才提到数据库的例子是很好的一个范本。升高开发的老本能够用描述性语言，也就是 SQL 的形式，通过 SQL 的形式能够把整个开发门槛急剧升高。绝大部分同学在本科的时候都曾经学过数据库这样的课程，所以用 SQL 的形式比那些须要学习 API，须要学习 SDK 的形式更有效率。这样的话，人才在市场上也更容易找到，也让公司把更多的精力从底层平台运维，向下层数据价值开掘上转变。
通过规范 SQL 跟其余零碎对接，不论是开发工具还是 BI 展现工具，都会更加中央便。
以上是从业务需要推导进去的一些技术需要。
第一代实时数仓：数据库阶段
接下来咱们看一下，过来的一些实时数仓开发技术是否可能满足以上需要。
第一代实时数仓技术咱们叫数据库阶段，是典型的 Lamda 阶段。
这个架构根本是有一个业务需要，就有一套数据链路，数据链路分为实时和离线两局部。数据收集到消息中间件，一部分走实时，加工后果集，存到 MySQL/HBase。另一部分离线通过 Hive/Flink，加工后果集，也是存到 MySQL/HBase，都是把大数据变成小数据，而后对上提供服务。
这套架构曾经有很多人剖析过问题了，两套架构相互数据冗余，产生数据不统一，这是比拟间接的，但这里更重要的问题是烟囱式的开发。
当业务端提出一个新需要的时候，程序员就要去找这个数据来自于哪个数据源，它应该跟哪些第三方数据源做关联，要做怎么样的汇聚加工，而后生成一个后果集，最初咱们会发现这个后果集或者是生成的数百张报表端，其中 80% 的局部相互有很大的冗余局部。有的业务部门看的是这三个指标，另外一个部门看的是其中两个指标，两头可能只是换了一个字段，这是常常产生的情况。原始数据都是一样的，然而统计的字段你多一个我少一个，然而咱们就要从新端到端去开发，重大升高开发效率。运维上也很难，开发了几千张报表，咱们不晓得这些报表是否有人在应用，咱们也不敢轻易下线。
除此之外，一旦任何一个数据源的字段减少或缩小，都要去调整、运维、批改，这件事简直是一个劫难。如果是一个人开发那么问题不大，咱们见过很多开发团队，四五个同学每天频繁写脚本，而后这些人员有人到职，有人入职，最初谁也不敢删老同事的代码，最初就变成调度几千个脚本，天天在查纠错，可能是脚本的错，也可能是数据品质的错，这件事让运维老本变得十分的高。
因而，这种烟囱式的开发属于上手很快，但在理论运维上是不可继续的一件事件。咱们解决烟囱式问题的形式是把共享的局部积淀下来，这就进入实时数仓的第二个阶段：传统数仓阶段。
第二代实时数仓：传统数仓阶段
数据仓库是很好的概念，就是把那些可被复用的计算指标积淀进去，因而数仓外面要分层，有 DWD、DWS、ADS 三层。通过层层的积淀，把共享的局部向下沉，把差别的局部向上移，缩小反复建设的问题，这也是数仓通过几十年积淀进去的一套根本的方法论。
这种形式通过 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 零碎的一些局限，元数据管理起比拟不不便。
第三代实时数仓：剖析服务交融阶段
实时数仓第三阶段是剖析服务交融阶段，这个阶段在阿里外部曾经实现，内部绝大部分的公司也在摸索的路线。
这个阶段跟之前的阶段有两个区别，一方面是在服务端的对立，不论是 OLAP 零碎还是点查零碎，通过一个零碎对立，缩小数据的割裂，缩小接口的不统一，缩小一份数据在不同零碎之间来回传递，实现了对立存储的成果，这让咱们数据状态的查看、修改都变得更简略。接口上对立到一个零碎，平安、拜访、管制、利用开发的接口能够统一化，在服务端做了一些优化。
另一方面数据加工链路也做了肯定的优化，这外面没有 Kafka 了。其实有没有卡夫卡是一个可选项，因为有些零碎具备了肯定的事件驱动能力，比方 Hologres，它具备内置的 Binlog 事件驱动能力，因而能够把 Hologres 当做一个 Kafka 来应用。通过 Binlog 搭配 Flink 实现了 DWD、DWS、ADS 层层实时汇聚，这也是一个十分好的能力。
通过这样一个架构，组件只剩下 Flink 和 Hologres，两头没有其余的内部零碎，仍旧能够通过实时链路驱动起来，数据没有决裂，所有数据都存在数据库。
要害收益是开发链路变短了，让调错老本也变低。其次是数据的明细状态被存储，因为 HBase 很难存明细状态。如果服务零碎外面存下明细之后，数据查错、修错的老本就变得非常低了。除此之外，组件变少，相应地运维老本也升高。
阿里双 11 实时业务实际
阿里双 11 就是通过上述形式去做，双 11 场景下的吞吐量简直是世界最大的。
能够看到，数据通过实时通道走消息中间件，首先个别是点击流数据，而后须要通过 Flink 做一些维表拉宽的操作。点击流外面记录了什么 ID 点击了什么样的 SKU，这个时候要把 SKU 作为表白宽，把它翻译成是什么商品，什么类别，什么人群，通过什么渠道点击的。把这些维表拉宽之后，存在 Hologres 里边，Hologres 在这里表演实时数仓的角色，另外一部分数据会离线定时同步到离线数仓 MaxCompute，MaxCompute 表演的是一个历史全局数据的概念。咱们常常会统计消费者过来一段时间的消费行为变动，这部分数据的加工时效性要求不高，然而数据量十分大，是在 MaxCompute 里执行的。
在剖析的时候，Hologres 和 MaxCompute 通过联邦查问的形式关联在一起，所以并不需要把数据都放在一个中央，用户还是能够通过实时和离线做联邦查问的形式缩小数据的冗余。
Apache Flink – 实时计算的行业事实标准
Apache Flink 已成为实时计算的行业事实标准，各个行业都在应用，阿里巴巴是这方面的领导者。开源技术背地都有一家胜利的商业公司，Flink 背地这家商业公司正是阿里巴巴。
实时计算的局部很简略，就是 Flink，然而在仓库零碎的抉择上不太容易，因为选项十分的多，次要能够分为三类，别离是事务零碎，剖析零碎和服务零碎。
事务零碎就是产生数据的零碎，它有很多业务零碎，这个零碎上不太容易间接做剖析。因为间接剖析的时候，负载很可能影响在线零碎的稳定性，而且性能也无奈保障，因为这些零碎它是面向随机读写优化的，根本是以行存为主。
对于统计分析类的场景，IO 开销十分大，它基本上是给 DBA 筹备的，保障线上零碎稳定性。所以咱们做的第一件事就是事务零碎和剖析零碎的拆散，把这些数据先做一次同步，同步到剖析零碎外面去。
剖析零碎专门为剖析做了很多优化，咱们会采纳列存、分布式、汇总、结构语义层等建模的形式，把剖析的数据模型简化与丰盛，而后进步数据分析的性能，这是面向分析师的零碎。
另外一个零碎叫 Serving 零碎，过来次要是 NoSQL，现在还有 HBase、Cassandra、Redis，这类零碎我也把它认为是一种类型的剖析，也是取数，它只是取数绝对比较简单，更多是通过主键进行取数。然而这类零碎也是通过数据来驱动的场景，更多是反对在线利用，也有数据高吞吐、更新等能力。
能够看到，数据从源头产生之后，个别有两个前途，一个是进入剖析零碎，一个是进入服务零碎反对在线利用。咱们会发现数据其实在不同零碎里产生了很多的割裂，之后就意味着数据的挪动，数据的搬迁，数据的依赖，接口的不统一，此时咱们开始想方法做翻新。
第一个翻新是在服务零碎和剖析零碎的边界处，咱们思考一个零碎是否既能够做剖析又能够做服务，这个想法比拟现实但在有些场景下的确也是适宜的。
然而这样的零碎也有一些限度，第一个限度是零碎的底线要保障事务。事务是对计算能力开销十分大的一件事件，能够看到绝大部分剖析零碎不反对事务，因为事务要带来很多的锁，如果有分布式锁的话，开销就会变得更大，所以这类零碎具备了肯定能力，但也就义了一部分的性能，因而在高并发场景下并不太适宜。
另一个限度是数据模型上的不适宜，在 TP 上产生的表可能有几百张，然而分析师不违心去看几百张的表，他更违心把几百张的表汇聚成几张大的事实表和维度表，这样的形式更合乎剖析语义层的要求。
综上所述，这个零碎很难做到数据模型上既能适宜 TP 零碎，又能适宜 AP 零碎，所以我感觉 HTAP 零碎的局限性比拟大。
另外一端的翻新是，咱们思考一个零碎是否既能够反对剖析的场景，查得足够灵便，又能够反对在线服务的场景，反对高并发，反对疾速的查问，反对数据的可更新，这也是很重要一个场景。
如果用一个零碎反对这两个场景的话，就会让咱们数据迁徙、数据开发的老本又升高了很多。
咱们看到这两个翻新零碎里很多共性的局部，比方数据根本以只读为主，根本没有锁的要求，都须要数据被加工、形象，能够看到这里定义的剖析零碎和服务零碎的共性是十分大的，有机会做翻新。
常见实时数仓架构选型参考
接下来咱们看一下 Flink 和市面上常见其余的数仓技术组合做实时数仓，从各个维度进行性能剖析。
例如 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
Hologres 的设计背地一个理念叫 HASP，就是同时反对 Hybrid Serving 和 Analytical Processing 两种负载，心愿做到对立存储，在数据写入的时候，不论是批量写入还是实时写入，用它能够使得写入效率足够的高。
其次，对象服务的时候对立服务接口，不论是外部交互式剖析的场景，还是在线点查的场景，都能够通过同样一个数据服务接口输入，通过把这两个场景交融在一起，进步开发效率。
- Hologres = Better OLAP + Better Serving + Cost Reduced
Hologres，附属阿里自研大数据品牌 MaxCompute，云原生分布式剖析引擎，反对对 PB 级数据进行高并发、低延时的 SQL 查问，反对实时数仓，大数据交互式剖析等场景。
在咱们的定义中，Hologres 是一个更好的 OLAP，过来 OLAP 零碎查得足够快、足够灵便等特点，这个零碎必须要具备。
其次它是个 Better Serving，过来点查零碎高吞吐的写入、更新、查问、10 万以上的 QPS 等能力，这个零碎也能够反对。
Cost Reduce 并不是示意这个零碎肯定很便宜，而是指咱们的学习老本、运维老本通过这个零碎能够急剧下降，这些都是咱们给零碎带来的收益。
云原生实时数仓解决方案：实时计算 Flink 版 + Hologres
在架构层面上，它是一个比拟灵便的架构。
数据实时接入进来之后，把加工层分成两个环节，一个叫明细层加工，一个叫汇聚层加工。
明细层加工的时候也是做荡涤、关联、转换，通过 Flink 来实现计算。加工完之后就能够把明细后果间接存下来，如果解决的是订单数据，这样根本就能够了，因为订单数据的数据量在千万规模的公司曾经算是比拟大的体量了。
这类明细数据间接对外提供报表服务，不须要做很多的二次汇聚加工。在清理加工的过程中常常会做维表的关联拉宽，这类点查场景在 Hologres 里边也是非常适合的。过来用 HBase/Redis 做的事件，在 Hologres 里边建一张表就能够实现。在明细加工阶段，既能够通过行表做拉宽，又能够用明细数据存下来，一读一写两种场景都能够撑持。
如果是行为数据、点击流数据的话，数据量往往更大，数据价值度更低，这个时候全存明细的话，剖析效率比拟低，此时能够去做二次的汇聚预加工。加工成一些轻度汇总层，就是轻度加工成 DWS 层，能够存下来也能够持续加工到 ADS 层，针对某个业务场景加工成一张最终的 ADS 后果集，也能够存下来。这类场景变成更小的数据，能够撑持更高的 QPS。
因而对上来说，这个数仓零碎给咱们提供更多的灵活性，做交互式剖析尽量存明细，做在线点查的话，就把这个表加工成一个能够依照主键进行查问的一个表即可，这给开发带来很多的灵活性。
加工也并不一定都是通过流计算的形式，有些状况下也能够通过数据存档明细数据，在数据库里边和做批量的调度都能够再持续做二次的汇聚预加工。
实时数仓场景 1：即席查问
Hologres 里定义了三种实现实时数仓的形式，第一种叫即席查问。
即席查问就是那种不晓得查问模式是什么样子，反正先把数据存下来，而后提供尽量多灵活性的场景。
因而，此时咱们就会倡议，尽量把操作层（ODS 层）的数据通过简略的数据品质的清理、关联，而后存到明细数据即可，先不做过多的二次加工汇总。因为此时应该怎么剖析数据都不太明确，能够通过视图封装，建很多 View 的形式，对外提供服务。
View 是对逻辑做很好的封装，把底下表的关联、嵌套等简单计算提前封装起来，但这个时候没有提前做固化，这样的话原始数据如果有任何的更新，咱们随时刷新一层数据，只更新一个中央的数据即可，不须要把下面所有的汇聚表更新，因为下面没有汇聚表，汇聚的是视图。
因而，这种计算的灵便度十分高，但它的查问性能不肯定是最好的，因为视图计算量十分大，每次查视图的时候都要对底下的原始数据做关联、嵌套，所以计算量绝对比拟大，适宜对 QPS 要求不高，对灵活性要求比拟高的场景。
实时数仓场景 2：分钟级准实时
第二种场景叫分钟级准实时，这种场景跟方才相比，对 QPS 要求更高一些，查问绝对更加固化。
此时，咱们就会把方才那些视图的局部，我就会把它物化成一张表，逻辑还是方才的逻辑，然而变成表了。变成表之后，查问的数据量就会小很多，晋升查问性能，这也是比较简单的形式，能够通过 DataWorks 的调度程序，用分钟级调度也能够实现准实时，5 分钟或者 10 分钟生成一个调度批次，可能满足绝大部分公司的业务场景需要。
通过这套形式，开发变得非常简单，任何环节、任何数据有谬误的时候，只有 DataWorks 调度从新运行就能够，运维也变得非常简单。
实时数仓场景 3：增量数据实时统计
还有一些场景对数据提早十分敏感，数据产生的时候必须就加工好，此时通过增量计算的形式，提前用 Flink 将明细层、汇总层等层层汇聚，汇聚之后把后果集存下来再对外提供服务，这就是增量计算的形式。
跟传统增量计算形式不一样的中央是，咱们倡议把两头的状态也长久化下来，益处是晋升后续剖析的灵便度，以及修改数据过错的老本会急剧下降。这也是咱们看到很多公司在用的形式，以前把数据通过 Kafka Topic 串起来全实时，一旦两头数据品质有问题的时候，Kafka 的数据很难修改，也很难查看哪里的数据有问题，查错老本十分高。
把每一条 Topic 数据同步到 Hologres 之后，一旦数据有问题，它在表数据库里边对这个表进行修改，而后在数据库里通过数据进行重刷，实现数据的修改。
Hologres 实时数仓场景 3 个场景抉择准则
在理论业务中，咱们能够依据不同的状况做抉择，Hologres 实时数仓场景 3 个场景抉择准则如下：
- 如果纯离线计算，优先 MaxCompute；
- 如果实时需要简略、数据量不大、只须要增量数据即可统计后果，适宜场景 3：增量数据实时统计；
- 如果有实时需要然而实时性要求不是很高，但开发效率优先，优先走分钟级准实时计划，适宜场景 2：分钟级准实时；
- 实时要求十分高，即席查问需要，资源较为短缺，适宜场景 1：即席查问。
阿里客户体验零碎 (CCO) 数仓实时化革新
CCO 服务经营零碎：数字化运行能力决定了消费者和商家的服务体验。
阿里客户体验零碎 (CCO) 实时数仓革新
实时数仓经验了数据库 -> 传统数据仓库 -> 实时数据仓库三个阶段。
- 业务难点：
1）数据复杂度高，加购、下单、领取、售后全渠道，90% 实时数据；
2）数据量大，日志（千万 / 秒)，交易（百万 / 秒)，征询(万 / 秒)；
3）场景丰盛，实时监控大屏，实时交互式剖析数据产品，ToC 线上利用。
- 技术架构:
DataHub + 实时计算 Flink 版 + Hologres + MaxCompute - 收益:
1）整体硬件资源老本降落 30+%；
2）高吞吐实时写入：反对了行存千万 / 秒，列存几十万 / 秒写入要求；
3）简化实时链路：面向公共层的开发和复用；
4）对立服务：同时撑持了多维分析和高 QPS 服务化查问场景；
5）MC-Hologres 查问服务：2020 双 11 当天查问 latency 均匀 142ms，99.99% 的查问在 200ms 以内；
6）撑持 200+ 实时数据大屏搭建，为近 300+ 小二提供稳固的数据查问服务。
电商营销流动剖析
接下来举一个营销的例子。
过来营销流动都是提前一个月做各种布局，包含在什么中央投什么样的广告，给什么人群投广告，投什么样的代金券等，但这件事在互联网畛域里有更高的要求。例如双 11 这类场景，对实时策略的调整需要越来越多，流动可能只有一天的工夫，咱们要实时地去理解成交排行，成交形成，库存状况，每个流量通道的转化率。比方关上一个网页，一开始要举荐的是某个商品，然而随着工夫流逝会发现，商品转化率十分的低，此时咱们须要调整营销策略。
因而，在这种实时营销的场景下，对实时数据分析的要求十分高，须要实时理解每个渠道，每类人群，每类商品转化率 / 成交率等，依据状况实时调整营销策略，最初进步转化率 / 成交率。
阿里外部计算大略架构如上所示，产品搭建应用 QuickBI，交互式剖析应用 Hologres，数据加工的局部通过 Flink 和 MaxCompute，这是一个比拟经典的架构。
实时计算 Flink 版 + RDS/KV/OLAP 计划
实时计算 Flink 版 + RDS/KV/OLAP 这套架构是晚期的计划，所有计算逻辑通过 Kafka 串起来加工的形式，而后用 Flink 汇总成后果集存起来，它的局限是开发效率和资源耗费十分大。
咱们晓得，数据分析可能是 N 个维度，例如工夫、地区、商品、人群、类别等，其中不同维度还能够进一步做划分，例如类别分一级类别、二级特地、三级类别，人群画像包含生产能力、教育水平、地区等，任何维度组合做关联剖析都会产生肯定的论断。
因而，咱们说过来的计算量十分大是因为要算 2 ⁿ种组合，能力把所有可能被剖析的角度都提前算好存下来，使得分析师看报表的时候，不论他抉择什么维度的组合，都能够找到对应的计算结果，但这个计算量是个天文数字，不可能有程序员写出这么多的计算，如果没有计算则没有后果集。
除此之外，如果咱们一开始算三个维度组合，忽然老板感觉这三个维度不足以判断出明天产生到底什么事，想再加一个维度。但咱们没有提前写这段逻辑，这时候上线数据曾经生产完了，没有方法从新计算出来，或者从新计算成本十分大，因而这是资源耗费十分大的一种办法。而且咱们开发完之后，计算了几千张两头表，这些后果集 / 组合关系是否有人应用，咱们无奈不确定，只能先算进去，放在数据库外面存一张长期表，老本十分大。
实时计算 Flink 版 + Hologres 交互式查问计划
如上所示，改革之后的架构其实没有实质的变动，还是那些加工的逻辑。最大变动在于通过视图的形式代替了很多两头加工的过程，视图在数据库外面做计算，把一部分计算前置的工作放在了计算后置。
原始数据还是通过消息中间件，通过 Flink 做解析去重，而后存着明细数据。明细数据不再做很多的二次汇总加工，而是通过很多逻辑视图，无论想看几个维度，能够随时写到 SQL 语句，视图能够随时上线，它并不影响原始的数据。这样的话，咱们想查什么数据它就算什么数据，所有的剖析负载没有节约，开发效率也会变得十分高。从过来要计算 2 ⁿ，到当初只存了一张明细，针对业务需要场景做一些轻度汇总层，DWD 和 DWS 的逻辑封装，建视图就能够了，大幅晋升开发效率。
运维老本要求架构具备很好的弹性伸缩能力，这也是 Hologres 具备的能力，在双 11 流量大十倍的场景下，能够随时弹性扩容，非常不便。
助力业务疾速决策调控
这带来了十分大的收益，过来须要很简单的计算逻辑流程，数据从产生到输入后果，可能须要几个小时的计算过程，这意味着咱们过了几个小时能力判几个小时之前的数据，调整业务逻辑想看后果的话又要等几个小时，整个业务的灵活性大打折扣。
应用 Flink + Hologres 这套架构之后，数据实时产生、实时剖析，随时能够做业务实时决策调控，剖析灵活性十分高。例如很多客户反馈，刚开始认为某些商品会卖得很好，后果到早晨发现跟预期齐全不一样，爆品反而是预期之外的商品。这些都是在提前打算好的报表上看不出来的问题，实在场景中有很多灵便上线新业务的需要，如果新业务能够在数分钟或者一小时之内上线，就可能解决这些灵活性的场景，这也是 Hologres 实时数仓带来一大收益。
高效的实时开发体验
咱们能够看到像大屏开发，大屏里边有几十个不同的指标，以前这类零碎开发的时候也是比较复杂，要拿不同的数据源做不同的汇聚，通过不同的调度才可能生成这样的数据。
应用 Hologres 之后，2 人日就能够实现开发，因为背地不须要那么多调度，写几条 SQL 语句即可，大幅晋升开发效率。
它单日写入能够撑持 500 亿条以上记录，峰值写入 QPS 为 100W+/s，查问响应提早小于 1 秒，不论是在写入数据量还是剖析体验都做得十分不错。
Hologres 数仓开发三阶段
Hologres 不仅有建实时数仓，有准实时、全实时、增量实时等不同计算形式，在公司数仓建设的不同阶段，Hologres 有不同的应用形式，包含摸索形式、倒退形式和成熟形式。
摸索形式是对灵便剖析需要比拟多，数据模型也不太固定，分析师不确定想怎么应用数据的场景。因而这个时候数仓建设以明细层的汇聚为主，首先要把公司的数据集中化，数据不集中的话，剖析效率无奈保障。以 ODS 建设为主，DWD 为辅，给 ODS 层做肯定的品质保障，把数据的荡涤、关联、拉宽等根本工作做好，生成一些 DWD 明细层数据，而后在明细的数据之上间接提供剖析，肯定要把 ADS 层做薄，下面不要做很多的调度、汇聚。因为这时候剖析数据的办法还不确定，以上层建设为主，在 Hologres 里能够存明细数据，用列 / 行存都能够。
第二个阶段叫疾速倒退阶段，这个时候的次要特色个别是公司开始思考数据中台，开始储备数据产品经理、数据分析师这样的角色。此时开始积淀公司的指标体系，积淀公司可被复用的数据资产，DWD 曾经不满足了，要持续在 DWD 之上做一些面向可复用的宽表，一些性能要害的场景还能够做二次加工汇聚变成 ADS 层表。Hologres 有行 / 列存，可被复用的指标根本是用列存为主，如果须要 ADS 点查场景，能够持续二次加工变成行存。
第三个阶段进入成熟稳固阶段，此时公司的指标体系绝对比较完善，有很多可被复用的指标，就须要从之前依照业务场景的汇聚往下积淀成 DWS 可被服用的汇聚层，很多公司的公共指标要变成公司的指标库，这时候以 DWS 建设为主。
在这个阶段 Hologres 也提供技术支持，能够看到从 DWD 到 DWS，Hologres 反对内置的 Binlog 驱动能够做继续的汇聚工作。
能够看到，数仓建设分为不同阶段，不同的阶段有不同的建设重点，在不同的建设阶段，能够采纳 Hologres 不同的技术来适应不同的需要。
总结
最初咱们总结一下，Hologres 是什么？
首先 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 架构，用一套更简略的架构撑持多个场景，实现更优性价比。
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
