企业大数据发展面临问题之存算分离技术思考

概述

背景

Hadoop一出生就是奔存算一体设计，当时设计思想就是存储不动而计算(code也即是代码程序)动，负责调度Yarn会把计算任务尽量发到要处理数据所在的实例上，这也是与传统集中式存储最大的不同。为何当时Hadoop设计存算一体的耦合？要知道2006年服务器带宽只有100Mb/s~1Gb/s,但是HDD也即是磁盘吞吐量有50MB/s，这样带宽远远不够传输数据，网络瓶颈尤为明显，无奈之举只好把计算任务发到数据所在的位置。

众观历史常言道天下分久必合合久必分，随着云计算技术的发展，数据库也开始拥抱云原生时代，在当前越来越强调云原生的环境下，存储计算分离已经是大势所趋，“存算分离”作为一种架构思想在企业项目研发过程中逐渐为大家所熟知和使用，随着数字化转型带来的企业IT架构的重塑，存算分离技术将逐渐走入历史的舞台。存算是指存储和计算组成，通常所说的计算是指由CPU和内存组成的算力单元，存储指的是持久化的数据存放单元。在企业生产实践过程中没有一成不变的架构，只有不变的以业务为核心的架构意识。

家庭宽带自从升级到100m bps甚至更大，从来不保存电影，要看直接下载，基本几分钟就好了，而这在十年前是不可想象。带宽的速度特别是IDC机房内带宽的速度，已经从1000mps、2000mps、10000mps，甚至100000mpbs，网络带宽提升100倍甚至更高，网络已经不再是瓶颈，但是从磁盘吞吐性能上并没有太大提升，仅仅提升1倍左右(100MB/S)，由于硬件的变化带来了软件架构的变化。高效的压缩算法与列式存储也进一步减少I/O的压力，大数据的瓶颈逐渐由I/O变成CPU。同时集群规模越来越大，存算利用率不均衡，选型受限的问题越来越明显。

为何要存算分离

随着累积的数据量的增大，大数据业务量的增多，数据存储和处理的成本越来越高，企业数据基础设施的投资越来越大。同时，大数据处理组件多，不同组件使用不同的数据处理格式，比如大家熟悉的数据湖、数据仓库使用的就是不同的格式，多样化的数据格式导致数据存储变得复杂，系统中应对不同的场景，往往同样的数据需要存储多份，不同组件之间还需要大量的数据拷贝和格式转换，消耗大量的资源。经过十几年大数据发展，随着海量负载和大数据用例的出现，单一Hadoop集群的规模变大，多个Hadoop集群需同时支撑不同的业务。因此在存储和计算耦合架构下，大数据集群将面临如下问题：

• 成本高：业务中对算力和存储需求是不平衡的，增长速度也是不均衡的。扩容时同时要扩容计算和存储，通常算力是有浪费的。

• 资源利用率低：由于多个Hadoop 集群承接不同的工作负载，随着支撑业务需求的波动，系统负载出现峰谷，然而存算一体的架构导致各集群的资源完全独立隔离不能共享（跨行业的存算一体架构下的Hadoop集群平均资源利用率在25%以下）。高密度存储型和算力增强型都难有用武之地；数据会倾斜，计算任务不一定能有效的调度到数据所在实例上。

• 运维困难：随着业务复杂度的增加和新业务上线的速度加快，对服务器资源配比的要求也会随之增加，如果服务器款型繁杂，维护难度就会增大，同时导致机房空间占用多、能耗大。实例要考虑计算与存储的均衡，机器选型受限。缩容较复杂，要对实例上的数据内容做迁移，这种情况无法做到弹性伸缩。

优势

• 逻辑单元分开扩容：通过计算和存储的分离部署实现计算和存储的隔离，根据业务负载需求，对计算/存储按需扩容。
• 大数据能力云化：计算分离之后，可将其迁移到K8S或其他的云上面，使得计算更轻量化。
• 多数据平台整合：底层提供统一的存储给到不同的大数据平台，实现多个大数据平台数据的整合，加速流程，逐步构建企业内部数据湖。

针对传统hadoop架构中计算资源和存储资源按某一比例强绑定，系统扩容必须按节点数目增加，导致内存或磁盘浪费的问题。“存算分离”不仅能节约成本，还可以让资源根据业务需求弹性伸缩，按需分配，降低了系统部署和扩展成本，解决了资源利用不均衡的问题。

