HashData 数据仓库

原文链接

产品试用

自创立之日起,酷克数据一直致力于降低企业进行大数据分析的门槛,推动数据民主化。今天,我们朝这个目标迈出了第一步:酷克数据在青云QingCloud上推出基于PostgreSQL和Greenplum Database的SQL-on-Cloud解决方案--HashData数据仓库。利用HashData数据仓库,企业用户可以随时随地用标准的SQL客户端和BI工具对海量数据进行极速分析,轻松把握商业趋势,及时应对各种变化。

什么是HashData数据仓库

HashData数据仓库是一个高性能、完全托管的PB级数据仓库服务,让企业用户能够更轻松地分析海量数据。通过使用HashData,企业用户无需购买、配置和管理庞大的服务器集群,按使用量付费,没有任何前期投入,使得数据存储和分析的成本不到传统解决方案的十分之一。另外,HashData数据仓库兼容标准的JDBC和ODBC,无缝集成企业内部已有的ETL和BI工具。这意味着HashData数据仓库使用起来跟部署在企业内部数据中心的传统数据仓库一样自然方便。

HashData数据仓库的优势

完全托管,快速上手

通过使用HashData云服务,企业用户可以在几分钟内创建启动一个包含几个到几十个甚至上百个节点(根据业务需求)的数据仓库集群,数据加载后马上可以开始数据分析任务。随着业务负载的变化,用户还可以动态地对数据仓库集群进行纵向伸缩(scale up and down)和横向伸缩(scale in and out)。同时,由于是完全托管的云服务,HashData数据仓库承担了所有的集群资源配置、数据备份、持续监控、网络迁移、错误恢复、高可用和升级等纷繁复杂、极易出错的运维工作,让用户专注于业务分析上面。

为数据仓库而优化的架构

大规模并行处理(MPP)架构:基于企业级PostgreSQL数据库和MPP架构的分布式数据库Greenplum Database,HashData数据仓库通过将数据切片分布到各个计算节点后并行处理来解决海量数据分析的难题。每个HashData数据仓库集群由一个称为Master节点的主节点和多个称为Segment节点的计算节点组成。主节点和每个计算节点都有自己独立的CPU,内存和外部存储。主节点负责接收客户端的请求,生成查询计划,并将计划下发到每个计算节点,协调查询计划的完成,最后汇总查询结果返回给客户端。计算节点负责数据的存储以及查询计划的执行。计算节点之间是没有任何共享依赖的(shared nothing)。查询在每个计算节点上面并行执行,大大提升了查询的效率。

列式存储:HashData数据仓库提供了列式的存储策略。由于数据仓库中的大部分查询只涉及整表中的部分字段,相比于行式存储需要加载整表的数据,列式存储只需要加载某几列的数据,磁盘的IO及内存的消耗都显著减小。同时,HashData数据仓库还支持按列数据压缩。由于同列的数据类型相同、甚至有很多值也相同,按列的压缩比会非常高。这大大减少磁盘占用空间、读写IO和内存占用空间,并提高了查询的性能。

大表分区:MPP架构实现了对表数据的横向物理切分,而表分区则是对表数据的纵向逻辑切分,将一张顶层(父)大表根据约束条件分成一层或多层子表,每一层包含多张子表。HashData数据仓库支持基于数值范围(如日期或价格)、列表包含的数值(如销售地区或产品线)以及两者组合的分区策略。当查询优化器能够利用查询语句中的过滤条件(与分区表的约束条件进行匹配)避免大部分分区扫描的时候,查询性能将得到大幅的提升。

互联互通,拥抱开源

HashData数据仓库服务实现了多种途径将存放在青云QingCloud上面的数据加载到数据仓库中以供分析。对于传统的没有使用云的用户,只需要先将数据文件上传到青云QingCloud上面,同样可以使用HashData数据仓库来分析海量数据。

从QingStor对象存储中加载数据:传统的用户可以将数据文件上传到青云QingCloud的对象存储服务QingStor上,然后利用HashData提供的命令将QingStor中的数据并行加载到数据仓库中。

从Hadoop中加载数据:青云QingCloud提供了基于Hadoop框架的大数据处理服务。经过大数据平台加工后存放在HDFS上的数据可以通过HashData数据仓库的SQL语句直接加载到数据仓库中。

其它数据源:青云QingCloud提供了很多数据服务,如关系型数据库MySQL和PostgreSQL,NoSQL数据库MongoDB,缓存服务Redis,消息服务Kafka,以及服务器本身。在后续版本开发中,HashData会逐步实现相应的访问协议从这些服务将数据加载到数据仓库中。

为了充分利用云平台的特性,HashData数据仓库在PostgreSQL和Greenplum Database的基础上对系统架构和运行实现进行了深度的优化,但查询接口(甚至是使用习惯)以及底层数据文件存储格式和访问协议保持与开源版本的PostgreSQL和Greenplum Database一致。即便是那些为青云QingCloud数据服务而开发的访问协议代码也将陆续开源。所以,使用HashData数据仓库完全没有数据绑架的风险。

丰富的分析功能

作为企业级的数据库和数据仓库产品,PostgreSQL和Greenplum Database提供了丰富的分析功能。HashData数据仓库在继承这些功能的同时,并结合云平台的特性进行了调整和改进。

SQL: HashData数据仓库实现了ANSI SQL 2008标准和2003 OLAP扩展,支持标准的JDBC和ODBC接口。业界常用的ETL和BI工具都可以支持HashData数据仓库作为分析引擎。

用户自定义分析:通过支持用户自定义数据处理函数,HashData数据仓库大大扩展了自身的分析能力。支持的语言包括PL/Pgsql,PL/C,PL/Python,PL/Java和PL/R。

