流式数据一经采集，就可以立即参与计算，并将计算结果投入到业务应用。实时数据计算早已经进入到人们生活的方方面面，越来越多的实时计算场景被开发出来，大家对“一切都在变化之中”的感受越来越深刻。有越来越多的业务需要“实时计算”能力，建设更好的数据中台才能服务业务。

实时计算技术这几年也在急剧变化。实时计算架构，从最早的 Lambda，到 Kappa 架构，再到现在的流计算+交互式分析双擎架构；流计算框架，从 Storm 到 Spark Streaming 到 Flink；实时计算结果存储，有 Redis、HBase、MySQL 等等。阿里巴巴资深技术专家姜伟华表示：“实时数仓的实践往往是八国联军齐上阵，各种引擎各负责一小块，形成了大量的数据重复和孤岛。”

在实践中，阿里总结了一套通用的支撑实时数仓构建的方法，我们对此进行了采访。他将在ArchSummit 北京做主题为“实时计算+交互式分析双擎解决数仓实时性的短板和痛点”的演讲。

姜伟华，阿里巴巴资深技术专家。曾长期在 Intel、唯品会等公司工作。在 Intel 期间，创建并负责 Intel 大数据研发团队，创立 Intel 大数据发行版，并连续多年保持国内市场占有率第一。领导 Intel 大数据开源，团队涌现出10+ Apache Committer，创立两个 Apache 项目。曾获 Intel 最高奖（Intel Achievement Award）和 Intel 中国最高奖（Intel China Award）。在唯品会期间负责大数据平台与AI平台。现在阿里巴巴从事新一代大数据交互式分析引擎的研发工作。

InfoQ：你能定义“数据中台”是什么吗？

姜伟华：数据中台这个概念很热，每个人对它的理解也不一样。从我自己的理解来说（更偏底层一些），中台相比平台最大的区别是：平台的业务化能力和复用能力。平台建设更多的是用户或者业务来适应平台。平台提供了什么组件，那么用户只能用这些组件（不管好不好用）。而且这些组件可能是互相割裂开的。而中台更强调的是提供用户好用、易用的高质量平台，让用户自助，缩短 Time to Market (TTM)，同时能快速响应变化。

InfoQ：你如何定义“实时数据中台“？能解决什么痛点？

姜伟华：数据中台的时效性是数据中台的价值倍增器。这里说的时效性是一个泛的概念，包含了实时数据、实时分析、如何让结果快速为生产系统获得、如何让业务自助快速进行分析、如何快速响应业务变化等等。数据本身的价值是随着时间推移而快速降低的。只有把这几个方面做好，才能充分数据的价值，让数据中台更好的为业务服务。

目前实时这边，主流的还是 Lambda 架构。但这个方案其实是有很多痛点的，仅仅解决了能用的问题，但离好用、易用、更好的服务业务还差的很远。

主要的痛点是：

多套系统、多份数据、链路长且不可靠。简单来说，就是实时链路和离线链路是完全分开的，互相没有关系。那么相同的数据、逻辑都需要在两边各做一遍。逻辑对齐很困难。同时，链条中环节比较多，涉及到很多的同步任务。某个环节出问题的监控和定位都相对困难。

数据业务化的能力很差，业务方必须要懂专门的实时计算知识才能开发相关的实时任务。这往往导致实时业务开发沦为实时平台团队的主要工作内容。

响应业务变化的能力很差。一个新需求离线可能1天就开发完了，实时这边可能要一周甚至更长的时间。

数据治理比较差。对于实时这边，数据治理一般都比较弱。因为存储、计算都是完全独立的，所以常规的数据治理手段在实时这边基本都不能用。这就导致实时链路的可靠性相对比较差。

我们认为数据中台的实时化，或者说实时数仓，更加理想的架构应该是流计算+交互式分析这样的双擎架构，以带实时存储的交互式分析为中心去构建整个实时链路。数据经过流式 ETL之后，实时导入实时存储中。在这个实时存储之上，通过交互式分析实现即用即查。从而将大数据实时数仓的体验和传统的单机 OLAP 数据库体验对齐，最大程度简化链路和用户体验。

