做网站找客源,WordPress主题怎么保存,网页制作h5,wordpress美食模板阿里妹导读#xff1a;优酷一天的日志量会达到千亿级别#xff0c;面对如此大的数据样本#xff0c;2017年5月#xff0c;优酷完成了从Hadoop迁移到阿里云MaxCompute#xff0c;实现计算消耗和储存的消耗呈下降趋势#xff0c;得到了非常大的收益。今天#xff0c;阿里数…
阿里妹导读优酷一天的日志量会达到千亿级别面对如此大的数据样本2017年5月优酷完成了从Hadoop迁移到阿里云MaxCompute实现计算消耗和储存的消耗呈下降趋势得到了非常大的收益。今天阿里数据技术专家门德亮给大家做个分享从为什么要用MaxCompute到优酷的业务场景下典型的方案及应用分析聊聊迁移后对业务及平台的具体价值。本文内容根据演讲视频以及PPT整理而成希望对你有所助益。
大家好我是门德亮很荣幸我正好见证了优酷从没有MaxCompute到有的这样一个历程我们正好是在快到5年的时候做了从Hadoop到MaxCompute的这样一个升级。
2016年5月到2019年5月优酷的发展历程。整个用户数还有表的数据实际上是呈指数式增长的。但是在2017年5月当优酷完成了整个Hadoop迁移MaxCompute后优酷的计算消耗还有储存的消耗实际上是呈下降趋势的整个迁移得到了非常大的收益。 下面说一下优酷的业务特点。
第一个特点是大数据平台整个的用户复杂度不止是数据的同学和技术的同学在使用还会包括一些BI同学测试同学甚至产品运营都可能去使用这个大数据的平台。
第二个特点就是业务复杂优酷是一个视频网站它有非常复杂的业务场景从日志分类上除了像页面浏览还会有一些播放相关的数据、性能相关的数据。从整个的业务模式上有直播、有会员、有广告、有大屏等这样一些非常不一样的场景。
第三个特点就是数据量非常巨大一天的日志量会达到千亿级别这是一个非常庞大的数据量而且会做非常复杂的计算。
第四个比较有意思不管是小公司、大公司对成本的意识是非常高的。优酷也是有非常严格的预算包括在阿里集团内是有非常严格的预算系统的但是我们也经常会去做一些重要的战役像双十一战役像我们暑期的世界杯战役还有春节也会搞各种战役。这其实对计算资源的弹性要求是非常高的。
基于上面的优酷的业务特点我整理了MaxCompute可以完美的支持我们业务的几个特点。 简单易用。完善的生态。性能非常强悍。资源使用非常弹性。
第一个特点简单易用。MaxCompute有一个非常完整的链路不管是从数据开发还是数据运维包括数据集成数据质量的管控还有整个数据地图数据安全。当年优酷从Hadoop迁到MaxCompute之后我们最大的体会是不用经常自己半夜起来去维护集群了不用去跑任务了之前别人提一个需求过来我可能要排几周现在我可以告诉他我给你马上跑一下就可以出来了。包括之前像分析师BI还要登录客户端写脚本自己写调度经常会说我的数据今天为什么没出来包括高层看的数据可能要到12点钟才能出来。而现在基本上所有重要的数据都会在7点钟产出包括一些基本的业务需求其实分析师或者产品他们自己都可以实现了不需要所有需求都提到数据这边。 第二个特点完整的生态。优酷在2017年之前是完全基于Hadoop的生态迁到MaxCompute之后是基于阿里云提供的Serverless大数据服务的生态。大家可以在开源上看到的组件在整个的MaxCompute上都是有的而且比开源的要更好用、更简单。从架构图上可以看到我们中间是MaxCompute左侧依赖的Mysql、Hbase、ES、Redis这些都是由同步中心去做一个双向的同步。右侧会有资源管理、资源监控、数据监控包括数据资产还有一些数据规范。我们下层的数据输入包括一些集团的采集工具再往上边有提供给开发人员用的DataWorks包括一些命令行的工具有提供给BI人员用的QuickBI及数据服务。 第三个特点强悍的性能MaxCompute支撑了优酷EB级的数据存储千亿级的数据样本分析包括千亿级的数据报表10W级实例的并发、任务。这些在之前维护Hadoop的时候是想都不敢想的。 第四个特点资源使用的弹性。我们在2016年迁移之前其实优酷的Hadoop集群规模已经达到了一千多台这个当时还是一个比较大的规模。当时我们遇到了很多问题包括像NameNode 这种内存的问题机房没有办法再扩容的问题当时是非常痛苦的包括一些运维管理上面的问题。我们不断地去问运维要资源运维说你们已经花了资源多少钱。我们面临的问题是计算资源如何按需使用夜里的作业很多到了午后整个集群都空下来了没有人用造成了浪费。其实MaxCompute完美地解决了这个问题。 第一个它是按用量计费的不是说给你多少台机器就收你多少钱是你用了多少资源收多少钱的在成本上来说比自己去维护集群可能是一个砍半降50%的收益。
第二个实际上MaxCompue计算资源是可以分时的比如说生产队列凌晨的时候会调高一些保证报表能够尽快出来。到白天时候让开发的计算资源高一些可以让分析师、开发去临时跑一些数据会更顺畅一些。
第三个MaxCompute快速的扩容能力比如说突然有一个比较强的业务需求发现数据跑不动了计算资源不够所有的队列都堵死了这个时候其实可以直接跟运维说一声帮忙一键扩容两秒钟敲一个命令就搞定了。这样所有的资源可以迅速地消化下去。 这张图实际上是优酷包括可能现在阿里集团内部一些非常典型的技术架构图。中间可以看到MaxCompute在中间核心的位置左侧主要是一个输入右侧是一个输出的趋向绿色的线是一个实时的链路包括现在我们从整个的数据源上比如DB也好或者服务器的本地日志Log也好我们通过TTDatahub存储到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实际上也是做压缩的。我们会去做一些大字段的拆分来提高压缩的比例。
共建大数据生态企业级大数据平台开发者版已正式发布点击文末“阿里技术”阅读原文立即申请。
原文链接 本文为云栖社区原创内容未经允许不得转载。
