的短板； 4. ClickHouse的调优，运维介绍； 5. 应用总结； 全球敏捷运维峰会 广州站 根据实际业务场景需要来选择 1. 不固定的查询条件，不固定的汇总条件； 2. 数据量日益增量，每天要更新的数据量也不断增大； 3. 业务场景不断增多，涉及面越来越广； 4. 需要保证高可用并秒出； 5. 从Sql，Es， CrateDB， Kylin，Ingite，MongoDB，Hbase into，但最理想的是消费Kafka； 全球敏捷运维峰会 广州站 ClickHouse/StarRocks在酒店数据智能平台的架构 全球敏捷运维峰会 广州站 ClickHouse的全量数据同步流程 1. 清空A_temp表，将最新的数据从Hive通过ETL导入 到A_temp表; 2. 将A rename 成A_temp_temp; 3. 将A_temp 1. 采用 waterdrop 的方式大幅提升写入速度； 2. 直接读Hdfs文件的方式，但内存波动较大； 全球敏捷运维峰会 广州站 ClickHouse的增量数据同步流程 传统方式： 1. 将最近3个月的数据从Hive通过ETL入到A_temp表; 2. 将A表中3个月之前的数据select into到A_temp表；

应用实践 01 数据链路长 现状 即席查询性能差 数据压缩率低 需求响应慢 02 数据架构 数据同步ck 01 1，基于公司对数据要求为T+1 2. 基于现有开发人员水平及成本 因此采用可视化同步工具kettle. 先将oracle数据平台维度信息以及相关主题清单数据同步至clichouse数据 仓库 Oracle数据平台 • 通过kettle每天 定时导出文件至 本地 – 维度表 一般维度表数据量不大. 目前采用的是引擎Log+字典表(dictionary) 数 仓 建 设 – 主题事实清单表 主题事实清单表采用引擎MergeTree. 同步策略: 每日从 oracle数据平台增量同步到ck数仓. 数 仓 建 设 – 对外数据 目前对外开放是主题事实清单表+维度表 封装成一个视图,类 似如下 数 据 展 示 + 多 维 分析 采用开源报表系统davinci

uniqHLL12 4：Join时小表放到右边，“右表广播” ^v^ 我们遇到的问题 zookeeper相关的问题 问题一：zookeeper的snapshot文件太大，follower从leader同步文件时超时 问题二：zookeeper压力太大，clickhouse表处于”read only mode”，插入失败 分析： clickhouse对zookeeper的依赖还是很重的，有大量的数据