分布式技术剖析-Toy模板网

这篇具有很好参考价值的文章主要介绍了分布式技术剖析。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

随着企业数字化进程的进一步深入，企业为了解决大数据的“4个V”问题，往往需要构建多个不同技术栈的大数据平台，其中不乏会使用到分布式相关的存储、计算、资源管理技术。分布式系统的出现解决了单机系统无法解决的成本、效率和高可用问题。那么什么是分布式技术？如何发展至今？主要包括哪几方面的技术？本文将对分布式计算技术、存储技术和资源管理技术做简单介绍。

分布式技术剖析

— 分布式技术的发展历程 —

谷歌在2003年发表了包括Google File System在内的著名的3篇论文，打开了分布式技术快速发展的大门。2006年，Apache基金会创建了Hadoop开源项目，用来解决大规模的数据存储和离线计算的难题，开始解决商业场景下的技术问题。社区里首先诞生的是分布式文件系统HDFS和分布式计算框架MapReduce。HDFS至今仍被沿用，而MapReduce限于当时硬件计算能力的限制，如今已被更优秀的计算框架所替代。但MapReduce在那时的软硬件条件下，已经是最适合的设计，其技术意义非凡。随后在2007年，Apache Hadoop项目仿照谷歌的Bigtable开发了大型分布式NoSQL数据库HBase。除此之外还有Apache Hive，开发者可以使用类SQL语言查询存放在HDFS上的数据。从2015年开始Spark逐渐成为主流的计算引擎并开始替代已经被广泛地使用的MapReduce，为多样化的大数据分析提供更加强大的性能保障。

2016年之后，开源的大数据技术创新逐渐减少，原来各个项目背后的商业公司开始转向商业化，主要关注解决用户的产品化需求，客观上导致技术创新的削弱。从2018年开始，Hadoop技术生态企业在资本市场上发生一系列的重要事件，先是“Hadoop三驾马车”中的Cloudera和Hortonworks都实现了上市但股价持续低迷，此后Cloudera和Hortonworks两家公司被迫合并，两家的产品也随之开始融合；2019年MapR因为经营不善被迫卖身，被HPE低价收购后产品逐渐淡出市场。自此美国市场上的三家主流Hadoop发行版只剩下最后一家，Cloudera随后也迅速调整了产品策略并全面拥抱云计算，开始了开源大数据技术体系演进的新一个阶段。

与Hadoop技术的发展出现高开低走不同，Spark和Flink技术目前仍然处于技术和业务的高速发展阶段。UC Berkeley大学Matei Zaharia在2012年的一篇论文中首次提出了RDD（Resilient Distributed Datasets，弹性数据集）的概念，并逐步推出了开源Spark项目，其核心是通过弹性数据集作为大数据分析的基础数据描述接口和API规范，结合内存计算、DAG计算模型、Lazy Evaluation等优化技术，解决在交互式分析、离线批处理等领域的性能需求。由于其架构相对于MapReduce更加高效，此外大内存、SSD等硬件技术也在快速普及，从2015年开始Spark逐渐成为主流的计算引擎并开始替代已经被广泛使用的MapReduce，为多样化的大数据分析提供更加强大的性能保障。此后，UC Berkeley的研究团队成立了专门的商业化公司Databricks来支撑Spark的技术运营，并逐渐发展出SparkSQL、Spark MLLib、Spark Streaming等主要的项目，分别用于解决结构化数据的交互式分析、机器学习和实时数据的计算需求。

2020年后，随着企业数字化需求的快速演进和云原生技术的进一步普及，分布式技术的发展往更加方案化的方向发展，行业里围绕着某些比较突出的技术架构问题针对性的提出了一些解决方案，譬如面向湖仓一体架构的Apache Hudi和Iceberg，主要解决数据联邦分析的Presto和Trino技术，为了支撑更加实时性业务的流批一体架构，以及更好解决多部门灵活数据业务需求的数据云技术如Snowflake等。这些新的分布式技术的出现和逐渐成熟，让大数据的业务化发展有更快的趋势。

