大数据10年，从“尝鲜”到“普惠”

大数据技术已经存在了20年的历程，并且阿里的飞天平台也有了10年的历程。上图是Gartner非常有名的评测机构，在Emerging Technologies中展示了Hype Cycle。Emerging Technologies是指其中所有的技术都视为新兴技术。横轴分为五个部分，从Trigger开始，到达最热潮，然后到了冷静期，再继续向前发展。不同的颜色表示在所指的几年之后相应的技术会变得成熟。在2014年，Big Data已经到达了尖峰期的末端状态。在2015年，Big Data就不在上图中了，关于Big Data应该放在哪里的问题，许多人都参与了讨论，最终Gartner 的分析员 Betsy Burton给出了总结性的一句话：“Big Data..has become prevalent in my lives”，其中的含义是指大数据已经不是一个特定的技术，它是一个普惠的技术领域。阿里巴巴认为大概在2014年大数据会从尝鲜期到普惠期，并且带来了非常多的价值变化。 大数据领域Value Proposition的迁移

上图所示为尝鲜期到普惠期的对比。尝鲜期更注重的是快速上手。其次是灵活性，无论是平台、配套的东西还是工具链都不是特别成熟，怎样更快的做一些调节和修改可以满足需求是很重要的。另外还需要能达到一些目标，不需要特别全面，甚至不需要很稳定，只要能进行试对和试错就可以。普惠期的特点与尝鲜期的特点几乎是不相同的，甚至是对立的。从普惠期开始，成本和性能变得很关键，其中特别关键的是“成本”，因为通过调研得出用户对“成本”是很关注的，用户的关注不仅仅是对大数据处理上所付得的钱数，更多的关注是数据在海量的增长的情况下，怎样保证成本在可控的范围之内。当进入到普惠期，进行大规模应用时，企业级服务能力就变的很关键。例如，阿里的大数据平台每天都会产生支付宝的商户对账单，商户和商户之间、商户和上下游之间、及商户和银行之间结算的系统要求都万无一失。当从尝鲜期进入到普惠期之后，应该有一个相对丰富且完整的工具链和生态体系，这就需要生态体系和工具链能融合在一起，才能实现整个性能。 从阿里巴巴的角度看 – 飞天平台发展历程

MaxComputer是飞天底座平台的系统，同时支撑了飞天绝大多数的数据存储和计算力的需求。从阿里的角度来看，在2002年，Oracle是做数仓型的数据建设，包括算账和inside。在2006年，是亚洲最大的Oracle Rack。在2008年和2009年，分别启动了Hadoop和飞天的体系，后面是大家熟知的登月系统。在2015年，登月系统完成，所有的数据汇集到一起，同时建立了数据的底座作为统一的存储系统、一套中间的统一运算系统以及数据中台，整个系统以中台体系为核心，成为阿里巴巴内部的大数据一体化。在2016年，启动了MaxComputer 2.0项目，几乎替换了从2010年到2015年的整体，同时开始给国内云计算的客户提供服务。在2019年，可以转型到MaxComputer 3.0，除了关注性能和成本之外，随着数据量超大规模的增长，以及数据领域的优化几乎已经超出了人类的范畴，中台的工程师很难靠人的方式完成中台的建模和优化的工作。阿里认为向智能化的方向发展，通过智能化来优化大数据是至关重要的。

核心技术发展方向可以从四个角度分析:

上图展现的是来自阿里云的上百家客户调研数据结果，其中黄色的曲线表示公司和部门业务的增长，蓝色表示大数据开始应用的过程，在第一年期间是属于平稳发展方向，到了普惠期，大家发现大数据的技术和价值之后，大数据就开始向上攀升，刚开始攀升的过程不是平缓的，是一个快速增长的过程。 随之而来有一个问题，数据量和计算量的增长以及对成本的付出超过了已有的增长速度，到后续阶段有可能会继续上涨，如果有相关的系统做匹配，以及很好的优化和治理，那么数据将会降下来，最终达到应用与发展几乎匹配的速度，同时保证成本是可持续的。比如业务增长了5倍时，成本只增长了1倍。如果不能将数据降下来，则会出现的情况是，数据中心变成了成本中心，同时有非常多的数据和计算，但是哪些是有价值的是不清楚的。为了解决这个问题，需要提供更好的高性能和低成本的服务能力，将平台层的成本降下来，同时可以通过数据治理服务来为数据做治理。此外，可以通过智能化方法来优化大数据以达到相应的目的。 构建“高效率与低成本”的计算平台阿里针对构建“高效率与低成本”的计算平台所面对的挑战分为四个部分： 1、当规模过万台之后就会面临成本的持续增长。 2、数据或计算爆炸，硬件投入大于业务增速。 3、中大型公司的技术发展进入开源软件盲区。 4、无法形成大集群，多小集群拼凑，导致整体利用率低。 相应的，阿里巴巴计算平台对以上挑战做了以下四项优化：