机器学习:HashData数据仓库原生支持Apache MADlib,一个开源的,基于SQL的in-database机器学习库。Apache MADlib基本包含了所有常见的机器学习方法。

其它:全文检索和地理信息处理是很重要的分析功能。PostgreSQL社区提供了相应的扩展和项目,但这些功能模块现在只支持单机版的执行引擎。HashData数据仓库计划在未来的版本中提供基于这些项目的并行全文检索和地理信息处理功能。

总结

上面讨论了很多HashData数据仓库的技术功能,但如同酷克数据的公司使命,HashData数据仓库云服务给企业带来的真正价值在于,它降低了企业进行大数据分析的技术门槛,消除了规划、购买和运维大量基础设施给企业带来的负担,让企业专注于自己的核心业务上面。加载数据,分析数据,挖掘价值,其他一切交给HashData!

Apache HAWQ 的可扩展性与其设计哲学

Apache HAWQ 的可扩展性与其设计哲学

Apache HAWQ 作为一款先进的SQL-On-Hadoop开源分布式数据库产品,其代码基础源自著名的分布式数据库Greenplum Database (GPDB)。在设计之初,高可扩展性(Scalability)即成为HAWQ的一个重要的设计目标。因此HAWQ在架构与实现上均与GPDB有着明显的不同。这些不同点反应了HAWQ对高可扩展性的追求。本文将介绍这些不同点与其背后的设计哲学。

HAWQ架构简介

HAWQ是一款基于massively parallel processing (MPP)架构的分布式数据库。HAWQ由一个master节点,一个可选的standby节点和多个计算节点(segment)组成。其中master节点负责接收用户的查询请求,生成查询计划。然后master节点会指挥多个计算节点执行查询计划,最后将查询结果返回给用户。

无状态的计算节点

从HAWQ的架构可以大概看出,作为计算节点,HAWQ的可扩展性与segment的设计实现密不可分。为了提高HAWQ的可扩展性,HAWQ的计算节点被设计成无状态的节点。GPDB的计算节点存储了大量的状态信息,其中包括用户的配置选项和事务的状态等等。维护多个节点间状态的一致性成为影响可扩展性的重要原因。HAWQ的所有状态信息统统保存在master节点,在执行查询计划的时候,状态信息随着查询计划一并分发到计算节点。无状态计算节点的设计使得计算节点不必要再费力的维护状态信息的一致性。而master的唯一性使得维护状态信息的复杂度不随计算节点的增加而增加。

元数据的存储与访问

基于无状态计算节点的设计理念,HAWQ的元数据集中存储在master节点。这成为HAWQ与GPDB的一个重要的设计区别。元数据集中存储的好处是便于管理与一致性的控制。再加上HAWQ的用户数据存储在分布式文件系统HDFS上,HAWQ因此不在需要为计算节点设计镜像(mirror)节点,从而简化了系统设计并且提高了HAWQ的可扩展性。

计算节点在执行查询计划的时候是需要访问元数据的,HAWQ通过元数据分发(metadata dispatching) 来解决这个问题。对于一个查询请求,master在生成查询计划之后,需要遍历整个查询计划来收集执行这个查询计划所需要的元数据。Master将这些元数据收集起来,保存在查询计划里。我们称这样的查询计划为自描述的查询计划。计算节点接收到自描述的查询计划后即可以完成全部计算工作,不需要请求额外的元数据。

一个数据库在刚刚完成初始化的时候就已经存在大量的元数据了,这些元数据包括了数据库支持的各种数据类型,系统表信息,内建函数等等。这些初始的系统元数据并不会被修改,因此HAWQ在每个计算节点上保留这些只读元数据的备份,从而减少自描述查询计划的大小,提高元数据分发的性能。

一些DDL语句会修改元数据,计算节点在每个语句结束的时候收集所有被修改的元数据,将修改的元数据返回给master节点,master负责对元数据的更新操作。

事务的实现

我们之前讲到,无状态的计算节点并不保存事务状态,我们在这一节介绍HAWQ的事务系统的实现。

GPDB与大多数分布式系统相同,采用分布式事务的设计,采用两阶段提交等算法实现分布式事务。HAWQ在设计之初,我们为了提高系统的可扩展性,并没有采用两阶段提交等分布式事务算法。而是采用了一种分布式系统中比较少见的集中式事务控制机制。HAWQ通过两个层次来实现事务系统。

  • 元数据的事务保证:HAWQ的元数据保存在master上,存储在本地文件系统中。HAWQ采用多版本并发控制(MVCC)算法实现元数据的并发隔离。通过日志(WAL)实现元数据的持久化。

  • 数据文件的事务保证:由于HDFS只支持文件的追加操作,因此对数据文件的版本控制可以通过记录数据文件的逻辑长度实现。并发的数据追加可以通过并发写入多个不同的文件来实现。数据文件的长度记录在元数据中,因此数据文件的版本控制是通过元数据实现的。对数据文件的追加不记日志。计算节点对数据文件的追加操作都是即时提交并持久化保存在HDFS上的。

总结

HAWQ的设计理念在于,尽量简化计算节点的复杂度,通过集中式的方式存储和维护复杂的系统状态,从而简化系统整体的复杂度。通过降低系统的复杂度来提高系统的可扩展性。做到简单就是美的效果。

一个分布式系统的可扩展性受到系统设计的方方面面的影响。本文没有也不期待将这些方面一一枚举。本文通过比较HAWQ与GPDB架构的不同,向大家介绍一下HAWQ在设计之初的思考。