clickhouse数仓应用实践 演讲人：朱元 日期： 2019-10-20 所遇问题 目录 CONTENTS 现状背景 应用实践 01 数据链路长 现状 即席查询性能差 数据压缩率低 需求响应慢 02 数据架构 数据同步ck 01 1，基于公司对数据要求为T+1 2. 基于现有开发人员水平及成本 因此采用可视化同步工具kettle. 先将oracle数据平台维 clickhouse数据库 数 仓 建 设 01 ck数仓数据模型采用星型模型搭建 02 数 仓 建 设 – 维度表 一般维度表数据量不大. 目前采用的是引擎Log+字典表(dictionary) 数 仓 建 设 – 主题事实清单表 主题事实清单表采用引擎MergeTree. 同步策略: 每日从 oracle数据平台增量同步到ck数仓. 数 仓 建 设 – 对外数据 目前对外开放是主题事实清单表+维度表 目前对外开放是主题事实清单表+维度表 封装成一个视图,类 似如下 数 据 展 示 + 多 维 分析 采用开源报表系统davinci 地址: https://github.com/edp963/davinci 03 1. Memory limit (for query) exceeded 解决：通过在users.xml 配置 max_bytes_before_external_sort max_b

Clickhouse 的应用实践 iData 目录 部署与监控管理 一切以用户价值为依归 3 1 4 部署与监控管理 1 高内存，廉价存储： 单机配置: Memory128G CPU核数24 SATA20T，RAID5 万兆网卡 一切以用户价值为依归 5 部署与监控管理 1 生产环境部署方案： Distributed Table Replica1Replica1 Replica1Replica1 部署与监控管理 1 服务监控-响应耗时： 一切以用户价值为依归 13 部署与监控管理 1 立体监控模型： 监控分层 监控项 敏感度 紧急度 应用层 业务指标，数据异常 低 高 服务层 错误日志 中 中 请求指标 扫描详情 响应耗时 物理层 磁盘IO， 持续负载，流量 高 低 一切以用户价值为依归 业务应用实践 iData 14 2 一切以用户价值为依归 15 业务应用实践 小游戏 WEB 游戏 海外 游戏 TDM-SDK 客户端采集 特性 采集 大数据基础 PaaS平台 游戏 营销活动 Dbbinlog 数据库采集 Game DB 数 据 管 理 + 元 数 据 TDBANK 准实时传输管道 Kafka-Pipeline 实时管道 TDW 数据仓库 采 集 存 储 大数据应用 PaaS平台 数据挖掘与内容推荐 PaaS

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

'A188') WHERE ID LIKE 'A006%' ['A006', 'A007') 2. 递归交集判断 3. 合并MarkRange区间 索引的查询过程 二级索引 跳数索引 目前，MergeTree共支持4种跳数索引，分别是minmax、set和ngrambf_v1和tokenbf_v1。 数据存储 按列存储，精心编排，错落有致 压缩数据块，就好比是一本书的文字段落，是组织文字的基本单元。

Spark 用户画像平台 现有的流程：  ES中定义标签的大宽表  通过Spark关联各种业务数据，插入到ES大 宽表。  高频查询的画像数据通过后台任务保存到加 速层：Hbase 戒者 Redis  实时标签通过Flink计算，然后写入Redis  用户画像平台可以从ES、Hbase、Redis查 询数据 痛点：  标签导入到ES的时间过长，需要等待各种业