不过随着企业数字化进程的进一步深入，企业为了解决大数据的“4个V”问题，往往需要构建多个不同技术栈的大数据平台，如Hadoop平台用于存储和资源管理、MPP数据库用于数仓或者数据集市建设、Spark集群用于SQL处理和机器学习、搭建Flink集群用于实时数据处理等多个垂直系统，各个系统之间需要互相安全打通和资源共享，因此数据冗余和运维开发成本急剧提升，需要一个较大的专业团队来支撑，对企业来说，无论是应用开发难度、硬件资源有效利用，还是人才团队建设上有很大的压力，甚至决定了数字化业务是否能够成功。

分布式技术总体上可以概括为分布式计算技术、分布式存储技术和分布式资源管理技术，我们将对这些技术分别展开论述。

— 分布式数据存储技术 —

分布式存储技术是相对于集中式存储技术来说的，在大数据技术被广泛使用之前，企业级的存储设备都是集中式存储，整个数据中心的存储是集中在一个专门的存储阵列系统中，如EMC的机柜式存储。集中式存储多是采用专用的软硬件一体机的方案，相对成本比较高。机柜中有个专门的控制器用于业务端访问，底层将所有的磁盘抽象为一个资源池，然后在抽象给上层业务使用。可以看到，这个控制器是所有数据链路的入口，在分布式计算技术下，如果大量的计算都涉及比较高的IO带宽，那么这个入口就会成为性能瓶颈点。

Google的GFS文件系统和著名论文《Google File System》开启了业内从集中式存储到分布式存储的演进，它可以让分布式存储服务运行在廉价的服务器上，并且也提供了灾难冗余、存储弹性伸缩等能力。它的原理是通过文件服务层将每台服务器上的磁盘设备统一管理和使用起来，通过软件的方式来实现可靠性和资源池化，而无需将所有的存储集中起来并通过硬件方式来服务。此后Apache HDFS参考该架构做了第一个开源的分布式存储的实现，并被企业界大量落地使用，并推动着开源社区迅速的完善该技术，逐渐成为私有化场景下分布式存储的一个事实标准。

分布式技术剖析

图片来源于《The Google File System》

公有云厂商则从另外一个路径上逐步完善分布式存储技术，首先重点发展分布式对象存储和分布式块存储技术，其中块存储技术主要为云上虚机提供云盘等服务，而对象存储被用于存储业务数据。随着企业对数据库的需求快速爆发，后续各大云厂商陆续研发基于对象存储的分布式数据库技术。

分布式技术剖析

从抽象的视角来看，一个分布式存储系统就是建立一个从访问路径（文件路径、块地址或对象哈希）到实际数据的映射关系，并且可以支持读写，只不过这些数据是分布在不同服务器的不同的硬盘上，此外文件系统还必须做好资源协调、容错性保障以及可扩展性等。下图是一个概念上的架构图，可以看出来分布式存储技术的关键功能包括：

数据和元数据的数据分布、管理和读写策略，保证系统的可扩展性
如何快速的找到元数据和数据，提供数据读写能力，尽可能的数据本地化计算，保证系统的性能
数据的冗余、备份和协调策略来保障高可用
冷热数据存储、数据压缩与数据去重等技术，保证海量数据存储的经济性
良好的用户开发接口兼容性，如POSIX FS、S3、NFS协议等
跨平台能力，譬如支持Linux、Unix和Windows系统等

分布式技术剖析

另外的两个比较重要的功能特性是分布式存储的事务能力和安全能力。存储本身如果支持事务特性（如兼容POSIX文件协议），就可以比较方便地给上层有文件事务操作需求的应用直接开放。不过客观地说，事务特性会对存储的性能、可用性有一定的影响，如下图所示，因此很多分布式存储在设计上都放弃了事务特性，或者选择Optimistic Consistency的事务实现。

分布式技术剖析

