共计 2559 个字符，预计需要花费 7 分钟才能阅读完成。
高可用是数据库系统的根本需要，也是数据库技术实现的难点之一。
高可用不仅要求数据库在失常的场景下不间断的提供稳固服务，而且须要可能在呈现故障的状况下疾速复原并迅速提供服务，使用户难以感知到异样，保障业务的连续性。
作为一款云原生分布式数据仓库，HashData 在传统架构的 MPP 数据库根底上，对存储层、计算层、元数据等多方面进行了改良和优化，进一步晋升零碎的可用性。相比传统 MPP 架构的数据库，HashData 可能提供靠近“零停机”的服务，大幅升高数据库运维老本。
数据高可用
传统架构的 MPP 数据库，计算和存储是紧耦合的，用户数据和元数据都存储在本地磁盘。当零碎呈现故障时，传统架构的 MPP 数据库次要采纳多个正本的形式，来保证系统的可用性。为确保数据库在异样运行过程中能及时从主节点切换到备节点，传统架构的 MPP 数据库会通过 WAL replication 的形式，将 xlog 从主节点复制到备用节点。
HashData 云原生数据库采纳“存算拆散”的架构，架构上分为三个档次，顺次是元数据服务层、计算层以及数据存储层，每层之间齐全解耦。长久化数据由数据存储层提供，两头的计算层则实现了齐全无状态化，并且可能独立地扩容，很大水平上解决了传统 MPP 架构的许多局限。
HashData 的共享存储层采纳对象存储技术，用于保留表数据、长期数据等各类用户数据和后果数据，供所有计算集群拜访。
借助对象存储，HashData 能够提供近乎有限扩大能力，同时通过混合存储、压缩算法、Bucket 等多种优化技术，实现共享存储 IO 能力隔离和流量管制，保障了数据的高效拜访。
为进步拜访性能，HashData 在共享存储上，数据分片保留在不同的文件，供计算集群各节点并行拜访。分片数量在元数据集群创立时设定，个别依照计算集群最大规模设定数据分片数量（2 的幂次方），将每张表的数据依照 Hash 或 random 算法均匀分布到不同数据分片存储。
得益于存算拆散的架构，HashData 通过一致性哈希算法，将每个计算节点对应一个或多个数据分片，计算节点平均存储（缓存）、计算对应数据分片，防止了数据从新逻辑分组和从新物理散布，能够实现集群的秒级主动扩缩容。
利用高可用
数据高可用并不意味着利用高可用，因为数据高可用只是确保数据不会失落，然而是否对外提供数据库服务则是另一个问题。
传统架构的 MPP 数据库在运行时，通常会引入监控机制或者故障检测机制。当发现零碎产生故障时，须要立刻进行主从切换。
切换的形式个别有两种：一种是手动切换，须要 DBA 的参加，反应时间上无奈失去保障。
另一个计划是主动切换，由程序去监控数据库的衰弱状态，在检测到故障之后，程序主动执行切换。
如上图所示，目前较为常见形式是在主节点和备节点之外建设 monitor 节点。当 monitor 节点检测到 primary 产生故障后，就会把 Secondary 节点切换成主节点。
这样做的代价是，首先要确保 monitor 节点自身的高可用。其次，备节点切换成主节点后，部署该节点的机器上可能会有多个主节点在同时运行，对系统性能造成影响。同时，新节点的数据恢复工夫个别比拟长，运维压力绝对较大。
另外，如果一个数据节点只有一个从 / 备节点，当产生主从 / 备切换后，该节点处于单点状态，不再具备高可用性。如若在产生故障后依然要求零碎放弃高可用，还必须引入新的从 / 备节点。
与传统架构的 MPP 数据库相比，HashData 云数仓能够物理主机部署或者云环境部署，无论是哪种部署形式，都能够实现故障自愈的高可用。
为解决数据同步的问题，HashData 云数仓将数据存储在共享存储内，计算节点与数据块的对应关系能够实现动静调整，不波及到数据的搬迁，也不存在备用节点，因此可能实现分钟级新节点复原，整个过程不须要任何的人工干预。
面对企业一劳永逸的数据利用和治理需要，HashData 提供了治理组件 Cloudmanager，通过对各类云平台资源的对立治理，整合数据库集群的监控、运维、治理等性能，建设对立的数字化治理运维平台，实现图形化、自动化操作，达到“所见即所得”的成果，极大地升高了数据仓库集群的运维治理老本。
不同于开源数据库监控管理工具，Cloudmanager 既能够提供数据库的根底治理监控，同时又能实现对数据库集群节点的弹性扩容、缩容，加强集群的计算能力与可用性。
元数据高可用
传统 MPP 架构数据库用户数据和元数据是紧耦合的，在减少数据节点进行扩容的同时，也复制一份了元数据。此时数据库系统有多份元数据须要同步，同步元数据也会减少零碎开销和复杂性。
在应用过程中，随着数据量的增长，传统 MPP 架构数据库每个集群的数据都保留在计算节点本地磁盘，集群之间的数据无奈做到无效共享，造成“数据孤岛”景象。同时，大量数据拷贝操作，造成数据重大冗余。
HashData 元数据服务层是独立存储的，分成三个档次：调度层、无状态服务层和长久化存储层。
调度层次要解决两类问题。第一是帮忙计算集群去找到元数据节点。调度层须要把元数据节点以及它的角色公布到 ETCD，而后计算集群通过订阅 ETCD 上这些角色地位的变更信息，它们能够主动地去找到更新的 catalog，为不同的角色提供了不同的服务。
计算集群在计算的应用层来通过服务发现找到服务对象，尽可能地防止所有的节点去拜访同一个 catalog。
调度层还具备服务负载平衡的性能。调度层在 catalog 上会同时就一个角色注册多个入口，又能够容许计算机去通过 catalog 推送给调度层的负载状况，防止某些 catalog 呈现热点。
元数据服务层为所有计算集群提供对立的元数据管理服务，保障多个计算集群面对对立的数据视图，进行一致性拜访。同时，用户能够通过云管平台实现超大规模的元数据集群操作。
长久化存储层应用的是 FoundationDB，这款由苹果公司开源的数据库，通过大规模的商用验证，具备高度可用性。其最有名的两个利用场景是反对 iCloud 云服务和 Snowflake 的元数据服务。
因为采纳云原生架构，HashData 云数仓多个集群共享对立的元数据、对立的数据存储，集群间不竞争 CPU、内存和 IO 资源，能够依据业务需要有限地创立集群。为了进步并发数量，只须要减少计算集群，来满足弹性、高并发的要求，零碎可用性显著减少，同时进一步升高性能开销。
