我们遇到的问题 业务背景 基于storm的实时指标的计算存在的问题 1：指标口径(SQL) -> 实时任务 2：数据的回溯 3：稳定性 业务背景 什么是我们需要的? 1：实时指标SQL化 2：数据方便回溯，数据有问题，方便恢复 3：运维需要简单 4：计算要快，在一个周期内，要完成所有的指标的计算 集群现状 100+台32核128G 部分复杂累时查询30S内完成 集群现状 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的依赖还是很

Load Balancing 一切以用户价值为依归 6 部署与监控管理 1 线性平滑扩容： 扩容： 1.安装新部署新的shard分片机器 2.新shard上创建表结构 3.批量修改当前集群的配置文件增加新的分片 4.名字服务添加节点 一切以用户价值为依归 7 部署与监控管理 1 大批量，少批次 WriteModel BatchSize RowLengt h QPM IOUtils 游戏数据分析的业务背景 l iData 数据分析引擎TGMars l 为什么选用ClickHouse l 平台在ClickHouse上的使用 16 业务应用实践 iData 2 腾讯游戏 数据化驱动服务 场景视图： TGlog 服务端采集 腾讯游戏 服务器 腾讯游戏 移动客户端 微信 小游戏 WEB 游戏 海外 游戏 TDM-SDK 客户端采集 特性 采集 大数据基础 DataMore 任务系统 iData 数据可视化 游 谱 游戏说 神秘 商店 iData 多维提取 … 游戏数据 驱动场景 潘多拉 社交与功能 用户增长 服务场景 游戏 社区 微信手Q 渠道投放 直播 电竞 … 大数据基础PaaS平台 n 标准化、海量数据接入能力 n 实时化、低延时对接数据应用 n 异构化兼容能力 大数据应用PaaS服务 游戏数据驱动场景

正是由表引擎，决定了一张 数据表最终的性格，它拥有何种特性、数据以何种形式被存储以及如何被加载。 ClickHouse拥有非常庞大的表引擎体系，截至到目前(19.14.6)，共拥有合并树、 内存、文件、接口和其他5大类20多种。 合并树 这众多的表引擎中，又属合并树(MergeTree)表引擎及其家族系列(*MergeTree)最 为强大，在生产环境绝大部分场景中都应该使用此系列的表引擎。 型YYYYMMDD格式，则直接按照该整型的字符形式 输出作为分区ID的取值。 l 使用日期类型 如果分区键取值属于日期类型，或者是能够转 换为YYYYMMDD日期格式的整型，则使用按照 YYYYMMDD日期格式化后的字符形式输出作为分区 ID的取值。 l 使用其它类型 如果分区键取值既不属于整型，也不属于日期 类型，例如String、Float等。则通过128位Hash 算法取其Hash值作为分区ID的取值。 对于每一个新创建的分区目录而言，其初始值均为0。之 后,以分区为单位，如果相同分区发生合并动作，则在相 应分区内计数累积加1。 分区目录的合并过程 一级索引 稀疏索引 primary.idx文件内的一级索引采用稀疏索引实现 如果把MergeTree比作是一本书，那么稀 疏索引就好比是这本书的一级章节目录。 一级章节目录不会具体对照到每个字的位 置，只会记录每个章节的起始页码。 以默认的索引粒度(8192)为例，

数据架构 数据同步ck 01 1，基于公司对数据要求为T+1 2. 基于现有开发人员水平及成本 因此采用可视化同步工具kettle. 先将oracle数据平台维度信息以及相关主题清单数据同步至clichouse数据 仓库 Oracle数据平台 • 通过kettle每天 定时导出文件至 本地 Etl服务器 • 通过clickhouse- client将文本导 入ck数据库 clickhouse数据库

依赖稀疏索引，列式存储，cpu/内存的充分利用造就了优秀的计算能力， 并且不用考虑左侧原则； 缺点： 1. 不支持事务，没有真正的update/delete； 2. 不支持高并发，可以根据实际情况修改qps相关配置文件； 全球敏捷运维峰会 广州站 StarRocks的特点 优点： 1. 支持标准的SQL语法，兼容MySql协议； 2. MPP架构，扩缩容非常简单方便； 3. 支持高并发查询； 4 4. 将A_ temp_temp rename成 A_temp; 其他方式： 1. 采用 waterdrop 的方式大幅提升写入速度； 2. 直接读Hdfs文件的方式，但内存波动较大； 全球敏捷运维峰会 广州站 ClickHouse的增量数据同步流程 传统方式： 1. 将最近3个月的数据从Hive通过ETL入到A_temp表;

成立于2013年，是中国第一家互联网保险公司。 • 互联网保险特点： 1. 场景化 2. 高频化 3. 碎片化 • 今年上半年众安上半年服务用户3.5亿，销售保单33.3亿张。 CHAPTER 报表系统的现状 01 数据分析的最直观表现形式：报表 报表≠数据驱动 每天被访问超过10次的报表寥寥无几 传统报表访问往往是静态的、高聚合、低频、表单式的 集智平台可视化交互分析 数据加工的链路与数据价值发现 竞争优势 源数据 数据清洗 标准报表 OLAP系统 商务智能（BI） 机器学习建模 人工智能优化 发生了什么？ 为什么发生？ 什么会发生？ 什么是最佳决策？ 分析性数据仓库 数据洞察与可视化 数据治理 预测分析与机器学习 CHAPTER 众安集智平台与clickhouse 02 集智平台 X-Brain AI 开放平台 计算框架 Hadoop, JStorm, Spark Streaming Clickhouse, Kylin 数据接入 消 息 中 间 件 模型、 算法 模版 机器学习平台 Antron 机器人平台 X-Insight 数据洞察平台 X-Zatlas 数据可视化平台 模板 X-BI 数据探索平台 图像分类 平台 OCR工具 链 X-Farm 异构数据治理、协同平台 元数据管理/数据集市 数据权限管理 | 大数据、流数据建模 | 数据/模型生命周期管理

27 用户画像场景3—用户ID清单—示例 画像条件 查询SQL 28 用户画像新架构的优势  每个标签的数据可以幵行构建，加快标签数据生产速度。  HDFS文件幵发导入ClickHouse，加快标签数据的就绪速度。  查询请求平均响应时长在2秒以下，复杂查询在10秒内。  支持标签数据实时更新，增加标签、删除标签、修改标签。

常驻内存模式对内存消耗很⼤ v ⾮常驻内存模式index load过程慢 v 多并发加载优化索引加载速度： 日志 日志 v Elastic To ClickHouse迁移，降本增效 v OTEL标准化⽇志采集 v 统⼀scheme⽀持 日志 v ClickHouse较ES写⼊吞吐量提升近10倍 v ClickHouse存储成本为ES的1/3 日志 v ClickHouse中采⽤分表，统⼀schema的设计 ⽀持各个事件单独设置过滤条件 v 查询时间跨度最⼤⼀个⽉ v 数据按user id做Sharding，查询下推 Future Work Future Work v ClickHouse集群容器化，提升物理集群资源使⽤率 v ClickHouse倒排索引调研与改造，提升⽇志检索性能 v 丰富ClickHouse编码类型，拓展zorder应⽤场景，提升圈选计算性能 v ClickHouse存算分离探索，降低集群扩容成本