开什么网站暴利,网络营销渠道的设计方案,wordpress文章站主题,南京网站制作有限公司简介#xff1a; 本文作者关涛是大数据系统领域的资深专家#xff0c;在微软#xff08;互联网/Azure云事业群#xff09;和阿里巴巴#xff08;阿里云#xff09;经历了大数据发展20年过程中的后15年。本文试从系统架构的角度#xff0c;就大数据架构热点#xff0c;每…简介 本文作者关涛是大数据系统领域的资深专家在微软互联网/Azure云事业群和阿里巴巴阿里云经历了大数据发展20年过程中的后15年。本文试从系统架构的角度就大数据架构热点每条技术线的发展脉络以及技术趋势和未解问题等方面做一概述。
作者 | 阿里云计算平台研究员关涛、阿里巴巴项目管理专家王璀
任何一种技术都会经历从阳春白雪到下里巴人的过程就像我们对计算机的理解从“戴着鞋套才能进的机房”变成了随处可见的智能手机。在前面20年中大数据技术也经历了这样的过程从曾经高高在上的 “火箭科技rocket science”成为了人人普惠的技术。
回首来看大数据发展初期涌现了非常多开源和自研系统并在同一个领域展开了相当长的一段“红海”竞争期例如Yarn VS Mesos、Hive VS Spark、Flink VS SparkStreaming VS Apex、Impala VS Presto VS Clickhouse等等。经历激烈竞争和淘汰后胜出的产品逐渐规模化并开始占领市场和开发者。
事实上近几年大数据领域已经没有再诞生新的明星开源引擎Clickhouse2016年开源PyTorch2018年开源以Apache Mesos等项目停止维护为代表大数据领域进入“后红海”时代技术开始逐步收敛进入技术普惠和业务大规模应用的阶段。
本文作者关涛是大数据系统领域的资深专家在微软互联网/Azure云事业群和阿里巴巴阿里云经历了大数据发展20年过程中的后15年。本文试从系统架构的角度就大数据架构热点每条技术线的发展脉络以及技术趋势和未解问题等方面做一概述。
值得一提的是大数据领域仍然处于发展期部分技术收敛但新方向和新领域层出不穷。本文内容和个人经历相关是个人的视角难免有缺失或者偏颇同时限于篇幅也很难全面。仅作抛砖引玉希望和同业共同探讨。
一、当下的大数据体系热点
BigData概念在上世纪90年代被提出随Google的3篇经典论文GFSBigTableMapReduce奠基已经发展了将近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逐渐成为主流形成BIAI双模式
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/SSDSATA (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 IndexElastic Search的格式的方式。
从存储系统的接口/内部功能看越简单的接口和功能对应更开放的能力例如GFS/HDFS更复杂更高效的功能通常意味着更封闭并逐步退化成存算一体的系统例如AWS当家数仓产品RedShift两个方向的技术在融合。
展望未来我们看到可能的发展方向/趋势主要有
1平台层面存储计算分离会在两三年内成为标准平台向托管化和云原生的方向发展。平台内部精细化的分层成为平衡性能和成本的关键手段这方面当前数据湖产品还做得远远不够AI在分层算法上发挥更大的作用。
2Format层面会继续演进但大的突破和换代很可能取决于新硬件的演进编码和压缩在通用处理器上的优化空间有限。
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 MetaStoreHMS。在早期版本中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的能力的融合这个在湖上数据写入场景越来越丰富时支持DeltaHudiIceBerg表格式会是平台型产品的一个挑战。趋势二元数据的权限体系转向企业租户身份及权限体系不再局限于单个引擎的限制。趋势三元数据模型开始突破关系范式的结构化模型提供更丰富的元数据模型支持标签分类以及自定义类型和元数据格式的表达能力支持AI计算引擎等等。
原文链接 本文为阿里云原创内容未经允许不得转载。
