高性能,高可用,可扩展在途牛

2020-02-27 129浏览

  • 1.⾼高性能，⾼高可⽤用，可扩展 在途⽜牛旅游⽹网的实际经验 2014.4.26
  • 2.• ⼤大数据! • 搜索! • 价格计算
  • 3.途⽜牛⼤大数据模型架构 传统数据模型架构：需求驱动 • 需求驱动模型架构： 随需求变化快，模型的重构性低，⼤大数据 源表1 过渡表1 多维 模型1 源表2 过渡表2 多维 模型2 的处理和计算差性能 途⽜牛业务特点：变化⾮非常迅速，对数据的需求变化也⾮非常快； 途⽜牛模型架构：数据驱动的模型架构，⾮非需求驱动的模型架构；
  • 4.途⽜牛⼤大数据模型架构 途⽜牛数据模型架构：数据驱动 原始数据系统 业务流 数据流 途⽜牛核⼼心数据模型 特点： • 途⽜牛核⼼心层是基于公司的业务流设计的，不随需求的变动⽽而变动； • 需求的变动仅仅影响多维层模型； • 模型架构复杂性低，重构性强； 多维模型
  • 5.途⽜牛⼤大数据模型架构 业务流落地成数据流案例
  • 6.途⽜牛⼤大数据平台演变 ⽼老数据平台 ! SSAS ! ! SSRS SSIS SQLSERVER BI 订单系统 • ⽤用户⾏行为系 统 产品系统 …… 评论系统 数据架构：服务器架构伸缩性差， 1+1的服务器搭建模式（1台数据仓库服务器+1台报表 服务器）； • 数据存储：数据量不到1T，没有包含⽤用户⾏行为数据； • 系统并发：并发⽐比较差，⼏几⼗十个⼈人的并发，系统就会卡； • 数据处理：处理时间⻓长，每天数据处理需要8-10个⼩小时； • 数据运⾏行：系统负荷⾼高，系统异常频发；
  • 7.离线架构 – 物理架构 NameNode NameNode ⾮非关系型数据源 ⾮非关系型数据源 DataNode DataNode DataNode DataNode DataNode DataNode DataNode Rack1 Rack2 RackN …… 其他数据源 数据源 • … DataNode …… DataNode Mysql集群 …… ⼤大数据处理集群 ⼤大数据查询 服务群 数据架构：可伸缩性的服务器架构，⽀支持多台服务器扩充，⺫⽬目前20多台服务器，集群可以扩 张到上千台以上；! • 数据存储：包含了⽤用户⾏行为数据，上百T的数据容量；! • 数据并发：⽀支持上百⼈人同时在线并发；! • 数据处理：离线数据处理时⻓长控制在5⼩小时以内，实时数据处理达到5秒以内；! • 数据运⾏行：充分利⽤用各台服务器资源，每台服务器负荷均匀；
  • 8.离线架构 - 处理架构 应 ⽤用 层 流量监控系统 访 问 层 ⽤用户分析系统 推送接⼝口 访问接⼝口 计 算 层 Map/Reduce处理 存 储 层 HDFS分布式存储 采 集 层 数据采集引擎 源 数 据 层 ⾮非结构化数据 • • • 精准营销系统 其他数据应⽤用 BI分析系统 Oracle访问库 元 数 据 管 理 调度 数据检错引擎 结构化数据 数据逻辑层次分明，控制系统的⾼高可⽤用性和⼤大数据处理能⼒力； 降低系统的数据耦合性，降低数据出错⻛风险，提供数据的可⽤用性； 结构化和⾮非结构化数据进⾏行⼤大数据平台，进⾏行快速的批量处理； 其他数据 ETL
  • 9.离线架构 - 数据处理 多数据系统采集处理能⼒力：通过跨平台的数据采集服务引擎 1. 数据源系统繁多：由于各种历史缘故，途⽜牛底层数据系统繁多，共达60多个 ；! 2. 数据源跨平台：数据源系统分部在各不同的平台，linux、windows等；! 3. 数据源格式多样：有⽂文本数据、有各种关系型数据库（Oracle、Mysql、 Sqlserver等）； 海量数据计算能⼒力： 1. ⼤大数据平台拥有处理百T级别数据的能⼒力；! 2. Hadoop分布式处理能⼒力，各个数据节点并发处理海量数据；
  • 10.实时架构
  • 11.数据平台⾼高可⽤用性 • 软硬件设计时避免SPOF；! • ⾃自动化监控系统 • 采⽤用双NameNode，共享元数据库，当Active的NameNode异常后，系统能快速切换到Standby的 NameNode，使得Standby 的NameNode成Active，系统可以正常运⾏行；! • 多硬盘的DataNode，每个Data Block有三份，当数据损坏（⽐比如模块硬盘坏了或者某台服务器挂 了），集群可以从同个Rack或者最近的Rack中拷⻉贝数据Block，系统可以正常运⾏行
  • 12.数据平台⾼高可⽤用性 • 从机制上保证系统的可⽤用性，尽量降低系统不可⽤用的时⻓长和损失；! • 建⽴立Ganglia监控中⼼心，建⽴立实时报警机制，通过短信和邮件及时通知； ◆ Ganglia监控系统： Ganglia监控 短信系统 邮件系统
  • 13.搜索
  • 14.搜索
  • 15.⾼高频局部更新 – 现象 • • • • 产品属性构成复杂! 数据来源众多 ⼤大批量更新请求! ⽣生产使⽤用低版本Solr⽅方案
  • 16.⾼高频局部更新 – ⽅方案 • • • • 根源：低版本Solr(<4.0)不⽀支持局部更新! 原⽅方案! • 查询Solr获得需更新的产品的完整copy • 更新相应字段后重新提交新的copy ! 改进⽅方案! • 在⾼高性能KV存储中保存产品信息! • 产品信息局部更新时从KV中获得当前完整产品数据! • 更新相应字段后提交给Solr并更新KV ! 优缺点! • 优：每次更新减少⼀一次Solr查询，⼤大幅性能提升! • 弱：⾮非Solr原⽣生⽀支持，在KV失效后仍会对Solr产⽣生压⼒力
  • 17.⾼高频局部更新 – ⽰示意图
  • 18.搜索前置解析– 现象 • 搜索框仅⽀支持关键词查询! • 重度依赖分词和关键词匹配! • 相关性较差
  • 19.搜索前置解析 – ⽅方案 • ⺫⽬目的! • “⻢马尔代夫”仅呈现相关⺫⽬目的地产品 ! • 前置解析! • 分词优化! • 实体识别! • 词性分类! ! • ⾹香港杜莎夫⼈人蜡像馆 -> [⺫⽬目的地]⾹香港 + [景点]杜莎夫⼈人蜡像馆
  • 20.搜索前置解析 – ⽰示意图
  • 21.索引数据缓冲 – 现象 • • • • • 到达即消费，⽆无记录! 数据来源多 推送频率⾼高 监控能⼒力弱 问题定位难度⼤大
  • 22.索引数据缓冲 – ⽅方案&⽰示意图 • ⽀支持Failover修复! • ⽅方便定位! • 合并后更新
  • 23.起价计算 • 内容1 • 内容2
  • 24.起价计算架构演进—V1 价格变化 App MQ 全程异 步化 使⽤用MQ 事务机制 主动计算 推送搜索 Price Price !Price ! !!Price !! 计算线程池 !! 计算线程池 计算线程池 计算线程池 Master 搜索 MQ 主动计算 Slaver 读写分离 多线程计 算
  • 25.起价计算 - 我们需要更快响应 • 运维：你们的机器，经常CPU⾼高负载！! • 业务：下周要引⼊入新的业务，价格计算没有问题吧？! • 产品： 调整价格都半天了，⺴⽹网站显⽰示的还是⽼老价格！! • DBA： 你们单个表达到2亿级别了！!
  • 26.起价计算架构演进—V2 价格变化 App MQ 被动并⾏行计算 ! ! 消息处理层! ! ! 推送搜索 MQ 搜索 计算优先级! ! 计算价格计算 的优先级 分库分表 Gearman 并⾏行计算框架! ! ! Master Master Slaver Slaver Gearman计算 框架
  • 27.起价计算 – 经验教训 • ⽔水平扩展：系统在设计阶段就要考虑如何扩展! • 容量规划：系统在设计阶段对⾃自⾝身服务能⼒力的规划! • 监控报警：完善的监控报警机制，提前补漏! • 系统解耦：不要在⾼高并发下压垮依赖系统
  • 28.谢谢！