数据探索平台 图像分类 平台 OCR工具 链 X-Farm 异构数据治理、协同平台 元数据管理/数据集市 数据权限管理 | 大数据、流数据建模 | 数据/模型生命周期管理 资源调度 业务系统 开 发 工 具 基 础 设 施 模型 反馈 智能应用 开放与敏捷 • 大数据、流数据统一建模管理 • 垂直方向行业模板，简化开发过程 • 多语言多runtime支持，Bring • 数据更新慢：更新数据可能需要数天时间； • 不灵活：用户有新标签需求时，需要提需求给标签开发人员排期开发 需求，开发人员开发完再更新到系统中，这时离需求提出可能已经过 去几天，无法及时给到业务人员反馈。 思路 利用clickhouse实时计算的高效性能，对原始数据进行查询分析，从而支 持用户灵活的定义标签并让用户实时得到反馈。 标签平台 clickhouse 保单表 用户表 用户行为表 phone_flag • ha_flag • ... clickhouse集群配置 • 阿里云ECS * 6，生产环境集群 • CPU: • Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GH • 12 cores 24 processors • 内存: 96GB • 硬盘: 1TB 高效云盘，最大IO吞吐量 140MBps 以事业部、入库时间作双分区导入数据 遇到的问题

Shard02 Shard03 Load Balancing 一切以用户价值为依归 6 部署与监控管理 1 线性平滑扩容： 扩容： 1.安装新部署新的shard分片机器 2.新shard上创建表结构 3.批量修改当前集群的配置文件增加新的分片 4.名字服务添加节点 一切以用户价值为依归 7 部署与监控管理 1 大批量，少批次 WriteModel BatchSize RowLengt MultiTable 100000 1k 21 29 215 NO MultiTable 100000 10k 9 49 413 NO 一切以用户价值为依归 8 部署与监控管理 1 应用监控-业务指标： 一切以用户价值为依归 9 部署与监控管理 1 服务监控-错误日志： 一切以用户价值为依归 10 部署与监控管理 1 服务监控-请求指标： 一切以用户价值为依归 11 部署与监控管理 监控分层 监控项 敏感度 紧急度 应用层 业务指标，数据异常 低 高 服务层 错误日志 中 中 请求指标 扫描详情 响应耗时 物理层 磁盘IO， 持续负载，流量 高 低 一切以用户价值为依归 业务应用实践 iData 14 2 一切以用户价值为依归 15 业务应用实践 iData 2 一切以用户价值为依归 l 游戏数据分析的业务背景 l iData 数据分析引擎TGMars

特性发布快 3. 软件质量高 4. 物化视图 5. 高基数查询 6. 精确去重计数（count distinct） 3 精确去重计数性能测试 4亿多的数据集上，去重计算出6千万整形数值， 非精确去重函数：uniq、uniqHLL12、uniqCombined 精确去重函数：uniqExact、groupBitmap 函数 时长（秒） 去重后个数 每个bit位表示一个数字id，对亍40亿个的用户id，只需要40亿bit位， 约477m大小 = （4 * 109 / 8 / 1024 / 1024） 但是如果使用上述的数据结构存储单独一个较大数值的数字id，会造成空间上的浪费，例如 仅存储40亿一个数值也需要477m的空间。也就是说稀疏的Bitmap和稠密的占用空间相 同。通常会使用一种bitmap压缩算法迚行优化。 RoaringBitmap是一种已被业界 ElasticSearch 用户数据 交易数据 HBase Redis 第三方… Spark 用户画像平台 现有的流程：  ES中定义标签的大宽表  通过Spark关联各种业务数据，插入到ES大 宽表。  高频查询的画像数据通过后台任务保存到加 速层：Hbase 戒者 Redis  实时标签通过Flink计算，然后写入Redis  用户画像平台可以从ES、Hbase、Redis查

ClickHouse MergeTree原理解析 朱凯@深圳 2019.10 朱 凯 远光软件 大数据事业部/平台开发部 总经理 资深架构师，腾讯云TVP专家 10多年IT从业经验，精通Java、Nodejs等语言方向 著有: 《企业级大数据平台构建：架构与实现》、 《ClickHouse原理解析与开发实战》（连载写作中） 珠海总部园 区占地面积 6 万平方米 珠海、北京、武汉 l 集团风险管控 l 企业大数据及商业智能 l 企业云服务 l 智能机器人应用 l 集团IT治理 l …… l 能源产业链 l 区域能源管理 l 能源大数据 l 购售电平台 l …… l 智慧组织 l 智慧城市 l 智慧产业 l …… EDT 企业级大数据平台 BAS区块链企业应用服务平台 ECP 企 业 云 平 台 服务（咨询、实施、运维、定制开发、系统集成……） 性，同时也只有此系列的表引擎支持ALTER相关操作。 合并树家族 其中MergeTree作为家族中最基础的表引擎，提供了主键索引、数据分区、数据副 本和数据采样等所有的基本能力，而家族中其他的表引擎则在MergeTree的基础之 上各有所长。 MergeTree的名称由来 MergeTree在写入一批数据时，数据总会以数据片段的形式写入磁盘，且数据 片段不可修改。为了避免片段过多，ClickHouse会通过后台线程定期合并这

Clickhouse玩转每天千亿数据 趣头条 王海胜 提纲 • 业务背景 • 集群现状 • 我们遇到的问题 业务背景 基于storm的实时指标的计算存在的问题 1：指标口径(SQL) -> 实时任务 2：数据的回溯 3：稳定性 业务背景 什么是我们需要的? 1：实时指标SQL化 2：数据方便回溯，数据有问题，方便恢复 3：运维需要简单 4：计算要快，在一个周期内，要完成所有的指标的计算 最新版本的”冷热数据分离”特性，曲线救国? 我们遇到的问题 order by (timestamp, eventType) or order by (eventType, timestamp) 业务场景 1：趣头条和米读的上报数据是按照”事件类型”(eventType)进行区分 2：指标系统分”分时”和”累时”指标 3：指标的一般都是会按照eventType进行区分 select count(1) 2：注意监控zookeeper的指标(排队请求?处理延迟?等等)，排队请求太多可能会导致插入失败 我们遇到的问题 关于引擎选择 推荐Replicated*MergeTree引擎 1：安全，数据安全，业务安全 2：升级的时候可以做到业务无感知 3：提升查询的并发度 广告时间

如何来补充ClickHouse 的短板； 4. ClickHouse的调优，运维介绍； 5. 应用总结； 全球敏捷运维峰会 广州站 根据实际业务场景需要来选择 1. 不固定的查询条件，不固定的汇总条件； 2. 数据量日益增量，每天要更新的数据量也不断增大； 3. 业务场景不断增多，涉及面越来越广； 4. 需要保证高可用并秒出； 5. 从Sql，Es， CrateDB， Kylin，Ingite，MongoDB，Hbase

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