爱奇艺大数据平台的构建之路.pptx

1、爱奇艺大数据平台的构建之路目录 爱奇艺大数据平台的挑战 平台的构建之路1.0 专业化2.0规模化3.0生态化 案例 总结20112010爱奇艺大事记6月23日“奇艺出品”战略11月26日品牌战略升级为“爱奇艺”4月22日视频网站“奇艺”正式上线201211月2日2016爱奇艺成为百度的全资子公司20135月7日爱奇艺与PPS合并提供更优质服务2月7日独家直播2016猴年春晚除夕当晚总播放量突破4500万4月15日2015太阳的后裔26亿播放量收官微博话题阅读量达122亿微指数峰值达到83万20142月18日羊年春晚独家在线直播7月6日5月6日2016爱奇艺世界大会圆满收官中国首个开放娱乐生态首

2、次展现全貌构建“爱奇艺世界观”6月1日盗墓笔记全集上线60小时总播放量破10亿10月14日爱奇艺VI P 会员品牌全面升级12月1日爱奇艺VIP会员突破1000万7月17日爱奇艺宣布成立影业公提出“爱7.1电影大计划”爱奇艺有效VIP会员数已突破2000万爱奇艺移动端 核心指标行业领先移动端数据l 爱奇艺移动端以3.3亿人的月度覆盖位列行业第一，总体占比高达55%，行业领先优势持续加大l 爱奇艺移动端月度总使用次数（活跃度）达212亿次，成为视频用户首选(数据来源：艾瑞MUT，2 016 年8 月)日均覆盖人数 NO.1月度覆盖人数 NO.1月度浏览时间NO.1月度覆盖人数（万人）32,592

3、.8月度浏览时间（万分钟）21,148,529.5日均覆盖人数（万人）13,735.6爱奇艺腾讯视频优酷爱奇艺腾讯视频优酷爱奇艺优酷8,770.36,163.92,631.71,851.21,065.921,555.418,923.412,981.77,742.34,415.618,160,244.58,585,908.53,984,815.3腾讯视频乐视视频风行视频搜狐视频土豆网乐视视频芒果TV芒果TV2,491,726.02,159,663.51,370,436.21,218,759.2834,657.4乐视视频搜狐视频风行视频PPTV网络电视土豆网风行视频搜狐视频土豆网960.0593.

4、23,518.82,440.22,185.4芒果TV543.4111.5PPTV网络电视凤凰视频PPTV网络电视响巢看看响巢看看568.1161,279.1（数据来源：艾瑞MUT，2016年8月）（数据来源：艾瑞MUT，2016年8月）（数据来源：艾瑞MUT，2016年8月）挑战30X2PB+/day 10PB/人数据量日均处理量人均运维量爱奇艺大数据应用TA精算大剧探针爱奇艺指数大数据后羿（会员精准营销系统）电影探针VIP服务广告投放品牌分析众里寻TA剧场受众分析一搜百映追星族、接力赛、群英荟1.0专业化 时间：2010 2013 规模MapReduce 集群：50 330台 存储：16PB

