Upload
bing
View
259
Download
0
Embed Size (px)
DESCRIPTION
!. mdrill - 大数据即席 分析. 子落 - 母延年 2013 年 11 月. 内容大纲. 为什么要做 mdrill 什么是 mdrill mdrill 在阿里 关键技术点分享 未来. 为什么要做 mdrill ?. 解决什么样的问题?. 数据 量大(百亿条, 45T/ 天) 10 秒 内 响应. 场景一: 全文检索 - 在线查询. 阿里内 支付宝的交易日志查询 阿里妈妈的广告 pv 明细 查询 阿 里外 某运营商的每天的电话清单 某即时通讯软件的用户的聊天记录 - 关键词匹配 铁路交通系统中的每位乘客信息. Hadoop ?. - PowerPoint PPT Presentation
Citation preview
!mdrill- 大数据即席分析
子落 - 母延年2013 年 11 月
内容大纲• 为什么要做 mdrill• 什么是 mdrill• mdrill 在阿里• 关键技术点分享• 未来
为什么要做 mdrill ?
解决什么样的问题?
场景一:全文检索 - 在线查询数据量大(百亿条, 45T/ 天)10 秒内响应
Hadoop?
hbase?
阿里内• 支付宝的交易日志查询• 阿里妈妈的广告 pv 明细查询
阿里外• 某运营商的每天的电话清单• 某即时通讯软件的用户的聊天记录 - 关键词匹配• 铁路交通系统中的每位乘客信息
场景二: 在线多维分析
阿里内• TOP N 查询• 热词,热销• 趋势
阿里外• 日常报表统计,排序• 实时流量系统
Hadoop?
storm?
扫描量大(单次百亿条记录)任意维度过滤、统计、排序10~200 秒响应
前世今生
2011.7:Higo Kickoff
2011.12:higo 第一个版本
2012.3:支付宝黄金策上线
2012.12:阿里妈妈 adhoc 上线。higo分支更名为mdrill
2013.7:mdrill正式开源
mdril
l
什么是
一个在几秒到几十秒的时间,分析海量的任意维度组合数据的工具。
?
关键词
秒级即席查询
A
海量数据B
任意维度组合&过滤
C
实时数据D
基本功能• 查询明细:
Select x1,x2,x3 from table • 查询明细,并排序:
Select x1,x2,x3 from table order by x1 • 支持任意维度的分组统计
Select x1,count(*) from table group by x1• 分组统计后可以按照某个统计值,或列进行排序
Select x1,x2,x3,count(*) as cnt from table group by x1,x2,x3 order by cnt• 支持的过滤与统计
支持 like,in,not in,等于,不等于,大于等于,小于等于等过滤方式 对数据进行 sum,max,min,count,avg,dist等统计
Mdrill在阿里
Adhoc- 全文检索• 每天 162亿 *70维度的数据增量。• 通过mapreduce创建索引 (1000slot 6小时 )• 使用云梯 hdfs存储和检索( 45T/天)• 10台机器 -48G内存• 响应时间 3~10秒
• 共存储半年 600亿 80~400维度的数据。• 12张表,单表最大 220亿行数据。• 使用本地硬盘存储和检索。• 10台机器 (每台: 48G内存 ,2T*12磁盘 )。• 对 180亿数据进行 count(*)耗时 30秒单列 sum耗时 40~80秒(跨越 18个分区)
Adhoc- 即席分析
• 实时数据流入 (实时 append)。• 3台机器,每天千万的增量 (到亿很轻松 )。• 存储每个 pid, pv, click, rt, load等的每分钟的明细存储。• 前台根据不同的维护组合统计与过滤。
全景监控
Adhoc- 数据查询过滤
Adhoc- 数据分类汇总
Adhoc- 数据汇总排序
Adhoc- 趋势分析
Adhoc- 对比
全景监控
• 支付宝黄金策 (higo)。• 支付宝无线日志统计。• ……
其他
mdrill
Solrlucene
核心依赖对源码和索引结构做了较大的改动
hadoop
创建与存储索引
jstorm
Solr服务的调度与管理
心跳和任务协调
依赖的主要开源项目
zookeeper
mdrill技术要点
快怎样才能做到
? • 减少磁盘 IO。• 减少网络 IO。• 提升计算速度。• 分布式,并行计算。
基于行的存储
基于列的存储
有什么好处?
倒排索引
有什么好处?
差值存储
?长文本的重复值很少,压缩比不高……
长文本占用空间较大,完整扫描一遍 IO时间太长……
关于长文本问题
长文本占内存多……太长的字符串计算速度慢……
关于长文本问题
在 group by和排序的时候,仅使用数值代号
呈现给用户的时候,将代号转换回原始值
查询多层合并流程
顶层MS
MS1
shard1 shard2
MS…
Shard…
Ms 合并(优先合并本机器的shard 和 ms )
无论是 shard 还是 ms 均只返回TOP 1W 条结果
每个 solr 在各自的 shards 内
计算
merger过程的优化
merger过程的优化
仅回查这 8条的文本值
用户
真实值
创建索引流程
最终的索引
hdfs 小索引
内存中的小索引
内存中的小索引
Hdfs 小索引
内存中的小索引
Hdfs 小索引先在内存中创
建小索引
生成小索引
将小索引合并成最终的大索引
实时索引
queue
Tmp Index
write
RAMB
RAM A
守护进程
disk1
disk2
disk3
diskN
search
AB切换
hdfs1
hdfs2
hdfs3
hdfsN
系统架构
jstorm
Solr5
201306 201307 ……
…Solr6…
hadoop
mdrill-jdbc
SQL
mdrill-shell
建表,建索引
建表,建索引Solr search
mdrill-core
copy 索引 … 碎片 1 碎片 2 … …
201306… …
合并索引
全文检索 TOP N
个别词频率特别高,但往往仅需要 TOP N 个结果,怎么办?
Doclist的压缩利用doclist本身可以跳跃的特性,多条件组合查询只读取 top 1W
其他
• tii 跳跃表的加载优化• 直接在 hdfs 上创建索引• 合并索引优化 (addIndexesNoOptimize)• fdt 文件 - 移除或采用变长数据
版本规划
规划
• 0.18 当前版本• 0.19 基于 replication形式的 HA• 0.20 实时数据源• 0.21 调度考虑基于 hadoop yarn 实现
相关资源
https://github.com/alibaba/mdrillhttps://github.com/muyannian/higohttps://github.com/alibaba/jstorm新浪微博:延年
谢谢聆听!