部分复杂累时查询30S内完成 集群现状 我们遇到的问题 关于机器的配置 早期集群机器配置16核64G 一块1.7T本地SSD 问题： 1：内存限制，对于一些大的查询会出现内存不够问题 2：存储限制，随着表越来多，磁盘报警不断 3：cpu限制 64G对于一些大表(每天600亿+)的处理，很容易报错，虽然有基于磁盘解决方案，但是会影响速度 clickhouse的数据目录还不支持多个数据盘，单块盘的大小限制太大 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 uniqCombined / uniqHLL12 4：Join时小表放到右边，“右表广播” ^v^ 我们遇到的问题 zookeeper相关的问题 问题一：zookeeper的snapshot文件太大，follower从leader同步文件时超时 问题二：zookeeper压力太大，clickhouse表处于”read only mode”，插入失败 分析： clickhouse对zookeeper的依赖还是很

01 / 一级索引&二级索引 02 / 数据存储 03 / 数据标记 04 / 表引擎 表引擎，是ClickHouse设计实现中的一大特色。可以说正是由表引擎，决定了一张 数据表最终的性格，它拥有何种特性、数据以何种形式被存储以及如何被加载。 ClickHouse拥有非常庞大的表引擎体系，截至到目前(19.14.6)，共拥有合并树、 内存、文件、接口和其他5大类20多种。 合并树 这众 [SETTINGS name=value, 省略...] 分区键 排序键 主键 index_granularity = 8192 索引粒度 MergeTree的存储结构 数据以分区的形式被组织 , PARTITION BY 各列独立存储, 按ORDER BY 排序 一级索引, 按PRIMARY Key 排序 数据分区 数据的分区规则 l 不指定分区键 如果不使用分区键，既不使用PARTITION 对于每一个新创建的分区目录而言，其初始值均为0。之 后,以分区为单位，如果相同分区发生合并动作，则在相 应分区内计数累积加1。 分区目录的合并过程 一级索引 稀疏索引 primary.idx文件内的一级索引采用稀疏索引实现 如果把MergeTree比作是一本书，那么稀 疏索引就好比是这本书的一级章节目录。 一级章节目录不会具体对照到每个字的位 置，只会记录每个章节的起始页码。 以默认的索引粒度(8192)为例，

的特点 优点： 1. 数据压缩比高，存储成本相对非常低； 2. 支持常用的SQL语法，写入速度非常快，适用于大量的数据更新； 3. 依赖稀疏索引，列式存储，cpu/内存的充分利用造就了优秀的计算能力， 并且不用考虑左侧原则； 缺点： 1. 不支持事务，没有真正的update/delete； 2. 不支持高并发，可以根据实际情况修改qps相关配置文件； 全球敏捷运维峰会 广州站 StarRocks的特点 4. 将A_ temp_temp rename成 A_temp; 其他方式： 1. 采用 waterdrop 的方式大幅提升写入速度； 2. 直接读Hdfs文件的方式，但内存波动较大； 全球敏捷运维峰会 广州站 ClickHouse的增量数据同步流程 传统方式： 1. 将最近3个月的数据从Hive通过ETL入到A_temp表; 数据导入时根据分区做好Order By； • 左右表join的时候要注意数据量的变化； • 是否采用分布式； • 监控好服务器的cpu/内存波动/`system`.query_log； • 数据存储磁盘尽量采用ssd； • 减少数据中文本信息的冗余存储； • 特别适用于数据量大，查询频次可控的场景，如数据分析，埋点日志系统； 全球敏捷运维峰会 广州站 StarRocks应用小结 • 发挥分布式的优势，要提前做好分区字段规划；

精确去重计数性能测试 6 ClickHouse在苏宁使用场景  OLAP平台存储引擎 -- 存储时序数据、cube加速数据，应用亍高基数查询、精确去重场景。  运维监控 -- 实时聚合分析监控数据，主要使用物化视图技术。  用户画像场景 -- 标签数据的存储、用户画像查询引擎。 7 Contents 苏宁如何使用ClickHouse ClickHouse集成Bitmap 用户画像场景实践 8 Bitmap位存储和位计算 每个bit位表示一个数字id，对亍40亿个的用户id，只需要40亿bit位， 约477m大小 = （4 * 109 / 8 / 1024 / 1024） 但是如果使用上述的数据结构存储单独一个较大数值的数字id，会造成空间上的浪费，例如 仅存储40亿一个数值也需要477m的空间。也就是说稀疏的Bitmap和稠密的占用空间相 RoaringBitmap原理介绍 11 丌仅数据结构设计精巧，而且还有 很多高效的Bitmap计算函数。 稀疏数据，劢态分配 最大存储：4096元素 最大空间：8KB 连续数据，劢态分配 最大存储：65536元素 最大空间：128KB 稠密数据，固定大小 最大存储：65536元素 最大空间：8KB RoaringBitmap原理介绍 丼个栗子： 40亿（0xEE6B2800

