大数据时代feed架构 (archsummit beijing 2014)
TRANSCRIPT
⼤大数据时代 feed架构新浪微博 @TimYang
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service !
MC
MQ(mcq)
FirehoseRedisCon
fig
Serv
ice
RPC Motan
Trace体系超⻓长列表
平台 服务层
feed 算法
微博 内容 关系 评论 短链⽤用户
SLA体系
平台 接⼊入层 内⺴⽹网核⼼心池 内⺴⽹网池 公⺴⽹网池
私信
端 Web 客户端 开放平台
计数服务TouchStone
算法 策略
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service !
MC
MQ(mcq)
FirehoseRedisCon
fig
Serv
ice
RPC Motan
Trace体系超⻓长列表
平台 服务层
feed 算法
微博 内容 关系 评论 短链⽤用户
SLA体系
平台 接⼊入层 内⺴⽹网核⼼心池 内⺴⽹网池 公⺴⽹网池
私信
端 Web 客户端 开放平台
计数服务TouchStone
算法 策略
每天数百亿调⽤用
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service !
MC
MQ(mcq)
FirehoseRedisCon
fig
Serv
ice
RPC Motan
Trace体系超⻓长列表
平台 服务层
feed 算法
微博 内容 关系 评论 短链⽤用户
SLA体系
平台 接⼊入层 内⺴⽹网核⼼心池 内⺴⽹网池 公⺴⽹网池
私信
端 Web 客户端 开放平台
计数服务TouchStone
算法 策略
服务化 !!!!
每天数百亿调⽤用
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service !
MC
MQ(mcq)
FirehoseRedisCon
fig
Serv
ice
RPC Motan
Trace体系超⻓长列表
平台 服务层
feed 算法
微博 内容 关系 评论 短链⽤用户
SLA体系
平台 接⼊入层 内⺴⽹网核⼼心池 内⺴⽹网池 公⺴⽹网池
私信
端 Web 客户端 开放平台
计数服务TouchStone
算法 策略
服务化 !!!!
性能 !!!!
每天数百亿调⽤用
扩展性 !!!!
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service !
MC
MQ(mcq)
FirehoseRedisCon
fig
Serv
ice
RPC Motan
Trace体系超⻓长列表
平台 服务层
feed 算法
微博 内容 关系 评论 短链⽤用户
SLA体系
平台 接⼊入层 内⺴⽹网核⼼心池 内⺴⽹网池 公⺴⽹网池
私信
端 Web 客户端 开放平台
计数服务TouchStone
算法 策略
服务化 !!!!
性能 !!!!
每天数百亿调⽤用
扩展性 !!!!
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service !
MC
MQ(mcq)
FirehoseRedisCon
fig
Serv
ice
RPC Motan
Trace体系超⻓长列表
平台 服务层
feed 算法
微博 内容 关系 评论 短链⽤用户
SLA体系
平台 接⼊入层 内⺴⽹网核⼼心池 内⺴⽹网池 公⺴⽹网池
私信
端 Web 客户端 开放平台
计数服务TouchStone
算法 策略
可⽤用性 !!!!
服务化 !!!!
性能 !!!!
每天数百亿调⽤用
扩展性 !!!!
中间层
实时数据流 !!!!
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service !
MC
MQ(mcq)
FirehoseRedisCon
fig
Serv
ice
RPC Motan
Trace体系超⻓长列表
平台 服务层
feed 算法
微博 内容 关系 评论 短链⽤用户
SLA体系
平台 接⼊入层 内⺴⽹网核⼼心池 内⺴⽹网池 公⺴⽹网池
私信
端 Web 客户端 开放平台
计数服务TouchStone
算法 策略
可⽤用性 !!!!
服务化 !!!!
性能 !!!!
每天数百亿调⽤用
架构特点✓ 解决了数据规模⼤大且超⻓长LIST访问的问题 ✓ MySQL sharding by time range
✓ 解决了数据存储可扩展的问题 ✓ 2~3 years
✓ 解决了百万QPS访问的问题 ✓Cache replication及分级
✓ 解决了可⽤用性及错误隔离问题 ✓ by SLA体系，核⼼心功能 99.99%+
读写⽐比例⾼高 10:1读写⽐比以上
冷热数据明显 80%访问的是当天内的数据
存在热点问题 峰值写⼊入80万/分钟!(2014元旦)
⾼高访问量 每天超过7000万⽤用户访问!(2014Q3数据)
⼤大数据环境的性能解决之道 — 缓存
读写⽐比例⾼高 10:1读写⽐比以上
冷热数据明显 80%访问的是当天内的数据
存在热点问题 峰值写⼊入80万/分钟!(2014元旦)
⾼高访问量 每天超过7000万⽤用户访问!(2014Q3数据)
Service
L1/LRUPool 1
L1/LRUPool 2
L1/LRUPool 3
MasterPool
SlavePool
⼤大数据环境的 性能解决之道
Service
L1/LRUPool 1
L1/LRUPool 2
L1/LRUPool 3
MasterPool
SlavePool
⼤大数据环境的 性能解决之道
主数据
Service
L1/LRUPool 1
L1/LRUPool 2
L1/LRUPool 3
MasterPool
SlavePool
⼤大数据环境的 性能解决之道
主数据 副本（对等）
Service
L1/LRUPool 1
L1/LRUPool 2
L1/LRUPool 3
MasterPool
SlavePool
⼤大数据环境的 性能解决之道
主数据 副本（对等）
分级缓存 - 副本 （可选）
Service
L1/LRUPool 1
L1/LRUPool 2
L1/LRUPool 3
MasterPool
SlavePool
⼤大数据环境的 性能解决之道
主数据 副本（对等）
分级缓存 - 副本 （可选）
分层设计 解决热数据 性能
• 如何使⽤用缓存模型来解决可⽤用性及性能问题
• ⼆二级缓存的运作机制详解
Cache service
Master Slave
Client0
L1L1
read
Write
Cache service
Client1
feed性能 - 总结
‣ Local cache?
‣删除实现复杂 ‣可以通过短超时⽅方式 ‣极热数据的带宽问题需要提前考虑
Hadoop / Spark
feed消息队列Feed 发表
feed mq
mcq mcq
多机房分发
worker (in)
worker (out)
Data C
enter 2
Firehose
Fanout
feed存储
cache redis mysql画像 标签
⼲⼴广告 推荐
Data change event
开放 平台
其他 业务
msg processorworker worker
worker worker
Appli- cations
Fanout Fanout
Input
Hadoop / Spark
feed消息队列Feed 发表
feed mq
mcq mcq
多机房分发
worker (in)
worker (out)
Data C
enter 2
Firehose
Fanout
feed存储
cache redis mysql画像 标签
⼲⼴广告 推荐
Data change event
开放 平台
其他 业务
msg processorworker worker
worker worker
Appli- cations
Fanout Fanout
Input
信息流处理
流式计算
Hadoop / Spark
feed消息队列Feed 发表
feed mq
mcq mcq
多机房分发
worker (in)
worker (out)
Data C
enter 2
Firehose
Fanout
feed存储
cache redis mysql画像 标签
⼲⼴广告 推荐
Data change event
开放 平台
其他 业务
msg processorworker worker
worker worker
Appli- cations
Fanout Fanout
Input
信息流处理
流式计算 分布式 多机房
Hadoop / Spark
feed消息队列Feed 发表
feed mq
mcq mcq
多机房分发
worker (in)
worker (out)
Data C
enter 2
Firehose
Fanout
feed存储
cache redis mysql画像 标签
⼲⼴广告 推荐
Data change event
开放 平台
其他 业务
msg processorworker worker
worker worker
Appli- cations
Fanout Fanout
Input
信息流处理
架构特点(1)✓实时：处理时间 100ms 以内
✓可扩展：⽆无状态设计，简单增加节点扩容
✓可⽤用性：99.99%+，⾃自动failover，⽆无单点
性能
架构特点(2)
✓统⼀一实时推送通道 — mcq & firehose
✓统⼀一数据流，职责分明，解决三⼤大需求
✓标准化格式，internal probuf 格式
数据流
firehose - 实时的业务数据流Consumer!Group
Config!Service
broker
broker!(slave)
Consumer Consumer Producer Producer✓ ⼀一对多(pub-sub)
✓ 实时数据流
✓ 补推能⼒力
✓ 数据量⼤大，每秒数万条
✓ 可靠性
✓ Fan-outBroker
Memory!Queue
Offset!Magager
Topic!Magager
Cold!Data!
Buffer
broker
broker!(slave)
broker
broker!(slave)
放⼤大
Storm⽐比较
‣ msg processor相对于storm没有调度(nimbus)功能；
‣ 没有bolt的streaming串联功能，但可以通过在任务中重写对应业务的mq消息间接实现
Databus⽐比较
‣ Databus基于数据库事件触发消息到总线； ‣ 我们使⽤用⾃自⾏行写⼊入消息到firehose的⽅方式
Kafka⽐比较
‣ feature基本类似，firehose更偏业务 ‣ pub-sub/offset/at least once
‣ 都不⽀支持 timeline consistency，不保证时序 ‣ 社交产品⼤大多数场景适合
实时数据流 - 总结
‣罗⻢马不是⼀一天建成的 ‣⾃自定义队列满天⻜飞的时代的痛苦 ‣尝试过databus trigger⽅方式
‣需要具有抽象共性的意识 ‣ Lambda architecture
Feed Events Queue
Application
Application
Application
多元化存储数据类型 特点 存储解决⽅方案 存储产品
微博内容 类型简单 海量访问
关系型数据库 分布式Key - Value MySQL
微博列表 结构化列表数据 多维度查询
关系型数据库 NoSQL
HBase MySQL
关系 类型简单 ⾼高速访问
内存式 key-value key-list结构
MySQL Redis
⻓长微博 图⽚片/短视频
块数据 ⼩小⽂文件 分布式⽂文件系统
计数 (微博数 阅读数…）
结构简单 数据及访问量⼤大
内存紧凑型 NoSQL Redis
多元化存储数据类型 特点 存储解决⽅方案 存储产品
微博内容 类型简单 海量访问
关系型数据库 分布式Key - Value MySQL
微博列表 结构化列表数据 多维度查询
关系型数据库 NoSQL
HBase MySQL
关系 类型简单 ⾼高速访问
内存式 key-value key-list结构
MySQL Redis
⻓长微博 图⽚片/短视频
块数据 ⼩小⽂文件 分布式⽂文件系统
计数 (微博数 阅读数…）
结构简单 数据及访问量⼤大
内存紧凑型 NoSQL Redis
列表型数据数据类型 结构 单个List
⻓长度 规模
关注 {“uid”: “follow_uid1”, “follow_uid2”… “follow_uidn”} 1-3000 千亿级
粉丝 {“uid”: “fan_uid1”, “fan_uid2”… “fan_uidn”} 1-8000万 千亿级
发表微博列表 {“uid”: “feed_id1”, “feed_id2”… “feed_idn”} 1-100万+ 千亿级
转发微博列表 {“weibo_id”: “repost_id1”, “repost_id2”… “repost_idn”} 1-500万+ 千亿级
评论列表 {“weibo_id”: “cmt_id1”, “cmt_id2”… “cmt_idn”} 1-500万+ 千亿级
列表型数据数据类型 结构 单个List
⻓长度 规模
关注 {“uid”: “follow_uid1”, “follow_uid2”… “follow_uidn”} 1-3000 千亿级
粉丝 {“uid”: “fan_uid1”, “fan_uid2”… “fan_uidn”} 1-8000万 千亿级
发表微博列表 {“uid”: “feed_id1”, “feed_id2”… “feed_idn”} 1-100万+ 千亿级
转发微博列表 {“weibo_id”: “repost_id1”, “repost_id2”… “repost_idn”} 1-500万+ 千亿级
评论列表 {“weibo_id”: “cmt_id1”, “cmt_id2”… “cmt_idn”} 1-500万+ 千亿级
类型多
列表型数据数据类型 结构 单个List
⻓长度 规模
关注 {“uid”: “follow_uid1”, “follow_uid2”… “follow_uidn”} 1-3000 千亿级
粉丝 {“uid”: “fan_uid1”, “fan_uid2”… “fan_uidn”} 1-8000万 千亿级
发表微博列表 {“uid”: “feed_id1”, “feed_id2”… “feed_idn”} 1-100万+ 千亿级
转发微博列表 {“weibo_id”: “repost_id1”, “repost_id2”… “repost_idn”} 1-500万+ 千亿级
评论列表 {“weibo_id”: “cmt_id1”, “cmt_id2”… “cmt_idn”} 1-500万+ 千亿级
类型多 变⻓长/超⻓长
列表型数据数据类型 结构 单个List
⻓长度 规模
关注 {“uid”: “follow_uid1”, “follow_uid2”… “follow_uidn”} 1-3000 千亿级
粉丝 {“uid”: “fan_uid1”, “fan_uid2”… “fan_uidn”} 1-8000万 千亿级
发表微博列表 {“uid”: “feed_id1”, “feed_id2”… “feed_idn”} 1-100万+ 千亿级
转发微博列表 {“weibo_id”: “repost_id1”, “repost_id2”… “repost_idn”} 1-500万+ 千亿级
评论列表 {“weibo_id”: “cmt_id1”, “cmt_id2”… “cmt_idn”} 1-500万+ 千亿级
类型多 变⻓长/超⻓长 ⼤大数据
列表访问效率
列表访问效率
列表访问效率
列表访问效率
列表访问效率
列表访问效率
关系数据库并⾮非为list scan设计
通⽤用的⼆二级索引
通⽤用的⼆二级索引
count index [6, 12]
通⽤用的⼆二级索引
Offset index [15, 8]
count index [6, 12]
shard-3shard-2shard-1
2013
2012~
2009
2014
2013
2014
2013
2014
2012~2011
列表性能及成本
shard-3shard-2shard-1
2013
2012~
2009
2014
2013
2014
2013
2014
2012~2011
列表性能及成本
shard-3shard-2shard-1
2013
2012~
2009
2014
2013
2014
2013
2014
2012~2011
pool 1 ⾼高速 设备
列表性能及成本
shard-3shard-2shard-1
2013
2012~
2009
2014
2013
2014
2013
2014
2012~2011
pool 1 ⾼高速 设备
列表性能及成本
shard-3shard-2shard-1
2013
2012~
2009
2014
2013
2014
2013
2014
2012~2011
pool 1 ⾼高速 设备
列表性能及成本
shard-3shard-2shard-1
2013
2012~
2009
2014
2013
2014
2013
2014
2012~2011
pool 1 ⾼高速 设备
pool 3 廉价 设备
列表性能及成本
加速层!⼆二级索引
列表存储服务
存储!引擎 MySQL HBase
存储!策略层
接⼝口 saveList(id, offset, size)
⼀一致性 SLA(QoS) Metrics超⻓长列表 Sharding Trace
offset index count index
loadList(id, offset, size)
feed存储 - 总结
‣从各⾃自建设到可复⽤用的⽅方向发展 ‣曾尝试mysql-proxy⽅方向，但业务⽅方需求不强烈
‣类似超⻓长列表的服务得到了较好⽀支持 ‣抽象共性问题并解决，⽽而不是增加熵
聚合 Feed流 Timeline
反垃圾策略
微博特征
⽤用户特征
⽇日志 Firehose
分析
⽤用户 feed-list⽤用户
feed-list⽤用户
feed-list
MySQL
Cache
Redis
Read/write Through
反馈
算法!(推荐、提权、排序)
feed展⽰示过程
关注关系
聚合 Feed流 Timeline
反垃圾策略
微博特征
⽤用户特征
⽇日志 Firehose
分析
⽤用户 feed-list⽤用户
feed-list⽤用户
feed-list
MySQL
Cache
Redis
Read/write Through
反馈
算法!(推荐、提权、排序)
⽤用户维度feed展⽰示过程
关注关系
聚合 Feed流 Timeline
反垃圾策略
微博特征
⽤用户特征
⽇日志 Firehose
分析
⽤用户 feed-list⽤用户
feed-list⽤用户
feed-list
MySQL
Cache
Redis
Read/write Through
反馈
算法!(推荐、提权、排序)
⽤用户维度feed展⽰示过程
关注关系⽤用户维度
聚合 Feed流 Timeline
反垃圾策略
微博特征
⽤用户特征
⽇日志 Firehose
分析
⽤用户 feed-list⽤用户
feed-list⽤用户
feed-list
MySQL
Cache
Redis
Read/write Through
反馈
算法!(推荐、提权、排序)
⽤用户维度feed展⽰示过程
关注关系⽤用户维度
兴趣聚类
๏ 基于⽤用户维度组织内容⾼高效满⾜足兴趣阅读的难度
๏ 信息识别及低质内容鉴定的技术挑战
๏ 反垃圾算法的难度
不⾜足的做对的
✓ 成熟的feed推拉聚合模型
✓ 成熟的⽤用户数据组织⽅方式
feed展⽰示- 总结
总结与展望• Key List • Key Value • SQL
MQ firehose
• 趋势 • 降噪、提权 • 反垃圾 • 排序
缓存复制 proxy
微博 feed
feed 存储
feed 消息队列
Feed展⽰示 聚合、排序
feed 性能与可⽤用性