分布式存储的安全性是必备的基础功能之一，包括用户授权、访问控制ACL、数据链路加密、密钥管理和透明加密等。Kerberos和LDAP协议是比较常见用户分布式存储的网络授权协议，透明加密技术可以保证第三方无法从磁盘上直接获取数据。目前一些开源的存储项目的安全功能实现不够完整，或者是以商业化插件的方式来提供，这导致网络上存在大量的未做有效的安全防护的存储集群，造成大量的数据泄露事件，成为近年来网络安全的重要泛滥区。

— 分布式计算技术 —

当一个计算任务过于复杂不能被一台服务器独立完成的时候，我们就需要分布式计算。分布式计算技术将一个大型任务切分为多个更小的任务，用多台计算机通过网络组装起来后，然后将每个小任务交给一些服务器来独立完成，最终完成这个复杂的计算任务。Google是分布式计算的引导者，其发明的MapReduce计算框架是第一代被成功用于大规模生产的分布式计算技术，而后Apache Hadoop社区实现了这个技术并开源，后被业界大量采用。此后旺盛的数据分析需求推动了该领域技术的突破，大量新的计算引擎陆续出现，包括Spark、Tez、Flink等著名的分布式计算引擎。

在分布式计算中，一个计算任务一般叫做Job，一个Job有多个Task，每个Task是可以在一套服务器上独立运行，一个Job被拆分为多少个Task就决定了分布式计算的并行度（Granularity或Parallel）。一个节点指的是可以独立运行某个Task的服务器或者虚机实例，将多个节点连接起来并且可以联合处理一个计算任务就需要有好的拓扑（Topology）设计。分布式计算的核心就是要将一个大的计算任务拆分为多个小的计算任务，并且让这些任务可以并行起来，还需要尽量减少分布式网络带来的网络和数据shuffle开销。通常情况下，这个分布式系统都是通过局域网连接，各个服务器可能存在异构性，为了保证性能，分布式计算技术需要尽可能地将任务调度到所有的节点上，并且避免“木桶效应”导致的性能慢问题。有几种比较常见的任务并行算法，包括：

数据并行模型

这个最简单的一个计算模型，每个节点处理的计算任务是相同的，并且分配到不同的数据，每个节点完成计算任务后再汇总出计算结果。如何有效地做数据分区是决定整个模型的效率的关键。

分布式技术剖析

任务依赖图模型

计算平台将一个复杂Job拆分为多个任务，并且按照Task之间的依赖关系生成一个依赖图（DAG），如下图所示，每个节点是一个计算任务，每个有方向的边代表依赖关系。在这个例子里，Task1-4可以同时执行，并行度为4，也就是可以同时有4个节点在执行任务。Task 5和6需要等待前序4个任务都完成后才能开始计算任务，而Task 7需要等待Task 5和6完成后才能开始计算。每个服务器处理哪些Task是由一些mapping算法来决定，如在MapReduce和Spark中，都采用了这个模型，并且都是根据数据在哪个节点上来决定对应的计算任务在哪个服务器上启动。

分布式技术剖析

任务池模型

在这个模式下，一个调度单元负责将Job生成为一系列的Tasks并将其存入一个任务池中，每个Task分配给哪些服务器是完全随机的，根据一些检测算法来识别到有新的Task后动态的决定新计算任务的调动。

数据管道模型

这个模式下，有一个数据的管道（pipeline），这个管道分为几个Stage，每个Stage都有一些数据计算任务，并且将结果传给下个Stage。每个Stage都切分为多个计算任务，多个相连的Stage上的Tasks就组成了一个生产者-消费者模型。每个阶段任务的切分一般是静态切分的，按照数据特点或某些Hash算法。

混合模型

顾名思义，就是采用以上多个模型组合为一个新的计算模型。譬如Spark就采用的任务依赖图模型和数据管道模型混合的方式。

分布式计算技术是技术难度非常高的技术领域，为了保证能够适应多种计算需求，一个优秀的分布式计算框架需要满足较高的架构要求，主要包括：

透明性：无论分布式的系统有大的集群规模，在开发和使用上应该像是一个单一系统，不需要开发者感知其复杂性
可扩展性：计算能力能够随着服务器节点的增加而线性增长
异构能力：能够屏蔽底层软硬件的异构性，能够在不同的系统环境下运行
容错能力：单个或者少量的服务器阶段宕机后不会导致计算引擎停止服务
任务调度能力：可以通过策略将任务调度到给定的计算节点并保证有最大化的性能和资源隔离性
安全性：无论底层网络的拓扑如何变化，分布式计算引擎要保证计算过程中的数据安全性

