数据分析引擎百花齐放，为什么要大力投入 ClickHouse？

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

近年来，OLAP 产品的竞争日渐激烈，目前企业间流行的既有 Impala、Greenplum 等上一代较为成熟的数据分析产品，也有 ClickHouse、Kylin、Druid、Doris、StarRocks 等在不同场景各具特色的新一代分析引擎。这些产品各有胜场，用户在进行选择时需要对各产品有全面的了解，并且要求产品知识紧跟最新版本，才能准确的选出适合自己公司的产品。

字节跳动旗下抖音、今日头条等产品的成长速度很快，需要分析处理的数据也随之指数级的快速增长，这对分析的实时性有极高的要求。在选择 OLAP 引擎时，字节也尝试过 Kylin、Druid、Spark 等，并且其他产品也做了广泛的调研。经过不断尝试和思考，字节从性能、稳定、可复用等角度考量，最终选择了 ClickHouse 作为主分析引擎，承载字节跳动广泛的业务增长分析工作。当前，字节跳动内部的 ClickHouse 节点总数已经超过 18000 个，管理总数据量超过 700PB，最大的集群规模在 2400 余个节点，是全国乃至于全世界最大的 ClickHouse 用户之一。

字节跳动的 OLAP 演进

起初时，最大需求的是“快”，所以字节团队尝试了 Kylin，它的优点是能够提供毫秒级别的查询延时。但同时 Kylin 也存在需要预聚合、需要提前定义数据模型和无法进行交互式分析等问题，随着数据量变大反而会导致返回结果慢。随后团队又希望用 Spark 来解决问题。但 Spark 同样存在不少问题困扰着团队，比如查询速度不够快、资源使用率高、稳定性不够好，以及无法支持更长时间的数据等。

经过认真思考，字节决定从以下角度来选择 OLAP 分析引擎：

一是对 OLAP 非常朴素又简单的要求：高可用和强性能。不论给 OLAP 加上多少复用、赋予多少身份，最核心且首要的诉求是能存储足够多的数据、足够稳定，并且可以非常快地查到数据。这是第一个要求——要好用，即满足海量数据下交互式分析的性能要求，达到秒级响应。

二是复用。在好用的基础上，团队希望能尽量用一套技术栈解决大部分问题甚至是所有问题，这就需要引擎是可定制的，能让开发人员在这套技术栈上搭建各种面向场景化的应用。

三是易用，能让用户更加自主地把产品使用起来。

最终，经过对当时市面上已有的多款开源引擎的调研和测试，团队最终选择采用 ClickHouse 作为 OLAP 查询引擎，并开始基于此不断迭代。

ClickHouse 简介

ClickHouse 是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。于 2016 年开源，以性能强悍著称。其具备列式存储、向量化执行引擎、高压缩比、多核并行计算等特性。

1.  性能强

号称最快的 OLAP 引擎，在 1 亿数据量级相同服务器的性能对比如下：

2. 功能丰富

ClickHouse 支持数据统计分析各种场景：

• 支持类 SQL 查询；

• 支持繁多库函数（例如 IP 转化，URL 分析等，预估计算/HyperLoglog 等）；

• 支持数组(Array)和嵌套数据结构(Nested Data Structure)；

• 支持数据库异地复制部署。

3. 数据导入速度快

ClickHouse 使用大规模并行计算框架，超高吞吐的实时写入能力，每秒在 50-200M 量级。

ClickHouse 采用类 LSM Tree 的结构，数据写入后定期在后台 Compaction。通过类 LSM tree 的结构， ClickHouse 在数据导入时全部是顺序 append 写，写入后数据段不可更改，在后台 compaction 时也是多个段 merge sort 后顺序写回磁盘。顺序写的特性，充分利用了磁盘的吞吐能力。

4. 发展前景好

自 2016 年开源以来，ClickHouse 凭借其数倍于其他顶尖交互式分析数据库的极致性能，发展速度非常迅猛。目前，ClickHouse 已在 Github 上获得 24.2K Star，1000+的 Contributors。

ClickHouse 的缺点

没有任何一个数据引擎是完美无缺的，在大量使用过程中，字节也发现了 ClickHouse 的一些缺点：

1. 关联查询能力差

ClickHouse 的优势在单表查询性能，但是在一些要求灵活查询的场景，ClickHouse 多表关联能力的不足就暴露了出来，难以满足这类场景。

2. 依赖 Zookeeper

Zookeeper 在 ClickHouse 中主要用于副本表数据的同步（ReplicatedMergeTree 引擎）以及分布式表（Distributed）的操作上。但是对 Zookeeper 的不当使用很容易引起 ClickHouse 集群的不稳定。

3. 不支持 upsert

ClickHouse 仅支持批量删除或修改数据，ReplacingMergeTree 需要依赖 merge 异步去重。

4. 运维复杂

ClickHouse 扩缩容时需要创建新表重新导数据，十分不方便。ClickHouse 集群不能自动感知集群拓扑变化，也不能自动 balance 数据。当集群数据量较大，复制表和分布式表过多时、想做到表维度、或者集群之间的数据平衡会导致运维成本很高。

立即跳转火山引擎ByteHouse官网了解详情！欢迎下载《从ClickHouse到ByteHouse》白皮书了解更多~