当您拥有 Sber 秤时。 将 Ab Initio 与 Hive 和 GreenPlum 结合使用

前段时间，我们面临选择 ETL 工具来处理大数据的问题。 由于功能有限，之前使用的 Informatica BDM 解决方案不适合我们。 它的使用已简化为启动 Spark-Submit 命令的框架。 市场上原则上能够处理我们每天处理的数据量的类似产品并不多。 最终我们选择了 Ab Initio。 在试点演示中，该产品表现出了非常高的数据处理速度。 俄语中几乎没有关于 Ab Initio 的信息，所以我们决定谈谈我们在 Habré 上的经验。

Ab Initio 有许多经典和不常见的转换，其代码可以使用自己的 PDL 语言进行扩展。 对于小型企业来说，如此强大的工具可能会显得大材小用，而且其大部分功能可能价格昂贵且未使用。 但如果您的规模与 Sberov 的规模接近，那么从头开始可能会对您感兴趣。

帮助企业在全球范围内积累知识、发展生态系统，帮助开发者提高ETL技能、提高shell知识、提供掌握PDL语言的机会、加载流程可视化、简化开发由于功能成分丰富。

在这篇文章中，我将讨论 Ab Initio 的功能，并提供其与 Hive 和 GreenPlum 的工作特点的比较。

• MDW 框架的描述及其针对 GreenPlum 的定制工作
• Hive 和 GreenPlum 之间的 Ab Initio 性能比较
• 在近实时模式下使用 GreenPlum 从头开始​​工作

这个产品的功能非常广泛，需要大量的时间去研究。 然而，通过适当的工作技能和正确的性能设置，数据处理的结果是非常令人印象深刻的。 使用 Ab Initio 可以为开发人员提供有趣的体验。 这是 ETL 开发的新方式，是可视化环境和类似脚本语言的下载开发的混合体。

企业正在开发他们的生态系统，这个工具比以往任何时候都更方便。 通过 Ab Initio，您可以积累有关当前业务的知识，并利用这些知识来扩展旧业务和开辟新业务。 Ab Initio 的替代方案包括可视化开发环境 Informatica BDM 和非可视化开发环境 Apache Spark。

从头开始的描述

Ab Initio 与其他 ETL 工具一样，是一个产品集合。

Ab Initio GDE（图形开发环境）是一个供开发人员配置数据转换并以箭头形式将它们与数据流连接起来的环境。 在这种情况下，这样的一组变换称为图：

功能组件的输入和输出连接是端口，并且包含在转换中计算的字段。 按执行顺序以箭头形式的流连接的多个图称为计划。

功能组件有几百个，数量很多。 其中许多都是高度专业化的。 Ab Initio 中经典转换的功能比其他 ETL 工具更广泛。 例如，Join 有多个输出。 除了连接数据集的结果外，您还可以获得键无法连接的输入数据集的输出记录。 您还可以获得拒绝、错误和转换操作的日志，这些日志可以在文本文件的同一列中读取并与其他转换一起处理：

或者，例如，您可以以表的形式具体化数据接收器，并在同一列中从中读取数据。

有原始的转变。 例如，扫描变换具有与分析函数类似的功能。 有些转换的名称不言自明：创建数据、读取 Excel、规范化、组内排序、运行程序、运行 SQL、连接数据库等。图形可以使用运行时参数，包括从或向其传递参数的可能性操作系统。 具有传递到图形的现成参数集的文件称为参数集 (psets)。

正如预期的那样，Ab Initio GDE 有自己的存储库，称为 EME（企业元环境）。 开发人员有机会使用本地版本的代码并将其开发签入中央存储库。

在执行期间或执行图形之后，可以单击连接转换的任何流并查看在这些转换之间传递的数据：

还可以单击任何流并查看跟踪详细信息 - 转换在多少个并行中进行，有多少行和字节加载到哪个并行中：

可以将图的执行分为多个阶段，并标记需要首先执行某些转换（在零阶段），接下来的转换在第一阶段，接下来的转换在第二阶段，等等。

对于每个转换，您可以选择所谓的布局（将在其中执行）：没有并行或并行线程，可以指定并行线程的数量。 同时，Ab Initio 在转换运行时创建的临时文件可以放置在服务器文件系统和 HDFS 中。

在每个转换中，基于默认模板，您可以在PDL中创建自己的脚本，这有点像shell。

使用 PDL，您可以扩展转换的功能，特别是，您可以根据运行时参数动态（在运行时）生成任意代码片段。

Ab Initio 还通过 shell 与操作系统进行了完善的集成。 具体来说，Sberbank 使用 Linux ksh。 您可以与 shell 交换变量并将它们用作图形参数。 您可以从 shell 调用 Ab Initio 图的执行并管理 Ab Initio。

