共计 6657 个字符，预计需要花费 17 分钟才能阅读完成。
随着企业数字化过程的进一步深刻，企业为了解决大数据的“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 十分无效地实现了其技术价值，但受限于其架构设计，很难往一个通用的数据中心调度零碎演进。
— 小结—
本文从分布式计算技术、存储技术和资源管理技术三个方面介绍了分布式，置信大家对分布式技术体系曾经有了整体的把握。前面那咱们将对这三个层面的具体技术开展介绍，下一篇将介绍分布式文件系统 HDFS 与对象存储 Ceph。
【参考文献】Ghemawat S, Gobioff H, Leung S T. The Google File System[J]. 2003.
