补齐OLAP引擎短板！ByteHouse 是如何实现流批一体的？

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

计算机领域一直流传一句话——“没有银弹”，这句话出自计算机科学家布鲁克斯《没有银弹》一书，意思是软件工程是一个超级复杂系统，没有任何特效的方法，可以一直提高效率。

在数据库选型当中也是如此。一款面向实时查询场景的计算引擎，在离线场景的表现可能会稍显逊色。

以某内容APP对OLAP引擎选型为例。该内容APP基于OLAP引擎构建了支持全公司的数据平台，覆盖业务线多、复杂度高，对数据分析的要求也非常高。在APP的直播场景中，主播、商家需要直播间核心实时数据，在直播过程中依据数据做相关决策，比如在流量下降时投流、发福袋等。而OLAP引擎具备高性能、时效性强、弹性扩容的特点，能满足实时查询的诉求，成为该内容APP对计算引擎的首选。

但在一些不需要实时数据的场景中，例如内容APP日报、周报、月报等数据，往往是T+1时间产出，OLAP引擎就很难满足需求，反而需要再搭配Spark、Hive、MapReduce等批处理平台共同使用。

一方面，这样的组合方案会导致数据链路复杂，操作成本高。为了保证OLAP引擎和其他批处理平台的数据一致性， 研发团队要建立稳定的数据同步管道，这将增加开发成本，造成系统复杂度高，对日常运维和故障排查带来难题。另一方面，两者都需要占用一定的计算和存储资源，导致资源消耗较大，同时也会造成数据延迟。

近期，火山引擎云原生数据仓库ByteHouse上线的“离线加工”能力则一举解决这一问题。

ByteHouse 云数仓版一直具备强大的实时数据消费能力，通过设计新的实时消费执行流程、实现 Exactly—Once 语义以及对 Memory buffer 的优化，ByteHouse 具备了对 Kafka 流数据的集成能力。

据介绍，ByteHouse 在云数仓版的全新版本中支持了完整的离线加工能力，使得作为轻载数仓的 ByteHouse能同时兼顾实时数据的查询效率和离线加工任务的稳定性，大大降低运维压力，简化数据开发链路，为用户提供更优越的企业级数仓体验。

性能、效率、成本在行业中一直被认为是“不可能三角”，如果用户将ByteHouse作为统一的数据分析平台，则可以最大程度实现性能、效率、成本的“三赢”。

ByteHouse“离线加工”能力架构图

从性能层面来看，作为高性能的列式数据库，ByteHouse的查询引擎和聚合能力能提升离线计算速度，帮助用户更快进行离线数据处理、聚合和转换，缩短任务执行时间，提高数据处理效率。

从效率层面来看，ByteHouse将实时查询、交互式分析与离线数据加工的处理流程整合在同一个平台，不仅仅能保证数据的一致性和准确性，避免数据在系统流转中出现不一致的问题，还可以简化数据处理架构，研发人员不再需要维护和管理多个工具、系统。另外，ByteHouse使用SQL作为查询语言，研发人员可以利用熟悉的SQL语法进行数据查询、聚合和转换操作，无需学习新的编程语言或框架。

从成本层面来看，ByteHouse的列式存储和压缩算法在提升查询速度、缩短响应时间的同时，还可以减少数据存储的占用空间，降低存储成本。

随着数据分析和计算的场景愈多，链路愈加复杂，企业更需要统一的平台、简单的架构、便捷的运维，才能支撑业务快速发展。ByteHouse不仅专注于强化实时计算能力，还补齐了离线任务加工场景，通过结合任务编排和开发工具，支持复杂的 ETL 处理流程，适用于企业用户行为分析、人群圈选、风控等更丰富的场景。

此次“离线加工”新能力的发布，仅仅只是ByteHouse产品迭代版图上的一环。作为源于字节跳动多年积累的云原生数据仓库，ByteHouse不断提升用户体验，帮助企业更好地构建交互式大数据分析平台和云原生数据仓库。目前，中国地震台网中心、海王集团等已与火山引擎ByteHouse达成合作，率先通过海量数据实时分析的极速体验，辅助决策落地，加速业务洞察，实现自身数字化升级的进一步加速。

 点击跳转火山引擎ByteHouse了解更多