除了 Ab Initio GDE 之外，交付中还包含许多其他产品。 有它自己的Co>Operation System，声称被称为操作系统。 有一个控制>中心，您可以在其中安排和监控下载流量。 有些产品可以在比 Ab Initio GDE 允许的更原始的级别上进行开发。

MDW 框架的描述及其针对 GreenPlum 的定制工作

除了其产品之外，供应商还提供 MDW（元数据驱动仓库）产品，这是一个图形配置器，旨在帮助完成填充数据仓库或数据仓库的典型任务。

它包含开箱即用的自定义（特定于项目的）元数​​据解析器和现成的代码生成器。

作为输入，MDW 接收数据模型、用于设置数据库（Oracle、Teradata 或 Hive）连接的配置文件以及一些其他设置。 例如，项目特定部分将模型部署到数据库。 该产品的开箱即用部分通过将数据加载到模型表中来为其生成图形和配置文件。 在这种情况下，会为更新实体的初始化和增量工作的多种模式创建图形（和 pset）。

对于 Hive 和 RDBMS，会为初始化和增量数据更新生成不同的图。

对于 Hive，传入的增量数据通过 Ab Initio Join 与更新前表中的数据连接。 MDW（Hive 和 RDBMS 中）中的数据加载器不仅从增量中插入新数据，而且还关闭其主键接收增量的数据的相关周期。 此外，还必须重写数据中未更改的部分。 但这是必须要做的，因为Hive没有删除或更新操作。

就 RDBMS 而言，增量数据更新的图表看起来更优化，因为 RDBMS 具有真正的更新功能。

接收到的增量被加载到数据库中的中间表中。 此后，增量将连接到更新之前表中的数据。 这是通过使用 SQL 生成的 SQL 查询来完成的。 接下来，使用SQL命令delete+insert，将增量中的新数据插入到目标表中，并关闭主键收到增量的数据的相关周期。
无需重写未更改的数据。

所以我们得出的结论是，对于Hive来说，MDW必须去重写整个表，因为Hive没有更新功能。 没有什么比在更新时完全重写数据更好的了。 相反，对于 RDBMS，该产品的创建者发现有必要将表的连接和更新委托给 SQL 的使用。

对于 Sberbank 的一个项目，我们为 GreenPlum 创建了一个新的、可重用的数据库加载器实现。 这是根据 MDW 为 Teradata 生成的版本完成的。 最接近且最好的是 Teradata，而不是 Oracle，因为…… 也是一个MPP系统。 Teradata 和 GreenPlum 的工作方法以及语法非常相似。

不同 RDBMS 之间 MDW 关键差异的示例如下。 在GreenPlum中，与Teradata不同，创建表时需要编写一个子句

distributed by

Teradata 写道：

delete <table> all

，在 GreenPlum 中他们写道

delete from <table>

在 Oracle 中，出于优化目的，他们编写

delete from t where rowid in (<соединение t с дельтой>)

，以及 Teradata 和 GreenPlum 写入

delete from t where exists (select * from delta where delta.pk=t.pk)

我们还注意到，要使 Ab Initio 与 GreenPlum 配合使用，必须在 Ab Initio 集群的所有节点上安装 GreenPlum 客户端。 这是因为我们从集群中的所有节点同时连接到 GreenPlum。 为了从 GreenPlum 进行并行读取，并且每个并行 Ab Initio 线程从 GreenPlum 读取自己的数据部分，我们必须在 SQL 查询的“where”部分放置一个 Ab Initio 可以理解的结构

where ABLOCAL()

并通过指定从转换数据库读取的参数来确定此构造的值

ablocal_expr=«string_concat("mod(t.", string_filter_out("{$TABLE_KEY}","{}"), ",", (decimal(3))(number_of_partitions()),")=", (decimal(3))(this_partition()))»

，它编译成类似的东西

mod(sk,10)=3

， IE。 您必须为每个分区提示 GreenPlum 显式过滤器。 对于其他数据库（Teradata、Oracle），Ab Initio 可以自动执行此并行化。

Hive 和 GreenPlum 之间的 Ab Initio 性能比较

Sberbank 进行了一项实验，比较 MDW 生成的图表与 Hive 和 GreenPlum 的性能。 作为实验的一部分，在 Hive 的情况下，与 Ab Initio 相同的集群上有 5 个节点，在 GreenPlum 的情况下，在单独的集群上有 4 个节点。 那些。 Hive 比 GreenPlum 有一些硬件优势。

我们考虑了两对图，它们执行 Hive 和 GreenPlum 中更新数据的相同任务。 同时，MDW配置器生成的图表也启动了：

• 初始加载 + 将随机生成的数据增量加载到 Hive 表中
• 初始加载 + 将随机生成的数据增量加载到同一个 GreenPlum 表中