1、引擎优化：核心引擎全自研技术，具备把控力，持续优化。 2、存储优化：保证数据不重复，存储智能分级（1.6），压缩分级。 3、资源优化：云原生统一资源池（以及对应的削峰填谷）+在离线混布。特别注意的一点是，资源层面的优化要优于作业本身的优化，作业的极值性能追求和极值速度已经不是阿里最大的追求，而最大的追求是在整体的情况下将资源利用率提升。 4、数据与计算管理与治理。

上图是以阿里从2015年到2018年双十一的例子，左边的图为单日作业量，中间的图为单日处理数据量，右边的图为成本的曲线。事实证明，阿里通过飞天平台以及技术能力，几乎做到了使业务增长的速度和成本增长的速度相适应。 在此基础上又做了以下部分优化工作： 1、引擎侧：• NativeEngine+LLVM CodeGen，Vectorization+SIMD • CBO+HBO，Dynamic DAG • 针对Input/Shuffling海量数据，新引入“富结构化数据” • 数据可以按Range/Hash方式存储，支持一级Index和Order 2、存储侧：兼容开源Apache ORC，全新的C++ Writer和改进的 C++ Reader，读取性能对比CFile2和开源ORC均快50%+。 3、资源侧：一套跨集群数据、计算调度能力，将多个集群的服务器做成一台计算机。 4、调度系统优化：平均集群利用率70%，除了优化单作业指标，更偏重整个集群的吞吐率。 5、通过混布技术，提升在线服务器利用率到50%以上。同时支持双十一场景的业务弹性。 部分数据和案例： • 2015年，SortBenchmark，MaxCompute 100TB GreySort冠军。 • 2016年，SortBenchmark, EMR 100TB CloudSort冠军。 • 2017年，MaxCompute+PAI，全球首家100TB规模TPCx-Bigbench测试通过。 • 2018年，MaxCompute+PAI，指BigBench标继续提升1X+，继续保持全球最高分数。 • 2018年，Flink内部版是社区性能数倍，2019年开源。 • 2019年，EMR TPC-DS 10TB全球最快 • 2019年，MaxCompute+PAI，指标继续提升，保持全球第一，30TB性能快一倍，成本低一半。

上图是在BigBench上从2017年到2019年的统计图，可以明显的看出，几乎每年增长一倍。

从上图可以看出，与业界的其它系统做对比，性能几乎高出一倍，成本几乎低一半。 构建“多功能的企业级”计算平台构建“多功能的企业级”计算平台是属于系统后台的工作，大概分为四个部分： 1、需要可靠的数据交汇点（数据底盘），因为很多公司的数据就是公司的资产，数据的安全性问题就显得至关重要。具体包括以下内容： • EB级规模，扩展能力（单集群，多级群，全球部署三级扩展） • 数据可靠性（已经走过了能用，可用的阶段，需要提供万无一失的保障 能力，例如DC级别的容灾能力） • 安全性（从存储，运算，管理，运维，把数据安全做到每一层） 2、针对容灾部分，是需要企业自主解决的工作，通过选择容灾，使得达到某种能力，具体需要包括以下内容： • 基于高性价比硬件 • 自助运维与自动化运维 • 完善的故障容错（软件，硬件，网络，人为） 3、由于隐私泄露的情况是经常会发生的，但是阿里却不会发生隐私泄露的情况，主要是因为对数据管理、共享与安全性的要求。具体包括以下内容： • 容灾备份 • 细粒度授权，安全卫士，审计，存储加密 • 数据管理能力，数据血缘和追踪，基于数据血缘的分析和报表 • 多数据/多作业管理和调度 • 基于基线保障的调度能力 4、调度能力与扩展性作为系统内部的优化，具体包括以下内容： • 超大规模，统一的资源池 • 超卖 • 基线保障 • 伸缩能力与混布能力 构建“生态融合的”计算平台

上图是飞天MaxCompute平台融合的案例。其中一层为统一的存储层，不仅仅可以开放MaxCompute的引擎，也可以开放其他的引擎。中间的抽象层为联合计算平台，联合是指将数据、资源和接口抽象成一套标准的接口，包括Spark和其他引擎都可以应用，形成一套完整的生态系统。第二条线的生态是MaxCompute源向外的生态，数据源是多种多种的，不仅仅存在阿里自已的存储里，也可以存在于数据库的系统和文件系统等。此外，可以让用户在不搬迁数据的情况下和其他系统做联动，称为联邦计算的概念。 另外，Blink是当年在Flink社区的一个单独的分支，针对阿里内部的最佳开发实践的系统，在1.9的版本上已经成为完全默认的社区，在SQL引擎、调度系统以及Algo on Flink上做出了很多贡献。随着和Flink的某公司存在收购关系之后，将会推动Flink公司一直向前发展。

