看场景、重实操，实时数仓不是“纸上谈兵”

本文转载自阿里云Hologres产品负责人合一在ITPUB的访谈，谈谈他眼中的实时数仓， 原文链接： https://mp.weixin.qq.com/s/RZMWf9r4fKV9mNoGGUtaVw

这两年，企业IT领域掀起实时数仓热潮。然而，只要稍做梳理就会发现，实时数仓格局未定，各种流派群雄逐鹿，还有很多需要进一步探讨的话题方向。

比如：实时数仓是什么？如何从概念上去定义？有人认为，传统数据仓库做了实时化，就是实时数仓；有人认为，云数仓、湖仓一体是实时数仓；还有人认为，HTAP是解决实时数仓需求的一个重要手段！

再比如：实时数仓是一款产品，还是一个解决方案？99%的企业都会认为是一个解决方案，1%的企业会认为是一款产品，这1%就是阿里云！

为了弄清事实真相，帮助用户找到应用选型“快速通道”，本期实时数仓系列访谈，特邀请到阿里云自研大数据平台产品负责人刘一鸣（合一），请他从实时数仓的技术演进、应用场景、架构以及Hologres自身实践角度，一层一层揭开实时数仓的“谜团”！

阿里云自研大数据平台产品负责人刘一鸣（合一）

实时数仓进化

如果，非要给实时数仓下一个定义，一定要符合从1.0到3.0时代的进化特征。

首先，得是一个数仓，具备规模数据的交互式分析能力。实时数仓不只是“实时”，很多系统不支持标准SQL，不能算数仓。所以，属于1.0时代的实时数仓，有一个重要前提，就是支持较为完善的SQL以及优秀的大规模分析能力，因此很多系统采用了分布式、列存、索引、压缩等数仓加速的技术。

其次，面向实时场景做了针对性优化，包括实时写入、实时分析、实时取数等。如果和普通数据库相同，没有针对实时场景做优化，很难达到实时数仓对吞吐和分析的时效性要求。实时数仓需要具备高吞吐写入和更新能力，数据写入即可用，支持灵活的数据更新。比如：很多普通数据库，虽然能写也能查，但当数据规模放大到一定规模，要么牺牲了写入性能保查询，要么牺牲了查询性能优化写入，无法针对实时数据多场景进行优化，这不能算好的实时数仓。

进入2.0时代，实时数仓就要尽可能快地支持在线业务。企业之所以做实时数仓，是希望数据进来之后能够被足够新鲜地消费，能实时写入、实时分析，还要支撑在线服务。在线服务场景需要更高的性能、低抖动、稳定性、并发能力，对在线服务场景进行支持，是实时数仓关键一环。

而3.0时代的实时数仓，可以定义为一站式实时数仓。这个时候的实时数仓，不仅具有高吞吐写入与更新、端到端的全链路实时加工以及低延迟高并发在线服务能力，在保证数据一致的前提下，需要支持多种负载之间完备的隔离和弹性能力，以确保各个业务互不干扰，各自按需使用资源。同时实时数仓的使用通常离不开离线数仓的组合关系，通过离线平台对历史数据的周期性汇聚、抽象和加工，并将结果数据导入实时数仓进行丰富和修正，需要更有效地打通实时与离线两套系统，实现元数据和数据的无缝交换，这也是实时数仓落地时需要具备的能力。这种一站式体现在存储状态的一致性，减少了不同负载之间的数据同步和存储开销，避免了数据服务层的数据孤岛难题。

所以，实时数仓既不是传统数据库的旧瓶装新酒，也不是湖仓一体的多产品组合，它和离线数仓的本质区别是，通过对易变数据结构（包括内存结构、文件存储）和计算资源的细粒度灵活管控，更好地支撑数据的实时写入、实时更新、实时查询 。 至于，很多公司之所以把实时数仓定义为是一个解决方案，是因为技术相对更加复杂，既要考虑写入和加工能力，又要支持查询和在线分析场景，不得已针对不同技术需求将多种技术栈堆砌在一起，包括采用流式计算、消息中间件来达到端到端的实时加工，采用列式数据库应对分析需求，采用行存系统支撑在线服务系统，并依赖复杂的调度配置，实现数据在中间件、存储系统之间的最终一致性。而将复杂技术落地成为一款易于使用的成熟数仓产品，仍然是少数技术创新者在努力的方向。

