数据库 频道

柏睿数据RapidsDB联邦,ETL的进阶之路

  导语

  在对海量多源异构数据进行融合和分析时,为破解使用ETL方法产生的难题,柏睿数据探索出一个更高效、更智能、更低TCO、更准确的实现路径,通过RapidsDB联邦系统打造出一个统一的联邦SQL数据库,从而支撑企业关键业务决策。本文通过问题分析、技术方案与探索、案例实践几方面进行阐述与探讨。

  大数据时代,数据作为“第五类生产要素”,是企业进行科学管理、决策分析的基础。金融、能源、通信等诸多行业企业都需要充分激活大数据价值来支持关键业务决策,因此在规定的时间内实现对不断增长的多源异构数据的分析至关重要,但往往其实现成本和复杂程度却相当高。

  那么如何高效、智能、低TCO、准确地实现对多源异构数据的融合和实时分析呢?这将是本文要探讨的问题。

  一、挑战及问题

  当下大数据环境,数据处理需求正由单一数据类型、有限量的数据向海量、多源、异构的数据变化,为在规定的时间内实现对不断增长的多源异构数据的分析,首先需要对海量多源异构数据进行整合。传统上,企业通常会部署复杂、耗时又昂贵的ETL(数据抽取、转换和加载)操作工具,来实时地将复杂的大数据环境整合为单个数据库模式,但ETL过程本身却对企业及时做出业务决策设立了障碍。

  此处展示了一个典型的大数据环境,如图可见有一组快速变化和扩张的、不同类型的数据源,企业要查询和整合所有数据源中的数据,通常采用ETL方式将数据转换为通用格式并转移到可查询的位置,往往会造成“数据湖”的形成,从而导致实现过程具有复杂性、效率低、成本高等弊端。

  复杂性:ETL过程会产生多余的数据副本,导致数据冗余。“数据湖”的形成也增加了其复杂性,既要管理好多源异构数据的数据库模式信息和对象命名,以便为整个数据湖提供一个统一视图;同时随着新数据源不断出现,额外的ETL过程需要被开发出来以将新的数据源抽取、转换和加载到当前的数据湖中,数据湖也将随之持续扩大,难以应对实时产生的海量数据。

  效率低:数据的提取、转换和加载需要大量的时间,同时由于数据量庞大,ETL流程影响数据分析速度。

  成本高:ETL流程比较复杂且维护难,需要熟练的技术人员才能操作,而且需要不断维护,将产生大量的人力和财力成本。

  可以明确,为实现在规定的时间内对不断增长的多源异构数据进行分析,企业需要针对复杂性、效率低、成本高等常见问题予以优化。

  二、技术方案与探索

  柏睿数据基于自主研发的、以RapidsDB为核心的全内存分布式数据库产品体系和人工智能产品体系,以“Data+AI”核心技术,探索出能够完全避免ETL过程而实现更高效、更智能、更低TCO、更准确地融合和分析多源异构数据的非常好的路径,即RapidsDB联邦系统,有力支撑了企业关键业务决策。

  柏睿数据RapidsDB联邦系统具有如下特性:

  无需数据迁移:允许数据处于原来的数据源中,避免冗余的数据副本。

  • 标准SQL统一接口:ANSI-SQL模式涵盖所有在联邦中的数据源, 使该系统成为所有数据源的统一查询接口。这些数据源包括关系型数据库管理系统,JDBC数据源,HDFS,CSV文件和其它文件系统。

  • 基于底层数据源的抽象化模式:RapidsDB执行引擎将所有数据视为一个单一的整体,具有可以将多个数据源和多张数据表格相连接起来的能力。

  • 高性能引擎:RapidsDB执行引擎是一个分布式全内存大规模MPP引擎,其高性能可以确保业务用户在规定时间内获得数据处理结果。

  • 生产数据实时分析:轻松集成现有数据源中的新数据或者新数据源,消除ETL过程的落盘中转需求。

  那么RapidsDB联邦系统是如何实现以上特性,并避免ETL方法所带来的的问题的?它主要是基于RapidsDB联邦架构,通过RapidsDB联邦连接器和自适应查询下推功能实现的。

  1、RapidsDB联邦架构

  RapidsDB联邦系统的设计旨在支持对多源异构数据的分析型SQL查询,下图是RapidsDB联邦系统的架构图,从中可以看出RapidsDB联邦连接器子系统是如何被集成在该系统中的。

  从上图中可以看到,RapidsDB联邦架构为用户提供了一组可以在应用程序中向系统提交查询的接口,它包含:一个基于动态成本的SQL查询编译和优化器,用于生成查询计划;一个与联邦连接器相结合的MPP执行引擎,能够对结构图底部所示的分布式数据源执行实时查询。还有至关重要的联邦连接器,能够控制对数据的访问并与RapidsDB数据库执行引擎进行协作,来完全避免系统对ETL的需求,进而为用户提供访问数据的能力。

  2、RapidsDB联邦连接器

  RapidsDB联邦连接器能够为用户提供一个可以将底层所有数据源整合起来的单一的SQL联邦数据库。这意味着用户可以专注于构建针对多源异构数据的查询,而不用担心数据类型或所处位置。

  在对所有数据源运行查询时,RapidsDB联邦连接器能够自动提取元数据,将数据以ANSI-SQL模式呈现,处理不同数据源之间的数据类型转换,并以行和列的形式传递给RapidsDB执行引擎,由此通过这个单一的联邦SQL数据库,用户可以使用SQL查询访问所有数据源的数据。而其他允许用户访问远程数据源的系统,通常要求用户在访问对象之前明确指定模式。

  随着新数据源不断出现,用户的数据也在不断变化。为实现对生产数据的实时分析,RapidsDB联邦连接器提供了一个可扩展框架,当可用的新数据源出现时能够轻松添加新连接器。

  作为RapidsDB的本地连接器,这个新连接器叫做IMPEX,其含义为导入和导出,旨在访问处于集群磁盘中的csv(逗号分隔值)文件里的数据,能够支持Linux、S3等其他外部数据存储仓,所有的文件都可以加载到任何与连接器相连的数据源中,其中也包括RapidsDB本身所带的名为MOXE的内存存储仓。并且IMPEX还可协助将数据导出为标准的csv文件。

  3、自适应查询下推功能

  为真正获得非常好的性能,单靠一个非常高效的执行引擎是不够的,对于不同数据源的远程数据访问,RapidsDB设计出自适应查询下推功能。自适应查询下推功能设计意图主要有两个,一是尽可能多地将工作量卸载给远程数据源处理,RapidsDB执行引擎收到的数据越少,数据在网络上移动的成本就越低;二是尽量减少RapidsDB执行引擎本身必须要处理的数据量,需要处理的数据越少,查询速度也就越快。

  自适应查询下推功能能够充分利用原始数据源的处理能力。在查询执行过程中,每个连接器会智能分析查询计划,访问在查询计划中它所管理的表数据,然后决定哪一部分的查询可以被下推到底层数据源执行;下推查询的执行结果会以流数据的方式返回给RapidsDB执行引擎,并由它来完成最终的查询步骤。

  三、实践案例

  以下是一个简单案例,以展示运用RapidsDB联邦连接器对数据库中数据的运行查询。在这个示例中只有一个名为“dw1”的Postgres数据库。在这个数据库中有两个数据库模式,一个叫做“客户(customer)”,另一个叫做“网络(web)”, 还有一组表格。

  首先需创建一个连接器。以下是RapidsDB中用于创建Postgres连接器的语句示例:

  CREATE CONNECTOR PG1 TYPE POSTGRES WITH USER=‘adm’, PASSWORD=‘admpsw’,DATABASE=‘dw1’;

  在默认情况下,连接器会尝试访问该数据库中可用的所有模式。本例中连接器将自动获取Customer和Web数据库模式下所有表的全部元数据。

  当然我们也可以具体列出特定的一个或一组模式,还可以列出想让连接器去访问的模式中的特定表。在本例中,比如说创建一个只去访问客户人口统计表的连接器,而不访问其他表,从本质上来说,我们可以让连接器来提供数据源中数据的视图。

  连接器将会查看需要管理的所有表的模式信息,然后把这些信息放入RapidsDB元数据存储仓中。可以看到其中一个重要特性是连接器保留了原始数据库中的模式名、表名以及列名。因此,对于这一特定表的查询其实是在Postgres数据库中运行的,它们都始终保留在原系统中。

  上述例子未涉及到某特定数据库或特定模式中的客户人口统计表。但如果在有两张客户人口统计表,一张在Postgres数据库中,另一张在Oracle数据库中,它们都会被联邦进来。在这种情况下,查询就必须提供模式。可以在查询中创建这样一个语句,来消除名称上的歧义:SELECT * from customer_demographics where cd gender= 'F' and cd marita' status= 'SINGLE*;

  但在此例中可以看到,虽然我们正在对Postgres运行查询,但查询所涉及的实际数据库是通过RapidsDB来管理的。

  四、收益总结

  本文主要针对破解使用ETL方法所带来的难题,进行了问题分析、技术方案与探索、案例实践,最终探索出一套高效、智能、低TCO、准确地实时分析多源异构数据的非常好的路径,从而支撑企业关键业务决策,这正是柏睿数据RapidsDB联邦系统所实现的。

  RapidsDB联邦系统打造出一个统一的联邦SQL数据库,能够让用户更高性能、智能化地来访问多源异构数据。从底层技术逻辑上来说,RapidsDB联邦系统完全取代了ETL提取、转换和加载三个过程,避免使用ETL方法所带来的复杂性、效率低和成本高等问题。

  在ETL提取阶段,RapidsDB联邦系统是在不改变数据位置的情况下,通过联邦连接器自动提取元数据的能力和自适应查询下推功能来实现的,因此可以完美跳过提取阶段,数据提取可以直接被设置为SQL查询的一部分。

  在ETL转换阶段,通过 IMPEX连接器,用户能够以标准的SQL函数来高效地完成所有数据源中数据的转换。

  ETL加载阶段更是被完全消除了,因为数据仍处于原来的位置,只有查询所需数据时,相关数据才会被流式传输到执行引擎,而这一过程已经在上述所提到的提取和转换阶段被完成了。

  而且这一技术方案带来的其他显著益处是“数据一旦可用就可被查询”,避免了ETL过程中可能会发生的数据丢失问题,从而影响决策的准确性。

特别提醒:本网信息来自于互联网,目的在于传递更多信息,并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益,请及时联系我们,本站将会在24小时内处理完毕。
0
相关文章