近日，火山引擎数字智能平台VeDI与DataFun联合举办了主题为“OLAP计算引擎”的直播活动。 火山引擎数字智能平台VeDI的产品专家从技术选型、能力分析、性能优化和应用场景等方面实施了多种解决方案。 从角度介绍了火山引擎ByteHouse如何基于ClickHouse实现实时算力升级。
据介绍，火山引擎ByteHouse来自于字节跳动内部多年的沉淀。 由于场景日益丰富，数据分析需求不断增加，业务对数据仓库的实时性要求越来越高。 首先是数据量大且持续增长的问题。 早在2019年，Byte每天新增的数据量就达到了100TB。 其次，基于海量数据，数据类型多样（包括批量数据和流数据）、查询需求多样、交互分析复杂，数据引擎需要灵活。 目前业界Redis、SparkSQL等开源解决方案可以从不同角度满足以上两种需求。 然而，维护多个开源数据库会导致高昂的成本。 选择能够避免成本无限制扩张的计算引擎，成为了字节数据研发的首要考虑因素。 。
ClickHouse性能高、灵活性强，且主要依赖磁盘，成本相对可控，成为字节跳动内部计算引擎的首选。 但原生的ClickHouse能力很难支持一些翻转、数据实时更新等场景，并且在很多层面上都有局限性，例如：
·单表性能较强，但多表能力有限，对标准SQL的兼容性较低。
缺乏成熟的运维管理工具，运维复杂度较高。
·ClickHouse是MPP架构（存储计算一体化架构），性能较强，但水平扩展成本很高，数据隔离性较差。
ByteHouse产品专家在直播中介绍，“为了解决上述问题，我们主要从四个方向进行优化，进一步升级OLAP引擎能力、性能、运维、架构。”
首先，丰富的自研表引擎实现了OLAP引擎能力的演进。 ByteHouse弥补了ClickHouse表引擎的不足，并衍生出新的表引擎，包括高可用表引擎、实时数据引擎、Unique引擎和Bitmap引擎。 以Unique引擎为例，它解决了社区版ReplacingMergeTree的实时更新延迟问题，真正实现了实时翻转。
其次，增加优化器、字典、索引的支持能力，实现OLAP引擎性能的演进。 ClickHouse在多表场景下存在性能缺陷，而ByteHouse通过自研的CBO和RBO（基于成本和规则的优化器）支持多层嵌套下推、Join子查询下推、Join-Reorder等。 Bucket Join、Runtime Filter等优化器特性使得TPC-DS的性能能够达到99条SQL语句的100%覆盖，大大提升了多表场景下的性能。 此外，ByteHouse还支持全局字典和更多索引，例如Bitmap索引，使查询效率更快。
第三，自动化、可视化实现OLAP引擎运维的演进。 ByteHouse提供标准化运维、集群健康检测以及出现问题时的诊断工具，帮助运维人员提高效率。 例如集群健康检测工具，类似于集群的实时检查。 可以报告当前集群状态、出现了什么问题以及如何解决问题，从而提前最大程度地减少问题发生，降低运维风险。 从效果来看，18000个节点只需要不到10名运维人员即可支撑。
第四，存储与计算分离，实现OLAP引擎架构的演进。 ByteHouse推出了MPP 2.0，即存储计算分离架构。 一方面，存储和计算分离可以更好地实现资源隔离。 每个计算任务都会提交到不同的计算资源上，这样用户之间互不影响，并且存储计算资源可以灵活扩展和缩减。 另一方面，存储和计算的分离可以实现真正的云原生（Cloud Native）。 ByteHouse存储层不仅支持HDFS，还支持S3对象或其他对象存储，实现云原生部署。
目前，ByteHouse已在行为分析、精准营销、实时监控等业务场景落地。 以实时监控为例。 很多互联网APP都有在线运营、直播电商等服务，因此数据的实时性就显得尤为重要。 从数据产生到显示在大屏幕上，延迟往往需要控制在几分钟甚至几秒内。 ByteHouse的高吞吐量性能和查询性能使数据从输入到输出的流动达到秒级。 在数据保证层面，ByteHouse还可以细化Exactly Once的语义，保证数据不丢失、不重复，最终实现数据的高效存储和精准查询。 （作者：金晶杰）