阿里云Hologres，整体技术水平领先业界1-2年，是基于在阿里巴巴内部数据技术的广泛应用与沉淀，一步一步走过来的。阿里有海量数据的复杂应用场景，有历年双11等大促的深度压力测试，有在存储和计算领域深扎多年的技术专家，有上万名数据小二支持业务的灵活需求与快速迭代，这些都是其他公司不具备的得天独厚的条件，推动着阿里在数据技术领域的持续创新。

Hologres支撑的业务的规模、复杂性和对效率的极致追求，实现了通过有些开源技术组合无法达成的数据价值目标。行业内不少企业采用部分开源技术栈，如：用Kafka做中间件，用Hudi做离线存储，用Presto做离线查询加速，用ClickHouse做OLAP查询，用Flink做流式数据加工，用MySQL做缓存，用HBase做在线服务引擎。这些架构也是阿里采用过的第一代实时数仓架构，但当开发效率遇到瓶颈时，当数据链路复杂到成为运维负担时，当数据不一致不得不80%时间在对数排查时，工程师们开始思考是否还有更好的解决方案，是否有一个更加集中化、一体化、能力更全面的数仓选择。而Hologres的出现也就重新定义了实时数仓的形态。

基于此，OLAP查询和在线服务使用Hologres，满足分析的灵活和效率，离线数仓使用MaxCompute，支撑规模性和Serverless扩展性，实时流式计算用Flink，凸显端到端全实时加工，三者的结合让实时和离线计算，分析和服务都能达到一个非常好的平衡，满足业务的多种需求。

阿里云Flink版的出处与Hologres的渊源

有人可能会说，阿里云Hologres+Flink这套组合也用了Flink，和其他解决方案相比，有什么不同呢？

没错，Hologres要想发挥最佳水平，与Flink结合，一定是首选。实时计算需要后台有一套强大的大数据计算能力，而Apache Flink作为一款开源大数据流式计算技术，从设计之初就由流计算开启，相比传统的Hadoop、Spark等计算引擎，更能确保数据处理的低延时，让数据在第一时间发挥价值。

早在2016年，Apache Flink捐献给Apache之后的第三年，阿里已经开始大规模上线使用实时计算产品，用于阿里最核心的搜索推荐以及广告业务场景。2017年，基于Flink的实时计算产品，开始服务于整个阿里巴巴集团，同年双11服务全集团的数据实时化，包括双11的实时大屏。2018年，基于Flink的实时计算平台产品不仅服务于集团内部，同时开始服务于云上中小企业，以公有云的形式对外提供服务。2019年，阿里巴巴收购了Flink的创始公司-Ververica，阿里的Flink实时计算技术团队和德国总部的Flink创始团队，组成全球顶领先的Flink技术团队，共同推进整个Apache Flink开源社区的发展。

用户通过Flink可以把数据实时写入到Hologres，也可以通过Hologres做维表关联。如此一来，离线分析走MaxCompute，数据的点查、联邦分析以及OLAP分析走Hologres。举一个维表加工的例子，Flink每次加工进来之后，每一条事件都要跟维表做关联，比如：事件数据中包含了渠道ID，在分析时需要知道是什么渠道类型，因为要通过加工链路将ID还原为渠道属性，这种关联有时候每秒钟要达到上万、上十万的 QPS。过去，很多业务团队采用HBase来支撑这类点查业务，但HBase没有 Schema，数据写错很难发现，很难修正；现在，Hologres只用过去50% 的资源，支撑了HBase完整的业务。

与开源Flink相比，阿里的实时计算Flink版进行了多处核心功能的优化，在存储、网络和传输等方面都调整到满足业务场景所需要的效果。并且，阿里云Flink版和Hologres做了大量的结合优化工作，不仅支持维表到结果表，也支持通过阿里云Flink的全量读取、Binlog 读取、CDC 读取、全增量一体化等多种方式读取 Hologres 源表数据，尤其是阿里云Flink支持读取Hologres Binlog，就使得Hologres能够达到像Kafka等消息中间件同等的能力，一个 Hologres Table 的数据既可以提供给下游阿里云 Flink 任务消费，还可以对接上游 OLAP/在线服务查询，不仅节省了成本，还简化数仓架构，同时也让数仓中的每一个层次都可以实时构建、实时查询，提升数据的流转效率。在元数据管理方面，阿里云Flink版与Hologres元数据打通，支持Hologres Catalog，实现元数据的自动发现和管理，也大大简化了开发和运维管理工作。