5、HiveHBase 计算：HDFS 日均作业：3万 日均tasks数：220万 日处理数据：150TB 开源服务 HDFS、MapReduce、Hive、HBase1.0专业化痛点方案 业务自己维护集群 运维不规范 集中到云平台管理 脚本化、流程 Ganglia+Nagios 半监控状态 Name/Space Quota(1.3亿小文件，2PB冷数据）小文件多/存储压力大 Jobtracker性能瓶颈 改源码，JT任务调度加快12倍JobTracker调度性能差 Hadoop1.x+FairScheduler 同时运行的任务多 调度时间60ms 心跳延迟大 解决方案：修改FairSchedul

6、er源代码，一次排序分配多个任务 修改后调度时间5ms2.0规模化 时间：2014 2015工作平台 规模MapReduceSparkStreamingSparkStorm 集群：1000+台 存储：30PB 计算：YARN/M esosHiveHBase 日均作业：8万 日均tasks数：1800万 日处理数据：900TBHDFS 开源服务 HDFS、MapReduce、Hive、HBase Spark、Storm2.0规模化痛点方案 运维脚本较散乱 存储成本骤增 离线服务延迟大 资源利用率不够高 权限控制不够 故障处理慢 Hadoop工作平台 Parquet+gz组合（省20%）推广Spa

7、rk、Storm 升级到Yarn（提高21%）Kerberos、HDFSACL 源码解决（贡献了45+Patch）Hadoop工作平台 后台管理（CMDB）集群、服务器、配置、用户等 运维管理 运维操作Web化，配置与脚本分离运维管理数据管理公共库管理 脚本Ansible为主，Python为辅后台管理（CMDB）数据管理 数据注册与发现 MetadataAPI 公共库管理 HiveUDFYARN升级对比项Hadoop 1.0Hadoop 2.0(YARN)计算框架只支持MapReduceYARN成为一个通用的资源管理系统，支持MapReduce、Spark、Storm等目前比较流行的计算框架，

8、甚至还允许用户自定义计算框架调度JobTracker负责所有的任务调度，负担 双层调度：应用调度、应用内task s调度。较重 将应用内调度交给应用自己负责，减轻调度器负担资源隔离将资源简单地划分为slot，比如1slot=使用LXC进行隔离，用户可以自己申请需要多少资(1CPU,2GB Mem)；源，更加灵活、更充分利用；将slot资源人为地划分为map、reduce，2.6开始支持Docker不适用于动态变化的生产环境Availability单点HA作业运行时间475s201s（降低57.7%）资源利用率(min/avg/max)CPU:15.4%/40.7%/61.2%Memory:35

9、.7%/41.4%/45%CPU:20.4%/49%/73.9%（高峰时提高21%）Memory:24%/33%/40%（高峰时下降11%）Spark inIQIYI 部署方式 Standalone（虚机为主）SparkonYarn（占Yarn2030%资源）Spark onYarn 优点：资源共享、扩容方便 缺点：对于实时任务，会受大集群波动影响 优化 使用yarn-cluster模式 禁止YARN重启应用，用户通过平台（Europa）控制重试策略 开发了Spark访问HBase的Kerberos验证，并定期刷新Token 根据执行器的核数自动配置GC策略Spark 算法优化 Hadoop

10、Mahout-Spark Mllib LogisticRegression/DecisionTree/LDA/ALS 算法实现优化 LR/ALS/FP-growth：实现调优和BUG修复 AllPairSimilaritySearch(APSS)计算出每个item最相似的TOPK个item，并返回它们之间的相似度 实测性能大约对600万个item的集合计算两两相似度，并返回每个item的TOP16 2小时-20分钟社区贡献 爱奇艺向ApacheHadoop社区贡献45+Patches，如：HDFS-7798：解决Checkpoint失败问题 HDFS-8113：解决bloc kreport失败

11、问题 YARN-3024：提高localization效率 YARN-3266：解决NodeManager识别问题 HIVE-11149：解决PerfLogger引起的Hive任务卡住 HBASE-12590：降低了数据倾斜的HBase表对计算资源的浪费HBASE-125903.0生态化 时间：2015 2016 规模 集群：2000+台 存储：60PB 计算 日均作业：15万 日均tasks数：4000万 日处理数据：2PB+开源服务 HDFS/MapReduce/Hive/HBase Spark/Storm OLAP:Impala/Kylin 自研系统 QoS/Koala/Gear/Ven

12、us/Europa3.0生态化痛点方案 OLAP查询慢 Impala、Kylin 监控报警不够精准 运维成本高 HadoopQoS Koala自动化运维系统 Gear工作流管理系统 Venus日志收集计算平台 Europa大数据开发平台 Crontab不易管理 日志不易管理、排障难 易用性不足、门槛高Impala 产品优势 快速响应：通常为秒级到几分钟 Hadoop生态：方便集成、交互数据 SQL接口：使用简单 实际场景 报表系统：Hive查询几十分钟 广告：MySQL超过TB后很慢 测试结果 Impala比Hive快10倍；支持TB数据规模；Kylin 产品特点 优势：查询时间在秒级 原理：

13、空间换时间，预先计算每种维度组合的测量值 限制：查询维度不宜过多，维度和测量指标需预定义 实际场景 报表团队：行为表，每天产生3.5TB数据，Hive预处理存到MySQL，时间超过1天 测试结果 Kylin查询时间在1s以下 Kylin构建时间2.5小时（10倍）KylinCube大小9GB（0.76%）HadoopQoS Ganglia缺点 指标过多而且分散 不能排序和聚合 非功能导向自助服务报表 优化 排障 报警 主要功能HealthIndexes 报表 HDFS、HBase、YARN健康度 优化 HBase Region的热点分析 排障BasicOSMetricsHDFSMetrics

14、Metrics Metrics72+17+72+YARNHBase HBase的callQueue排查 报警OpenTSDB 当前Inode数/预估最大Inodes数85%Koala自动化运维系统 报警事件的自动处理 快速响应 无人值守 失败后通知 运维脚本的统一管理 Gerrit/Gitlab Web/RestAPI 审计 操作记录的存储、查询、统计Koala自动化运维系统 硬件故障自动报修是故障批准报警事件故障判断发送故障处理申请Zabbix服务下线报修拒绝不是故障处理结束Gear工作流管理系统 基本功能 作业管理、定时启动 依赖管理、重试机制 特色功能 基于YAML的配置文件 使用Git

15、Lab管理，自动提交 报警订阅 自定义报警接口 任务机负载均衡 业务应用 已上线80个项目，360个工作流，1500+个任务Venus实时数据收集计算平台 主要功能 公司统一的日志入口（Pingback+机器日志）一站式的收集、分析、报表Venus Web（报表&报警）展示方案 自助服务 全链路分析业务定制系统HadoopHDFSVen u sSQL ServerVenusSQLServerElasticSearch云存储（冷备）SparkStreaming 目前状况 核心业务全部接入 接入机器数3000+每日数据吞吐180TB+峰值330万条日志/秒Venus Data Syncer(onQ

16、AE)Kafka数据缓冲VenusagentVenusagentVenusagent 典型应用业务机器业务机器业务机器 线上排障（播放、会员）大数据分析（安全）Docker日志 重要日志备份Europa 大数据开发平台 目标：提高大数据分析的效率AppStore 开发层开发环境提交平台开发层控制层计算层 提交方式：网页、命令行、SDK、Maven插件EPipeSpark监控报警 AppStore：共享和构建 控制层ESQL Epipe：基于Gear工作流管理系统 监控报警：错误检测、报警订阅、资源审计EDataHDFMySQLMongoDBCouchbase 计算层数据层SKafkaAMQ 高

17、级用户使用Spark 入门级用户使用ESQLHBaseBatchSourceVenusStreamingSourceMySQLIO 数据层 Edata方便操作HDFS以外的数据源（官方库有BUG且接口不统一）Europa ESQL 痛点：Spark学习成本高、调试困难、维护难 方案：ESQL提供了配置文件+SQL的方式编写Spar k程序 案例：Venus标准化日志-匹配-存到HDFS 对比：数百行代码V.S.几行配置+SQLMySQLIO(InsideOut)MySQL数据变更订阅服务 基于binlog实时解析的MySQL数据变更增量订阅与同步工具，基于阿里开源的canal 实现优势主要功能

18、 实时解析binlog，数据变更信息写入MQ 实时共享数据变更，写入方无需做额外工作 支持读/写binlog数据的事务性，数据不丢失 支持数据过滤，包括基于操作类型、列名、列值的 对MySQL没有侵入性，不影响线上系统稳定性过滤 支持数据转换，包括库/表/列的映射、空值处理等 支持数据写入到ActiveMQ、Kafka、Hbase和ES支持HA，各组件均有热备节点支持Metrics监控和告警CanalServerMySQL IO架构风控ActiveMQExporterBinlog解析DB/Table过滤数据存储实时统计BINLOGDUMP订阅管理KafkaExporterMySQLsubscr

19、ibe()get()ack()rollback()异常检测ETLESExporter条件过滤简单转换输出HBaseExporterCanalClient消息通知Metrics爱奇艺大数据平台架构EuropaGearKoalaQoS工作平台MapReduceSparkStreamingSparkStormImpalaKylinYARN/M esosHiveHBaseVenusMySQLIOEDataHDFS日志MySQL 其它案例：风控系统 利用云服务高效构建：四个月，2.5个人力 数据：跨业务、异构的数据系统 计算：各种复杂的批处理和流处理业务系统安全大数据社工库QLBIPSolar RPC处

20、罚中心规则监控访问历史业务数据风控实时服务(QAE)EData日志RedisCouchbaseMongoDB缓存Europa大数据开发平台MySQLHBaseVenus持久化ElasticSearch大数据案例：风控系统 举例：支付表监听 特点 需要实时获取业务方数据变化 支付系统存在已久,不便于进行相关数据的实时投递开发 结合实时与存量数据，进行事前/中/后风险决策支付写数据Binlog dump输出到MQ用户支付系统MySQLMySQLIOActiveMQ消费数据实时计算中间结果SparkStreamingEData风控系统CacheDaily运算存量数据SparkSQL以支付表监听举例,风控需要实时获取用户的当天支付数据,提现数据等,用于风险决策总结 阶段感受 专业化：专人做专事、规范化 规模化：技术深入、突破规模瓶颈 生态化：平台、工具链、易用性 Romewasnotbuiltinaday 每个阶段需要根据人员和ROI调整优先级