优酷：Hadoop迁云案例

案例背景

在2016年5月到2019年现在的5月优酷的发展历程中，优酷的系统架构始终是上层为计算资源，下层是储存资源。优酷整个用户数和表的数据，实际上是在呈一个指数式增长的。但是在2017年5月，当优酷完成了整个Hadoop迁移MaxCompute后，优酷的计算消耗，还有储存的消耗实际上是呈下降趋势的，整个迁移得到了一个非常大的收益。

优酷的业务特点

• 大数据平台的用户复杂度。不止是数据的同学和技术的同学在使用大数据平台，还会包括一些BI同学、测试同学、甚至产品运营都可能去使用这个大数据的平台。
• 业务复杂。优酷是一个视频网站，它有非常复杂的业务场景，从日志分类上，除了像页面浏览，还会有一些播放相关的数据、性能相关的数据。从整个的业务模式上，有直播、有会员、有广告、有大屏等场景。
• 优酷的数据量非常巨大，一天的日志量会达到千亿级别，这是一个非常庞大的数据量，而且会做非常复杂的计算。
• 预算严格，对计算资源的弹性要求很高。不管是小公司、大公司，对成本的意识是非常高的。优酷也是有非常严格的预算，包括在阿里集团内是有非常严格的预算系统的，但是我们也经常会去做一些重要战役，像双十一战役、暑期的世界杯战役、春节战役等。

为什么选择MaxCompute

基于优酷业务的特殊性，MaxCompute通过强大的功能、性能和生态完美支撑了我们的业务。

• 简单易用
  MaxCompute有一个非常完整的链路，不管是从数据开发，还是数据运维，包括数据集成，数据质量的管控，还有整个数据地图，数据安全。当年优酷从Hadoop迁到MaxCompute之后，最大的体会是不需要始终24小时维护集群、不用跑任务了。写一个任务、处理一个需求可能需要排期几周，迁移之后可以直接跑任务出结果。在次之前分析师BI需要登录客户端写脚本、自己写调度，需要半天甚至更长时间才能得到结果。而现在基本上所有重要的数据都会在7点钟产出，包括一些基本的业务需求，其实分析师或者产品，他们自己都可以实现。
• 完整的生态
  优酷在2017年之前是完全基于Hadoop的生态，迁到MaxCompute之后，是基于阿里云提供的Serverless大数据服务的生态。MaxCompute拥有许多开源组件，甚至比开源的更好用、更简单。从架构图上可以看到，我们中间是MaxCompute，左侧依赖的MySQL、Hbase、ES、Redis这些都是由同步中心去做一个双向的同步。右侧会有资源管理、资源监控、数据监控，包括数据资产，还有一些数据规范。下层的数据输入包括集团的采集工具，再往上，有提供给开发人员用的DataWorks，包括一些命令行的工具、有提供给BI人员用的Quick BI及数据服务等。
• 强悍的性能
  MaxCompute支撑了优酷EB级的数据存储，千亿级的数据样本分析，包括千亿级的数据报表，10W级实例的并发、任务。这些在之前维护Hadoop的时候，是完全做不到的。
• 资源使用的弹性
  我们在2016年迁移之前，其实优酷的Hadoop集群规模已经达到了一千多台，当时属于比较大的规模。迁移之前我们遇到了很多问题，包括NameNode 内存的问题、机房无法扩容的问题、运维管理问题等。我们不断的去问运维要资源，但是资源成本已经到达了非常高的水平。我们面临的问题是计算资源如何按需使用，夜里的时候作业很多，到了下午之后，整个集群都空下来了，没有人用，造成了浪费。其实MaxCompute完美的解决了这个问题。

  • MaxCompue按用量计费，不是按照机器量收费，而是根据资源使用量计费。在成本上来说，比自己去维护集群节约了大约一半的成本。
  • 实际上MaxCompue计算资源是可以分时的，比如说生产队列，凌晨的时候会调高一些，保证报表能够尽快出来。到白天时候，让开发的计算资源高一些，可以让分析师、开发去临时跑一些数据，会更顺畅一些。
  • MaxCompute快速的扩容能力非常优秀。例如突然有一个比较强的业务需求，发现数据跑不动了，计算资源不够，所有的队列都堵死了，此时可以请运维同学一键扩容，所有的资源可以迅速的消化下去。

  

优酷的典型大数据方案

MaxCompute在中间核心的位置，左侧主要是一个输入，右侧是一个输出的趋向，绿色的线是一个实时的链路，包括现在我们从整个的数据源上，比如DB也好或者服务器的本地日志Log也好，我们通过TT&DataHub存储到MaxCompute上面做分析。当然现在非常火的Flink实时计算，其实是作为一个实时处理的链路。包括DB的同步，除了实时的链路，DB也会去通过按天/按小时，把数据同步到MaxCompute，数据计算结果也可以同步到Hbase、Mysql这种DB上面。再通过统一的服务层对应用提供服务。下面这个是机器学习Pai做的一些算法训练，再把训练的结果通过OSS传到一个算法的应用上面去。

