• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Web请求异步处理和海量数据即时分析在淘宝开放平台的实践
 

Web请求异步处理和海量数据即时分析在淘宝开放平台的实践

on

  • 3,484 views

Web请求异步处理和海量数据即时分析在淘宝开放平台的实践

Web请求异步处理和海量数据即时分析在淘宝开放平台的实践

Statistics

Views

Total Views
3,484
Views on SlideShare
2,445
Embed Views
1,039

Actions

Likes
9
Downloads
0
Comments
1

3 Embeds 1,039

http://www.mysqlops.com 1036
http://webcache.googleusercontent.com 2
http://cache.baidu.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • 不错,学习一下
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Web请求异步处理和海量数据即时分析在淘宝开放平台的实践 Web请求异步处理和海量数据即时分析在淘宝开放平台的实践 Presentation Transcript

    •  放翁(文初)  fangweng@taobao.com    
    • Outline  s  Web请求异步化处理的实践   s  Web请求异步化的原因   s  异步化模式在开放平台的使用场景  s  “海量”数据“即时”分析   s  “海量”、“即时”的需求背景   s  整体设计结构和思路   s  优化实践  
    • Web请求异步化的原因 s  为什么要异步化?   渲染          根本原因:容器线程利 展示 用率不高。   s  业务处理天然异步化需业务 求(业务处理消耗比较处理 久,外部事件激发)   容器线 s  减少连接带来的消耗, 充分利用服务端并行处 程 理能力   s  减少业务依赖不稳定对 容器线程资源的低效率 占用  
    • 异步化模式在开放平台的使 用场景 框架控制串行化逻辑隔 离   实际应用:服务降级, Beta发布       半异步化模式再次分配 请求处理资源    实际应用:服务隔离       并行任务执行,部分累 加输出    实际应用:batch  api       基于事件驱动,服务端 异步消息推送   实际应用:streaming   api  
    • 异步化模式在开放平台的使 用场景管道化:    1.串行逻辑非关键路径降级。  2.框架级支持公用逻辑植入。(log,lazy  parser,event  driven,comet…)  3.流程逻辑复用与隔离。      
    • 异步化模式在开放平台的使 用场景
    • 异步化模式在开放平台的使 用场景
    • 异步化模式在开放平台的使 用场景服务隔离的效果3,6,2  某一天三个时间段的淘客服务统计数据
    • 异步化模式在开放平台的使 用场景
    • 异步化模式在开放平台的使 用场景
    • “海量”、“即时”的需求背景 现状 需求 应用维度分析 服务维度分析 1台实体机器+12台 虚拟机 器 平台维度分析 15亿(400G) 监控告警,趋势分 析 产出周期小于2分(结果 钟)
    • 整体设计结构和思路
    • 整体设计结构和思路 Master:管理任务(分析任务),合 并结果(Reduce),输出结果(全量 统计,增量片段统计) Slave:Require  Job  +  Do  Job  +  Return   Result,随意加入,退出集群。 Job:(Input  +  Analysis  Rule  +  Output) 的定义。
    • 整体设计结构和思路•  后台系统任务分配:无负载分配算法,采用细化任务+工作者按需 自取+粗暴简单任务重置策略。•  Slave与Master采用单向通信,便于容量扩充和缩减。•  Job自描述性:数据来源,分析规则,结果输出。异构化任务处理 集群共享Slave。•  数据存储无业务性,分析规则包含业务含义(优势在于可扩展,劣 势在于全量扫描日志)•  透明化整个集群运行状况,保证简单粗暴的方式下能够快速定位出 节点问题或者任务问题。•  Master单点采用冷备方式解决。(异步化外移状态,减少服务端状 态数据)
    • 整体设计结构和思路Master Slave 数据量:2千万 -­‐-­‐>1亿 -­‐-­‐>8亿  -­‐-­‐>15亿。   报表输出结果:10份配置 -­‐-­‐>30份 -­‐-­‐>60份 -­‐-­‐>100份。   统计后的数据量:10k    -­‐-­‐>10M    -­‐-­‐>  9G。   统计周期的要求:1天 -­‐-­‐>5分钟 -­‐-­‐>3分钟 -­‐-­‐>1分半。
    • 优化实践纵向系统的工作的分担 1.平面化分担合并任务   2.中间结果输出,外部合并
    • 优化实践流程中间数据优化 减少中间结果无 节省带宽, 用存储和处理 内存, cpu 压缩中间结果和内部 taobao.user.get—12132342—fangweng 标识(可逆vs不可逆, 算法vs对照表) 服务成功率=服务成功次数/服务总数
    • 优化实践 特殊化处理特殊的流程:Master 1.  简化序列化(已知序列化对象可简单化)   2.  减少内存申请,尽快释放处理后的数据   3.  减少中间过程的消耗
    • 优化实践特殊化处理特殊的流程:<K,V>    à    Report    =  N  *  <K,V>  group  by    K   KV  Pool1 apiName,apiTotalCount 1.深度遍历+二维数组  apiName,apiResponse apiName,apiFailCount KV  Pool2   2.广度遍历+一维数组 KV  Pool3 Report   apiName,apiTotalCount,apiResponse,apiFailCount
    • 优化实践合并调度及磁盘内存互换的优化:   合并数据是内存消耗重灾区:  合并数据是内存消耗重灾区:   1.是否可以快速处理回收?  1.合并前有大量数据挂接在接收 2.是否可以减少中间结果占用空缓存列表上   间  2.合并过程会消耗大量的内存   3.是否可以释放主干,需要时载3.合并后主干占用大量内存   入  4.输出时占用大量内存 4.是否可以压缩和过滤
    • 优化实践合并调度及磁盘内存互换的优化:  
    • 优化实践磁盘内存互换的优化:   消耗:   主干载入和输出   收益:   周期内主干内存 释放(GC减少提 高速度)     优化细节:   1.载入最优时机   2.输出内容压缩, 速度加快   3.导出异步化   4.  
    • 优化实践1.        利用可横向扩展的系统来分担纵向扩展系统的工作。2.        流程中中间数据的优化处理。3.        特殊化处理可以特殊处理的流程。4.        从整体流程上考虑不同策略的消耗,提高整体处理能力。5.        资源的快用快放,提高同一类资源利用率。6.        不同阶段不同资源的互换,提高不同资源的利用率。  
    • 附录分析器:http://code.taobao.org/p/top-­‐analyzer/src/trunk/    异步化:http://code.taobao.org/p/PipeComet/src/trunk/    REST,logdrager:git://github.com/cenwenchu/PythonBox.git  
    • 附图
    • 附图
    • 附图
    • 附图