共计 2123 个字符，预计需要花费 6 分钟才能阅读完成。
更多技术交换、求职机会、试用福利，欢送关注字节跳动数据平台微信公众号，回复【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 年开源，以性能强悍著称。其具备列式存储、向量化执行引擎、高压缩比、多核并行计算等个性。
- 性能强
号称最快的 OLAP 引擎，在 1 亿数据量级雷同服务器的性能比照如下：
图片
- 功能丰富
ClickHouse 反对数据统计分析各种场景：
反对类 SQL 查问；
反对繁多库函数（例如 IP 转化，URL 剖析等，预估计算 /HyperLoglog 等）；
反对数组 (Array) 和嵌套数据结构(Nested Data Structure)；
反对数据库异地复制部署。
- 数据导入速度快
ClickHouse 应用大规模并行计算框架，超高吞吐的实时写入能力，每秒在 50-200M 量级。
ClickHouse 采纳类 LSM Tree 的构造，数据写入后定期在后盾 Compaction。通过类 LSM tree 的构造，ClickHouse 在数据导入时全副是程序 append 写，写入后数据段不可更改，在后盾 compaction 时也是多个段 merge sort 后程序写回磁盘。程序写的个性，充分利用了磁盘的吞吐能力。
- 发展前景好
自 2016 年开源以来，ClickHouse 凭借其数倍于其余顶尖交互式剖析数据库的极致性能，倒退速度十分迅猛。目前，ClickHouse 已在 Github 上取得 24.2K Star，1000+ 的 Contributors。
ClickHouse 的毛病
没有任何一个数据引擎是白璧无瑕的，在大量应用过程中，字节也发现了 ClickHouse 的一些毛病：
- 关联查问能力差
ClickHouse 的劣势在单表查问性能，然而在一些要求灵便查问的场景，ClickHouse 多表关联能力的有余就裸露了进去，难以满足这类场景。
- 依赖 Zookeeper
Zookeeper 在 ClickHouse 中次要用于正本表数据的同步（ReplicatedMergeTree 引擎）以及分布式表（Distributed）的操作上。然而对 Zookeeper 的不当应用很容易引起 ClickHouse 集群的不稳固。
- 不反对 upsert
ClickHouse 仅反对批量删除或批改数据，ReplacingMergeTree 须要依赖 merge 异步去重。
- 运维简单
ClickHouse 扩缩容时须要创立新表从新导数据，非常不不便。ClickHouse 集群不能主动感知集群拓扑变动，也不能主动 balance 数据。当集群数据量较大，复制表和分布式表过多时、想做到表维度、或者集群之间的数据均衡会导致运维老本很高。
立刻跳转火山引擎 ByteHouse 官网理解详情！欢送下载《从 ClickHouse 到 ByteHouse》白皮书理解更多~