分布式计算技术按照其业务场景的不同又可以分为离线计算和实时计算，其中离线计算因为被广泛应用于批处理业务，对应的计算框架经常被称作批处理引擎，MapReduce、Tez和Spark是其中的重要代表。

实时计算的发展历史只有十几年，其与基于数据库的计算模型有本质的区别，实时计算是固定的计算任务加上流动的数据，而数据库基本上是固定的数据和流动的计算任务，因此实时计算平台对数据抽象、延时性、容错性、数据语义等的要求与数据库明显不同，面向实时计算的数据架构也就自然发展起来，Lambda和Kappa两种架构是其主要的代表。

在企业数据应用中，实时计算拥有丰富的场景性需求，主要包括以下几类：

实时数据 ETL：实时消费 Kafka 数据进行清洗、转换、结构化处理用于下游计算处理。
实时数仓：实时化数据计算，仓库模型加工和存储。实时分析业务及用户各类指标，让运营更加实时化。
实时监控：对系统和用户行为进行实时检测和分析，如业务指标实时监控，运维线上稳定性监控，金融风控等。
实时分析：特征平台，用户画像，实时个性化推荐等。

— 分布式资源管理技术 —

无论是类似Linux OS这样的单机调度系统，还是YARN这样的集中式调度器，亦或是Kubernetes这样的分布式调度器，都需要解决三个最基本的需求:

资源的有效利用：支持各种规模的集群的资源的统一管理和调度
任务的有效响应：支持长、中、短等各种生命周期的任务调度和及时响应
调度策略的灵活配置：多样化的方式可以让集群运维者根据生产状况来灵活定制调度策略，甚至自定义其调度算法

除此以外，调度系统尤其是分布式调度系统，还需要解决包括状态的有效同步、有效容错、可扩展性等技术限制。

YARN是一种集中式的调度器，适合批处理任务和吞吐量较大的任务，对频繁开启关闭的交互式分析任务等支持的不好，因此适合应用和集群规模都不是非常大的集群的资源管理。另外YARN实质上只能对内存资源做限制，因为其本身是运行在用户态，虽然调度接口上做了CPU的限制，但是实质上并不能真正限制CPU资源，这样导致其相对于Kubernetes等调度系统就有非常大的劣势，不过在Hadoop 2.9之后支持容器的调度管理，通过与操作系统cgroup结合使用才逐步解决无法调度CPU资源的问题。另外由于YARN是天生为Hadoop设计的资源管理体系，其设计核心是为了支持短生命周期的批处理数据任务，而不能支持长生命周期的服务，这是一个非常致命的限制，因此不能成为整个数据中心的统一调度系统。YARN提供了多种调度策略来适配不同的业务场景需求，有非常好的落地灵活性。在容错性方面，YARN通过主备切换的方式来解决单点故障问题，但是可扩展性比较一般。

随着数据服务的深入，大量的非Hadoop技术的数据平台，以及大量的数据应用都需要进行有效的统一管理和调度，对CPU、GPU等资源的细粒度调度也变成刚需；此外集群的规模也越来越大，集中式的调度器逐渐成为瓶颈，调度的对象也需要从单纯的Hadoop任务逐步往通用化应用的方向发展，类似Kubernetes这样的基于共享状态的调度器，能够支持超大规模集群，同时又能支持各种生命周期的服务管理和调度，才是大规模集群调度器的发展方向。星环科技在2017年就已经实现内部大数据平台从YARN切换到Kubernetes，而开源社区从2018年开始，多个项目如Spark、Flink、Tensorflow等都开始从YARN转向基于Kubernetes的管理和调度。长期上看，作为Hadoop集群的资源管理系统，YARN非常有效地完成了其技术价值，但受限于其架构设计，很难往一个通用的数据中心调度系统演进。