京东零售大数据 OLAP 应用与实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. !"#$%&'()*+
,-./0
嘉宾：京东大数据架构师 陈洪健
2. 目录
CONTENTS
!" 背景介绍
!$ 查询架构
Subject
Subject
!# 数据工具
!% 问题和规划
Subject
Subject
3. !"
应用场景
Subject
介绍京东黄金眼在京东零售大数据
OLAP的项目背景和解决思路
4. 京东黄金眼商智流量业务场景
流量实时
流量概览
流量来源去向 流量归因
实时流量数据全量化分析， 离线流量数据分析uv、 展示首次来源、末次来源和 基于用户在网站上的行为连
实时流量概览，流量来源 pv，有效用户数、成交 去向分析数据，支持流量节 续性，将用户的行为划分为
去向。 用户，全维度分析 点之间的流量衰减、购买等 相互独立的访问区间，并假
数据分析，支持更精细的维 设该区间内的行为具有因果
度分析。 关系，从而将用户点击与其
产生的经济价值进行关联计
算的平台。
5. 流量分析特征
Ø 海量
l
万亿流量数据，每日更新千亿数据
Ø 多变性
时效性
组织架构变化
l 采销岗位变化
l 商品、品牌、品类等属性变化
Ø 复杂性
海量
多变性
l
复杂性
l 关联维度多
l 追溯层级深
l 数据随机性
Ø 时效性
l 出数时间
l 查询时效，高并发、低延时
6. 京东黄金眼解决思路
时效性 准确性 高并发
ü 每日8点前出数 ü 每日更新数据维度信息 ü 不同存储引擎combo
ü 平均10亿条/min更新数据 ü 特定场景物化视图精确去重 ü 多集群负载
ü 版本化更新数据无感知
ü 集群状态管控
7. !#
数据工具
Subject
介绍ClickHouse推数工具和刷数工具、预
计算框架
8. ClickHouse推数工具
9. 技术特性
Hive
版本表
数据量检查
元数据检查，集群负载， 指标合理值检查
删除数据检查，元数据更新 空值检查
缓存表
正式表
分片级数据回滚
集群检查
数据传输
数据验证
版本化更新
数据Shard切分
合并小文件 数据从Hive更新到ck版本表
并发推数 校验完成
异常处理
ALTER TABLE A_local ATTACH PARTITION (dt) FROM A_tmp_local
10. ClickHouse刷数工具
11. 技术特性
ü 数据分布
分布式表和字典表根据同一id分布、例如（sku_id）
ü Local to Local
聚合逻辑和刷岗逻辑都是本地表 to 本地表的方式，不走分布式表，减少网络开销
ü 各分片字典不同动态加载
各分片将本地维表加载到字典表中，减少内存占用
ü 多主题字典
可拆分交易、流量主题的字典，减少字典数据量，加速刷数速率
ü 多副本刷数
多副本可以刷不同周期的数据，并行执行，减少整体刷数时间
ü 数据校验和版本化
刷数完成校验相应的指标值，确认数据后从版本表中attach到线上表，用户无感知
12. ClickHouse预计算
Grouping_ID
路径生成
数据智能切分
并行度调节器 聚合计算
集群状态监控 CH Cluster
中间数据缓存
13. 技术特性
ü Grouping sets
l
指定所有维度、必须要有的维度、有级联关系的维度、需要剔除的维
度
l
根据Spark sql规则生成grouping sets id
ü 智能裁剪数据
l
本质是union all，当计算数据量超过ck集群内存时，将各维度所有枚
举值count出来，从少到多，迭代每一个值，计算结果insert到结果
表
ü 数据缓存和数据校验
l
group by 后面的维度组合，desc排序，打开clickhouse缓存设置
<use_uncompressed_cache>1</use_uncompressed_cache>
l
预计算结果和spark sql运行结果校验
ü 集群状态管控
l
查询system.query_log表获取当前正在执行的sql以及
memory_usage内存使用情况
l 查询system.asynchronous_metrics读取cpu负载情况
l 根据集群cpu、内存状态动态调节并发数
14. !$
查询架构
Subject
通过查询架构升级，满足海量数据查询的
高并发和低延时
15. 高可用查询架构
各个组件的用途
Data Service
• Data Service数据服务层
• Redis存储各个用户首开页面的数据以及缓存用户查询的
Query Route
Redis
ES
结果
Proxy
CH Cluster
• Es存储大的数据集合的预计算数据，变动较小
• CK存储
CH Cluster
•
• 1、通过Spark sql离线计算的预计算数据
• 2、通过CK进行预计算采销细粒度变动较大数据
• 3、流量明细数据，满足前端任意维度交叉olap计算
Proxy负载均衡、Quota控制、容灾、多活集群控制
16. 多存储引擎Combo方案
ü ClickHouse多活集群
l
l
重要的业务需要做多活集群，为满足容灾从集群负载控制在30%以下，并且要跨机房。
集群主从切换根据集群状态自动切换，减少人为干预。
ü 分布式Redis
l
首开页面的高并发和低延时需要内存式存储引擎，但需要控制数据量，量比适当的同时
提供用户极致的查询体验
ü ES
l
大的数据集合，更新较少，查询请求多变且具备谷峰周期，超大的瞬时并发CK无法承受。
ü Spark预计算
l
当前ClickHouse Sql语义和内存的限制使得主体的预计算还是通过Spark计算，但细粒
度内存消耗少CK预计算可以更加快速的计算，在凌晨可以充分利用CK的算力。
17. 查询优化
去重计算
- countDistinct根据业务需要替换为
uniqCombined64或者count group by
Join优化
- 本地in取代join
- 能转换成UInt64的转换，使用Array -过滤条件放到Join的子查询
- optimize+ final 方式去重可以在多分区间 - 关联字段Int32会比String计算性能
去重
好1倍
- argMax方式可以在多节点间去重 - GLOBAL JOIN会把数据发送给所有
- Group bitmap去重 UInt64 节点参与计算，针对较小的维度表性
能较好
数据裁剪
- 建立rollup小表
- 物化视图
-name不参与计算，可通过字典获取
- JOIN会在本地节点操作，适合于相
同分片字段的两张表关联
- Join的顺序，大表在左，小表在右
-…
18. !%
问题和规划
Subject
在高并发调用下遇到的问题，以及未来的
规划
19. 常见问题
导数
查询
l 查询多次返回结果不一致，有节点掉盘 l 多任务同时导数
l 节点替换ZK元数据不一致 l 脏数据处理
l 关联字典无法高并发查询 l 单副本集合压力过大
l CPU打满无法获取集群状态 l 分片级数据回滚
l 多集群返回结果不一致 l 导数期间删除数据，页面无数据
l HLL近似计算误差 l 多实例集群
l 内存溢出OOM l 物化视图表导数
l 索引优化 l 无法进行DDL操作
20. 未来规划
Ø 多集群联合查询
l
首先要对分级查询的方式进行优化，解决逐级匹配带来的查询时间上的浪费。其次是利用多集群联合查询来解决单集群性能提升有限
的问题，并为多集群联合查询制定了协作策略和负载均衡
Ø ClickHouse预计算的通用性
l
不额外增加服务器成本的情况下，立足于数据和集群本身，在保证集群稳定的前提下提升集群的高并发能力，同时提高集群进行聚合
计算的数据量级。
l
ClickHouse 的预计算SQL语义向Hive靠近，使得原来的Hive脚本可以在ClickHouse上运行，具备通用性
Ø 不同存储数据库的同步
l
ClickHouse预计算的结果可以同步到ES、分布式Redis
21. 未来规划 – 查询资源容器化
22. 非常感谢您的观看