Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
⼤大数据时代
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
Próxima SlideShare
Cargando en…5
×

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

3.506 visualizaciones

Publicado el

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

Publicado en: Tecnología
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

大数据时代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

×