• Clickhouse 的部署与监控管理 • Clickhouse 的应用实践 iData 目录 部署与监控管理 一切以用户价值为依归 3 1 4 部署与监控管理 1 高内存，廉价存储： 单机配置: Memory128G CPU核数24 SATA20T，RAID5 万兆网卡 一切以用户价值为依归 5 部署与监控管理 1 生产环境部署方案： Distributed Table Load Balancing 一切以用户价值为依归 6 部署与监控管理 1 线性平滑扩容： 扩容： 1.安装新部署新的shard分片机器 2.新shard上创建表结构 3.批量修改当前集群的配置文件增加新的分片 4.名字服务添加节点 一切以用户价值为依归 7 部署与监控管理 1 大批量，少批次 WriteModel BatchSize RowLengt h QPM IOUtils iData大数据分析：多维分析，画像分析能力 n DataMore大数据实时决策能力 一切以用户价值为依归 17 业务应用实践 iData 2 新大数据分析引擎2.0 业界传统 大数据分析 引擎 大数据分析引擎&存储 Analytical Engine & Database 大数据仓库 Hadoop Data Lake 计算引擎 MR & Spark Data Warehouse OLTP Big

v Map隐式列将每个Key存储为独⽴列 v Map隐式列查询时只读取需要的隐式列 Bulkload v 原⽣写⼊⽅式消耗ClickHouse Server资源，影响查询性能 v 实时写⼊任务长期占⽤资源，故障恢复的时间和运维成本较⾼ v 基于中间存储的Bulkload⽅案降低ClickHouse Server压⼒ Bulkload v 基于中间存储的Bulkload可以降低ClickHouse ckHouse Server压⼒ v 基于中间存储的Bulkload受HDFS和⽹络稳定性影响，且传输成本较⾼ v 直达ClickHouse的Bulkload稳定性，性能都更佳 Unique Engine v ⽬标：⽀持UpSert，Delete操作，提升查询性能 v 设计：delete on insert Unique Engine v write-write冲突依靠table level Elastic To ClickHouse迁移，降本增效 v OTEL标准化⽇志采集 v 统⼀scheme⽀持 日志 v ClickHouse较ES写⼊吞吐量提升近10倍 v ClickHouse存储成本为ES的1/3 日志 v ClickHouse中采⽤分表，统⼀schema的设计 v ⽇志查询采⽤类似ES语法，降低⽤户迁移成本 用户行为数据分析 概述 v 基于ClickHouse构建B站⽤户⾏为数据分析产品：北极星

众安集智平台与clickhouse 02 集智平台 X-Brain AI 开放平台 计算框架 Hadoop, JStorm, Spark Streaming, Flink 离线/实时任务监控 数据、模型存储 Hive, HBase, Clickhouse, Kylin 数据接入 消 息 中 间 件 模型、 算法 模版 机器学习平台 Antron 机器人平台 X-Insight 数据洞察平台 全生命周期管理 追溯与可重现 洞察平台架构 Why Clickhouse? Clickhosue 性能 高效的数据导入和查询性能 开源 低成本，免费 压缩比 高度的数据压缩比，存储成本更小 面向列 真正的面向列存储， 支持高维度表 易观开源OLAP引擎测评报告 洞察数据模型+Clickhouse 使用效果 CHAPTER 使用ck对百亿数据的探索 03 背景 我们希望对保单、 rows/s • 用到六块硬盘的io：6*140=840mb/s • io吞吐量加倍时，对于冷数据的处理速度是之前的~180% 28 ClickHouse 百亿数据性能测试与优化 • 硬盘存储升级 • 高效云盘 --> SSD + RAID0 • 140MBps --> ~600MBps, ~4x • 升级后 • ~250s --> ~69s，~3.62x l 数据加热后 ～69s

能力的时序数据库产品 高性能并发读写 • 千万数据点并发实时写入 • 引入辅助索引，加快数据检索 速度 低成本存储 • 列式存储结合高效的编码 • Delta、XOR 等适合时序场景的压缩算法 • 通过 Rollup 功能，对历史数据做聚合，减少数据量 稳定可扩展 • 分布式架构 • 数据多副本存储 • 服务高可用 Thanks For You

基于现有开发人员水平及成本 因此采用可视化同步工具kettle. 先将oracle数据平台维度信息以及相关主题清单数据同步至clichouse数据 仓库 Oracle数据平台 • 通过kettle每天 定时导出文件至 本地 Etl服务器 • 通过clickhouse- client将文本导 入ck数据库 clickhouse数据库 数 仓 建 设 01 ck数仓数据模型采用星型模型搭建 02