HSAP分析服务一体化的独特之处

Hologres是两个英文单词的组合，即Holographic+Postgres，Holographic来源于物理学，Postgres代表的是PostgreSQL生态。

从物理学原理看，地球没有被黑洞吸进去，是因为有一个临界点，这个临界点所组成的面，被证明是一个球面，也叫世界面。与此同时，黑洞里所有信息在世界面上都有投影，即3D全息投影技术。Hologres想做的事情是，通过产品化的能力对数据黑洞做全息展示。

为了简化数据存储和统一数据服务，阿里云提出了HSAP架构理论 (Hybrid Serving & Analytical Processing，后续简称HSAP)，而Hologres是实践HSAP目标的一个具体实现。Hologres的目标是，做分析服务一体化的实时数仓，典型特征是：存算分离的云原生架构、多负载隔离、端到端实时毫秒级的交互式分析体验、超高QPS的在线服务能力等。从应用场景来看，既可满足实时数仓的需求，也能对离线数据进行查询加速，同时还可实现实时与离线数据的联邦计算，为用户构筑全链路、精细化运营能力。

为什么说分析服务一体化能力特别重要呢？

以广告推荐为例，这是一个非常典型的在线服务场景，如果一个人收藏了一个链接，他就会获得相应的广告推荐，该推荐包含了你过去30 天、60天或者90 天里的行为，还包括你的教育程度、家庭关系，这些是典型的离线特征。对于后端技术平台来说，这些行为不用每天去算，每周算一次就可以。但另一部分特征是实时的，比如你当下点了什么内容，对什么感兴趣，跳转了什么链接，这部分行为就需要通过Flink 这样的流式计算实时处理。只有把实时和离线两部分信息结合起来做推荐，才有全面的360信息，使得推荐更加精准，更加具备上下文相关性。

过去，没有Hologres之前，如果一个大数据系统要支撑广告推荐业务需要写一条很长的链路，反复同步数据，这很难提供灵活敏捷的数据服务，大量数据作业开发成本很高，出现数据不一致等问题。阿里的工程师尝试把问题简化，让数据不动，通过Flink或者MaxCompute加工好的数据，直接提供在线服务，这就需要把Serving场景做强，面向应用程序，或者面向API 消费数据的场景时，要有高QPS、低延迟能力。

而针对Analytics能力，很多企业都会基于OLAP引擎做数据分析。这部分数据一般会有两个出口：一个出口是给机器使用，通过API访问，主要是推荐系统和风控系统；另一个出口是给分析师使用，通过SQL访问，看报表，做对比分析，找到趋势变化。这两个出口的数据需要保持一致性。Hologres作为交互式分析引擎，针对两个场景做了执行优化。在支持在线的高 QPS 服务型查询时，这类查询逻辑相对简单，但并发高，因此采用了Short-Cut技术，通过FixedPlan执行优化，减少在SQL解析优化和调度层的开销，请求直达存储节点，延迟更短；在支持分析师的复杂多维分析时，采用MPP分布式计算框架、列式存储和向量化引擎，有效率大范围过滤数据，保障了亿级数据的秒级数据分析。这样，通过Hologres统一数据服务出口，同时支持在线服务和多维分析两个场景。

Hologres借鉴了主流的数据架构，包括采用类似LSM-tree(Log-Structured Merge Tree)这种高吞吐写入和更新友好的存储架构，利用了CPU指令向量化、异步化的最新技术创新，基于云原生的计算存储分离架构，形成了一款低门槛的生产级产品。Hologres在协议层面上用到了PostgreSQL的这种协议，简化了与业务系统的对接，应用无需重写，也没有厂商引擎绑定，开箱即用，核心的存储引擎、查询引擎是阿里自研的一套系统，持续改进效率、稳定和易用。

Lambda 与Kappa的纷争

其实，最早阿里云没想到要做实时数仓，只是想把实时和离线数据实现一体化。

