本文整理自直播《实时数仓助力互联网实时决策和精准营销-合一》
视频链接: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架构，用一套更简单的架构支撑多个场景，实现更优性价比。
活动推荐
阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：
99元试用实时计算Flink版(包年包月、10CU）即有机会获得 Flink 独家定制T恤；另包3个月及以上还有85折优惠！
了解活动详情：https://www.aliyun.com/product/bigdata/sc
