关键词：
关注公众号，获取更多一线大厂最新技术
安排！~
本文摘要：今天分享的主要内容是ClickHouse在字节跳动内部的技术演化
分享时间：2021年5月28日
内容分享：陈*星
摘要整理：皮卡丘
主要内容：
1、ClickHouse简介
2、字节跳动如何使用ClickHouse
3、问题与解决方案
一、ClickHouse简介
1.1 简介：
1. Developed by Yandex, and open source since 2016
2. 查询性能优越的分析型引擎
3. 主要特点：
面向列+向量执
本地连接存储（非Hadoop生态系统）
线性可扩展且可靠（分片+副本）
标准SQL接口
快！！！（为什么会快？）
1.2 性能优越的因素：
1. Data Skipping
分区以及分区剪枝
数据局部有序（LSM-like engine, zone map)
2. 资源的垂直整合
并发 MPP+ SMP（plan level)
Tuned执行层实现 （multi-variant agg implementation…, SIMD)
3. C++ Template Code
1.3 适用场景与不足：
1. 适用场景：
单表分析\\大宽表
绝大多数请求都是用于读访问的
2. 不足：
不持事务、不支持真正的删除/更新
不支持高并发，官方建议qps为100
不支持二级索引
有限的SQL支持，Join实现与众不同
注：ClickHouse版本更新速度贼快，未来这些不足可能都会得到解决
二、字节跳动如何使用ClickHouse
2.1. 选择ClickHouse的原因：
交互式分析能力 (in seconds)
查询模式多变
以大宽表为主
数据量大
开源MPP OLAP引擎-（性能、特性、质量）
2.2.1. 字节跳动如何使用ClickHouse：
几千个节点, 最大集群1200个节点
数据总量 ~ 几十PB
日增数据 ~ 100TB
查询响应时间(mostly) ～ ms - 30s
覆盖产品运营、分析师、开发人员、少量广告类用户、openapi
2.2.2. 字节跳动如何使用ClickHouse：
多种数据源 （离线 + 实时 + …) ,如上图
交互式分析
数据处理链路对业务方透明
满足数据中台对数据查询需求
三、问题与解决（老师说该划重点了！！）
3.1 数据源-->ClickHouse服务化：
上架构图：
问题描述：
HDFS数据访问
数据导入过程中Failover
CK数据就绪速度（Part生成）
解决方案：
增加HDFS数据访问能力(HDFS client porting from HAWQ）
ETL服务维护外部事务保障数据一致性（fail over)
INSERT INTO LOCAL TABLE
数据构建与查询分离 (experimental feature)
3.2 Map数据类型-动态Schema：
问题描述：
客户端上报字段多变 (自定义参数）
数据产品需要相对固定schema
性能需求：访问MAP 键值需要与访问POD 类型的列速度一致
实现方式：LOB ？Two-implicit column? Other
问题调研：
数据特征：# keys 总量可控， 局部有限
局部（PART level)展平模型 (自描述）
解决方案：
MAP键访问自动改写
"select c_map'a' from table" will be rewrote to "select c_map_a from table"
MAP列访问 (代价较大)
select c_map from table
Merge阶段优化（无需重构MAP column)
收益：
自动化接入
Table schema 简化
极大简化数据构建(ETL)逻辑
语法示范：
Create table t(c1 UInt64, c2 Map(String, UInt8)) ENGINE=MergeTree….
insert into t values(1, 'abc':1, 'bcd':2)
Select c2'abc' from t
3.3 Zookeeper使用问题：
问题背景：
两副本保障数据
ReplicatedMergeTree in ClickHouse （Issue)
- Async Master-Master replication
问题描述：
ReplicatedMergeTree的问题
ZooKeeper压力大，znode太多
400 Nodes 集群， 半年数据， 800万znodes
ReplicatedMergeTree use ZK to store:
Table schema
副本状态（part info & log info)
分片（shard) 状态
问题调研：
数据继续增长会导致ZK无法服务
社区mini checksum in zk能缓解内存使用，但不能解决问题
基于MergeTree开发HA 方案
解决方案：【HaMergeTree】
ZooKeeper只用作coordinate
Log Sequence Number(LSN) 分配
数据Block ID 分配
元数据管理
节点维护local log service (action log)
Log 在分片内部节点间通过Gossip协议交互
数据信息（parts) 按需交互
外部接口与社区兼容（例如：multi-master写入）
解决方案：
1. A 获取LSN和Block ID
2.1 A Push log to active replica B
2.2 B get its log lags from ZK and pull logs from A
3. B redo the log and get Block from A
收益：
ZooKeeper压力不会随着数据量增长
~ 3M znodes in ZK
保障数据&服务高可用
3.4 String 类型处理效率-Global Dictionary：
问题描述：
String 类型的滥用（from HIVE), 处理低效
Why not LowCardinalityColumn？
算子尽量在压缩域上执行（actionable compression)
pure dictionary compression
predication (equality family)
group by (single/composite keys)
问题背景：
Per replica字典(异步)构建
why not cluster level/shard level?
Support xxMergeTree only
解决方案：
压缩域执行
分布式表字典 （per shard, per replica)
分布式表压缩域执行
收益：
性能提升约 20% ～ 30%
3.5 特定场景内存OOM - Step-ed Aggregation：
问题描述：
Query：60天内用户转化率/行为路径，以及对应每天转化率
内存使用量大，OOM对服务稳定性影响
Aggregator无法感知底层数据特性
解决方案：
Aggregator 由执行HINT控制
HINT 感知数据分区/指标语义
Blocked Aggregator 按partition pipeline计算指标
收益：
内存使用比默认方式降低约五倍
3.6 Array类型处理 - BloomFilter & BitMap index：
问题描述：
Array类型用来表示实验ID
Query：命中某些实验的用户指标
单条记录Array（实验）～ 几百 or 上千
解决方案：
需要辅助信息减少 Array column materialize
Two scale BloomFilter (Part level, MRK range level)
减少Long Array column in Runtime Block
Transform hasAny into BitMap index OR-ing
Array Column —> value+BitMap 集合
has(array, value) —> get BitMap (执行层自动改写）
四、写在最后
内容整理不易，欢迎感兴趣的小伙伴关注，我会定期分享各个大厂的技术资料，欢迎留言讨论。
识别下方二维码，关注后，点击 “资料获取”，即可获取免费学习资料，并且资料在不断更新中。记得关注点赞、点点在看哦！ღ( ´･ᴗ･` )笔芯~
END
关于bytehouse你想知道的一切，看这一篇就够了
ByteHouse的前世今生字节跳动最早是在2017年底开始使用ClickHouse的，用于支撑增长分析的业务场景。对于字节跳动而言，增长分析的重要性不言而喻。这是一项十分考验运营团队能力的工作，如何衡量不同运营方法的有... 查看详情
presto在字节跳动的内部实践与优化
引言在字节跳动内部，Presto主要支撑了Ad-hoc查询、BI可视化分析、近实时查询分析等场景，日查询量接近100万条。功能性方面完全兼容SparkSQL语法，可以实现用户从SparkSQL到Presto的无感迁移；性能方面实现JoinReorder&#... 查看详情
揭秘字节跳动云原生sparkhistory服务uiservice
本文是字节跳动数据平台数据引擎SparkSQL团队针对SparkHistoryServer(SHS)的优化实践分享。*文|字节跳动数据平台—数据引擎—SparkSQL团队*在字节跳动内部，我们实现了一套全新的云原生SparkHistory服务——UIService，相比开源的SHS，UIServ... 查看详情
从clickhouse到bytehouse：实时数据分析场景下的优化实践
...级技术服务平台火山引擎正式对外发布了ByteHouse。在打造ClickHouse企业版ByteHouse的过程中，我们经过了多年的探索与沉淀，今天和大家分享字节跳动过去使用ClickHouse的两个典型应用于优化案例。近日，字节跳动旗下的... 查看详情
火山引擎dataleap：揭秘字节跳动数据血缘架构演进之路
...导入离线数仓。经过离线数仓的数据加工逻辑，流转到以ClickHouse为代表的OLAP引擎。另外，在消息队列部分 查看详情
一文了解字节跳动如何解决sla治理难题
动手点关注 干货不迷路 👆基于字节跳动分布式治理的理念，数据平台数据治理团队自研了SLA保障平台，目前已在字节内部得到广泛使用，并支持了绝大部分数据团队的SLA治理需求，每天保障的SLA链路数量过... 查看详情
presto在字节跳动的内部实践与优化
引言在字节跳动内部，Presto主要支撑了Ad-hoc查询、BI可视化分析、近实时查询分析等场景，日查询量接近100万条。功能性方面完全兼容SparkSQL语法，可以实现用户从SparkSQL到Presto的无感迁移；性能方面实现JoinReorder&#... 查看详情
名震github，字节跳动内部顶级数据结构刷题学习笔记根本停不下来
前段时间字节跳动发布了年前再招1万人的消息，从大部分的字节招聘岗位来说的话，Java研发岗位位居榜首！这个消息一经发布就让大部分的程序员蠢蠢欲动，毕竟字节谁不想去？字节跳动的岗位大多数看中的... 查看详情
字节跳动内部学习资料泄露！java前端框架排行
那么，如何学习Kafka源码？？我觉得最高效的方式就是去读最核心的源码，先看一张 Kafka结构图 以及 Kafka源码全景图梳理一下关于 Kafka框架，找到学习的重点。其次，我要说的就是一个Kafka源码解析的文... 查看详情
真给力！字节跳动内部前端开发手册（完整版）开放下载！
...制，每篇都有项目实战训练，非常便于我们学习如何获取？ 长按下方二维码识别，找我助理领取👆长按上方二维码 2秒找我助理领取额外福利，2021年前端面试题视频详解曾经花... 查看详情
真给力！字节跳动内部前端开发手册（完整版）开放下载！
...制，每篇都有项目实战训练，非常便于我们学习如何获取？ 长按下方二维码识别，找我助理领取👆长按上方二维码 2秒找我助理领取额外福利，2021年前端面试题视频详解曾经花... 查看详情
字节跳动在异构场景下的高可用建设实践
字节跳动有众多的APP和服务，如何用混沌工程的方式保证这些系统和服务的高可用？本文详细介绍了字节跳动混沌工程技术的演进和系统高可用建设实践。本文主要为大家介绍字节跳动在高可用建设上的一些思考和落地... 查看详情
字节跳动如何从0到1打造一个开源项目？
本文整理自51CTO开源基础软件学习季的直播公开课《字节跳动的开源实践与思考》 像很多公司一样，字节跳动接触开源也有一个从0到1、由浅入深的过程，大体经历三个阶段： 第一阶段，使用开源。为了推动业务更快发... 查看详情
字节跳动面试官：java线程池详解
Netty实战无论是想要学习Spring5、Spark、Cassandra等这样的系统，还是通过学习Netty来构建自己的基于Java的高性能网络框架，或者是更加具体的高性能Web或者游戏服务器等，本书都将是你的超强拍档。本书共分为4个部分&#x... 查看详情
字节跳动（今日头条）的题目真的难吗？
...的笔试非常难，一共有几道题，难度分布是怎样的，应该如何分配作答时间?A：首先，真的不难。真的。.一般来说，每套笔试题是由1个简单难度题目、2个中等难度题目及1个较难的题目构成，部分岗位方向还有选择题。单道题的... 查看详情
clickhouse引擎在行为分析场景下的join优化(代码片段)
火山引擎增长分析DataFinder基于ClickHouse来进行行为日志的分析，ClickHouse的主要版本是基于社区版改进开发的字节内部版本。1.背景火山引擎增长分析DataFinder基于ClickHouse来进行行为日志的分析，ClickHouse的主要版本是基于社... 查看详情
字节还能如何“跳动”
字节跳动的下一个增长点会是什么？裁员频传的字节据《晚点LatePost》报道，被给予厚望的字节跳动旗下教育品牌大力教育，正在进行新一轮调整：向3-8岁孩子提供AI动画课程的瓜瓜龙开始裁撤辅导老师，计划... 查看详情
字节跳动开源数据集成引擎bitsail的演进历程与能力解析
导读BitSail是字节跳动开源数据集成引擎，支持多种异构数据源间的数据同步，并提供离线、实时、全量、增量场景下全域数据集成解决方案，目前支撑了字节内部和火山引擎多个客户的数据集成需求。经过字节跳动各大业务线... 查看详情