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

1 关亍我  苏宁科技集团大数据中心架构师  曾就职亍中兴通讯10+years ，从事大规模分布式系统研发  10+years C++、Java、Go编程经验，熟悉大数据架构、解决方案  ClickHouse Contributor  Github: https://github.com/andyyzh Contents 用户画像场景实践 8 Bitmap位存储和位计算 每个bit位表示一个数字id，对亍40亿个的用户id，只需要40亿bit位， 约477m大小 = （4 * 109 / 8 / 1024 / 1024） 但是如果使用上述的数据结构存储单独一个较大数值的数字id，会造成空间上的浪费，例如 仅存储40亿一个数值也需要477m的空间。也就是说稀疏的Bitmap和稠密的占用空间相 同。通常会使用一种bitmap压缩算法迚行优化。 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，然后把剩余的低 16位（Valu

珠海总部园 区占地面积 6 万平方米 珠海、北京、武汉 3 研发中心 36 个 分支机构 4 多名员工 下属公司 14 年+ 14 上市 千+ 大 家 用优质的产品和服务 推动企业管理和社会进步 产品服务 l 集团资源管理 l 资产全寿命周期管理 l 集团风险管控 l 企业大数据及商业智能 l 企业云服务 l 智能机器人应用 l 集团IT治理 l …… l 能源产业链 台 服务（咨询、实施、运维、定制开发、系统集成……） 面向 集团企业 面向 能源行业 面向 社会治理 公司主要客户 海尔集团 东风汽车 中信重工 首创经中 河南省人民医院 宏发股份 国家电网 国家电投集团 华能集团 大唐集团 华电集团 电建集团 能建集团 华润电力 中广核 内蒙古电力 浙能集团 陕能集团 中石油 中石化 中冶集团 酒钢集团 中国商飞 擎，决定了一张 数据表最终的性格，它拥有何种特性、数据以何种形式被存储以及如何被加载。 ClickHouse拥有非常庞大的表引擎体系，截至到目前(19.14.6)，共拥有合并树、 内存、文件、接口和其他5大类20多种。 合并树 这众多的表引擎中，又属合并树(MergeTree)表引擎及其家族系列(*MergeTree)最 为强大，在生产环境绝大部分场景中都应该使用此系列的表引擎。 只有合并

定制开发的 ClickHouse-JDBC 与ClickHouse兼容的 HTTP 接口 请求管理/流量控制 查询缓存 查询分发器 查询处理器 ClickHouse 监控管理平台 元数据管理 库表管理 权限管理 埋点分析 报表平台 HDFS/Hive Kafka/Databus 离线接入 (Rider/Spark/WaterDrop) 实时接入 (BSQL/Saber/Flink 标签圈人 。。。 广告DMP 内容定投 内容分析 日志&Trace 平台 APM ClickHouse as Service v Berserker数据源管理： Ø 建表 Ø 修改表元数据 Ø 表元数据管理 v Yuuni： Ø 屏蔽集群信息 Ø 原⽣JDBC，HTTP接⼜ Ø 读写分离 Ø 动态查询缓存 Ø 流量控制 v 监控管理平台： Ø 统计⼤盘 Ø 回归测试 Ø Server资源，影响查询性能 v 实时写⼊任务长期占⽤资源，故障恢复的时间和运维成本较⾼ v 基于中间存储的Bulkload⽅案降低ClickHouse Server压⼒ Bulkload v 基于中间存储的Bulkload可以降低ClickHouse Server压⼒ v 基于中间存储的Bulkload受HDFS和⽹络稳定性影响，且传输成本较⾼ v 直达ClickHouse的Bulkload稳定性，性能都更佳

order by (timestamp, eventType) or order by (eventType, timestamp) 业务场景 1：趣头条和米读的上报数据是按照”事件类型”(eventType)进行区分 2：指标系统分”分时”和”累时”指标 3：指标的一般都是会按照eventType进行区分 select count(1) from table where dt='' and timestamp>='' zookeeper上面，数据Part都在 zookeeper上面有个节点与之对应以及表的元数据信息等等. 解决： 1：zookeeper机器的snapshot文件和log文件最好分盘存储(推荐SSD)提高ZK的响应 2：zookeeper的snapshot文件存储盘不低于1T 3：做好zookeeper集群和clickhouse集群的规划，可以多套zookeeper集群服务一套clickhouse集群

机器人平台 X-Insight 数据洞察平台 X-Zatlas 数据可视化平台 模板 X-BI 数据探索平台 图像分类 平台 OCR工具 链 X-Farm 异构数据治理、协同平台 元数据管理/数据集市 数据权限管理 | 大数据、流数据建模 | 数据/模型生命周期管理 资源调度 业务系统 开 发 工 具 基 础 设 施 模型 反馈 智能应用 开放与敏捷 • 大数据、流数据统一建模管理 支持算法模型结果的可重现、可审计 • 缓解AI/机器学习带来的潜在伦理与法律担忧 全生命周期管理 追溯与可重现 洞察平台架构 Why Clickhouse? Clickhosue 性能 高效的数据导入和查询性能 开源 低成本，免费 压缩比 高度的数据压缩比，存储成本更小 面向列 真正的面向列存储， 支持高维度表 易观开源OLAP引擎测评报告 洞察数据模型+Clickhouse 使用效果 CHAPTER 使用ck对百亿数据的探索 03 背景 我们希望对保单、用户数据进行灵活分析，根据用户标签筛选出符合 要求的客户进行精准营销。 原始保单数据百亿+，用户数据数亿，如果用户标签几百个，数据存 储和查询以及分析的压力就会很大，原有系统使用es来保存用户标签 数据。 保单表 用户表 用户行为表 ODPS ES 用户标签表 痛点 • 数据查询慢：每个查询需要5～10分钟； • 数据更新慢：更新数据可能需要数天时间；

小游戏 WEB 游戏 海外 游戏 TDM-SDK 客户端采集 特性 采集 大数据基础 PaaS平台 游戏 营销活动 Dbbinlog 数据库采集 Game DB 数 据 管 理 + 元 数 据 TDBANK 准实时传输管道 Kafka-Pipeline 实时管道 TDW 数据仓库 采 集 存 储 大数据应用 PaaS平台 数据挖掘与内容推荐 PaaS 精准 推荐 Column2 Column3 ColumnN bitmap 画像下钻分布式计算引擎 多维 提取 iData大数据分析引擎 分布式多维计算引擎 基于位图索引和行式内容存储 分布式画像引擎 基于位图索引和列式内容存储 多维 分析 跟踪 分析 下钻 分析 透视 分析 画像 分析 一切以用户价值为依归 19 业务应用实践 iData 2 旧画像系统 Block

query：执行的详细SQL，查询相关记录可以 根据SQL关键字筛选该字段 query_duration_ms：执行时间 memory_usage：占用内存 read_rows和read_bytes ：读取行数和大小 result_rows和result_bytes ：结果行数和 大小 以上信息可以简单对比SQL执行效果 全球敏捷运维峰会 广州站 采用ClickHouse后平台的查询性能 全球敏捷运维峰会 广州站

不断收集CPU、 Memory等系统指标预 测系统未来趋势 不断收集市场变化信 息预测股价涨跌 不断的汇总日成交量从 而制定商业规划 不断收集温度，坐标，方向 ，速度等指标，优化路线和 驾驶方式 ► 上述业务数据特点: ► (1) 数据多 ► (2) 旧数据趋于不变 ► (3) 新数据更有价值 ► (4) 数据总是随时间变化而不断变化 Why we choose it