• 提升资源利用率：“存算一体”架构需要考虑CPU、内存、存储容量/IOPS/带宽，网络IO/带宽，多达7个维度，任意一个维度的资源不满足就会导致无法满足应用诉求。而“存算分离”，按照计算和存储两个维度，将这7个维度拆分为两个领域，降低选型复杂度。分别构建计算资源池和存储资源池，提升资源利用率。扩容可实现计算和存储的按需扩容，节约投资。
• 高可用：外置存储阵列本身有非常好的可靠性设计，如RAID冗余、静默数据校验、两地三中心等可靠性保障，其可靠性等级高于服务器至少两个数量级，因此存储应该是一个“长期”的共享存储。服务器的可靠性偏弱，“存算分离”后，即使服务器故障，由于全局共享一份数据，可实现免数据复制快速恢复业务，实现分布式数据库整体的高可用。
• 高性能：采用“存算分离”架构后，由于全局共享一份数据，一些不必要的消耗可以被避免，可提升数据库整体的性能表现。例如半同步，每增加一个从节点都会导致10%的性能下降。采用“存算分离”后，不再需要半同步技术。外置存储阵列对性能的优化更加深入，全闪存存储，尤其是全NVME的存储，可提供极致的性能体验。存储共享资源池不仅可提升资源利用率，还能利用不同应用不同时间对存储性能峰谷要求不同的特点，将所有的IO分散到所有的磁盘，实现削峰填谷，达到最佳性能。

应用场景

存储和计算分离目前主要应用在数据库和消息队列两个方向。

• 数据库：以传统主从架构数据库系统为例，主库接收数据变更，从库读取binlog，通过重放binlog以实现数据复制。在这种架构下，当主库负载较大的时候，由于复制的是binlog，需要走完相关事务，所以主从复制就会变得很慢。当主库数据量比较大的时候，增加从库的速度也会变慢，同时数据库备份也会变慢，扩容成本也随之增加。因此企业也逐渐开始接受走计算和存储分离的道路，让所有的节点都共享一个存储，其实这就是计算和存储分离思想，现在很多的分布式NewSQL数据库都向“计算和存储分离”靠拢，包括PolarDB、OceanBase ，TiDB等等。
• 消息队列：目前主流的消息队列如Kafka、RocketMQ设计思想都是利用本地机器的磁盘来进行保存消息队列，其实这样是有一定的弊端的。首先本地空间的磁盘容量有限容易造成消息堆积，导致需要追溯历史数据时无法满足，而只能扩容新节点，成本也比较高、运维难度较大。针对这些问题Apache Pulsar出现在人们的视野中，在Pulsar的架构中，数据计算和数据存储是单独的两个结构。数据计算组件为Broker，其作用和Kafka的Broker类似，用于负载均衡，处理consumer和producer，如果业务上consumer和producer特别的多则可以单独扩展这一层。数据存储组件则为Bookie，Pulsar底层存储使用的是成熟的Apache Bookkeeper存储系统，因此其并没有过多的关注底层存储细节，可以将中心放在计算层的细节和逻辑。现在Kafka也在逐渐向这些方面靠拢，因此说“计算和存储分离”应该是消息队列未来发展的主要方向。

存算分离产品

技术流派

存储作为数据湖的底座，业界有两个技术流派：一是基于分布式文件，二是基于对象存储。

• 基于分布式文件存储的大数据方案：原生 HDFS 大数据方案：主要适用于业务适合文件存储，对 Hadoop 组件兼容要求高，和大数据计算层无缝对接，计算层程序零改造的大数据场景。
• 基于对象存储的大数据方案：适用于业务适合对象存储，需要在对象存储上提供大数据分析能力，且可以无缝上下云，做云端分析或云端数据重建。

华为

华为OceanData