在这两种情况下（Hive 和 GreenPlum），他们都在同一个 Ab Initio 集群上运行 10 个并行线程的上传。 Ab Initio 将计算的中间数据保存在 HDFS 中（就 Ab Initio 而言，使用了使用 HDFS 的 MFS 布局）。 在这两种情况下，一行随机生成的数据占用 200 字节。

结果是这样的：

蜂巢：

Hive 中的初始加载

插入的行数
6 000 000
60 000 000
600 000 000

初始化持续时间
几秒钟内即可下载
41
203
1 601

Hive 中的增量加载

可用行数
实验开始时的目标表
6 000 000
60 000 000
600 000 000

应用于的增量线数量
实验过程中的目标表
6 000 000
6 000 000
6 000 000

增量持续时间
几秒钟内即可下载
88
299
2 541

绿梅：

GreenPlum 中的初始加载

插入的行数
6 000 000
60 000 000
600 000 000

初始化持续时间
几秒钟内即可下载
72
360
3 631

GreenPlum 中的增量加载

可用行数
实验开始时的目标表
6 000 000
60 000 000
600 000 000

应用于的增量线数量
实验过程中的目标表
6 000 000
6 000 000
6 000 000

增量持续时间
几秒钟内即可下载
159
199
321

我们看到，Hive 和 GreenPlum 中的初始加载速度都线性取决于数据量，并且由于硬件更好，Hive 的初始加载速度比 GreenPlum 稍快。

Hive 中的增量加载还线性取决于目标表中先前加载的可用数据量，并且随着数据量的增长，增量加载的速度会相当缓慢。 这是由于需要完全重写目标表而导致的。 这意味着对大表应用小的更改对于 Hive 来说并不是一个好的用例。

GreenPlum 中的增量加载弱依赖于目标表中先前加载的可用数据量，并且进展得相当快。 这要归功于 SQL Joins 和 GreenPlum 架构，它允许删除操作。

因此，GreenPlum使用删除+插入的方式添加增量，但Hive没有删除或更新操作，因此在增量更新期间整个数据数组被迫完全重写。 以粗体突出显示的单元格的比较最具启发性，因为它对应于使用资源密集型下载的最常见选项。 我们看到 GreenPlum 在这次测试中击败了 Hive 8 倍。

在近实时模式下使用 GreenPlum 从头开始​​工作

在本实验中，我们将测试 Ab Initio 使用随机生成的数据块近实时更新 GreenPlum 表的能力。 让我们考虑一下我们将使用的 GreenPlum 表 dev42_1_db_usl.TESTING_SUBJ_org_finval。

我们将使用三个 Ab Initio 图来处理它：

1) Graph Create_test_data.mp – 在 HDFS 中以 10 个并行线程创建包含 6 行的数据文件。 数据是随机的，其结构经过组织以便插入到我们的表中

2) 图 mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset – MDW 通过在 10 个并行线程中初始化数据插入到我们的表中生成图（使用图 (1) 生成的测试数据）

3) 图 mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset – MDW 生成的图，用于使用图 (10) 生成的一部分新接收的数据（增量）在 1 个并行线程中增量更新我们的表

让我们在 NRT 模式下运行以下脚本：

• 生成6条测试线
• 执行初始加载，将 6 条测试行插入到空表中
• 重复增量下载 5 次
  • 生成6条测试线
  • 向表中执行增量插入 6 条测试行（在本例中，valid_to_ts 过期时间设置为旧数据，并插入具有相同主键的最新数据）

这个场景模拟了某个业务系统的真实运行模式——相当大一部分新数据是实时出现的，并立即涌入GreenPlum。

现在让我们看一下脚本的日志：

