當您擁有 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刪除+插入命令，將增量中的新資料插入目標表中，並關閉主鍵收到增量的資料的相關週期。
無需重寫未更改的資料。

所以我們得出的結論是，對於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等領域的能力。

來源： www.habr.com