换言之，阿里云的HSAP架构也是由Lambda架构走过来的。众所周知，Lambda架构有一个优势，既支持流式数仓，又能满足离线数仓的计算要求；但是也有一个弊端，就是流和批分为两套技术栈，运维要维护两套系统架构。后来，Kappa架构出现，有人认为能很好地解决Lambda架构的问题，但事实并非如此。因为企业的数据加工永远会有实时和离线两条链路，这是数据加工作业的属性决定的。实时链路数据总会晚来，或者不来，数据质量并不可靠。所以，只有实时链路，解决不了数据质量问题，还需要离线链路对实时链路的修正和丰富，而依赖消息中间件支撑海量数据的回刷是成本极高及不稳定的架构。也就是说，只要有离线场景，Lambda架构就有存在的合理性。

但问题是，Lambda架构一定需要两套系统，这该如何解决？本质上，还是技术的割裂，导致架构不统一。好的Lambda架构，应该是状态层统一的，实时的业务逻辑和离线的业务逻辑尽管加工链路不同，但存储层应该统一，减少数据割裂和不一致，通过实时和离线两套业务逻辑相互补充，离线的业务逻辑对实时数据链路进行修正。

在Lambda架构实践过程中，很多企业实时业务用HBase，离线业务用Hive，这种存储割裂状态，导致数据不一致，口径不一致。正确的架构选择应该是Lambda的改进版，把数据状态统一存储在一个存储系统，这个存储同时支持离线批量导入，也支持实时更新与查询，这也是一种可落地的批流一体实践。

虽然，有些企业在推Kappa，但从实践的角度看，Kappa其实是个伪概念，因为实时业务系统如果取代离线，意味着数据要频繁地修正、更新，而Kappa无法从根本上解决这个问题。目前，推Kappa架构的企业，大部分是消息中间件厂商，或者一些纯粹做实时的团队。他们假设了一种状态，所有的数据都可以通过消息中间件恢复。但现实是，企业不会把所有的状态都通过消息中间件去回放，或者长期存储。所以，通过消息中间件替代数据库的方式，只有消息中间件厂商在力推，不具备广泛落地的参考意义。

在阿里内部，HSAP架构把分析和服务两个场景放在一起，解决了数据不一致问题，减少了数据同步的开销，避免了数据孤岛，数据加工链路保持了实时和离线双链路，实时业务系统解决时效性问题，离线可以为实时业务系统进行修正和丰富，两条链路各解决各自的问题，使得实时和离线由一套系统承载，也就真正实现了流批一体。

下一代实时数仓更重实操

到今天为止，Hologres作为标准产品对外提供服务已经两年多，每年客户数都是三位数增长。在实践中，60%的用户主要使用OLAP场景，20%主要使用Serving场景，还有20%做到了HSAP混合负载的优化架构，通过技术创新为企业降本提效。实时数仓还处于发展过程中，相信随着大数据的不断推动，实时数仓会成为推动业务发展的“有力抓手”。

过去，数据团队更偏内部业务场景，主要的工作就是给管理层出报表，做领导驾驶舱。但在今天，数据团队正从成本中心转为盈利中心，大数据团队要想去影响业务，提升价值感，包括风控、实时画像、实时推荐等手段，是提升业务的主要入口，这也是实时数仓需求快速增长的最根本原因。实时数仓会成为大数据平台里一个重要组成部分，是数据消费端的核心组件。

当然，实时数仓并不是一个新事物，从有数仓开始，用户需求一直存在。但是，因为方案的不成熟，很多都是由开源组件堆在一起，从开发和运维成本上看，技术门槛比较高，导致实时数仓没有实现规模化发展。企业必须招聘来自BAT的人才才能玩得转实时数仓，这个是不正常的，也不是时代发展的趋势，技术一定会普惠化，所有的企业都会用上大数据，但不应该所有的企业都成为技术专家。

真正受市场欢迎的实时数仓产品，简单、易用是前提，能处理海量数据，不用懂很多参数，不用写很多程序，能做到只会写SQL就可以上手。另外，企业希望数据写进来就能用，尽量减少数据加工过程，减少数据链条，实现敏捷化。即使业务方突然提出一个新需求，只要改下SQL就可以了，不用做任何数据重刷，对开发效率提升来说，带来的是根本性的转变。

所以，下一代实时数仓到底如何发展？ Hologres已经“打好样”！那就是技术门槛会越来越低，同时计算力会越来越强大，使用方式越来越简单，不仅数据能实时写得进来，还要在原始数据上直接做分析，查询要足够快，并发足够高，取数不用等，需求不求人。希望通过Hologres这样的产品，能够将实时数仓变得更加普惠化、敏捷化，让各行各业的数智化建设迈上新台阶。