从 ClickHouse到ByteHouse 实时数据浅析场景下的优化实践
发布时间：2023-02-15 11:21:33 所属栏目：云计算 来源：互联网
导读：作为国内规模最大的 ClickHouse 用户，目前字节跳动内部的 ClickHouse 节点总数超过 1.8W 个。综合来说，字节跳动广泛的业务增长分析很多都建立在 ClickHouse 为基础的查询引擎上。 在打造ByteHouse的路程中，我们经过了多年的探索与沉淀，本文将分享字节跳
|
作为国内规模最大的 ClickHouse 用户，目前字节跳动内部的 ClickHouse 节点总数超过 1.8W 个。综合来说，字节跳动广泛的业务增长分析很多都建立在 ClickHouse 为基础的查询引擎上。 在打造ByteHouse的路程中，我们经过了多年的探索与沉淀，本文将分享字节跳动过去使用 ClickHouse 的两个典型应用与优化案例。 •需要支持一些机器学习和统计相关的指标计算（比如 AUC）。 •数据由推荐系统直接产生，写入 Kafka——为了弥补缺少 Flink 的 ETL 能力，推荐系统做了相应配合，修改 Kafka Topic 的消息格式直接适配 ClickHouse 表的 Schema； •敏捷 BI 平台也适配了一下实时的场景，可以支持交互式的查询分析； •如果实时数据有问题，也可以从 Hive 把数据导入至 ClickHouse 中，除此之外，业务方还会将 1% 抽样的离线数据导入过来做一些简单验证，1% 抽样的数据一般会保存更久的时间。 除了技术选型和实现方案，我们在支持推荐系统的实时数据时遇到过不少问题，其中最大的问题随着推荐系统产生的数据量越来越大，单个节点的消费能力也要求越来越大，主要碰到如下问题： •最后扫描根据 skip index schema 去构建 skip index 文件。三个步骤完成之后才会算 Part 文件构建完毕。 在需要保证构建完 columns 数据之后用户即可正常查询的前提下，ByteHouse 同步完成前面两步，第三步把构建好的 Part 放入到一个异步索引构建队列中，由后台线程构建索引文件。 在改成异步后，整体的写入吞吐量大概能提升 20%。 前面提到的优化手段都不尽如人意，最后决定改造 Kafka Engine 在其内部支持多个消费线程，简单来说就是每一个线程它持有一个消费者，然后每一个消费者负责各自的数据解析、数据写入，这样的话就相当于一张表内部同时执行多个的 INSERT Query。 改进 Kafka Engine 确保主备模式下只有一个节点能消费数据，即使出现节点故障在新节点恢复过程中同样保障了解决了数据完整性的问题。 增强 Buffer Engine，解决了Buffer Engine 和 ReplicatedMergeTree 同时使用下查询一致性的问题。 ClickHouse 缺少事务支持。一批次写入只写入部分 Part 后出现宕机，因为没有事务保障重启后可能出现丢失或者重复消费的情况。 实时数据分析是ClickHouse的优势场景，结合字节跳动实时数据场景的特点，我们对 ClickHouse 进行了优化和改造，并将这些能力沉淀到了 ByteHouse 上。ByteHouse 基于自研技术优势和超大规模的使用经验，为企业大数据团队带来新的选择和支持，以应对复杂多变的业务需求，高速增长的数据场景。 未来，ByteHouse将不断以字节和外部实践输出行业用户，帮助企业更好地构建交互式大数据分析平台。 （编辑：莱芜站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
