云原生数仓九大误区，你知道多少？

纵观数据库的发展历史，传统关系型数据库最早期主要针对交易处理为主要应用设计的，对于数据仓库分析统计类的应用，也都运行在这类数据库上，比如传统的Oracle、DB2等。这一阶段， 一种架构支持多类应用 (One Size Fits All）。

随着基础设施的演进和业务需求的激增，逐步引发数据处理架构的变革，行业的技术思路由“一种架构支持所有应用”转变成“多种架构支持多类应用”，以Hadoop、MPP数据库为代表的基于分布式架构的计算和存储平台，大大拓展了系统可处理的数据规模和存储空间。以Greenplum、Vertica 、Gbase为代表的基于分布式架构的MPP数据库（shared-nothing），大大拓展了系统可处理的数据规模和存储空间。因为采用无共享的分布式架构，计算和存储是紧耦合的，如果要做扩容，计算和存储必须同时扩，数据的迁移成本使可扩展性受到很大限制，所以一般只能到一两百个节点的规模。

伴随着数据体量的持续增长，业务复杂度的不断提升，上一代MPP数据仓库平台，在资源弹性、成本等方面已经很难适应业务需求。同时随着云计算的发展，云原生概念的兴起，云原生数据库便应运而生，再一次推动了数据库行业的产品创新与变革。

HashData作为一款支持高性能，高并发的云原生数据仓库产品，采用新一代存算分离的架构，灵活扩展的计算层和分布式的存储层，支持多云厂商及私有化环境的部署，集成超高的查询性能以及海量数据的综合处理能力，为企业提供云原生的数据仓库服务。

如图所示，HashData云数据仓库最上层是独立的元数据服务层，提供元数据存储和查询服务，中间是无状态计算层，由多个计算集群组成的数据仓库集群，最下层是软件定义存储层，使用云平台提供的对象存储服务，如AWS的S3、Azure的Blob Storage、阿里的OSS或者用户自己搭建的对象存储集群。

HashData云数据仓库的每一个数据仓库集群会有一个分布式缓存服务，用来缓存该集群需要访问的对象存储的数据，从而减少直接访问对象存储带来的延迟和API调用开销，整体解决方案实现跨集群、跨数据中心以及跨云中心的数据访问，并保证数据强一致性，用户可灵活合理规划生产数据与实验数据的部署和使用。

HashData云数据仓库关键技术特性：

• 创建数据仓库无感知

  HashData云数据仓库利用虚拟化技术，可以在几分钟内创建启动一个包含几个到几十个甚至上百个节点的数据仓库集群，数据加载后马上可以开始数据分析任务，目前是市场上创建集群最快的数据仓库平台。

• 计算存储物理分离

  在确保计算单元与数据存储有着明确的逻辑对应关系和集群I/O吞吐不下降的前提下，通过设计精妙的缓存策略，让客户充分享受计算存储分离带来的一系列便利，包括高可用、多维度弹性、高扩展性等。

• 对象存储为数据持久化存储

  HashData云数据仓库存储层使用对象存储，在大量优化对象存储访问和高效数据缓存技术的前提下，确保性能不会出现明显的下降。利用对象存储的元数据实现分布式事务的ACID性，单独封装的逻辑层实现immutable文件系统的写操作的原子性和业务回滚特性。

• 多集群共享统一存储架构

  HashData云数据仓库数据是shared-storage的，任何一个计算集群可以访问对象存储中的任何一份数据。不仅可以安全、轻松地实现不同集群之间的数据共享，同时避免了数据复制与数据移动的延迟和复杂性；其次，可以通过横向增加集群数量的方式，提升数据并发访问度；再次，支持多集群之间的数据强一致性，即便数据在某个计算集群上不断更新，也始终可以查看最新的数据；最后，企业能够安全管理与外部的协作以及跨组织共享数据。

• 独立元数据服务

  独立元数据服务是完全创新性的云原生架构，元数据状态从计算节点中消除，使得计算节点变得完全没有状态，新型的shared storage的MPP架构（与传统的shared-nothing架构对应）。尽管每个计算节点都是没有状态的，但在增加节点数量时候，它们能够访问到系统中任何数据和任何元数据。

• HashData云原生数据库将元数据、计算和存储三者分离，高效响应高并发复杂查询，体系架构随业务需求动态伸缩，在提供高性能数据仓库服务的同时实现资源的最优配置。

  在学习和了解云原生数据仓库过程中，很多人经常遇到存算分离架构下集群的规模调整和多集群数量调整的问题，本文以HashData云数仓为例，就学习和使用过程中常见的几大误区逐一进行解析。

误区1:单个集群创建之后无法修改大小？

单个集群在任何时候都可以调整大小，即便可能有正在运行的查询和排队等待的其他查询，也可以进行调整。HashData的存算分离架构，数据共享存储，避免重新物理分布，可以实现秒级扩缩容。 

如上图所示，一个4节点规模的集群通过扩容为6节点规模。单个集群的大小可以在1和1024之间进行调整。

当集群中某个计算节点异常下线，只是从6节点规模调整为5节点规模，计算节点与数据块的对应关系动态调整不影响整个集群的正常运行。本例展示了在计算节点异常情况下的自愈高可用，集群的缩容机制与节点异常下线机制完全一致。

误区2:只有调整单个集群的规模大小才可以提升并发？

调整单个集群规模大小和调整多集群中的集群数量有重要区别，对性能或并发性都会有不同的影响。

（a）单个集群的规模变大可以提高性能，在大多数情况下，查询与集群大小成线性关系，尤其是对于更大、更复杂的查询，提升查询效率，在一定程度上可能会增加并发。

（b）多集群通过调整每个集群的负载，可以有效提高并发性，用于应对大量并发请求的场景，解决排队等待的性能问题。

 

如图所示，左侧可能比右侧更快地处理任何单个查询。但是，如果同时发出查询1和查询2，则左侧单个集群的查询2很可能会排队等待。多集群中的每个集群都可以并行执行查询1和查询2，有效提高并发性。

误区3:多集群中每个集群的规模必须保持一致

当部署多集群仓库时，单个集群无须使用完全相同数量的节点。多集群环境下，具有不同节点数的计算集群中可以正常并行启动。

 

在多集群环境下，每个集群的规模大小可以根据承载的业务需求自行设置，不同节点数的集群可以正常并行运行。

误区4:增加集群规模大小会提高当前运行缓慢的查询性能

单个集群的规模大小可以随时调整（动态扩缩容），但不会中断或影响当前运行的查询。通过扩容额外新增的资源不会影响任何已经处于运行状态的查询，新增资源被完全配置完成后，才可以提供给排队等待或新提交的查询请求使用。

 

如上图所示，当查询1仍在执行时，可以动态调整集群的大小，从4节点到6节点。规模调整不会中断或影响查询1的执行，查询1继续由最初的四个节点提供服务。如果查询需要完全利用6个节点，则必须在新增资源完成配置后，新发起的执行任务才会利用上新增资源。

误区5:如果当前集群有任务运行，新发起查询会一直处于排队状态

同时处理的查询数量取决于每个查询的大小和复杂性。提交查询时，集群会通过执行计划计算并保留处理每个查询所需的计算资源。只有当集群没有足够的剩余资源来处理查询时，查询才会排队，等待其他正在运行的查询完成后释放出可用的资源。

查询过程中有许多因素可能会对性能产生影响，在复杂的多用户环境中，大部分查询可能会因为并发问题而不是复杂性而处于等待状态，可以通过创建多个集群来提升并发，避免查询排队。

如图所示，如果查询1和查询2都有足够的资源，那么集群就可以并行执行这两个查询，只有分配不到足够的资源的情况下，才会处于排队状态等待资源释放。可以通过使用多集群来提升并发，避免查询排队。

误区6:对于简单查询可以只使用单独集群中的少量计算节点

在单个集群中所有计算节点都统一启动和配置。对于资源消耗不高的简单查询，可能只需要一个计算节点的资源就足够了，但是在生成执行计划时，还是会下发给所有的计算单元，无法单独只使用一个或几个计算节点。

 

在正常运行的集群中，所有的节点都会参与到任务执行。如上图右侧所示，无法只单独使用4个正常节点集群中的两个节点。

误区7:通过增加集群的大小，一定可以提升加载性能

单纯增加集群的规模大小，并不能保证在任何场景下都能够有效提升数据加载性能。加载文件的数量和每个文件的大小对数据加载性能的影响，远远大于集群规模大小对加载性能的影响。使用更大规模的集群将消耗更多的资源，有可能不会带来任何加载性能提升。

如果同时接收多个文件，采用多集群的方式，数据加载速度可能会更快。当加载大文件时，因为数据量很大，一次读取一个大文件，建议优先采用规模较大的集群做并行加载，能够有效提升大文件预读取的速度。

误区8:一个查询任务可以同时由多个集群处理

一个查询只能由一个集群执行。在多集群环境下，查询可能会指派给其中的一个集群执行。单个集群是由N个计算节点组成的集合，这些节点需要统一配置并执行查询，单集群在执行任务时，无法调用其他集群的计算节点资源。

前一个查询1只能由多集群中的某一个集群执行，即使它可能需要更多资源来实现最佳处理，也无法为同一个查询跨集群分配其他节点。

误区9:多集群环境下集群数量越多，复杂查询的效率越高

多集群有助于并行处理多个查询。但是一个查询总是在一个仓库中处理，对查询性能产生影响的是单个集群的规模大小，而不是集群的数量。单个集群的规模越大，对于复杂查询场景越具有优势。在这种情况下，多集群环境下集群数量的多少并不重要。

 

对于查询1的执行，有两个大小相同集群的多集群环境并不重要。查询仍将分配给其中一个单独的集群。