Clickhouse玩转每天千亿数据 趣头条 王海胜 提纲 • 业务背景 • 集群现状 • 我们遇到的问题 业务背景 基于storm的实时指标的计算存在的问题 1：指标口径(SQL) -> 实时任务 2：数据的回溯 3：稳定性 业务背景 什么是我们需要的? 1：实时指标SQL化 2：数据方便回溯，数据有问题，方便恢复 3：运维需要简单 4：计算要快，在一个周期内，要完成所有的指标的计算 集群现状 集群现状 100+台32核128G 部分复杂累时查询30S内完成 集群现状 我们遇到的问题 关于机器的配置 早期集群机器配置16核64G 一块1.7T本地SSD 问题： 1：内存限制，对于一些大的查询会出现内存不够问题 2：存储限制，随着表越来多，磁盘报警不断 3：cpu限制 64G对于一些大表(每天600亿+)的处理，很容易报错，虽然有基于磁盘解决方案，但是会影响速度 clickho cpu需要根据实际情况而定 解决： 1：机器的内存推荐128G+ 2：采用软连接的方式，把不同的表分布到不同的盘上面，这样一台机器可以挂载更多的盘 最新版本的”冷热数据分离”特性，曲线救国? 我们遇到的问题 order by (timestamp, eventType) or order by (eventType, timestamp) 业务场景 1：趣头条和米读的上报数据是按照”事件类型”(eventType)进行区分

内存: 96GB • 硬盘: 1TB 高效云盘，最大IO吞吐量 140MBps 以事业部、入库时间作双分区导入数据 遇到的问题 导入效率： • 原有导入数据方式在百亿级数据下会报Too many partitions for single INSERT block的问题 • 数据导入慢 原因： • ck-loader-mr方式对大数据量场景支持不够友好 • 单次插入分区过多 解决方法：

clickhouse数仓应用实践 演讲人：朱元 日期： 2019-10-20 所遇问题 目录 CONTENTS 现状背景 应用实践 01 数据链路长 现状 即席查询性能差 数据压缩率低 需求响应慢 02 数据架构 数据同步ck 01 1，基于公司对数据要求为T+1 2. 基于现有开发人员水平及成本 因此采用可视化同步工具kettle. 先将oracle数据平台维