NoSQL为什么需要模式自由的ETL工具?

2018-01-09 11:03:49 浏览数 (1)

【IT168 评论】了解一个开源工具,可以有效帮助人们解决NoSQL在数据输入、处理、输出方面困难。大数据时代,不了解NoSQL数据库的程序员大抵应该是没有的吧!

许多NoSQL数据库缺少工具和分析。本文,将讨论模式无关(schema-agnostic)的现代ETL方法如何为NoSQL供应商和客户提供帮助。对于涉及数据的任何操作或者一般计算,都需要实施三件事:输入、处理、输出。

NoSQL在输入、处理、输出方面的困难:令人不安的真相

NoSQL数据库是存储不同数据(结构快速变化的数据)的绝佳方式,例如在无法控制源格式的时候。

然而,用户往往缺乏的是先进的工具,首先要处理数据(输入部分),通过工具对数据进行高级分析和数据科学(处理部分),最后是显示结果或可视化用户的NoSQL数据库(输出部分)中包含的内容。

长期以来,这并没有成为NoSQL采用的一种障碍。传统上,采用NoSQL的开发人员使用对数据库开发友好的API来将其封装在一个定制的应用程序中。这对早期的NoSQL市场发展非常有效。

尽管如此,为了这个市场继续得到增长,并挑战传统的数据库厂商,更多的人需要采用NoSQL,而不仅仅是API的开发人员使用。

即使是开发人员也不喜欢写乏味的“管道代码”(plumbing code),这只是将数据从一个地方连接到另一个地方的代码。这样的代码既单调又重复。客户也不喜欢它,因为任何需要代码的地方都不可避免地意味着需要更多的维护,更重要的是要花很长时间来编写和测试。这意味着部署像NoSQL这样的新技术需要增加更多的成本。

同样,在输出方面,如果用户无法快速查看可从数据中收集到的见解,则无法完全了解投资NoSQL数据库技术的好处。而试图对问题进行编码会导致项目时间延长,并且与上述自定义编码相关的成本也会增加。

许多NoSQL公司都试图将SQL支持融入其产品中,以弥合传统商业智能(BI)供应商与其产品之间的差距。这只是达到了部分成功。商业智能在创建可视化的最后阶段是一种非常固定的模式。这些SQL层却添加了一些限制,并消除了NoSQL数据库提供的一些非常好的灵活性和内置功能。因此,这样做的客户并没有充分认识到NoSQL数据库可以提供的好处,从而降低了投资回报。

由于这些原因,在NoSQL数据库中保持数据的输入、处理、输出的自定义编码大大增加了用户使用NoSQL的障碍,并限制了NoSQL市场的增长。

因此,用户所需要的是围绕这些NoSQL数据库提供更好的工具。

现在可以使用哪些工具?

带有用户界面的工具,使非开发人员用户能够与保存在各种系统中的数据进行交互,并以可视方式创建数据处理,从而减少了使用新技术的障碍。在传统的关系数据库(RDBMS)空间中,采用ETL(提取、转换、加载)工具执行此功能。

当然,历史性的问题是用户的ETL过程在创建时是固定模式。在设计ETL过程中,用户可以有效地对这些字段进行硬编码。如果底层结构改变,那么在最好的情况下,新的数据将被忽略。而最糟糕的情况是用户的ETL工作中断。

在NoSQL世界中,数据结构是多种多样的,而且经常改变,固定模式的ETL在用户所能做的事情上限制太多。

但是NoSQL仍然可以从类似的工具中受益,这种工具可以使非开发人员从各种系统读取数据,清理数据,发现数据信息,将数据与其他数据源合并,执行统计分析,以及机器学习等对其进行高级操作,然后将丰富的数据和新的见解存储到目标数据库,这通常是NoSQL数据库或用于内存存储的快速报告。

这些工具对于采用NoSQL的客户非常有用。

模式灵活的ETL工具

人们喜欢使用易于使用的工具,以便从技术投资中获得快速的业务收益。并希望采用与NoSQL协同工作的模式自由ETL。

