Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
⼤大数据时代
feed架构
新浪微博 @TimYang
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service
!
MC
MQ(mcq)
Firehose
Redis
Config
Service
RPC
Motan
Trace体系
超⻓长列表
...
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service
!
MC
MQ(mcq)
Firehose
Redis
Config
Service
RPC
Motan
Trace体系
超⻓长列表
...
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service
!
MC
MQ(mcq)
Firehose
Redis
Config
Service
RPC
Motan
Trace体系
超⻓长列表
...
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service
!
MC
MQ(mcq)
Firehose
Redis
Config
Service
RPC
Motan
Trace体系
超⻓长列表
...
扩展性
!
!
!
!
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service
!
MC
MQ(mcq)
Firehose
Redis
Config
Service
RPC
Motan
Tr...
扩展性
!
!
!
!
中间层
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service
!
MC
MQ(mcq)
Firehose
Redis
Config
Service
RPC
Motan
Tr...
扩展性
!
!
!
!
中间层
实时数据流
!
!
!
!
存储层
当前架构
MySQL HBase Redis(存储) 分布式⽂文件
Cache-Service
!
MC
MQ(mcq)
Firehose
Redis
Config
Servic...
架构特点
✓ 解决了数据规模⼤大且超⻓长LIST访问的问题	

✓ MySQL sharding by time range	

✓ 解决了数据存储可扩展的问题	

✓ 2~3 years	

✓ 解决了百万QPS访问的问题	

✓Cache ...
读写⽐比例⾼高 10:1读写⽐比以上
冷热数据明显 80%访问的是当天内的数据
存在热点问题 峰值写⼊入80万/分钟!
(2014元旦)
⾼高访问量 每天超过7000万⽤用户访问!
(2014Q3数据)
⼤大数据环境的性能解决之道 — 缓存
读写⽐比例⾼高 10:1读写⽐比以上
冷热数据明显 80%访问的是当天内的数据
存在热点问题 峰值写⼊入80万/分钟!
(2014元旦)
⾼高访问量 每天超过7000万⽤用户访问!
(2014Q3数据)
Service
L1/LRU
Pool 1
L1/LRU
Pool 2
L1/LRU
Pool 3
Master
Pool
Slave
Pool
⼤大数据环境的	

性能解决之道
Service
L1/LRU
Pool 1
L1/LRU
Pool 2
L1/LRU
Pool 3
Master
Pool
Slave
Pool
⼤大数据环境的	

性能解决之道
主数据
Service
L1/LRU
Pool 1
L1/LRU
Pool 2
L1/LRU
Pool 3
Master
Pool
Slave
Pool
⼤大数据环境的	

性能解决之道
主数据 副本(对等)
Service
L1/LRU
Pool 1
L1/LRU
Pool 2
L1/LRU
Pool 3
Master
Pool
Slave
Pool
⼤大数据环境的	

性能解决之道
主数据 副本(对等)
分级缓存 - 副本 (可选)
Service
L1/LRU
Pool 1
L1/LRU
Pool 2
L1/LRU
Pool 3
Master
Pool
Slave
Pool
⼤大数据环境的	

性能解决之道
主数据 副本(对等)
分级缓存 - 副本 (可选)
分层设计
解...
• 如何使⽤用缓存模型来解决可⽤用性及性能问题
• ⼆二级缓存的运作机制详解
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)
DataCenter
2
Firehose
Fanout
feed存储
cache r...
Hadoop / Spark
feed消息队列
Feed 发表
feed mq
mcq mcq
多机房分发
worker
(in)
worker
(out)
DataCenter
2
Firehose
Fanout
feed存储
cache r...
流式计算
Hadoop / Spark
feed消息队列
Feed 发表
feed mq
mcq mcq
多机房分发
worker
(in)
worker
(out)
DataCenter
2
Firehose
Fanout
feed存储
ca...
流式计算 分布式
多机房
Hadoop / Spark
feed消息队列
Feed 发表
feed mq
mcq mcq
多机房分发
worker
(in)
worker
(out)
DataCenter
2
Firehose
Fanout
f...
架构特点(1)
✓实时:处理时间 100ms 以内	

✓可扩展:⽆无状态设计,简单增加节点扩
容	

✓可⽤用性:99.99%+,⾃自动failover,⽆无单点
性能
架构特点(2)
✓统⼀一实时推送通道 — mcq &
firehose	

✓统⼀一数据流,职责分明,解决三
⼤大需求	