于 2020-06-04 11:49:11 启动 Create_test_data.input.pset
于 2020-06-04 11:49:37 完成 Create_test_data.input.pset
于 42-1-2020 06:04:11 启动 mdw_load.day_one.current.dev49_37_db_usl_testing_subj_org_finval.pset
于 42-1-2020 06:04:11 完成 mdw_load.day_one.current.dev50_42_db_usl_testing_subj_org_finval.pset
于 2020-06-04 11:50:42 启动 Create_test_data.input.pset
于 2020-06-04 11:51:06 完成 Create_test_data.input.pset
于 42-1-2020 06:04:11 启动 mdw_load.regular.current.dev51_06_db_usl_testing_subj_org_finval.pset
于 42-1-2020 06:04:11 完成 mdw_load.regular.current.dev53_41_db_usl_testing_subj_org_finval.pset
于 2020-06-04 11:53:41 启动 Create_test_data.input.pset
于 2020-06-04 11:54:04 完成 Create_test_data.input.pset
于 42-1-2020 06:04:11 启动 mdw_load.regular.current.dev54_04_db_usl_testing_subj_org_finval.pset
于 42-1-2020 06:04:11 完成 mdw_load.regular.current.dev56_51_db_usl_testing_subj_org_finval.pset
于 2020-06-04 11:56:51 启动 Create_test_data.input.pset
于 2020-06-04 11:57:14 完成 Create_test_data.input.pset
于 42-1-2020 06:04:11 启动 mdw_load.regular.current.dev57_14_db_usl_testing_subj_org_finval.pset
于 42-1-2020 06:04:11 完成 mdw_load.regular.current.dev59_55_db_usl_testing_subj_org_finval.pset
于 2020-06-04 11:59:55 启动 Create_test_data.input.pset
于 2020-06-04 12:00:23 完成 Create_test_data.input.pset
于 42-1-2020 06:04:12 启动 mdw_load.regular.current.dev00_23_db_usl_testing_subj_org_finval.pset
于 42-1-2020 06:04:12 完成 mdw_load.regular.current.dev03_23_db_usl_testing_subj_org_finval.pset
于 2020-06-04 12:03:23 启动 Create_test_data.input.pset
于 2020-06-04 12:03:49 完成 Create_test_data.input.pset
于 42-1-2020 06:04:12 启动 mdw_load.regular.current.dev03_49_db_usl_testing_subj_org_finval.pset
于 42-1-2020 06:04:12 完成 mdw_load.regular.current.dev06_46_db_usl_testing_subj_org_finval.pset

原来是这张图：

图表
开始时间
完成时间
长度

创建_测试_数据.输入.pset
04.06.2020 11：49：11
04.06.2020 11：49：37
00:00:26

mdw_load.day_one.current。
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11：49：37
04.06.2020 11：50：42
00:01:05

创建_测试_数据.输入.pset
04.06.2020 11：50：42
04.06.2020 11：51：06
00:00:24

mdw_load.regular.current。
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11：51：06
04.06.2020 11：53：41
00:02:35

创建_测试_数据.输入.pset
04.06.2020 11：53：41
04.06.2020 11：54：04
00:00:23

mdw_load.regular.current。
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11：54：04
04.06.2020 11：56：51
00:02:47

创建_测试_数据.输入.pset
04.06.2020 11：56：51
04.06.2020 11：57：14
00:00:23

mdw_load.regular.current。
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11：57：14
04.06.2020 11：59：55
00:02:41

创建_测试_数据.输入.pset
04.06.2020 11：59：55
04.06.2020 12：00：23
00:00:28

mdw_load.regular.current。
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12：00：23
04.06.2020 12：03：23
00:03:00

创建_测试_数据.输入.pset
04.06.2020 12：03：23
04.06.2020 12：03：49
00:00:26

mdw_load.regular.current。
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12：03：49
04.06.2020 12：06：46
00:02:57

我们看到6分钟内处理了000条增量行，这是相当快的。
目标表中的数据分布如下：

select valid_from_ts, valid_to_ts, count(1), min(sk), max(sk) from dev42_1_db_usl.TESTING_SUBJ_org_finval group by valid_from_ts, valid_to_ts order by 1,2;

您可以看到插入的数据与图表启动时间的对应关系。
这意味着您可以在 Ab Initio 中以非常高的频率将数据增量加载到 GreenPlum 中，并观察到将此数据插入 GreenPlum 的速度很高。 当然，不可能每秒启动一次，因为 Ab Initio 与任何 ETL 工具一样，在启动时需要时间“启动”。

结论

目前，Sberbank 使用 Ab Initio 来构建统一语义数据层 (ESS)。 该项目涉及构建各银行业务实体的统一状态版本。 信息来自各种来源，其副本在 Hadoop 上准备。 根据业务需求，准备数据模型并描述数据转换。 Ab Initio将信息加载到ESN中，下载的数据不仅是业务本身感兴趣的，而且可以作为构建数据集市的来源。 同时，该产品的功能允许您使用各种系统作为接收器（Hive、Greenplum、Teradata、Oracle），从而可以轻松地为企业准备所需的各种格式的数据。

Ab Initio 的功能非常广泛；例如，所包含的 MDW 框架使得构建开箱即用的技术和业务历史数据成为可能。 对于开发人员来说，Ab Initio 使得不必重新发明轮子，而是可以使用许多现有的功能组件，这些组件本质上是处理数据时所需的库。

作者是Sberbank SberProfi DWH/BigData专业社区的专家。 SberProfi DWH/BigData专业社区负责开发Hadoop生态系统、Teradata、Oracle DB、GreenPlum以及BI工具Qlik、SAP BO、Tableau等领域的能力。

来源： habr.com