• 问题：存算一体架构在故障恢复和搬迁时都要全量恢复数据，不仅降低了可靠性，也增加了运维工作量和成本，同时迁移扩容时间不可控，需要更多资源冗余来弥补？
• 解决：华为OceanData分布式数据库存算解决方案，在基于存算分离架构上，利用容器的技术把整个数据库的一层做成无状态，真正的数据通过持久化卷的方式存到存储，磁盘故障有存储保障，服务器故障的时候，通过容器K8S的自动编排的技术，快速恢复数据。几个小时的数据重构时间，缩短至分钟级，大大提升系统效率和可靠性。
• 问题：一个几百G数据库down掉之后，花了3个小时和5个相关的工程师去解决，因为还有很多的操作要手工去做没法完全形成自动化。云原生里有个“不可变基础设施”的概念，无状态解耦之后，数据都落在了解耦的存储上，计算部分就可以任意的去漂移。交易型的数据库它的数据规模虽然相对来说不是很大但要求性能和容量都具备一定的扩展性？
• 解决：华为OceanData方案采用了一种云原生的架构，通过容器和企业级存储的结合，可以做到整个计算侧是无状态的，数据库部署在容器里面，当数据库算力不够的时候，实现了算力的横向扩展;磁盘不够了，只需要把存储资源扩展。
• 问题：只有可靠性、扩展性的问题解决后，才能够放手去提升资源利用率。经过估算如果可靠性问题能解决那么计算的利用率能够从10%提升到30%左右，成本将近节省一半，尤其是在机房和耗电能够降低大概60~70%；那为什么之前大家没有去做存算分离这个事情?
• 解决：很多企业也尝试过用这种存算分离的架构，整个性能出现断崖式的下跌，网络是很关键的一环。但是随着网络技术的发展，随着RoCE网络逐渐的成熟，可以通过无损以太网，NVMe协议，远端直接访问存储内存的数据，缩短整个lO路径。在客户场景实测发现，用NoF网络相比于FC网络，性能提升20%~30%，跟服务器的本地盘性能持平。给客户带来直观感觉就是性能没下降，但是可靠性提升了很多。
• 问题：当我把大量数据集中到存储上之后，如果存储的可靠性和存储性能达不到要求，将会成为整个系统的瓶颈？
• 解决：是的，为什么强调是端到端支持 NVMe over Fabric，因为网络虽然用了高速无损以太网RoCE网络，但只是解决了通道的问题，如果前端还是用传统SAS接口，无法解决问题。因此，存储也要端到端支持NVMe ，以及提升存储可靠性的亚健康主动检测，磨损均衡和反磨损均衡等。通过磨损均衡和反磨损均衡防止盘批量故障，同时换盘的动作都是主动告知，主动监测。
• 问题：业界这些厂家在做存算分离的时候，也是要利用存储的一些能力来去解决问题，不管是亚健康还是磨损均衡，因为本地盘上没有亚健康检测，也没有磨损均衡能力，有些客户为保证性能，用NVMe的SSD卡，但是NVMe的SSD卡，很难在服务器上做RAID的，还有存储层的性能隔离也很难在服务器上实现。
• 解决:专业的人干专业的事。整个IT架构中也一样，磁盘数据的管理放在存储上去做，无论从效率还是可靠性肯定是更好的。除了刚才讲的IO性能、磁盘的监测外，存储还可以做很多事情，企业级的存储支持快照备份，容灾的能力，有些开源的工具做整个数据库的备份恢复1TB的数据需要几个小时，效率很低。而借助存储的快照技术，可以大大提升效率。

数据是一个端到端的系统架构的方案，不光要考虑数据库软件自身，还要考虑整个集群管理，包括一些周边的备份容灾，以及整个基础设施的选择。所以华为构筑OceanData这样的一个解决方案出来，把整个数据库端到端的堆栈打通，去减少拼装这些方案的时候遇到的这些问题。更多的是把心思放在业务上，而不是放在怎么去搭建出一套完整的数据库方案出来。

华为OceanStor Pacific作为国内大数据下一代存算分离的解决方案先行者之一，在存储层实现了原生HDFS语义接口的存算分离方案，打破了传统大数据平台计算存储的部署架构。同时率先在存储上支持湖仓融合的新兴数据格式，在下一代存算分离架构下，基于一份数据支持接数据湖、数据仓库同时访问。提供以业务为中心的高弹性大数据计算，以数据为中心的高性能海量存储，用户无感知的原生HDFS和S3兼容能力。OceanStor Pacific不仅算力密度在业界领先30%，而且做到一站式交付、一键式部署，可以有效匹配企业大数据快速迭代发展。

JuiceFS

JuiceFS 是一款开源分布式文件系统，创新地将对象存储作为底层存储介质，实现了存储空间的无限扩展。任何存入 JuiceFS 的文件都会按照特定规则被拆分成固定大小的数据块保存在对象存储，数据块的元数据则保存在 Redis、MySQL、TiKV 等数据库中。同时 JuiceFS 的 Hadoop Java SDK 完全兼容 HDFS API，提供完整的文件系统特性，大数据组件可以无缝从 HDFS 迁移到 JuiceFS。

存算分离最初尝试:

使用对象存储替代HDFS

使用对象存储替代HDFS的优势和痛点分别如下：

• 优势

  • 存储系统服务化
  • 弹性伸缩

• 痛点

  • 存储系统API改变，兼容性也改变，需要在不同组件、不同版本上逐一验证兼容性。
  • 很多对象存储是最终一致性模型，会影响计算过程稳定性和正确性。
  • Listing性能弱。
  • 没有原子的rename，影响任务的稳定性和性能。

JuiceFS大数据存算分离方案

HashData

HashData为了追求极致的弹性和扩展性，计算集群和持久化存储严格实行物理分离：计算集群由类似AWS EC2的虚拟机组成，持久化存储则使用对象存储。

HashData利用云存储作为数据持久存储层，并与计算资源物理上分离、逻辑上集成。由于自身的高可用性和近乎无限的可扩展性，云存储大大简化了数据仓库系统错误恢复、多维度扩缩容、备份恢复等流程，同时使得不同集群间共享同一份数据、统一的数据存储平台成为可能。

