大规模数据处理
?Download as PPTX, PDF?
6 likes?1,329 views
Convert to study guideBETA
Transform any presentation into a summarized study guide, highlighting the most important points and key insights.
大规模数据处理
- 1. 互联网应用服务扩展的一点经验-- 以FreeWheel 核心系统演化为例王迪 Di Wangdwang@freewheel.tvMSN: wangdieda@hotmail.com
- 4. 为什么做这件事—why?广告是在线视频的主要盈利方式版权保护是视频行业的核心问题 （尤其在美国）传统媒体商拥有优质内容和广告资源，缺少传播渠道 – 供给视频网站拥有流量，需要内容吸引用户，以广告盈利 – 需求FW作为独立第三方应用服务有效调剂需求与供给，提供客观测量，可为用户挖掘更多视频广告价值。美国视频广告市场价值10亿美元来源: IAB Internet Advertising Report 2009国内视频广告市场价值14亿人民币来源: iResearch 2010.04 Summit
- 5. 产物服务Monetization Rights Management – MRMSyndication Video EconomyTV Everywhere
- 6. 产物应用示例
- 7. 如何实现？——互联网广告服务系统组成Web前端——B2B应用, Ruby on Rails后台核心系统广告服务器: 高性能/高可靠 分布集群，C++/Python/Lua日志收集处理分析ETL: 高吞吐量/及时, C++/Python预测系统: 高吞吐量/运算密集/支持多并发, Erlang/C++视频播放整合Flash SDKSilverlight SDKJavascript SDKiPhone/iPad app…
- 9. 需求难点分析商业模式决定设计方案：互联网服务的规模经济和沉淀成本流量价值高于扩展成本才有意义，运营成本往往占一半以上！云计算 vs自运营的选择B2B与B2C的不同：Web UI访问较少，后台服务压力较大商业逻辑复杂：亿级用户访问，数百万video/page，数十万广告创意，数万内容公司，数千家视频网站的广告选择匹配。服务的高可靠性：99.99% uptime，<300ms latency峰值比预留：5:1 Peak to Mean.数据驱动为中心：完整性，实时性，多用户隔离，可扩展商业客户议价能力强，需大量服务支持工具。
- 10. 我们的一些经验和原则应用服务扩展无状态应用服务器复制与多层次Cache数据仓库扩展De-normalization/PivotRoll up/Data AvailabilityBenchmarking与查询优化Split-Loading/Sharding运营原则50% 运行负载上限 & N+1 Data Center监控与响应多阶段部署
- 11. 无状态广告服务器Embed Lighttpd: 消除fastcgi进程间网络通信，方便部署。交易状态相关信息编码URL，消除服务器间通信依赖。例如：http://bd0dc.v.fwmrm.net/ad/l/1?last=1&metr=127&s=b004&t=12736523773101485&adid=145307&arid=0&reid=70701&auid=&cn=defaultImpression&et=i&_cc=145307,70701,,,1273652377,1&tpos=0&iw=&uxnw=&uxss=&uxct=&init=0&cr=s – 服务器IDt – 交易GUIDadid – 广告ID
- 12. 无状态应用服务器 (Case Demo)服务器间信息交换，通过定时反馈同步应用服务重启/运行不依赖于其他应用程序Load 叠补濒补苍肠别谤础诲蝉1础诲蝉2础诲蝉狈…….尝辞驳尝辞驳尝辞驳贵别别诲产补肠办叠补肠办别苍诲
- 13. 复制与多层次Cache广告服务器的核心功能：将OLTP中用户预定的广告定位条件与当前视频请求做最佳匹配。满足性能和高可用要求，实现了四点cache机制：Pusher Regular PushQuick PushMemcacheDot Server
- 14. Regular PushWhy分离数据库变动对广告服务器的影响，减少直接数据库访问What每个数据中心一台Slave，运行一个Pusher，Pull from DB，预处理和数据准备，“mmap” structured memory dump。Read DB->Prep Data->Dump Repo->Sync Repo-> Reload Repo->SwitchGen/Sync twice per hour，2.9 G/DumpMaster->Slave读写分离复制需要注意的方面避免Master“长”写锁block Slave读锁减少用trigger和procedure实现业务逻辑
- 15. Quick PushWhy部分服务数据对时效性要求高，要求更新小于半小时。WhatPusher 单独生成只包含时效敏感数据的小mmap, 每隔15分钟生成并同步到各服务器一次， 400 Mb/Dump。需要调度与正常Push错峰带宽使用
- 16. MemcacheWhy为响应实时直播视频信息快速上传同步和广告服务的要求What收到服务请求，内存查找If 命中，请求返回Else 查找memcacheIf cache命中，请求返回；同时item添加到内存中Else if cache正在被创建，返回。Else cache内容缺失，返回；启动异步OLTP查找If DB命中，item同时添加到cache和内存中Else DB缺失，item placeholder添加到cache中，设置过期
- 17. Ad Request come in.Look up video from RAM.3".? Video in mem, return response3.? Video not it mem, redirect to /ax/ interfaceAsync look up video from cache.5,6: Query memcached for Video. the result might be:?? a).NULL,?? b). Hit but data is loading by some adserver?? c). Hit and data available7". Return response.7.? if cache missing, then return.8. Set Video with status = loading9. Invoke a thread fetch video from oltp DB.10, 11. Query video and ge result from DB12,13.? Set Video with status = available and data in both cache and mem.
- 18. Dot ServerWhyAdserver高可用性保护方案以应对突发峰值和Bug down机.触发Down机的bug往往会中断全部应用服务器What服务器内维持一个待服务请求队列, 当排队请求超过阈值或由某用户请求触发特定Bug，导致机群相继Down机后续请求转到一个无逻辑的Server Farm，并返回一个cache的无广告标准输出.最大可能避免对外服务失效
- 19. 无状态日志处理日志处理设计的主要考虑因素:减少日志体积，容易扩展，避免自己定义格式和写ParserText Log -> Binary log by Google Protocol buffer用较少的机器达到较高吞吐量：理想情况下接近磁盘I/O日志收集分区，一个Node只处理固定一组广告服务器日志尽量减少日志中需要交换处理的内容MapReduce由Hadoop/Java 转C++Aggregation由Python转C++重处理：中断后，容易从头开始，避免人工接续处理无状态设计的关键：日志条目自身应包含交易所有现场和Callback的必要信息不变的Meta Data通过Pusher从OLTP中提取
- 20. 日志格式变化Protocol Buffer Binarylog:advertisement {ad_id: 29:121 ad_replica_id: 0 rendition_id: 40:20 flags: 0:9 slot_index: 0 associate: VIDEO content_right_owner { network_id: 6:10 revenue: 0.0 inventory_id: 1:10 context_id: 4:10 } distributor { network_id: 6:10 up_network_id: -1 revenue: 0.0 up_revenue: 0.0 inventory_id: 1:10 } …Text Log:ad_id, ad_replica_id, rendition_id, flags, slot_index, associate, cro_ network_id, cro_revenue, cro_inventory_id,cro_context_id,dist_network_id,dist_up_network_id,dist_revenue,dist_up_revenue,dist_inventory_id 29:121,0,40:20,0:9,VIDEO,6:10,0.0,1:10,4:10,6:10,-1,0.0,0.0,1:10Protocol Buffer Binlogvs Text Log扩展字段方便
- 21. 现成笔补谤蝉别谤
- 22. 存储更小数据仓库扩展易于查询和建模：Normalization vs De-normalization优化行数：PivotLong tail roll up & Data Availability基于Benchmarking优化查询Table PartitionDB Sharding分离data loading与Query的冲突: Split Loading
- 23. Normalization优点：Fact 表精简，数据无冗余缺点：当业务逻辑复杂时，查询可能变得很复杂，需多次Join。当需要按照某个dimension ID做Group 产测时不能有效利用蹿补肠迟表索引，尤其当贵补肠迟表数据量较大时，性能难以接受。
- 26. Long tail roll up & Data Availability一个简单的计算: 100,000 video X 100 site X 100 Country X 1,000 Ad = 1,000,000,000,000 行/天，Impossible!互联网视频的访问热度呈现典型“长尾”分布5%的热门视频占有50%的流量在所有视频上统计所有维度/粒度的指标，ROI太低Long Tail Roll up对单日小于某一阈值流量的video在DB中roll up成一个item创建Long tail表单独对长尾视频做粗粒度统计Data Availability对不需要某些粒度指标的客户不统计相关维度产物功能设计需谨慎，一旦发布很难收回，从而带来维护负担
- 27. Benchmarking与查询优化自动Benchmark所有查询使用Production数据自动check out SQL运行提取MySQL Slow Query log测量值，多次测量平均月度评审，选择top slow query优化查询优化Schema设计应尽量让SQL简单，复杂逻辑放到应用程序正确建立和使用必要的索引InnoDB buffer设置，70%机器内存参考：《高性能MySQL》(第二版)http://www.mysqlperformanceblog.com/
- 28. Benchmarking (Case Demo)Internal Benchmark ToolBenchmark Report w queries run longer than 10 min
- 29. Partition and Sharding做完上述优化以后的选择Table Partition: 选择event_date作为Key以Partition为单位增、删数据仓库表，几乎不用UpdateSharding的收益:容易为新客户扩展限制错误影响范围客户数据相对隔离，更容易添加新DB避免单点故障可并行Load数据，提高发布效率Sharding的代价：增加硬件、架构和监控的复杂性
- 30. DB Volume Increase Trendline Before Sharding29
- 32. Impossible to do migration and reprocess!
- 33. Hard to scale!30
- 34. Sharding Architecture 31Client Facing End Shard 2Shard 3Shard 1 Huge DB
- 35. 基于Sharding下的ETL流程演示32Client Facing End 服务中XXXXXX 脱离服务加载数据..ETL
- 36. 运营原则——50% 上限 & N+1 Data Center所有子系统做容量扩展规划时，预估上限以50%负载（经验值）为限。Adserver为峰值预留50%容量，e.g突发新闻，世界杯决赛后台日志处理在用户要求的数据发布时间50%内完成，有机会应对意外出错重做一遍。业务量上涨导致系统平均负载>50%，扩容的信号！N+1 Data Center数据中心不同地理位置分布备用ISP，备用CDN保证一个DC由于意外服务中断，其他N个可正常负载服务。
- 37. 监控与响应监控分类：应用服务Check Live服务异常警报：错误，延时等数据库Master-Slave同步Cache有效性：Quick Push端到端数据一致性检验：模拟用户行为Slow Query日报当日业务运营情况日报响应：优先级: P1/P2/P37x24 On-Call Rotation
- 40. 对于测试的一点话题以自动化回归测试为核心并未使用TDD单元测试坚持Local测试->集成测试->回归测试->Staging每次升级发布前的测试检查清单New Feature Function TestUI/Core/VI Integration TestRegression Case SuiteMemory Leak CheckPerformance TestCompatible TestPost Release Live Check
- 42. 系统演化路线图第一阶段：2007年12月 – 2008年6月 目标：上线，验证服务可用性扩展工作：Push/Quick Push，监控，日志处理架构集群规模：20台广告服务器，4ETL, 4 预测，3 OLTP, 1 OLAP.业务量：日均几万至几十万次访问，日志量<1G/天第二阶段：2008年6月--2009年9月目标：扩展服务客户，数据仓库调优扩展方面的主要工作：memcache，Binarylog，数据仓库Denormalize/Pivot/Partition/Benchmarking集群规模：+20 广告服务器，+2 MemcacheD，+2ETL, +2预测，+1 OLAP。业务量：日均几百万次访问，日志量约10G/天
- 43. 当前运营情况第三阶段：2009年10月--至今目标：支持大客户，运营友好扩展工作：DB Sharding，Dot Server, 多阶段部署集群规模：广告服务器：60台，日均服务视频广告请求5000万次，广告投放量约1亿次，5%负载。后台日志处理：8台，日均4小时处理日志200骋，20%负载预测系统：6台，日均4小时模拟500万请求，20%负载数据仓库：日新增约1000万条记录词10骋存储，1罢/厂丑补谤诲
- 44. 2009.5-2010.3间流量增长20倍!服务流量趋势和可用性Service Level Agreement (SLA) >= 99.99%
- 45. 对于分布式系统和Web服务扩展相关链接BlogsNatiShalom's Blog: Discussions about middleware and distributed technologieshttp://natishalom.typepad.com/nati_shaloms_blog/All Things Distributed: Werner Vogels' weblog on building scalable and robust distributed systems.http://www.allthingsdistributed.com/High Scalability: Building bigger, faster, more reliable websiteshttp://highscalability.com/ProductionScale: Information Technology, Scalability, Technology Operations, and Cloud Computinghttp://www.productionscale.com/iamcal.comhttp://www.iamcal.com/ (the "talks" section is particularly interesting)Kitchen Soap: Thoughts on capacity planning and web operationshttp://www.kitchensoap.com/MySQL Performance Blog: Everything about MySQL Performancehttp://www.mysqlperformanceblog.com/
- 46. PresentationsScalable Internet Architectureshttp://www.slideshare.net/shiflett/scalable-internet-architecturesHow to build the Webhttp://www.slideshare.net/simon/how-to-build-the-webNetlog: What we learned about scalability & high availabilityhttp://www.slideshare.net/folke/netlog-what-we-learned-about-scalability-high-availability-430211Database Sharding at Netloghttp://www.slideshare.net/oemebamo/database-sharding-at-netlog-presentationMySQL 2007 Techn At Digg V3http://www.slideshare.net/epee/mysql-2007-tech-at-digg-v3Flickr and PHPhttp://www.slideshare.net/coolpics/flickr-44054Scalable Web Architectures: Common Patterns and Approacheshttp://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approachesHow to scale your web apphttp://www.slideshare.net/Georgio_1999/how-to-scale-your-web-appGoogle Cluster Innardshttp://www.slideshare.net/ultradvorka/google-cluster-innardsSharding Architectureshttp://www.slideshare.net/guest0e6d5e/sharding-architectures
- 47. 对于FreeWhelFreeWheel是目前全美领先的互联网数字视频广告管理和增值服务提供商，创始人团队由前DoubleClick高管组成，在美国网络广告界拥有多年市场、产物、技术和管理方面的资深经验。公司创立于2007年，由Battery Ventures和Foundation Venture投资，并于2010年3月完成第三轮1680万美元注资，引入迪斯尼Steamboat Venture和特纳广播公司（Turner）作为战略投资人。公司专注于为大型媒体公司和互联网视频网站提供视频广告管理系统与增值服务，现有客户包括ESPN,华纳, CBS, Discovery, CNBC, CNN.com, NBA.com,?ESPN.com,?MLB.com,?Veoh.com, Vevo.com等，月度广告业务服务量约20亿次，并仍在快速增长。FreeWheel目前在硅谷、纽约和北京设有机构，其中北京研发中心担负全部的产物研发工作，包括核心广告系统、Web应用以及视频设备整合等。?
- 48. 贵谤别别奥丑别别濒北京工程师团队
- 49. 谢谢大家！蚕&补尘辫;础