作为国内规模最大的ClickHouse用户，字节跳动踩过哪些坑？

ClickHouse 由于其性能方面的突出优势，正在分析型数据库领域掀起一波新的技术浪潮。作为国内规模最大的 ClickHouse 用户，目前字节跳动内部的 ClickHouse 节点总数超过 15000 个，管理总数据量超过 600PB，最大的集群规模在 2400 余个节点。实际上，字节跳动广泛的业务增长分析很多都建立在 ClickHouse 为基础的查询引擎上。

那么，ClickHouse 具体应用于字节跳动哪些业务场景？为什么选择采用 ClickHouse 而不是其他数据分析技术？在使用 ClickHouse 的过程中，字节跳动内部团队又踩过哪些坑？近日，InfoQ 带着上述问题采访了字节跳动数据平台数据应用研发负责人郭东东。

郭东东：两家公司的发展阶段，包括本身数据的体量都有一些差异，所以这两个公司可能在建设上有一些比较相通的地方，也有一些差异化。在 360 那时候主要是 Hadoop 生态刚刚兴起，当时更多的工作是把 Hadoop、HBase 等一系列大数据技术引入到 360，去解决之前传统数据库构建、数据分析平台建设这块的一些瓶颈，当时更多只是把这些平台作为底座更好地支撑业务。

来字节跳动之后，这些开源的生态已经比较成熟了。我们更多是怎样体系化地建设数据平台，在技术平台的基础之上，更多地构建数据分析的其他能力。当然，字节跳动的数据量后期增速很大，本身底层分析引擎等方面的挑战也比较大。

郭东东： 我主要负责数据应用相关产品，跟火山引擎的数据中台其实是上下游的依赖关系。中台更多是把数据整理好加工好，形成相对规范的数据体系。数据应用的话更多考虑的是在数据体系上怎样把更多的数据能力赋能给业务线，比如各种分析能力、AB 实验能力、行为分析能力和可视化能力等等。二者是一个比较密切的协同关系。

郭东东： 我们基本上采用敏捷开发，一个迭代周期可能是两到三周，每个产品会不太一样，整体来说是小步快跑的节奏，快速把客户的需求转化成产品能力，然后提供给用户去使用。这里面包括测试环节、活动环节都需要把控，整个有一套相对完善的需求管理和研发管控的系统。

郭东东： 我以 AB 实验平台为例，简单介绍一下我们整体的技术栈和架构。AB 实验平台整个产品的技术架构包括指标建设模块、数据分流模块等，以及底层的查询引擎能力。指标建设模块负责数据的接入和清洗，包括整个 AB 实验平台数据体系的建设。数据分流模块模块主要是根据不同用户实时决定用户属于的实验组。最底层的查询引擎是我们的核心，主要负责保证整个交互式查询的能力，这里面还有一些增强分析的子模块等等。整个是以容器化部署的，编程语言的话包括 Python、Go 这些都有用到。

郭东东： 其实一个开源技术从开源到逐步成熟、被业内广泛采用，本来就需要一个过程。另外，如果有一些大公司逐步在使用这个技术的话，也有助于更好地推动这项技术在业内被普遍采用。应该说字节跳动内部的 ClickHouse 应用实践，对于 ClickHouse 在业内更大范围的使用也起到比较大的推动作用。很多公司都跟我们交流过 ClickHouse 的使用情况，包括技术改进、技术引进路线等等。

另外，从本质上来说 ClickHouse 确实解决了一些特定场景和业务上存在的比较大的痛点。数据分析之前大家更多是困在数据量，很少能得到相对明细数据的分析，而 ClickHouse 强大的分析能力刚好解决了这一痛点。这其实也反映了大家对数据更细粒度的分析需求的持续拓展。

郭东东：ClickHouse 在字节的应用场景比较多，比如我负责的数据应用平台，基本上很多底层技术都非常多地依赖 ClickHouse 提供的能力，比如 BI 分析能力、AB 实验的分析能力、行为分析能力等等，包括商业化层面的广告效果分析，也都是依赖 ClickHouse 的。

