8 / 1024 / 1024） 但是如果使用上述的数据结构存储单独一个较大数值的数字id，会造成空间上的浪费，例如 仅存储40亿一个数值也需要477m的空间。也就是说稀疏的Bitmap和稠密的占用空间相 同。通常会使用一种bitmap压缩算法迚行优化。 RoaringBitmap是一种已被业界广泛使用的高效的bitmap压缩算法，使用者包括Spark、 Hive、ElasticSea RoaringBitmap原理介绍 主要原理：将32bit的Integer划分为高16位和低16位(两个short int)，两者之间是Key-Value的 关系。高16位存到short[] keys，通过高16位（Key）找到所对应Container，然后把剩余的低 16位（Value）放入该Container中，RoaringBitmap有三类Container：  Array Container

阿里云ECS * 6，生产环境集群 • CPU: • Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GH • 12 cores 24 processors • 内存: 96GB • 硬盘: 1TB 高效云盘，最大IO吞吐量 140MBps 以事业部、入库时间作双分区导入数据 遇到的问题 导入效率： • 原有导入数据方式在百亿级数据下会报Too many FORMAT CSV" 效果： 单进程：每分钟2600w条记录，client占用核数=1，server占用核数=1，导入速率=80mb/s 2进程：每分钟4000w条记录，client占用核数=2，server占用核数约2-5，导入速率=140mb/s 4进程: 每分钟8000w条记录，每个client占核数=1，server占用核约2-5，导入速率=280mb/s 22 ClickHouse 百亿数据性能测试与优化 场景5涉及到全表百亿行数据，第一次执行与后续执行花费时间差距较大 • 第一次执行，数据在硬盘上 花费~250s，性能瓶颈在硬盘io (iostat util 100%) • 第二次执行，大部分数据已经在内存里 花费~18s，性能瓶颈在cpu (top cpu usage ~1447%) • 两次运行的比较： Metric First run Second run top %CPU ~116%

一块1.7T本地SSD 问题： 1：内存限制，对于一些大的查询会出现内存不够问题 2：存储限制，随着表越来多，磁盘报警不断 3：cpu限制 64G对于一些大表(每天600亿+)的处理，很容易报错，虽然有基于磁盘解决方案，但是会影响速度 clickhouse的数据目录还不支持多个数据盘，单块盘的大小限制太大 cpu需要根据实际情况而定 解决： 1：机器的内存推荐128G+ 2：采用软连接的方式， clickhouse裸奔时max_memory_usage_for_all_queries默认值为0，即不限制clickhouse内存使用 解决： clickhouse安装完成以后，在users.xml文件中配置一下max_memory_usage_for_all_queries，控制 clickhouse-server最大占用内存，避免被OS kill 我们遇到的问题 Memory limit (for query) exceeded:would 查询在该机器上面最大内存使用量 2：除了些简单的SQL，空间复杂度是O(1) 如: select count(1) from table where column=value select column1, column2 from table where column=value 凡是涉及group by, order by, distinct, join这样的SQL内存占用不再是O(1) 解决：

广州站 ClickHouse 的特点 优点： 1. 数据压缩比高，存储成本相对非常低； 2. 支持常用的SQL语法，写入速度非常快，适用于大量的数据更新； 3. 依赖稀疏索引，列式存储，cpu/内存的充分利用造就了优秀的计算能力， 并且不用考虑左侧原则； 缺点： 1. 不支持事务，没有真正的update/delete； 2. 不支持高并发，可以根据实际情况修改qps相关配置文件； temp_temp rename成 A_temp; 其他方式： 1. 采用 waterdrop 的方式大幅提升写入速度； 2. 直接读Hdfs文件的方式，但内存波动较大； 全球敏捷运维峰会 广州站 ClickHouse的增量数据同步流程 传统方式： 1. 将最近3个月的数据从Hive通过ETL入到A_temp表; 2 query_log表，记录已经 执行的查询记录 query：执行的详细SQL，查询相关记录可以 根据SQL关键字筛选该字段 query_duration_ms：执行时间 memory_usage：占用内存 read_rows和read_bytes ：读取行数和大小 result_rows和result_bytes ：结果行数和 大小 以上信息可以简单对比SQL执行效果 全球敏捷运维峰会 广州站

Unique Engine v write-write冲突依靠table level lock控制 v write-merge冲突： Unique Engine v 常驻内存模式对内存消耗很⼤ v ⾮常驻内存模式index load过程慢 v 多并发加载优化索引加载速度： 日志 日志 v Elastic To ClickHouse迁移，降本增效 v OTEL标准化⽇志采集 v

2 • Clickhouse 的部署与监控管理 • Clickhouse 的应用实践 iData 目录 部署与监控管理 一切以用户价值为依归 3 1 4 部署与监控管理 1 高内存，廉价存储： 单机配置: Memory128G CPU核数24 SATA20T，RAID5 万兆网卡 一切以用户价值为依归 5 部署与监控管理 1 生产环境部署方案： Distributed

可以说正是由表引擎，决定了一张 数据表最终的性格，它拥有何种特性、数据以何种形式被存储以及如何被加载。 ClickHouse拥有非常庞大的表引擎体系，截至到目前(19.14.6)，共拥有合并树、 内存、文件、接口和其他5大类20多种。 合并树 这众多的表引擎中，又属合并树(MergeTree)表引擎及其家族系列(*MergeTree)最 为强大，在生产环境绝大部分场景中都应该使用此系列的表引擎。