InfoQ：你有多年的实时计算经验，关于“实时”您认为业界哪些大的变化不得不提？

姜伟华：首先，实时不等于流计算。对实时的理解也是一个发展的过程。从最早的 Lambda 架构，到后来提出的 Kappa 架构，再到现在我们推的流计算+交互式分析双擎架构。

架构的演进本质上都是在往批流一体这个方向发展。让用户能够以最自然、成本最小的方式完成实时计算。其次，全链路的实时化和 SQL 化是一个非常明确的趋势。一方面，越来越多的业务需要实时（这个实时很多时候指的是分钟级的延迟和可接受的实现代价），另一方面，能用SQL（最好是标准 SQL）表达所有环节的计算也是很明显的趋势。

再者，如何让业务方参与进来，而不是让平台方独自完成是实时数据赋能业务的关键。将业务开发从实时平台同学还给业务同学。只有业务同学才最深刻的理解业务需要什么。最后，如何让实时系统能快速响应变化，缩短TTM时间变得越来越重要。传统实时开发一个应用往往会比离线数仓开发慢一个数量级。如果将开发时效达到和离线数仓相同甚至更高的水平会是越来越强的需求。

InfoQ：“实时数据中台的实践往往是八国联军齐上阵，各种引擎各负责一小块“，这些数据引擎包括哪些？为什么现在它们都还存在于系统中？未来是否都能被Flink取代？

姜伟华：生产系统中，一般实时链路包含了 Kafka，Storm/Flink，Redis/HBase/MySQL 等组件。其中，每个组件实例一般只做一件事情，比方说Redis用来做实时ETL的查表，Storm/Flink/Spark Streaming 用来做实时计算，Redis/HBase/MySQL 用来做实时计算的结果存储等等。因为链路比较长，所以有大量专门的同步任务将数据在不同的系统之间同步。

实时系统因为历史原因，Storm 等还广泛应用于生产系统中。用 Flink 去替换这些系统是在缓慢但稳健的进行中的。一方面 Flink 的优势非常明显，在流处理领域基本已一统天下；另一方面，实时生产系统的替换要比离线数仓换一个 SQL 引擎麻烦的多。需要逐个替换，并需要验证在极端情况下的稳定性。

但在现有的 Lambda 架构下，整体流程和模块是基本稳定的，变的更多的是每个模块内用什么引擎（比方说 Storm换成 Flink）。只有整个架构的更新，才会完全改变现有的链路和模块，比方说，我们推的流计算+交互式分析双擎架构就可以极大的简化这个实时链路。这里像 Flink 这样的流引擎，可以更关注在实时 ETL 和关键系统的实时计算上，而分析类的应用用交互式引擎更为合适。两者配合，实现1+1>2 的效果。

InfoQ：“批流一体”，你能大概描述下怎么实现吗？

姜伟华：我们认为在实时数据上，流计算+交互式分析双擎架构是一种各方面都比较完美的架构。在这个架构中，流计算负责的是基础数据，而交互式分析引擎是中心。这个引擎一定是自带存储的，通过计算存储的协同优化，实现高的写入 RPS、高的查询 QPS 和低的查询 latency。这样就可以用批的方式实现实时分析和按需分析，并能快速的响应业务的变化。业务方使用他们熟悉的开发工具和开发语言（SQL），就像开发单机一样，去开发基于大数据的实时应用，实现体验的最优。

精彩会议推荐：在12月6日北京 ArchSummit 架构师峰会上，姜老师将分享一种通用的支撑实时数据中台构建的方法与实践，实时数据中台构建的挑战与技术难点，帮助您透彻了解数据中台的难点。感兴趣可以点击阅读原文。会议正在9折售票中，购票可联系票务经理灰灰：微信15600537884

创作场景

专访阿里姜伟华：实时数仓，如何能做得更好？