ToB企服应用市场:ToB评测及商务社交产业平台

标题: 数据分析引擎百花齐放,为什么要大力投入ClickHouse? [打印本页]

作者: tsx81429    时间: 2022-8-26 10:26
标题: 数据分析引擎百花齐放,为什么要大力投入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支持数据统计分析各种场景:
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》白皮书了解更多~
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!




欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4