本文转载自阿里云 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 这样的产品，能够将实时数仓变得更加普惠化、敏捷化，让各行各业的数智化建设迈上新台阶。