三十年河东三十年河西，人生如此，大数据处理亦是如此

最新推荐文章于 2024-11-07 11:53:57 发布

梦回从前

最新推荐文章于 2024-11-07 11:53:57 发布

阅读量522

点赞数

分类专栏：云原生大数据平台文章标签：数据库大数据云原生存算分离移动计算

本文链接：https://blog.csdn.net/microGP/article/details/125913823

版权

大数据平台同时被 2 个专栏收录

14 篇文章 1 订阅

订阅专栏

云原生

4 篇文章 0 订阅

订阅专栏

前言

数据处理从诞生至今也不过几十年，如果针对大数据处理，那也是本世纪初才真正开始。但就是这么短的时间内，大数据处理技术却更迭频繁，从架构到具体技术实现都是如此。生命力弱的如昙花一现，很快被别人忘记；生命力强的繁华过后，也要砥砺前行，不能有丝毫放松。

在这种情况下，风水轮流转，三十年河东三十年河西的戏码几乎是家常便饭。北上广不相信眼泪，大数据同样不相信过往。如果技术跟不上潮流发展，等待它的只有被淘汰的命运，无论之前它曾经是多么的辉煌。这亦如我们的人生，我们的命运。

下面我们就从两个角度来回顾一下大数据世界的发展，也许从中也会看到我们人生的起伏！

从大权独揽到群雄并起

大数据处理的第一步是先把数据存起来，而存数据就离不开数据库。而数据库构架设计中主要有三种架构模式：Shared Everthting、Shared Disk以及Shared Nothing，见下图所示：

这三种模式代表了三个不同时代处理数据的不同需求，下面就来详细说说：

Shared Everthting

一般是针对单个主机，完全透明共享CPU/MEMORY/IO，大权独揽，一个服务器carry整个数据存储，典型的代表SQLServer。这种只能靠单机的纵向扩展能力的架构扩展性终究还是太差，哪怕是上了小型机等价格巨贵的硬件设备，在面对日益膨胀的数据时也只能望洋兴叹。廉颇真的老矣，只能告老还乡了！

Shared Disk

纵向扩展能力终究有限，于是各大服务器厂商想到了横向扩展。但是由于数据库数据一致性的要求，所以横向扩展面临的数据一致性和数据通信问题却成了拦路虎。

于是，为了避开分布式一致性的问题，一个折中方案就诞生了。在这套方案下，各个处理单元使用自己的私有 CPU和Memory，共享磁盘系统。这样的做的好处就是在数据只有一份不需要同步的情况下，横向的数据处理能力确实可以进行横向扩展的，典型的代表Oracle Rac。

它是数据共享，可通过增加节点来提高并行处理的能力，扩展能力较好。其类似于SMP（对称多处理）模式，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能。面对气势汹涌的数据增长速度和数据处理压力，这个方案慢慢也被淘汰了。

Shared Nothing

既然半分布式无法彻底解决问题，只能通过完全分布式来解决问题。针对无限扩展的数据量以及数据处理压力，只有完全分布式才能理论上解决这种扩展性上的限制。

在这种情况下，各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP（大规模并行处理）模式，各处理单元之间通过协议通信，并行处理和扩展能力更好。典型代表DB2 DPF和hadoop为开端的各种大数据存储和处理组件。各节点相互独立，各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转，配以分布式一致性算法、分布式通信协议、failover以及各种横向扩容等方案。

在这些技术的复杂以及完美配合的下，大数据处理再也不是美式英雄主义，单人独立面对所有困难力挽狂澜的局面；而是群雄并起，大家共同努力靠着集体的力量面对已知和未知的各种困难。到此大数据处理终于可以优雅的处理和面对不断增加和越发复杂的业务场景和数据场景。

移动计算还是移动数据

移动计算，存算耦合

如果从早期就接触到大数据，尤其是做hadoop起家的大数据从业人员，一定听说过“移动计算不移动数据”的说法。这在那个时代基本上就是金科玉律，而且数据处理的流程设计以及代码编写规范也是尽量围绕着这个原则展开。下面来看看hadoop的yarn调度的流程图：

从上面可以看出，client端向yarn提交任务后，ResourceManager首先启动第一个container即ApplicaitonMaster作为该任务的代理来全权负责该任务的筹划以及执行并保证任务顺利完成。