• 相比本地化存储，远程访问是否会带来性能上的下降？

  • HashData通过在计算节点和对象存储中间增加缓存层，可以大幅降低访问对象存储的频率，缓解性能下降的问题。
  • 传统的MPP架构数据库存储、计算紧耦合，数据存储在本地系统，存储能力的扩展通过增加集群节点实现，这样就会导致计算资源的浪费，无法匹配业务的发展。
  • HashData使用的是对象存储，独立于计算节点。利用对象存储技术，可以提供近乎无限的扩展能力，避免了传统数据平台基于成本考虑的归档需求和计算成本浪费。
  • 通过测试可以看到，HashData在计算节点和对象存储之间增加缓存层之后，相比MPP架构，几乎没有性能上的损耗，同时计算量可以提升近5倍。

  

• 缓存层设计理念是在元数据集群和对象存储集群之间，适度增加计算资源和缓存层，具体是怎么实现的？

  • HashData的缓存策略采用目前比较流行的LRU算法，来实现热点数据的识别和保留。LRU本质上是一个固定大小的队列，对于需要频繁访问的数据，会放到队列前面；对于不经常访问的数据，会放在后面。
  • 随着队列慢慢的增加，最终经常访问的数据会在最前面，不经常访问的数据会在最后面。
  • 最终，不经常访问的数据会被剔除掉。同时，对于缓存层屏蔽掉了所有远程文件操作。数据库内核在访问对象存储的时候，对远程操作不会有任何感知。

• 缓存的优化对象包括哪些？

  • HashData针对高并发、小文件等场景做了大量的优化，进一步降低系统开销，使远程访问的性能可以达到跟本地几乎完全一样。
  • 针对对象存储，HashData通过批量处理的方式对数据的查改删进行优化，大幅提升了操作效率。
  • 另外，HashData对数据的写和读做了很多的优化。比如企业业务场景上使用大文件比较多，那么我们采用分片上传方式将大文件传输到对象存储上。对于每个上传的文件，HashData经过测试配置了一个最优的分片大小去做分片上传，将文件在对象存储上合并。
  • HashData的缓存系统采用按块缓存，做到了按需下载需要的数据，避免下载整个文件。比如使用缓存系统去读取数据，将每个块设置8M，对于64M的文件会被切分为8个块，如果用户需要的数据分布在其中的一个块内，那么我们数据库在读取数据时只需要取其中一个块即可，不需要把整个数据全都下载下来，这样做到了按需下载。

• 通过网络获取到数据是否会导致网络IO的压力过大？

  • 网络IO压力大有两方面。一方面是对象存储压力过大。另一方面是集群本身随着主机和业务增多会更多地去访问对象存储，由此会带来集群整体和访问对象存储的网络开销越来越大。
  • 对于对象存储压力过大我们通过多bucket方式来解决。将文件分散存储到其他的bucket上以此来分流对象存储上的压力。
  • 对于集群因为业务增多出现网络压力过大，我们采用动态算法让系统根据当前的压力调整发送请求的间隔。再者可以通过调整参数降低集群发送网络请求次数。

• 存储层结构是底层采用对象存储，上层对资源进行分片，保障全数据类型的支持、拓展能力、高可用和高持久，能否举例详细说明？

  • 首先，因为我们通过缓存层，构建了统一的存储层，存储层可以保证所有的计算集群去访问缓存文件，从一定程度上解决了资源孤岛的问题。
  • 此外，对于大量集群访问，HashData会根据计算集群的规模进行分片存储，其他节点可以也同时访问这些文件，互相不会影响。
  • 在底层的存储方面，HashData采用对象存储，支持多集群同时访问一个文件，整个架构能适配更多的云。
  • 同时，对于对象存储，HashData做了大量的优化，包括对存储数据的格式、多线程、动态调整数据包大小等，这些优化都可以对访问存储层带来更高的性能。

• 对象存储相比于HDFS有什么优势？

  • HDFS默认采用三副本，整体成本更高。对象可以采用纠删方法，可以实现更高的利用率。HDFS适合存储大文件，更适合Hadoop的非结构化场景。数仓中小文件的场景很多，不适合HDFS。数仓通常将HDFS作为数据导入的入口，而不是存储的底座。

XSKY

XSKY 基于分布式文件的大数据方案

• 协议兼容性–原生 HDFS 协议：

• 用户和用户组权限兼容性
• 多协议融合互通：支持 NFS、SMB/CIFS、POSIX、FTP、HDFS、S3、CSI

• EC 纠删码：实现冗余和容错的目的。

• 扩展性

• 数据灾备：同步复制和异步复制

**本人博客网站 **IT小神 www.itxiaoshen.com