如何理解实时数据中台？
极客时间编辑部
讲述：初明明大小：4.24M时长：04:38
流式数据一经采集，就可以立即参与计算，并将计算结果投入到业务应用。实时数据计算早已经进入到人们生活的方方面面，越来越多的实时计算场景被开发出来，有越来越多的业务需要“实时计算”能力，建设更好的数据中台才能服务业务。
在实践中，阿里总结了一套通用的支撑实时数据中台构建的方法，InfoQ 对此采访了阿里巴巴资深技术专家姜伟华，他表示：“实时数据中台的实践往往是八国联军齐上阵，各种引擎各负责一小块，形成了大量的数据重复和孤岛。”
姜伟华对“数据中台”的定义更偏底层一些，他认为中台相比平台最大的区别是：平台的业务化能力和复用能力。平台建设更多的是用户或者业务来适应平台，平台提供了什么组件，用户就用什么组件，且不管好不好用。而中台更强调的是给用户提供好用、易用的高质量平台，让用户自助，缩短 Time to Market (TTM)，同时能快速响应变化。
对于“实时数据中台”，姜伟华表示，数据中台的时效性是数据中台的价值倍增器。这里说的时效性是一个泛概念，包含了实时数据、实时分析、如何让业务自助快速进行分析、如何快速响应业务变化等等。数据本身的价值是随着时间推移而快速降低的。只有把这几个方面做好，才能充分体现数据的价值，让数据中台更好的为业务服务。
目前建设实时数据中台，主流的架构是 Lambda 。但这个方案其实有很多痛点，比如多套系统、多份数据、链路长且不可靠；数据业务化的能力很差；响应业务变化的能力很差；数据治理能力差等等。目前该方案仅仅解决了能用的问题，离好用、易用、更好的服务业务还差的很远。
姜伟华认为数据中台的实时化，或者说实时数仓，更加理想的架构应该是流计算 + 交互式分析这样的双擎架构，以带实时存储的交互式分析为中心去构建整个实时链路。数据经过流式 ETL 之后，实时导入实时存储中。在这个实时存储之上，通过交互式分析实现即用即查。从而将大数据实时数仓的体验和传统的单机 OLAP 数据库体验对齐，最大程度简化链路和用户体验。
在这个架构中，流计算负责的是基础数据，而交互式分析引擎是中心。这个引擎一定是自带存储的，通过计算存储的协同优化，实现高的写入 RPS、高的查询 QPS 和低的查询 latency。这样就可以用批的方式实现实时分析和按需分析，并能快速的响应业务的变化。业务方使用他们熟悉的开发工具和开发语言（SQL），就像开发单机一样，去开发基于大数据的实时应用，实现体验的最优。
另外，实时数据中台的实践往往是八国联军齐上阵，各种引擎各负责一小块，这些数据引擎包括 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 的效果。
以上就是姜伟华对于构建实时数据中台的经验分享，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论