✓标准化格式,internal probuf 格式
数据流
firehose - 实时的业务数据流
Consumer!
Group
Config!
Service
broker
broker!
(slave)
Consumer Consumer Producer Producer
✓ ⼀一对多(pub-su...
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
Event...
多元化存储
数据类型 特点 存储解决⽅方案 存储产品
微博内容
类型简单
海量访问
关系型数据库
分布式Key - Value
MySQL
微博列表
结构化列表数据
多维度查询
关系型数据库
NoSQL
HBase
MySQL
关系
类型简单
...
多元化存储
数据类型 特点 存储解决⽅方案 存储产品
微博内容
类型简单
海量访问
关系型数据库
分布式Key - Value
MySQL
微博列表
结构化列表数据
多维度查询
关系型数据库
NoSQL
HBase
MySQL
关系
类型简单
...
列表型数据
数据类型 结构 单个List
⻓长度
规模
关注
{“uid”: “follow_uid1”,
“follow_uid2”… “follow_uidn”}
1-3000 千亿级
粉丝
{“uid”: “fan_uid1”, “fan...
列表型数据
数据类型 结构 单个List
⻓长度
规模
关注
{“uid”: “follow_uid1”,
“follow_uid2”… “follow_uidn”}
1-3000 千亿级
粉丝
{“uid”: “fan_uid1”, “fan...
列表型数据
数据类型 结构 单个List
⻓长度
规模
关注
{“uid”: “follow_uid1”,
“follow_uid2”… “follow_uidn”}
1-3000 千亿级
粉丝
{“uid”: “fan_uid1”, “fan...
列表型数据
数据类型 结构 单个List
⻓长度
规模
关注
{“uid”: “follow_uid1”,
“follow_uid2”… “follow_uidn”}
1-3000 千亿级
粉丝
{“uid”: “fan_uid1”, “fan...
列表访问效率
列表访问效率
列表访问效率
列表访问效率
列表访问效率
列表访问效率
关系数据库并⾮非为
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
offs...
feed存储 - 总结
‣ 从各⾃自建设到可复⽤用的⽅方向发展	

‣ 曾尝试mysql-proxy⽅方向,但业务⽅方需
求不强烈	

‣ 类似超⻓长列表的服务得到了较好⽀支持	

‣ 抽象共性问题并解决,⽽而不是增加熵
聚合
Feed流
Timeline
反垃圾策略
微博特征
⽤用户特征
⽇日志
Firehose
分析
⽤用户
feed-list
⽤用户
feed-list
⽤用户
feed-list
MySQL
Cache
Redis
Read/write ...
聚合
Feed流
Timeline
反垃圾策略
微博特征
⽤用户特征
⽇日志
Firehose
分析
⽤用户
feed-list
⽤用户
feed-list
⽤用户
feed-list
MySQL
Cache
Redis
Read/write ...
聚合
Feed流
Timeline
反垃圾策略
微博特征
⽤用户特征
⽇日志
Firehose
分析
⽤用户
feed-list
⽤用户
feed-list
⽤用户
feed-list
MySQL
Cache
Redis
Read/write ...
聚合
Feed流
Timeline
反垃圾策略
微博特征
⽤用户特征
⽇日志
Firehose
分析
⽤用户
feed-list
⽤用户
feed-list
⽤用户
feed-list
MySQL
Cache
Redis
Read/write ...
๏ 基于⽤用户维度组织内
容⾼高效满⾜足兴趣阅读
的难度
๏ 信息识别及低质内容
鉴定的技术挑战
๏ 反垃圾算法的难度
不⾜足的做对的
✓ 成熟的feed推拉聚合
模型
✓ 成熟的⽤用户数据组织
⽅方式
feed展⽰示- 总结
总结与展望
• Key List
• Key Value
• SQL
MQ
firehose
• 趋势
• 降噪、提权
• 反垃圾
• 排序
缓存复制
proxy
微博
feed
feed
存储
feed
消息队列
Feed展⽰示
聚合、排序
f...
Q&A
TimYang
微信公众号
http://timyang.net
Upcoming SlideShare
Loading in …5
×

大数据时代feed架构 (ArchSummit Beijing 2014)

3,479 views

Published on

介绍在性能、实时数据流、存储扩展性以及feed展示方面的架构设计。

Published in: Technology
  • Be the first to comment

大数据时代feed架构 (ArchSummit Beijing 2014)

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

×