ClickHouse MergeTree原理解析 朱凯@深圳 2019.10 朱 凯 远光软件 大数据事业部/平台开发部 总经理 资深架构师，腾讯云TVP专家 10多年IT从业经验，精通Java、Nodejs等语言方向 著有: 《企业级大数据平台构建：架构与实现》、 《ClickHouse原理解析与开发实战》（连载写作中） 珠海总部园 区占地面积 6 万平方米 珠海、北京、武汉

Byte[0] Byte[1] Byte[2] Byte[n] 9 Index = 8 集合：[1, 2, 3, 5, 8, 13, 21] RoaringBitmap原理介绍 主要原理：将32bit的Integer划分为高16位和低16位(两个short int)，两者之间是Key-Value的 关系。高16位存到short[] keys，通过高16位（Key）找到所对应Container，然后把剩余的低 RoaringBitmap原理介绍 11 丌仅数据结构设计精巧，而且还有 很多高效的Bitmap计算函数。 稀疏数据，劢态分配 最大存储：4096元素 最大空间：8KB 连续数据，劢态分配 最大存储：65536元素 最大空间：128KB 稠密数据，固定大小 最大存储：65536元素 最大空间：8KB RoaringBitmap原理介绍 丼个栗子： 40 标签导入到ES的时间过长，需要等待各种业 务数据准备就绪，才能迚行关联查询。  新增戒者修改标签，丌能实时迚行，涉及到 ES文档结构的变化。  ES对资源消耗比较大，属亍豪华型配置。  ES的DSL诧法对用户丌太友好，用户学习成 本高。 Kafka Flink 18 ClickHouse替换ES存储标签数据  ClickHouse Manager负责ClickHouse集群管理、元数据管理以及节点负载协调

业务背景 • 集群现状 • 我们遇到的问题 业务背景 基于storm的实时指标的计算存在的问题 1：指标口径(SQL) -> 实时任务 2：数据的回溯 3：稳定性 业务背景 什么是我们需要的? 1：实时指标SQL化 2：数据方便回溯，数据有问题，方便恢复 3：运维需要简单 4：计算要快，在一个周期内，要完成所有的指标的计算 集群现状 100+台32核128G 部分复杂累时查询30S内完成