有人会说:“ETL永远不会那么灵活,在NoSQL中不会帮助我们!”其实并不是这样。人们发现有一种方法可以执行模式自由的ETL,支持数百个数据的源和汇,机器学习以及将数据提供给可视化业务分析/商业智能仪表板层。还有一个开源的核心。

这个特殊的技巧是在Pentaho平台的两个特征之内进行的。这可以为Pentaho平台企业版的所有者和供应商工作。确实如此。

但是,如果用户不确定是否可以帮助解决NoSQL灵活架构工具问题的话,用户不相信这个产品,也不会通过Pentaho数据集成使用开源ETL工具。

Pentaho数据集成看起来像所有其他固定模式的ETL工具。如果拖动导入步骤并将其指向数据源,则在数据流中看到的字段是在数据源中看到的字段,并且对于“转换”(或流)的其余部分来说是固定的。

Pentaho数据集成(PDI)的元数据注入

Pentaho数据集成虽然有一个独特的功能,称为元数据注入。这使得父类转换能够动态地设置子转换中的步骤配置。它用于许多稍微不同的转换的地方。

元数据注入的一个很好的用例就是读取一个数据源(例如一个关系数据库)的位置,然后将这个数据结构发送到一个目标系统(例如一个NoSQL数据库)。用户可能会开发一个转换来读取其销售表,并将其加载到销售JSON文档中,另一个转换为客户详细信息,另一个转换为In-Flight购物篮等等。

虽然为500个源表创建500个这样的代码会很糟糕。而这是大多数其他ETL工具面临的问题。所有这些转换看起来都是一样的。他们可能会有十个步骤来加载数据,设置一些临时变量(如JSON集合名称,也许是在目标JSON结构中的一些常量或计算字段),然后将数据加载到特定的集合中。

500个转换乘以10个步骤= 人工配置5000个步骤,这对于工作人员来说不堪重负。

元数据注入的好处在于用户可以创建单个转换来执行此加载,但是可以通过父转换对其实施参数化。甚至可以在单个作业中配置此父转换项,并在输入数据源列表上循环以执行此项工作。

因此,现在只需创建两个转换:一个包含十个步骤,一个包含十个步骤的父步骤,循环遍历表集,并使用元数据注入调用子转换。两个转变总共只有20个步骤。工作人员可以进行轻松处理。

因此,利用Pentaho数据集成的元数据注入支持,使用足够灵活的ETL工具可以将不同结构加载到NoSQL中,甚至可以实现更低的成本。

PDI辅助数据发现和语义关系发现

但是如何在Hadoop或NoSQL中加载一个可变数据湖,其中包含变化很大的结构呢?

那么,Pentaho数据集成也可以加载这些数据。用户可以加载JSON数据(例如也支持XML),并将其解析到Pentaho中。 JSON输入步骤也支持元数据注入。因此,用户可以对数据进行采样(即使只记录一个记录),然后调用调用元数据注入转换来处理具有不同架构的数据。

甚至可以做更多的一些东西

行业专家日前与其数据科学团队的同事共同开发了一个自定义的步骤,实现了更多的功能,它将在转换中分析流中的所有数据,并输出有关它的汇总统计数据。

其步骤所做的是确定每个数据的类型(不考虑源系统中的数据类型),并确定该字段是分类的还是连续的。它计算唯一的、空值和连续字段的数量,计算最小、最大、中位数和平均值,以及偏度和离散度。

简而言之,需要确定源系统中每个字段和每个数据的组成。然后,将这些元数据存储起来,以便通过元数据注入来驱动ETL过程

在NoSQL的世界里,变得相关的是从各种来源加载大量的数据,并通过数据科学,而不是通过人工配置来确定数据实体如何在系统间相互链接。

使用这种方法,结合元数据注入将允许Pentaho转换加载多个数据源,并向集成开发人员提供组织数据中存在的实体以及这些实体之间关系的建议。

基本上,用户可以使用Pentaho来发现整个组织数据之间的语义联系。

