大数据时代的feed流架构

pocki

贡献于2014-12-21

字数:0 关键词: 分布式/云计算/大数据

⼤数据时代 feed架构 新浪微博 @TimYang 中间层 存储层 当前架构 MySQL HBase Redis(存储 ) 分布式⽂件 Cache-Service ! MC MQ(mcq) FirehoseRedis Config Service RPC Motan Trace体系 超⻓列表 平台 服务层 feed 算法 微博 内容 关系 评论 短链⽤户 SLA体系 平台 接⼊层 内⺴核⼼池 内⺴池 公⺴池 私信 端 Web 客户端 开放平台 计数服务 TouchStone 算 法 策 略 中间层 存储层 当前架构 MySQL HBase Redis(存储 ) 分布式⽂件 Cache-Service ! MC MQ(mcq) FirehoseRedis Config Service RPC Motan Trace体系 超⻓列表 平台 服务层 feed 算法 微博 内容 关系 评论 短链⽤户 SLA体系 平台 接⼊层 内⺴核⼼池 内⺴池 公⺴池 私信 端 Web 客户端 开放平台 计数服务 TouchStone 算 法 策 略 每天数百亿调⽤ 中间层 存储层 当前架构 MySQL HBase Redis(存储 ) 分布式⽂件 Cache-Service ! MC MQ(mcq) FirehoseRedis Config Service RPC Motan Trace体系 超⻓列表 平台 服务层 feed 算法 微博 内容 关系 评论 短链⽤户 SLA体系 平台 接⼊层 内⺴核⼼池 内⺴池 公⺴池 私信 端 Web 客户端 开放平台 计数服务 TouchStone 算 法 策 略 服务化 ! ! ! ! 每天数百亿调⽤ 中间层 存储层 当前架构 MySQL HBase Redis(存储 ) 分布式⽂件 Cache-Service ! MC MQ(mcq) FirehoseRedis Config Service RPC Motan Trace体系 超⻓列表 平台 服务层 feed 算法 微博 内容 关系 评论 短链⽤户 SLA体系 平台 接⼊层 内⺴核⼼池 内⺴池 公⺴池 私信 端 Web 客户端 开放平台 计数服务 TouchStone 算 法 策 略 服务化 ! ! ! ! 性能 ! ! ! ! 每天数百亿调⽤ 扩展性 ! ! ! ! 中间层 存储层 当前架构 MySQL HBase Redis(存储 ) 分布式⽂件 Cache-Service ! MC MQ(mcq) FirehoseRedis Config Service RPC Motan Trace体系 超⻓列表 平台 服务层 feed 算法 微博 内容 关系 评论 短链⽤户 SLA体系 平台 接⼊层 内⺴核⼼池 内⺴池 公⺴池 私信 端 Web 客户端 开放平台 计数服务 TouchStone 算 法 策 略 服务化 ! ! ! ! 性能 ! ! ! ! 每天数百亿调⽤ 扩展性 ! ! ! ! 中间层 存储层 当前架构 MySQL HBase Redis(存储 ) 分布式⽂件 Cache-Service ! MC MQ(mcq) FirehoseRedis Config Service RPC Motan Trace体系 超⻓列表 平台 服务层 feed 算法 微博 内容 关系 评论 短链⽤户 SLA体系 平台 接⼊层 内⺴核⼼池 内⺴池 公⺴池 私信 端 Web 客户端 开放平台 计数服务 TouchStone 算 法 策 略 可⽤性 ! ! ! ! 服务化 ! ! ! ! 性能 ! ! ! ! 每天数百亿调⽤ 扩展性 ! ! ! ! 中间层 实时数据流 ! ! ! ! 存储层 当前架构 MySQL HBase Redis(存储 ) 分布式⽂件 Cache-Service ! MC MQ(mcq) FirehoseRedis Config Service 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/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) Data Center 2 Firehose Fanout feed存储 cache redis mysql画像 标签 ⼲告 推荐 Data change event 开放 平台 其他 业务 msg processor worker worker worker worker Appli- cations Fanout Fanout Input Hadoop / Spark feed消息队列 Feed 发表 feed mq mcq mcq 多机房分发 worker (in) worker (out) Data Center 2 Firehose Fanout feed存储 cache redis mysql画像 标签 ⼲告 推荐 Data change event 开放 平台 其他 业务 msg processor worker worker worker worker Appli- cations Fanout Fanout Input 信息流处理 流式计算 Hadoop / Spark feed消息队列 Feed 发表 feed mq mcq mcq 多机房分发 worker (in) worker (out) Data Center 2 Firehose Fanout feed存储 cache redis mysql画像 标签 ⼲告 推荐 Data change event 开放 平台 其他 业务 msg processor worker worker worker worker Appli- cations Fanout Fanout Input 信息流处理 流式计算 分布式 多机房 Hadoop / Spark feed消息队列 Feed 发表 feed mq mcq mcq 多机房分发 worker (in) worker (out) Data Center 2 Firehose Fanout feed存储 cache redis mysql画像 标签 ⼲告 推荐 Data change event 开放 平台 其他 业务 msg processor worker 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-out Broker 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 性能与可⽤性 Q&A TimYang 微信公众号 http://timyang.net

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享文档获得金币 ] 0 人已下载

下载文档

相关文档