简介：本文作者关涛是大数据系统畛域的资深专家，在微软（互联网 /Azure 云事业群）和阿里巴巴（阿里云）经验了大数据倒退 20 年过程中的后 15 年。本文试从零碎架构的角度，就大数据架构热点，每条技术线的倒退脉络，以及技术趋势和未解问题等方面做一概述。
作者 | 阿里云计算平台研究员关涛、阿里巴巴项目管理专家王璀
任何一种技术都会经验从下里巴人到下里巴人的过程，就像咱们对计算机的了解从“戴着鞋套能力进的机房”变成了随处可见的智能手机。在后面 20 年中，大数据技术也经验了这样的过程，从已经居高临下的“火箭科技（rocket science）”，成为了人人普惠的技术。
回首来看，大数据倒退初期涌现了十分多开源和自研零碎，并在同一个畛域开展了相当长的一段“红海”竞争期，例如 Yarn VS Mesos、Hive VS Spark、Flink VS SparkStreaming VS Apex、Impala VS Presto VS Clickhouse 等等。经验强烈竞争和淘汰后，胜出的产品逐步规模化，并开始占领市场和开发者。
事实上，近几年，大数据畛域曾经没有再诞生新的明星开源引擎（Clickhouse@2016 年开源，PyTorch@2018 年开源），以 Apache Mesos 等我的项目进行保护为代表，大数据畛域进入“后红海”时代：技术开始逐渐收敛，进入技术普惠和业务大规模利用的阶段。
本文作者关涛是大数据系统畛域的资深专家，在微软（互联网 /Azure 云事业群）和阿里巴巴（阿里云）经验了大数据倒退 20 年过程中的后 15 年。本文试从零碎架构的角度，就大数据架构热点，每条技术线的倒退脉络，以及技术趋势和未解问题等方面做一概述。
值得一提的是，大数据畛域依然处于发展期，局部技术收敛，但新方向和新畛域层出不穷。本文内容和个人经历相干，是集体的视角，不免有缺失或者偏颇，同时限于篇幅，也很难全面。仅作抛砖引玉，心愿和同业独特探讨。
一、当下的大数据体系热点
BigData 概念在上世纪 90 年代被提出，随 Google 的 3 篇经典论文（GFS，BigTable，MapReduce）奠基，曾经倒退了将近 20 年。这 20 年中，诞生了包含 Google 大数据体系，微软 Cosmos 体系，阿里云的飞天零碎，开源 Hadoop 体系等优良的零碎。这些零碎一步步推动业界进入“数字化“和之后的“AI 化”的时代。
海量的数据以及其蕴含的价值，吸引了大量投入，极大的推动大数据畛域技术。云（Cloud）的衰亡又使得大数据技术对于中小企业唾手可得。能够说，大数据技术倒退正过后。
从体系架构的角度看，“Shared-Everything”架构演进、湖仓技术的一体化交融、云原生带来的根底设计降级、以及更好的 AI 反对，是当下平台技术的四个热点。
1.1 零碎架构角度，平台整体向 Shared-Everything 架构演进
泛数据畛域的零碎架构，从传统数据库的 Scale-up 向大数据的 Scale-out 倒退。从分布式系统的角度，整体架构能够依照 Shared-Nothing（也称 MPP）, Shared-Data, Shared-Everything 三种架构。
大数据平台的数仓体系最后由数据库倒退而来，Shared-Nothing（也称 MPP）架构在很长一段时间成为支流。随云原生能力加强，Snowflake 为代表的 Shared-Data 逐步倒退起来。而基于 DFS 和 MapReduce 原理的大数据体系，设计之初就是 Shared-Everything 架构。
Shared-Everything 架构代表是 GoogleBigQuery 和阿里云 MaxCompute。从架构角度，Shared-Everything 架构具备更好的灵活性和后劲，会是将来倒退的方向。
（图：三种大数据体系架构）
1.2 数据管理角度，数据湖与数据仓库交融，造成湖仓一体
数据仓库的高性能与治理能力，与数据湖的灵活性，仓和湖的两套体系在互相借鉴与交融。在 2020 年各个厂商别离提出湖仓一体架构，成为当下架构演进最热的趋势。但湖仓一体架构有多种状态，不同状态尚在演进和争执中。
(图：数据湖与数据仓库借鉴交融)
1.3 云架构角度，云原生与托管化成为支流
随着大数据平台技术进入深水区，用户也开始分流，越来越多的中小用户不再自研或自建数据平台，开始拥抱全托管型（通常也是云原生）的数据产品。Snowflake 作为这一畛域的典型产品，失去广泛认可。面向未来，后续仅会有大量超大规模头部公司采纳自建（开源 + 改良）的模式。
(图：snowflake 的云原生架构）
1.4 计算模式角度，AI 逐步成为支流，造成 BI+AI 双模式
BI 作为统计分析类计算，次要是面向过来的总结；AI 类计算则具备越来越好的预测将来的能力。在过来五年中，算法类的负载从不到数据中心总容量的 5%，晋升到 30%。AI 曾经成为大数据畛域的一等公民。
二、大数据体系的畛域架构
在前文 (#1.1) 介绍的 Shared-Nothing、Shared-Data、Shared-Everything 三种架构中，笔者经验过的两套体系（微软 Cosmos/Scope 体系，和阿里云 MaxCompute）均为 Shared-Everything 架构，因而笔者次要从 Shared-Everything 架构角度，将大数据畛域分成 6 个叠加的子畛域、3 个横向畛域，共 9 个畛域，具体如下图。
(图：基于 Shared-Everything 大数据体系下的畛域架构)
通过多年的倒退，每个畛域都有肯定的停顿和积淀，上面各个章节将概述每个子畛域的演进历史、背地驱动力、以及倒退方向。
2.1 分布式存储向多层智能化演进
分布式存储，本文特指通用大数据海量分布式存储，是个典型的带状态（Stateful）分布式系统，高吞吐、低成本、容灾、高可用是外围优化方向。（注：下述分代仅为了论述不便，不代表严格的架构演进。）
第一代，分布式存储的典型代表是谷歌的 GFS 和 Apache Hadoop 的 HDFS，均为反对多备份的 Append-only 文件系统。因 HDFS 晚期 NameNode 在扩展性和容灾方面的短板不能充沛满足用户对数据高可用的要求，很多大型公司都有自研的存储系统，如微软的 Cosmos（起初演进成 Azure Blob Storage），以及阿里巴巴的 Pangu 零碎。HDFS 作为开源存储的奠基，其接口成为事实标准，同时 HDFS 又具备反对其余零碎作为背地存储系统的插件化能力。
第二代，基于上述底盘，随海量对象存储需要激增（例如海量的照片），通用的 Append-only 文件系统之上，封装一层反对海量小对象的元数据服务层，造成对象存储（Object-based Storage），典型的代表包含 AWS S3，阿里云 OSS。值得一提的是，S3 与 OSS 均可作为规范插件，成为 HDFS 的事实存储后端。
第三代，以数据湖为代表。随云计算技术的倒退，以及（2015 年之后）网络技术的提高，存储计算一体的架构逐步被云原生存储（存储托管化）+ 存储计算拆散的新架构取代。这也是数据湖体系的终点。同时因存储计算拆散带来的带宽性能问题并未齐全解决，在这个细分畛域诞生了 Alluxio 等缓存服务。
第四代，也是当下的趋势，随存储云托管化，底层实现对用户通明，因而存储系统有机会向更简单的设计方向倒退，从而开始向多层一体化存储系统演进。由繁多的基于 SATA 磁盘的零碎，向 Mem/SSD+SATA (3X 备份)+SATA (1.375X 为代表的 EC 备份)+ 冰存储（典型代表 AWS Glacier）等多层零碎演进。
如何智能 / 通明的将数据存储分层，找到老本与性能的 Trade-off，是多层存储系统的要害挑战。这畛域起步不久，开源畛域没有显著好的产品，最好的程度由几个大厂的自研数仓存储系统引领。
(图：阿里巴巴 MaxCompute 的多层一体化存储体系)
在上述零碎之上，有一层文件存储格局层（File Format layer），与存储系统自身正交。
存储格局第一代，蕴含文件格式、压缩和编码技术、以及 Index 反对等。目前支流两类的存储格局是 Apache Parquet 和 Apache ORC，别离来自 Spark 和 Hive 生态。两者均为适应大数据的列式存储格局，ORC 在压缩编码上有专长，Parquet 在半构造反对上更优。此外另有一种内存格局 Apache Arrow，设计体系也属于 format，但次要为内存替换优化。
存储格局第二代 – 以 Apache Hudi/Delta Lake 为代表的近实时化存储格局。存储格局晚期，是大文件列存储模式，面向吞吐率优化（而非 latency）。随着实时化的趋势，上述支流的两个存储模式均向反对实时化演进，Databricks 推出了 Delta Lake，反对 Apache Spark 进行近实时的数据 ACID 操作；Uber 推出了 Apache Hudi，反对近实时的数据 Upsert 能力。
只管二者在细节解决上稍有不同（例如 Merge on Read or Write），但整体形式都是通过反对增量文件的形式，将数据更新的周期升高到更短（防止传统 Parquet/ORC 上的针对更新的无差别 FullMerge 操作），进而实现近实时化存储。因为近实时方向，通常波及更频繁的文件 Merge 以及细粒度元数据反对，接口也更简单，Delta/Hudi 均不是单纯的 format、而是一套服务。
存储格局再向实时更新反对方向演进，会与实时索引联合，不再单单作为文件存储格局，而是与内存构造交融造成整体计划。支流的是实时更新实现是基于 LogStructuredMergeTree（简直所有的实时数仓）或者 Lucene Index（Elastic Search 的格局）的形式。
从存储系统的接口 / 外部性能看，越简略的接口和性能对应更凋谢的能力（例如 GFS/HDFS），更简单更高效的性能通常意味着更关闭，并逐渐进化成存算一体的零碎（例如 AWS 当家数仓产品 RedShift），两个方向的技术在交融。
展望未来，咱们看到可能的倒退方向 / 趋势次要有：
1）平台层面，存储计算拆散会在两三年内成为规范，平台向托管化和云原生的方向倒退。平台外部，精细化的分层成为均衡性能和老本的要害伎俩（这方面，以后数据湖产品还做得远远不够），AI 在分层算法上施展更大的作用。
2）Format 层面，会持续演进，但大的冲破和换代很可能取决于新硬件的演进（编码和压缩在通用处理器上的优化空间无限）。
3）数据湖和数仓进一步交融，使得存储不仅仅是文件系统。存储层做的多厚，与计算的边界是什么，依然是个关键问题。
2.2 散布式调度，基于云原生，向对立框架和算法多元化倒退
计算资源管理是分布式计算的外围能力，实质是解决不同品种的负载与资源最优匹配的问题。在“后红海时代”，Google 的 Borg 零碎，开源 Apache Yarn 仍旧是这个畛域的要害产品，K8S 在大数据计算调度方向上仍在起步追赶。
常见的集群调度架构有：
中心化调度架构：晚期的 Hadoop1.0 的 MapReduce、后续倒退的 Borg、和 Kubernetes 都是中心化设计的调度框架，由繁多的调度器负责将工作指派给集群内的机器。特地的，核心调度器中，大多数零碎采纳两级调度框架通过将资源调度和作业调度离开的形式，容许依据特定的利用来定做不同的作业调度逻辑，并同时保留了不同作业之间共享集群资源的个性。Yarn、Mesos 都是这种架构。
共享状态调度架构：半分布式的模式。应用层的每个调度器都领有一份集群状态的正本，并且调度器会独立地对集群状态正本进行更新。如 Google 的 Omega、Microsoft 的 Apollo，都是这种架构。
全散布式调度架构：从 Sparrow 论文开始提出的全分布式架构则更加去中心化。调度器之间没有任何的协调，并且应用很多各自独立的调度器来解决不同的负载。
混合式调度架构：这种架构联合了中心化调度和共享状态的设计。个别有两条调度门路，别离为为局部负载设计的散布式调度，和来解决剩下的负载的核心式作业调度。
(图：The evolution of cluster scheduler architectures by Malte Schwarzkopf)
无论大数据系统的调度零碎是基于哪种架构，在海量数据处理流程中，都须要具备以下几个维度的调度能力：
数据调度：多机房跨区域的零碎服务带来全域数据排布问题，须要最优化应用存储空间与网络带宽。
资源调度：IT 基础设施整体云化的趋势，对资源的调度和隔离都带来更大的技术挑战；同时物理集群规模的进一步扩充，去中心化的调度架构成为趋势。
计算调度：经典的 MapReduce 计算框架逐步演变到反对动静调整、数据 Shuffle 的全局优化、充分利用内存网络等硬件资源的精细化调度时代。
单机调度：资源高压力下的 SLA 保障始终以来是学术界和工业界发力的方向。Borg 等开源摸索都假如在资源抵触时无条件向在线业务歪斜；然而离线业务也有强 SLA 需要，不能随便就义。
展望未来，咱们看到可能的倒退方向 / 趋势次要有：
K8S 对立调度框架：Google Borg 很早就证实了对立的资源管理有利于最优匹配和削峰填谷，只管 K8S 在“非在线服务”调度上依然有挑战，K8S 精确的定位和灵便的插件式设计应该能够成为最终的赢家。大数据调度器（比方 KubeBatch）是目前投资的一个热点。
调度算法多元化和智能化：随各种资源的解耦（例如，存储计算拆散），调度算法能够在繁多维度做更深度的优化，AI 优化是要害方向（实际上，很多年前 Google Borg 就曾经采纳蒙特卡洛 Simulation 做新工作资源需要的预测了）。
面向异构硬件的调度反对：众核架构的 ARM 成为通用计算畛域的热点，GPU/TPU 等 AI 减速芯片也成为支流，调度零碎须要更好反对多种异构硬件，并形象简略的接口，这方面 K8S 插件式设计有显著的劣势。
2.3 元数据服务统一化
元数据服务撑持了大数据平台及其之上的各个计算引擎及框架的运行，元数据服务是在线服务，具备高频、高吞吐的个性，须要具备提供高可用性、高稳定性的服务能力，须要具备继续兼容、热降级、多集群（正本）治理等能力。次要包含以下三方面的性能：
DDL/DML 的业务逻辑，保障 ACID 个性，保障数据完整性和一致性
受权与鉴权能力，保证数据拜访的安全性
Meta(元数据) 的高可用存储和查问能力，保障作业的稳定性
第一代数据平台的元数据系统，是 Hive 的 Hive MetaStore（HMS）。在晚期版本中 HMS 元数据服务是 Hive 的内置服务，元数据更新（DDL)以及 DML 作业数据读写的一致性和 Hive 的引擎强耦合，元数据的存储通常托管在 MySQL 等关系数据库引擎。
随着客户对数据加工解决的一致性（ACID），开放性（多引擎，多数据源），实时性，以及大规模扩大能力的要求越来越高，传统的 HMS 逐渐局限于单集群，单租户，Hive 为主的单个企业外部应用，为保障数据的安全可靠，运维老本居高不下。这些毛病在大规模生产环境逐渐裸露进去。
第二代元数据系统的代表，有开源体系的 Apache IceBerg，和云原生体系的阿里巴巴大数据平台 MaxCompute 的元数据系统。
IceBerg 是开源大数据平台最近两年呈现的独立于引擎和存储的“元数据系统”，其要解决的外围问题是大数据处理的 ACID，以及表和分区的元数据的规模化之后性能瓶颈。在实现办法上 IceBerg 的 ACID 依靠了文件系统 POSIX 的语义，分区的元数据采纳了文件形式存储，同时，IceBerg 的 Table Format 独立于 Hive MetaStore 的元数据接口，因而在引擎的 adoption 上老本很高，须要各个引擎革新。
基于将来的热点和趋势的剖析，凋谢的，托管的对立元数据服务越来越重要，多家云厂商，都开始提供了 DataCatalog 服务，反对多引擎对湖和仓数据存储层的拜访。
比照第一代与第二代元数据系统：
展望未来，咱们看到可能的倒退方向 / 趋势次要有：
趋势一：湖仓一体进一步倒退下，元数据的统一化，以及对湖上元数据和数据的拜访能力建设。如基于一套账号体系的对立的元数据接口，反对湖和仓的元数据的拜访能力。以及多种表格局的 ACID 的能力的交融，这个在湖上数据写入场景越来越丰盛时，反对 Delta，Hudi，IceBerg 表格局会是平台型产品的一个挑战。
趋势二：元数据的权限体系转向企业租户身份及权限体系，不再局限于单个引擎的限度。
趋势三：元数据模型开始冲破关系范式的结构化模型，提供更丰盛的元数据模型，反对标签，分类以及自定义类型和元数据格式的表达能力，反对 AI 计算引擎等等。
原文链接
本文为阿里云原创内容，未经容许不得转载。