然后,用户可以使用这些信息动态地配置其目标系统和元数据注入,以加载数据并将其融合,并在目标(可能是NoSQL数据库)中建立关系、语义关系模型和其他元数据。

如果用户有成千上万的源记录类型,并且不希望在NoSQL数据库(不管是文档存储区还是混合文档图/三重存储)中人工配置这些元模型,这一点尤其有用。

工作人员在现有的演示销售数据信息上运行了这个功能,并惊奇地发现语义图在发现之后是多么有用。所有主要实体都在语义图上出现在屏幕上,显示出已发现的关系和数据类型,以及关联的强度。

基本上,在NoSQL中使用Pentaho数据集成在数据发现、建模和数据加载开发方面为用户节省了几个月的的时间。

数据处理怎么样?

Pentaho数据集成还在Pentaho市场上提供了无数的数据科学插件,统计功能和第三方插件。这意味着任何数据处理、数据工程、特性创建、统计建模或机器学习都需要用户执行,用户可以使用Pentaho进行编排。

无论底层数据存储如何,Pentaho都可以成为这样一个中心,因此客户不必依靠数据库供应商来嵌入这些设施,而NoSQL数据库公司不需要投入数百万美元的费用来构建它们。

即使在Spark,Python或R中集成机器学习,也只是一个简单的例子,将单个步骤拖放到一个转换上。

可视化NoSQL保存的数据

企业版Pentaho平台的另一个强大功能就是Pentaho数据集成与Pentaho Business Analytics相结合来揭示数据服务。

数据服务在Pentaho数据集成(PDI)转换中配置。用户点击任何一个步骤,然后说:“我现在所拥有的数据流,我想公开为JDBC兼容的数据源。”它可以是任何东西,例如一个CSV文件,一组NoSQL记录等。当它被暴露时,数据集被赋予一个名称,并且可以从任何JDBC兼容的商业智能工具连接到它。

这个数据服务可以有多个选项。为了减少对源系统的负载,它可以在一段时间内缓存和刷新。它还可以关键地将通过JDBC传递的WHERE子句“下推”(push down)到源系统中配置的“输入”步骤。

这到底意味着什么?

可以把客户编号“下推”到首先传递给NoSQL数据库的查询中,而不是从其NoSQL数据库加载所有的客户销售,并将它们缓存在内存中。所以,数据服务就等同于带有参数的简单函数调用,只加载需要的数据来回答传递给数据服务的查询。这比传统的SQL翻译层执行速度快得多。

Pentaho平台可以为任何支持查询,搜索或过滤的数据源执行此操作。例如,开发了数据服务来为使用MongoDB和MarkLogic服务器的客户完成这项工作。例如,有一个本地的MongoDB步骤,使用MarkLogic的REST API将查询下推到NoSQL数据库。这很容易。然后,将其公开给Pentaho商业分析仪表板,可以在笔记本电脑上查询和查看几千条记录,并在几秒钟内执行。

一旦想到如何做到这一点,花费五分钟的时间来开发转换,使用PDI将客户数据加载到NoSQL中,另外五分钟用于数据服务转换,再用五分钟用于配置仪表板。所以,从加载数据到洞察分析只有15分钟。这很简单。

当然,使用元数据注入和变量模式开发许多这些转换将比这个简单的例子花费更长的时间,但是与编写数据加载代码相比,这样做速度更快,更不用说随着时间的推移而进行的维护和开发。这里的ETL模型基本上是可视化构建和记录的XML文件。

总结

在Pentaho数据集成(PDI)中,NoSQL社区可以访问创建无架构和可变架构数据加载以及数据科学和集成转换的能力,同时避免创建大量的转换。从而,大大减少与NoSQL系统相关的执行成本。如果需要动态调用,也可以称之为REST。

NoSQL社区还可以通过PDI Data Services over NoSQL数据源访问他们选择的商业智能工具中的仪表盘。

而且这个平台目前已经可以使用,并且具有一个开源内核。建议可以下载并尝试一下。

0 人点赞