这张图可能也是业界比较流行的一个数仓分层的图，因为我们这边是数据中台，所有的数据都是统一从ods层cdm层，然后ads层，去一层一层的往上去做精细，再到最上面，通过接口服务、文件服务、SQL服务，去提供多样化的服务。再往上面，提供对内的一些数据产品，对高管、对小二，可能还有一些对外的，比如说像优酷的播放数，包括热度这些对应用的数据。

这张图其实就是我们从Hadoop迁到MaxCompute平台上以来，两个非常经典的案例。我们通过数据中台对不同场景的用户打通，来去赋能到两个不同的场景，提升业务价值。第二个是内部的，我们通过优酷、还有集团内部的一些BU去做换量，我们通过统一的标签去做样本放大，把优酷的量导给其它的BU，把其它BU的量导给优酷，这样去达到一个共赢的效果。

这张图大部分互联网公司不太会涉及到，就是关于反作弊的问题。这个是我们在MaxCompute做的一个反作弊的架构，通过原始的数据去提取它的特征，然后再通过算法模型，包括机器学习、深度学习、图模型去支持流量反作弊、渠道反作弊等等。再通过业务场景上反作弊的监控工具，把监控到的作弊信息去打一个黑白样本，再把这个黑白样本跟特征一起来不断的迭代优化算法模型。同时针对算法模型，做一个模型的评价，不断来完善反作弊体系。

最后一点，其实还是跟成本相关，在日常使用中，一定是有小白用户或者一些新来的用户去错误的使用或者不在乎的使用一些资源，比如经常会有一些实习生或者是非技术的同学，如分析师，一个SQL消费比较高，这个其实是非常浪费资源，而且可能他一个任务，让其他所有人的任务都在这儿等着排队，实际上我们会去整体资源进行治理。

从节点的粒度上，通过大数据来治理大数据，我们可以算出哪些表产出来之后，多少天没有被读取的，包括它的访问跨度可能没有那么大，我们会去做下线或者去做治理，有一些业务场景可能并不是非常的重要或者它的时间要求没有那么高，比如一些算法训练，可以去做一些错峰的调度，保证水位不要太高。从MaxCompute任务的角度，可以算出哪些任务有数据倾斜、哪些数据可能会有相似计算，哪些任务需要去做MapJoin，哪些任务需要去做一些裁剪，然后来节省它的IO。还有哪些任务会去做暴力扫描，扫一个月、扫一年的数据，哪些数据可能会有这样一个数据膨胀，比如说它做了CUBE之类的这种复杂计算，一些算法模型的迭代；我们通过数据计算出来的这些迹象，去反推用户，来去提高它的这样一个数据的质量分，来去达到我们降低整个计算资源的目的。

在计算平台的角度，我们也持续的在使用MaxCompute推出的一些非常高级的用法，比如我们的HBO、Hash Cluster、Aliorc。

• HBO就是我们基于一个历史的优化，这样避免了用户不知道怎么调参，可能为了自己任务速度，就调一个特别大的参数，这样的话，对集成的资源是非常浪费的。通过这个功能，用户就不用去调参数，集群自动调好，用户就写好自己业务逻辑即可。
• Hash Cluster当时在使用Hadoop的时候经常会出现大表Join的时候无法计算的问题，Hash Cluster其实是一个优化的利器。大表跟小表Join，可以做一些分发，做一些优化。大表跟大表就涉及到一个排序的问题。这个Hash Cluster，实际上就是提前把数据排好，中间省掉很多计算环节，来达到效率提升的目的。
• Aliorc，在一些固定的场景上面，可以稳定的提升20%的计算效率。
• Session。对一些比较小的数据，直接就放到SSD或缓存里面，一个节点下游有100个叶子场景，是非常友好的，因为低延迟秒出结果。同时，优酷也在使用Lightning解决计算加速，这个是在一个计算架构方案上的优化，是一个MPP的架构。

存储优化

一些关键的原始数据或者是需要审计的数据是不能删除的，永久不能删除的。实际上会造成数据存储的趋势是一直往上不减的，计算会在某一个时间点达到一个平衡。当前用这么多的计算资源，再往后，其实应该也不会再大涨了，比如说旧的业务逻辑下掉了，会换新的业务逻辑，这样会保持在一个相对平稳的波动上面。但是储存，因为它有一些历史的数据是永远不能删的，可能会出现一直在增长，而且是指数级的。所以我们也会持续关注存储的情况，还是通过大数据来治大数据，去看哪些表的访问跨度比较小，来去做生命周期的优化，来去控制它的增速。还有刚才提到的Aliorc，实际上也是做压缩的。我们会去做一些大字段的拆分，来提高压缩的比例。