郭东东： 其实在选 ClickHouse 之前，我们也做了比较多的技术选型工作。当时我们有一个相对比较有挑战的技术场景，是要基于很多明细数据做行为分析，这一块我们研究了挺长时间，当时也试用了 Presto、Kylin 等等各种各样的分析技术，最后选择了 ClickHouse。主要是 ClickHouse 在相对固定的一个 Panel 场景下，查询能力确实有比较明显的优势，而且本身它是不会损失灵活性的，像 Kylin 的话其实灵活性会比较差，只要做一点修改就需要重刷。

另外我们其实也调研过 Druid 等，但使用起来跟 ClickHouse 还是有比较大差异的。我们本身选 ClickHouse，还有一个比较大的原因是 ClickHouse 本身 Engine 是相对简单的，因为它 Engine 的执行引擎写得比较高效，它带来的向量化执行等等这些特性对我们场景化分析的价值还是比较大的。

郭东东：ClickHouse 是本身开源版本，我们也会持续进行迭代和优化，还是做了不少工作的。比如说 ClickHouse 的单机用户规模原始是受限的，我们做到了大概几千台的单机用户规模，这里面就做了大量的优化。对于它本身查询能力层面、性能层面，我们也做了比较多的优化，包括特殊的像那些比较复杂的路径转换等等一系列分析。

另外我们也做了 ClickHouse 的云原生改造，本身它只支持 Local 部署的模式，我们做到了存储计算分离，就能比较容易地基于容器去调动算力，这些方面也做了很多事情。另外 ClickHouse 不支持事务、实时写入能力，包括对 Update 的支持，这块我们都做了比较多的改进.

我们整体来说还是按照云原生和相对完整的一个数据库去推进这个演进，包括对相对复杂 SQL 能力的支持、优化器能力的补足，这块都有投入。

郭东东： 我们使用 ClickHouse 算比较早的，中间遇到的问题比较多，踩了不少坑，但是现在来看的话，其实 ClickHouse 本身开源也在逐步成熟，很多问题也在逐步完善。至于有哪些经验可借鉴，我觉得可能有几个点拿出来跟大家分享一下。首先 ClickHouse 本身运维管控是比较弱的，所以我们内部自己搭建了一套相对完善的运维管控系统，以保证 ClickHouse 的稳定性，包括故障节点的停换等等一系列事情。另外 ClickHouse 在对外数据摄入这一方面其实也不算特别完善，这块我们也做了比较多事情，还有包括实时能力等等。

郭东东： 过去三年大数据分析技术发展还是挺快的，尤其业内也有比较多的开源技术出现，像 ClickHouse 这样的技术。另外业内云原生数据分析公司（如 Snowflake）的成功，也在大力推动技术的发展。

回到技术本身，大家其实可以看到越来越多的云原生能力，包括 AI 支持和数据分析、数据库和数据仓的结合、湖仓一体、批流一体等等，技术一直在持续推进。未来我认为数据分析能力会持续加强，包括数据分析技术的多样性、整个架构 Layer Out、存储计算分离等等，都是比较大的发展趋势。

郭东东： 目前在我们公司内部这两种架构都是存在的，每一种架构都有不同的使用场景。Lambda 架构本身离线和实时是分开的，在我们内部更多用于一些数据量比较大且整体有一些比较复杂的策略的场景，比如反作弊等策略，实时很难做得很准确，就需要把离线和实时分开，离线先提供一份数据，然后实时进一步修正这个数据，保证数据是可用的且准确性更高。

但有些场景其实我们也直接采用 Kappa 架构，尤其数据湖这些技术在内部的广泛使用，保证了实时的分析能力跟离线也差不了太多，类似这种场景我们就会把实时和离线整合起来，就只用一套，保证实时产出的数据就是我们最终需要的数据。我们只有在出现比较大的数据口径调整，或者其他事故的时候，才会跑离线任务去修正，默认的话就是一套。

采访嘉宾介绍：

郭东东，字节跳动数据平台数据应用研发负责人，负责数据应用相关产品的研发，具体包括 AB 实验平台、行为分析系统、智能 BI 洞察系统相关产品等，支撑内部的抖音、今日头条等核心业务线。曾经任职于奇虎 360，负责大数据平台相关建设，有 10 年的大数据平台以及应用架构经验，对 OLAP、大数据实时 & 离线处理技术有比较深入的了解，熟悉 ClickHouse、Spark、Presto 等主流的大数据处理技术。

--end--

扫描下方二维码
添加好友，备注【交流】
可私聊交流，也可进资源丰富学习群

更文不易，点个“在看”支持一下👇