ApplicaitonMaster根据任务信息和任务需要处理的数据所在的位置，向ResourceManager申请合适的资源来进行任务的执行。

ResourceManager根据ApplicaitonMaster的申请在集群中寻找“合适”的资源并封装成container提供给ApplicaitonMaster。ApplicaitonMaster将任务在这些container中启动，监控这些任务顺利完成并处理任务在运行过程中的各种问题。

如果想进一步形象化这个过程，可以把它类比成公司内部的项目实施流程。其中client就是销售；任务就是项目；ResourceManager就是部门经理；ApplicaitonMaster就是项目经理；数据就是项目中的各种需求；而container就是具备解决这些需求的各种项目参与人员。在这种对应关系下，我相信这个流程就很容易想明白了，我在这里就不过多赘述了。

上面提到的申请合适资源除了CPU以及Memory这种常规资源外，最重要的就是期望的计算节点，而这个则是根据数据所在位置进行的规划。

考虑到数据所在节点可能无法满足计算要求（资源不足或者负载过高，或者因为表现不佳就列入了“黑名单”），所以针对这个计算本地性的需求，yarn给出了自己的调度策略：

优先分配node-local(数据与container在同一个节点)
其次分配rack-local(数据与container在同一机架)
最后分配no-local(数据与container不在同一个机架)

可以看出，yarn尽量将计算放在里数据近的地方，以达到移动计算不移动数据的目标。而这个目标的根本原因就是移动数据的代价太高，也就是IO资源的瓶颈。

但是问题的根源找到了，那么问题来了，如果IO资源不再是瓶颈，移动计算还是必要的吗？

移动数据，存算分离

带着这个问题我们先来想想移动计算有没有什么问题或者短板？

资源浪费：移动计算带来的模式必然是存储和计算耦合。计算需要CPU和内存，而存储需要磁盘。但是无论是计算先达到瓶颈，还是存储先达到瓶颈，横向扩展都是加机器，因此就会存在不少的资源浪费。
扩展繁琐：计算和存储耦合模式下，机器扩展通常伴随着大量的数据迁移。如果该扩展仅仅是针对计算层面，那么这个数据迁移显然是多余的，也会增加整个扩展的复杂性。

再后来，随着硬件的发展，磁盘和带宽成本的大幅下降，性能反而提升很大，导致IO瓶颈问题并不向之前那么谈虎色变了。到此时，存算分离，即移动数据的方案被摆到了台面上。而在这个变革中，分布式数据库和消息中间件的发展最为迅速。

分布式数据库

相比于初代的NOSQL数据库，如HBase(HRegionServer)以及MongoDB(mongod)等存算一体的数据库，新一代的存算分离的数据库慢慢成为了现在的主流。

2014年AWS首次推出了Aurora，阿里在2017年推出了PolarDB，华为云在2020年推出了GaussDB for MySQL，华为存储也在2021年针对企业自建数据中心，推出OceanData分布式数据库存算分离方案。

而分布式数据库的新贵NewSQL的崛起也成为了存算分离场景的一个实践。下面的图就是TiDB这个NewSQL的基础架构：

从上图可以看出，TiDB为了解决不同的需求，满足不同的业务场景而设计了不同功能的业务组件。这些组件都是独立的小集群，都可以单独扩展，集群之前使用grpc进行通信，数据一致性通过raft-like算法保障。

组件之间相互独立，实现了模块化部署，数据在各个模块之间流动。真正做到了移动数据，存算分离。用户可以根据业务场景和需求进行定制化的部署，灵活性和可扩展性都达到了一个很良好和稳定的层级。

消息中间件

初代的消息中间件无论是kafka还是各种MQ，其设计思想都是利用本地机器的磁盘来进行保存消息队列，然后利用本机的CPU和内存资源进行数据的存取和处理，本质上也是存算耦合，也有那些存算耦合实现的各种问题和短板。

而新一代的消息中间件pulsar则是存算分离的代表。它借助Apache Bookkeeper的实现解决了存储层的问题，在上层单独实现了数据存储和处理的逻辑，做到了存算分离的架构，保证了灵活性和扩展性。这部分知识这里就不展开了，相关的内容和知识我的一个朋友公众号中有详细介绍和实践经验，欢迎大家关注和交流：公众号