产品介绍
设计理念
HashData 云数仓是为云原生基础架构平台而设计研发的分析性数据库,其设计理念是将数据库的处理核心进行重构以充分适配云原生基础架构, 从而能够充分发挥云基础设施的各种资源弹性、运维管理以及利用效率上的优势,大幅提高数据库服务在云原生架构下的配置效率,实现计算和存储弹性扩展,按需分配,为客户带来超高的投入产出比。
HashData 云数仓能够提供近乎无限可扩展的数据容量、并发性和分析性能,可以帮助企业整合内部的数据孤岛,轻松共享这些受监管的数据,并执行各种数据分析负载。同时能够跨多个公共云和私有云提供无缝的数据分析体验。作为企业数据分析的核心引擎,为数据仓库、数据湖、数据工程、数据科学、数据应用程序开发和数据共享提供整体的解决方案。
HashData 的愿景是打造一个让更多人能够更轻松地挖掘数据价值的平台,用领先的技术优势消除规划、购买和运维大量基础设施给企业带来的负担,让企业专注于自己的核心业务。加载数据,分析数据,挖掘价值,其他一切交给 HashData!
架构介绍
HashData 云数仓的技术架构如下图所示:
完整的HashData 云数仓分为两个大的模块:管理模块及用户模块,其中管理模块指管理控制台,用户模块指租户集群,包括:元数据服务、计算集服务和数据存储服务。
管理模块
管理模块主要是管理控制平台(Cloudmanager),负责所有元数据集群、计算集群的管理,包括集群创建、启停、资源管理、监控告警等。作为云数仓的重要组件,管理控制台能够对各类云平台资源进行统一管理,整合数据库集群的监控、运维、管理等功能,建立统一的数字化管理、运维平台,实现图形化、自动化操作,达到“所见即所得”的效果,极大地降低了数据仓库集群的运维管理成本,让企业用户能够高效、便捷管理上万节点的数据仓库集群。
服务名称 | 描述 |
---|---|
web_gateway | 接收http服务,分发给其他服务;处理cookie |
account | 账户服务 |
region | 核心服务 redion-console-default:静态界面服务 region-default:核心服务,处理业务逻辑 |
ops | 运维运营平台对接服务,将prometheus和grafana的页面即成提供出去 |
prometheus | 管理控制台监控服务 |
alertmanager | 告警服务;信息源来自于prometheus;进行告警分组 |
notification | 告警邮件、短信服务 |
grafana | 监控展示 |
teleport-proxy | ssh反向连接代理 |
teleport-auth | 堡垒机的鉴权 |
eureka | 服务发现与治理服务 |
config | 存放所有模块的配置信息 |
postgreSQL | 存放account、region(集群状态等信息)、prometheus、notificatin、grafana等服务的数据 |
etcd | teleport-auth数据;存放计算集群状态、catalog集群状态信息、计算集群的数据分布信息 |
用户可以在管理控制台中进行创建/删除、启动/停止、扩容/缩容、升级集群等操作;管理底层的对象存储、基础设施(节点生命周期等);查询和管理数据仓库自身的元数据,如用户、数据库、表、锁等;配置管理ETL任务,编辑、保存SQL文本等。
用户模块
HashData云数仓用户模块主要分为三个层次:元数据服务层、计算层以及数据存储层,每层之间完全解藕。
- 元数据服务层负责整体集群的的元数据管理和事务管理;
- 计算层主要是负责具体的接收用户查询请求、查询协调、查询调优和计算工作;
- 数据存储层提供持久化数据服务,计算集群所有节点都可以访问数据存储层。
元数据服务层
元数据服务层包括:调度层、服务层、元数据持久层,架构和各层功能如下:
层级 |
功能描述 |
---|---|
调度层 | 提供服务发现: 新建计算集群后,由调度层分配服务节点与计算集群的主节点进行连接,进行后续的元数据访 问; 如果计算集群与服务节点的连接断开,需要重新建立连接时,由调度层决定该计算集群应该访 问哪个服务节点; 调度层能够监控服务层和计算层的服务状态,当有节点宕机、服务进程宕或不可用等情况下, 调度层将信息反馈给管理组件; 提供负载均衡: 调度层集群中的每个节点都存有等量数据,客户端连接时将自动进行节点分配,保证节点负载 均衡(多活架构); 调度层作为计算层与元数据层之间的桥梁,统筹协调对主节点与服务层之间的连接,保证连接 的负载均衡; |
服务层 | 服务层由一组服务节点组成,每个服务节点其实是无状态的服务进程,负责接收计算集群发送 过来的元数据请求。 |
元数据持久层 | 提供元数据存储服务; 提供元数据多副本及高可用服务。 |
元数据服务层的部署架构
元数据服务层提供计算集群对数据库元数据的访问,是元数据访问的入口。调度层其实就是一个提供服务发现的etcd集群,默认配置是三个物理节点以保证高可用性。服务节点其实是无状态的进程,所以我们可以在任意空闲的物理服务器上启动元数据服务进程。元数据持久层是通过FoundationDB来实现。
调度层决定每个计算集群应该访问哪个元数据服务节点。所有跟系统持久化状态的信息都保存在元数据存储层中,元数据服务层只是缓存热点元数据信息在内存中,同时维护一些临时状态。当元数据服务节点失败了,它保存在内存的信息全部丢失,但是不会影响系统信息的全局一致性,因为元数据服务节点是没有状态的,系统会启动一个全新的元数据服务节点替换失败的节点,并从底层的元数据存储层重新加载需要的状态信息。系统通过调度层实现元数据的负载均衡。
元数据服务的高可用机制
整个元数据服务的架构设计思想都是物理上解耦、逻辑上集成。整个元数据服务分成三层:调度层、元数据服务层(无状态)以及元数据持久层。调度层是etcd集群,通过分布式数据库的技术确保集群的高可用性;服务层是无状态的,所以自然不存在高可用的问题,一个服务节点失败了,我们只要启动一个全新的服务节点即可;持久化层FoundationDB集群,同样通过分布式数据库的技术确保集群的高可用性。只要每一层本身是高可用的,整个元数据服务就是高可用的。管理组件会持续监控每一层上失败的节点,在每一层自身确保高可用的同时,管理组件会将新的空闲节点添加到对应的层中替换失败的节点,确保该层的处理能力没有下降。每一层根据需要提供的安全系数来调整部署的方式和规模。
计算层
计算层会包含多个独立的计算集群,共享存储服务和元数据服务,从共享服务中加载和查询数据,每个集群的资源和操作都是独立的。从而可以实现高度的敏捷性。每个计算集群包含两种逻辑角色:主节点(Master)、计算节点(Segment),计算集群都会由一个主节点和多个计算节点组成,逻辑结构如下图所示:
角色 |
功能描述 |
---|---|
主节点(Master) | 负责接收用户连接、进行认证授权、SQL解析、生成查询计划、分发查询计划给各个 计算节点(QD)、汇总查询结果并返回给用户,同时参与查询计划的QE生命周期管 理; 主节点的本地盘只做元数据的缓存使用,所有的元数据请求及持久化操作,都需要与 元数据服务进行交互,即所有的元数据都放在元数据持久层。 |
计算节点(Segment) | 充当QE的角色,是集群中的计算单元,根据主节点分发的执行计划进行SQL运算,并 将执行结果反馈给主节点; 计算节点不作应用数据持久化存储,根据需求从对象存储缓存所需数据。 |
计算层可以使用物理服务器、虚拟服务器或者容器部署,部署时每个物理服务器配置多少个Segment实例、操作系统参数、数据库参数等都可以通过管理控制台来实现。用户可以按需启动、暂停或者扩容集群,无需停机或者暂停当前的工作负载,新提交的查询自动在调整后的新集群运行。可以在同一个共享存储的不同计算集群上独立运行不同的任务,这样就实现了基于同一份数据并行运行大吞吐量工作负载,可以满足用户低延迟、快速响应的需求。可以在批量加载数据的表上进行数据科学操作,还能同时为用户仪表盘提供亚秒级的响应时间。最后,由于存在多个集群,可以在不停机或者对性能无影响的情况下,对单个集群进行扩缩容操作,提供了真正的弹性,计算节点数可以在2个和1024个之间任意伸缩。
数据分布式算法
HashData 云数仓采用的基于一致性哈希算法的数据分布策略, 其基本原理如下图所示:
如上图所示,一致性哈希算法会在根据每条记录的内容计算出Hash值,然后把Hash值映射到一个环上的一点,然后将这个环分成若干个连续的区间,每个区间对应一个计算节点。落到同一个区间上的点(对应一条记录)都存储在同一个计算节点上面。这种算法最大的优点在于,当新增一个节点的时候,只有一小部分数据需要转移。
对比传统采用MPP架构的数据库,虽然一些产品也采取了一致性哈希的数据分布策略,但由于还是经典的完全无共享架构,增删节点的过程中还是会涉及到将一部分数据从一个节点迁移到另外一个节点,只不过需要迁移的数据量减少了。而 HashData 云数仓是共享存储架构的。在上图所示的例子中,开始的时候集群包含两个计算节点,并将数据分成了六个切片。节点1负责数据切片1、2、3,节点2负责数据切片4、5、6。增加一个新的节点3之后,数据并不需要发生任何迁移。节点添加完成后,新的查询执行的时候,节点1负责数据切片1、2,节点2负责数据切片4、5,新增的节点3负责数据切片3、6,但数据切片3、6不需要从节点1、2的缓存中抓取,而是直接从对象存储访问,然后在节点3本地缓存,从而做到秒级扩容。
计算集群高可用
当计算集群中某一台物理机发生故障后,管理组件能够感知到该集群有一台服务器宕机了,用户可以通过管理控制台配置不同的故障恢复策略。一种是选择一个空闲的物理节点加入到计算集群,替换发生故障的物理节点。由于计算节点是没有状态的,所以整个替换过程是非常迅速的。
另外一种,特别是当没有空闲的物理节点的情况下,计算集群执行一个类似缩容的操作将发生故障的物理节点踢出可用计算节点列表中,这样新来的查询就按照新的可用计算节点列表来生成查询计划。在生成查询计划的过程中,每个计算节点负责的数据块(包括后续的计算分析)将会按照一致性哈希的策略重新计算,等价于原来由发生故障节点负责的任务均匀打散分配给其它剩余正常工作的计算节点。这个过程完全是按需的,动态调整的。对于第二种策略,后续发生故障的节点恢复了,只需要执行一个扩容的操作就可以将修复后的计算节点加入到可用计算节点列表中,这样新的查询就可以用上这个添加回来的节点。用户可以根据具体情况选择不同的策略。
当计算节点失败时,在底层的IaaS资源是充足的情况下,系统会通过底层的IaaS提供的API按照提前做好的镜像启动一个新的虚拟机,替换发生故障的计算节点。从而确保一个计算节点发生故障的时候,系统能够及时启动新的虚拟机接替故障节点。而虚拟机所在的物理机发生故障的情况,IaaS层会自动处理,上层的 HashData 云数仓是无感知的。
在节点发生故障后会导致每个计算节点负责的数据块(包括后续的计算分析)按照一致性哈希的策略重新映射(哪个正常工作的节点负责哪个数据块)的过程完全是按需的,只针对当前准备要执行的SQL语句,而不是全量的数据。所以每台物理服务器本地的磁盘容量大小对发生故障后恢复的效率没有任何影响。
计算集群数据缓存
对象存储服务理论上提供了一个无限空间的存储系统。但是其性能会低于云盘或者物理硬盘,为了提高计算集群的运行效率,HashData 云数仓使用本地硬盘作为对象存储服务的缓存,用户保存热点数据,从而减少直接访问对象存储带来的延迟和API调用开销,从而提升系统整体的 IO 性能。整体数据缓存方案实现跨集群、跨数据中心以及跨云中心的数据访问,并保证数据强一致性,用户可灵活合理规划生产数据与实验数据的部署和使用。
一般来说缓存占到热数据的50%左右、全量数据的5%~10%左右,系统的性能就跟完全使用本地盘就非常接近了。当然,本地缓存的容量取决于本地磁盘的容量。本地缓存主要有两种级别的策略:最底层的是经典的LRU算法,新数据要缓存的时候,发现缓存空间不足,就把老数据踢掉;上层的策略是,根据数据库当前正在执行的SQL语句操作决定。
例如,ANALYZE语句需要访问的数据是不缓存的,因为ANALYZE只是为了更新统计信息而已,下次什么时候访问这张表的数据还是未知的。INSERT INTO SELECT FROM这种语句访问到的数据也是不缓存的,因为后续访问的数据一般是INTO的目标表,而不是FROM的源表。可以通过估算热点数据从而确定本地缓存系统的大小,来实现更高的查询性能。
数据存储层
数据存储层采用对象存储来实现,提供统一的用户数据持久化,并以自身的架构优势提供数据访问安全、高可用等功能。HashData采用标准的对象存储访问协议可以对接各类对象存储产品。
HashData 云数据仓库围绕对象存储和抽象服务构建,支持多种对象存储。
- 在公有云场景下,对象存储跟云虚拟块存储服务有着很大的差别:对象存储是按照实际的使用量来收费的,按需收费,并且对象存储单位容量的存储成本,也大幅低于类似EBS的云盘。按需付费和低单位容量存储成本,使得基于对象存储的云端数据仓库的使用成本大幅降低。
- 在私有云环境中,对象存储集群的单位建设成本远低于块存储集群,对服务器和磁盘的配置要求要低很多,另外,对象存储集群自身支持纠删码机制,比Hadoop集群的多副本更节省存储空间。此外 HashData 云数仓还支持独有的压缩算法,可进一步提升2~3倍的存储空间利用率。
产品特性
数据仓库服务
“加载数据,分析数据,其它交给我们”。 HashData 云数仓可以让企业用户可以在几分中内启动一个包含几十个甚至上百个节点的数据仓库集群,数据加载后马上可以开始数据分析任务。而数据库本身承担了所有的集群资源配置、数据备份、监控审计、错误恢复、高可用和升级等纷繁复杂、极易出错的运维工作,让用户专注于业务分析。
灵活高效的业务支持
共享存储的不同计算集群上可以独立运行不同的任务,这样就实现了基于同一份数据可以并行运行大吞吐量工作负载,以满足用户低延迟、快速响应的需求;同时用户可以在批量加载数据的表上进行数据科学操作;还能同时为用户仪表盘提供亚秒级响应时间的数据支持。
多维度弹性
HashData 云数仓可以独立的扩展计算和存储,还可以按需增加或减少吞吐量。云原生架构可以通过扩展存储以保存日益增长的数据量,可以在用户数量增加时通过增加计算集群的数量以达到高吞吐量,还可以通过增加计算节点数量以实现快速响应,从而实现吞吐量、数据容量和响应时间这三个纬度上的完全弹性。
高可用和低成本
HashData 云数仓的整体架构的设计思想都是物理上解耦、逻辑上集成,所有的功能组件全都是采用无单点故障设计,包括管理控制台、元数据服务层、计算层和数据存储层都实现了无单点故障和自动故障恢复,从而保证整个数据库服务能够实现高可用、高容错。HashData 云数仓可以部署在主流公有云和私有云环境,无论是哪种部署方式,都可以实现故障自愈的高可用,同时也可以按需的关闭或者挂起暂时不用的数据库,以控制成本。
接近零停机时间
HashData 云数仓通过共享数据存储的架构设计,利用一致性Hash分布方案,能够在新建计算集群、对单个集群进行扩容或者缩容操作时,完全避免数据迁移,集群维护操作都不需要停机,用户可以正常使用数据库。
优化的硬件配置
HashData 云数仓可以根据业务的实际需求选择最合理的计算和存储资源的配置关系,这意味着可以用小型计算集群处理数PB级数据,或者在较小的数据集上运行强大的计算集群,从而更好的满足不同业务类型的数据处理需求,大幅提高硬件资源利用效率。
兼容开源
HashData 云数仓在查询接口(包括使用习惯)以及底层数据文件存储格式和访问协议方面,保持与开源PostgreSQL 和 Greenplum 完全兼容。用户可以充分利用已有的SQL技能和在BI和ETL工具方面的投入,降低业务迁移成本。
完善的数据库能力
完全支持UTF-8、GBK等编码格式,支持多租户管理,支持关系数据模型,支持标准SQL语法。支持行、列两种存储引擎,支持单表和多表并发IUD(Insert、Update、Delete),支持行级锁。满足事务数据强一致性,支持表数据并发增删改。支持主流的数据类型,提供数据库、表、索引、视图、存储过程(语法类似PL/SQL)、自定义函数等常用数据库对象的创建、修改和删除操作。支持数据库用户的创建、删除操作,以及用户权限的分配与回收。支持完善的分区管理功能,支持主流的JDBC、ODBC等接口。