2. Clickhouse玩转每天千亿数据-趣头条趣头条 王海胜 提纲 • 业务背景 • 集群现状 • 我们遇到的问题 业务背景 基于storm的实时指标的计算存在的问题 1:指标口径(SQL) -> 实时任务 2:数据的回溯 3:稳定性 业务背景 什么是我们需要的? 1:实时指标SQL化 2:数据方便回溯,数据有问题,方便恢复 3:运维需要简单 4:计算要快,在一个周期内,要完成所有的指标的计算 集群现状 100+台32核128G order by (timestamp, eventType) or order by (eventType, timestamp) 业务场景 1:趣头条和米读的上报数据是按照”事件类型”(eventType)进行区分 2:指标系统分”分时”和”累时”指标 3:指标的一般都是会按照eventType进行区分 select count(1) from table where dt='' and timestamp>='' timestamp>='' and timestamp<='' and eventType='' 建表的时候缺乏深度思考,由于分时指标的特性,我们的表是order by (timestamp, eventType)进行索引 的,这样在计算累时指标的时候出现非常耗时(600亿+数据量) 分析: 对于累时数据,时间索引基本就失效了,由于timestamp”基数”比较高,对于排在第二位eventType索引,0 码力 | 14 页 | 1.10 MB | 1 年前3
2. 腾讯 clickhouse实践 _2019丁晓坤&熊峰MultiTable 100000 10k 9 49 413 NO 一切以用户价值为依归 8 部署与监控管理 1 应用监控-业务指标: 一切以用户价值为依归 9 部署与监控管理 1 服务监控-错误日志: 一切以用户价值为依归 10 部署与监控管理 1 服务监控-请求指标: 一切以用户价值为依归 11 部署与监控管理 1 服务监控-扫描详情: 一切以用户价值为依归 12 部署与监控管理 监控分层 监控项 敏感度 紧急度 应用层 业务指标,数据异常 低 高 服务层 错误日志 中 中 请求指标 扫描详情 响应耗时 物理层 磁盘IO, 持续负载,流量 高 低 一切以用户价值为依归 业务应用实践 iData 14 2 一切以用户价值为依归 15 业务应用实践 iData 2 一切以用户价值为依归 l 游戏数据分析的业务背景 l iData 数据分析引擎TGMars 数据分析引擎TGMars l 为什么选用ClickHouse l 平台在ClickHouse上的使用 16 业务应用实践 iData 2 腾讯游戏 数据化驱动服务 场景视图: TGlog 服务端采集 腾讯游戏 服务器 腾讯游戏 移动客户端 微信 小游戏 WEB 游戏 海外 游戏 TDM-SDK 客户端采集 特性 采集 大数据基础 PaaS平台 游戏 营销活动 Dbbinlog0 码力 | 26 页 | 3.58 MB | 1 年前3
8. Continue to use ClickHouse as TSDBMemory等系统指标预 测系统未来趋势 不断收集市场变化信 息预测股价涨跌 不断的汇总日成交量从 而制定商业规划 Why we choose it 不断收集CPU、 Memory等系统指标预 测系统未来趋势 不断收集市场变化信 息预测股价涨跌 不断的汇总日成交量从 而制定商业规划 不断收集温度,坐标,方向 ,速度等指标,优化路线和 驾驶方式 ► 上述业务数据特点: ►0 码力 | 42 页 | 911.10 KB | 1 年前3
蔡岳毅-基于ClickHouse+StarRocks构建支撑千亿级数据量的高可用查询引擎如何来补充ClickHouse 的短板; 4. ClickHouse的调优,运维介绍; 5. 应用总结; 全球敏捷运维峰会 广州站 根据实际业务场景需要来选择 1. 不固定的查询条件,不固定的汇总条件; 2. 数据量日益增量,每天要更新的数据量也不断增大; 3. 业务场景不断增多,涉及面越来越广; 4. 需要保证高可用并秒出; 5. 从Sql,Es, CrateDB, Kylin,Ingite,MongoDB,Hbase0 码力 | 15 页 | 1.33 MB | 1 年前3
6. ClickHouse在众安的实践数据探索平台 图像分类 平台 OCR工具 链 X-Farm 异构数据治理、协同平台 元数据管理/数据集市 数据权限管理 | 大数据、流数据建模 | 数据/模型生命周期管理 资源调度 业务系统 开 发 工 具 基 础 设 施 模型 反馈 智能应用 开放与敏捷 • 大数据、流数据统一建模管理 • 垂直方向行业模板,简化开发过程 • 多语言多runtime支持,Bring • 数据更新慢:更新数据可能需要数天时间; • 不灵活:用户有新标签需求时,需要提需求给标签开发人员排期开发 需求,开发人员开发完再更新到系统中,这时离需求提出可能已经过 去几天,无法及时给到业务人员反馈。 思路 利用clickhouse实时计算的高效性能,对原始数据进行查询分析,从而支 持用户灵活的定义标签并让用户实时得到反馈。 标签平台 clickhouse 保单表 用户表 用户行为表0 码力 | 28 页 | 4.00 MB | 1 年前3
4. ClickHouse在苏宁用户画像场景的实践ElasticSearch 用户数据 交易数据 HBase Redis 第三方… Spark 用户画像平台 现有的流程: ES中定义标签的大宽表 通过Spark关联各种业务数据,插入到ES大 宽表。 高频查询的画像数据通过后台任务保存到加 速层:Hbase 戒者 Redis 实时标签通过Flink计算,然后写入Redis 用户画像平台可以从ES、Hbase、Redis查0 码力 | 32 页 | 1.47 MB | 1 年前3
共 6 条
- 1