最后，是存储层面的发展。上图是有关压缩、读和写以及数据相关格式的改造，所有的改造都会推进给社区，橙色的字体是按照设计标准改的。

计算引擎的优化除了自身的优化以外，还涉及到自动驾驶。上图是使用车的例子，展现了飞天进化的过程。第一个过程为可用阶段，比如双十一当天是否能支撑如此大量的负载以保证系统是可用的。第二个过程是在性能和成本上达到极致的追求。第三个过程是让性能变得更好。 智能云数仓（Auto Cloud Data Warehouse）在阿里内部已经出现了三条关键的挑战： 1、EB级数据和百万级别作业，很难管理。数据中台团队不再胜任（传统的DBA模式不能支撑） 2、多种数据融在一起，人无法在海量规模上理解数据的所有价值 3、大数据系统经过多年发展，如果需要实现“跃迁”式的进步，需要体系结构层面的改造

从智能云数仓的角度来看，可以从三个方面上做优化。第一方面是效率优化，包括HBO是基于历史信息的优化，可以理解是一个全新的作业作用到系统中，当系统对它并不了解时，对资源的分配相应的会采用保守的方式，使作业运行完成。在第一次运行作业时，系统的调优可能是保守的，慢慢的会越来越贴近自身的运行状态，到四天之后，所认为的作业就非常好了。通过HBO优化，阿里巴巴的资源利用率达到了70%。此外，还包括Learned Statistics、智能计算重用和智能的数据分层。 第二方面是资源规划，当云上有十万台的机器分布在不同的数据中心时，怎样规划数据和资源调动是不属于人工的过程，应属于自动化的过程，包括作业运行模式的自动分类，其中有三种不同的运行模式是针对非常大的作业和交互性非常高的作业。此外，还包括动态Quota调整、缩扩容、作业运行预测与自动预报警、作业自动升降级和数据排布与跨集群调度。 第三方面是智能建模，包括相似作业与数据的识别、自动纠错、作业运行预测与自动预报警以及作业自动升降级。 以上这三个方面是在智能数仓领域可以持续发展的方面，上图中带*的是阿里已经或者马上要公布的功能。 Auto CDW – 智能索引推荐

通过作业之间运行的关系，做cost module的同化，通过这种方式是找到一种index最优的调节并且进行push。例如，基于MaxCompute，在阿里集团内挑选了8W张表的30W个字段 ，从中为4.4W张表推荐出最优的Clustering方案，平均Cost节省43%。 Auto Tired Store - 冷热数据识别和管理

在今年9月1号时，阿里的存储整体降价了30%，其中一部分计算就来自上图中的Auto Tired Store技术，包括冷热数据的自动分离，之前的数据是通过两个方式进行分离，第一个方式是系统自动做冷压缩，降低的成本大概有三分之二。第二个方式是允许用户通过做flag的方式。但是，当系统里有千万级别的表时，数据开发工程师时很难甄别出数据的使用方式的，这时可以使用经济学的模型，构建Access和Storage之间的关系，针对每个不同作业的不同分区，自动地定制冷热的程度。通过这种方式，把阿里的压缩率从3倍率压缩到1.6倍率，整体的存储效率提升了20%。 Yugong – 智能全局数据排布与调度

因为云系统是多个数据中心部署在全球各个地方的，数据的产生是与业务相关的，但数据之间的关联是不许被打破的，把什么样的数据放在什么样的机房里，什么样的作业调度到最优的效果，是属于全局最优匹配的问题。在阿里的内部实际上是将作业的静态排布以及动态的调度融合了一个系统称为Yugong。上图中右边是两个原理图。 DPSAaS– 基于差分隐私的数据共享与分析服务

针对敏感数据的计算能力称为密态计算，针对隐私的数据希望做到可算不可见。上图表中前三列为敏感数据，后三列为不敏感数据。通过查分隐私的编码方式，将所有的敏感数据都隐蔽掉了，当要care敏感数据时是care不到的，但做计算时所有数据的计算结果都是正确的，阿里正在通过这种方式探索如何在数据共享与隐私之间找到平衡。 其他面向未来的探索

针对其他面向未来的探索方面，阿里主要涉及的方面包括怎么在基于图的关系上做运算、怎样找到系统之间最优的平衡、基于隐私的计算、如何在多种目标的情况下做更好的调度、在采样层面如何大幅度的降低数据的情况下仍然做的更好。

原文链接

本文为云栖社区原创内容，未经允许不得转载。