ETL 彙整 - 歐立威科技

Apache Kafka 是什麼？核心元件、優勢、常見使用案例一次看！

Omni — Thu, 28 Mar 2024 03:58:33 +0000

Kafka 是什麼？

Apache Kafka 是專為處理大數據而生的分布式資料串流平台，能輕鬆處理每秒數萬次的請求（Request）。

相較其他消息佇列系統（Message Queue），Kafka 擁有更好的吞吐量，內建的分區（Partition）機制，和卓越的容錯能力，這使其被應用於各種大數據使用情境，例如即時資料分析、日誌聚合、消息傳遞和支援微服務架構。

本文將深入探討 Kafka 的基本概念、功能、架構和主流使用情境。

Kafka 解決了什麼問題？

許多發佈 / 訂閱系統經常在初期作為簡易消息佇列架構。開發者只需架設 Web 伺服器、配合前端網頁、後端程式與資料庫串接，即可滿足大部分使用需求。

隨著 Web 系統使用規模增加，API 呼叫（Request）與資料庫存取頻率也會跟著提高，萬一系統缺乏有效的緩衝機制，資料庫很快就會承受過大的工作負載。

不僅如此，當企業進入擴張期，必然產生用戶行為、業務狀態等資訊分析需求，這時系統就必須追加監控功能等額外應用程式。如果未能妥善規範資料流架構，系統結構將變得複雜、難以追蹤與管理。

為了解決上述困難，開發者可以將前端資料發佈到 Kafka、形成資料暫存區，再藉由後端程式從中訂閱資料。這麼一來，既能減緩資料庫負載，也能達到較不複雜的系統架構。

Kafka 的資料管道（Data Pipeline）工作流程

綜觀整個資料處理架構，自資料來源導入系統的應用程式可稱作「輸入端」、取用資料的應用程式則稱為「輸出端」；Kafka 位於「輸入端」與「輸出端」之間，

一邊從「輸入端」接收資料，一邊分配資料到「輸出端」，完成後續的資料加工與傳遞作業。

Kafka 作為資料流的「管道」（Pipeline），可以讓資料流通於各類基礎架構、降低元件之間的耦合程度；這種架構有利於日後系統維運，即降低「輸出端」應用程式原始碼修改後，連帶影響其它元件設定值的修改成本。

Kafka 4 大核心元件

一、Events（事件）＆消息（Message）

在 Kafka 中，事件是帶有資料的消息。消息是 Kafka 中的最小資料單元，此概念類似於資料庫的 Row 和 Record。通常一個事件會回傳以下消息： Key、 Value、 Timestamp 以及 Meta Data Header。

以下為一個事件範例：當一位新訪客在網銀上匯款時，此匯款行為就會被視為一個事件，並回傳以下消息（Message）：匯款者姓名、值、時間戳。

Event key: “Ethan”
Event value: “向 Claire 支付 200 元”
Event timestamp: “2023/05/06 3.30pm”

二、Topics（主題） & Partition（分區）

Kafka 會將每一條資料歸納在事先指定的 Topic 中，即每個 Topic 處理同一類型的資料；當生產者 (Producer) 指定目標 Topic 時，就代表提供了明確的資料分類標示。

Topic（主題）可以被理解為資料庫的資料表或檔案系統的資料夾，每條資料都具有值（Value）、鍵（Key）和標頭（Header）。Topic 作為資料訂閱、發佈的基本單位，不僅可以單純接收生產者發佈的資料，也可以接收一或多個消費者訂閱消息。

一個 Topic 可以區分為多個 Partition，從提交日誌紀錄（Log）的角度理解，每個 Partition 代表了各自紀錄的集合，一但資料發佈到 Kafka Topic，資料就會預設以「僅限追加」（Append-only）的方式加入 Partition 佇列末端，並加上 Offset（偏移值）來標記先後順序與資料傳輸進度。

Kafka 或 Zookeeper 會記錄每個 Partition 最後被訂閱的資料 Offset，因此即使消費端中斷與 Kafka 的連接並再次重新訂閱也不會遺失任何資料。

受到 Partition 結構影響，直接觀察 Kafka Topic 無法確認資料傳輸的具體順序，但如果觀察個別 Partition 就能發現資料按照寫入順序排列。

下圖是一個由 3 個 Partition 組成的 Topic，資料會進入每個 Partition 末端並被賦予 Offset。相同 Topic 所屬的 Partition 可以分布於不同主機，也就是說，Topic 可以跟隨需求、在多個伺服器進行水平擴展。

三、Producers（生產者）和 Consumer（消費者）

Kafka 的客戶端系統應用程式主要分為生產者和消費者。

Producer （生產者）

負責產生消息。在發布 / 訂閱系統中，它們被稱為發佈者或寫入端。

生產者會在產生消息後將其寫入特定 Kafka Topic 中。通常生產者並不特別指定消息應寫入哪個 Partition，而是將其平均分佈到 Topic 中所有的 Partition 上。生產者的形式多樣，它可以是運行於網頁伺服器的應用程式、IoT 設備或監控程式等等。

當使用者登入購物網站時，他們的登入資訊、購物喜好以及瀏覽資訊都會作為消息發送到 Kafka Cluster 中。從這個例子可以看出，任何生成消息的實體都可以作為生產者。

Consumer（消費者）

負責讀取消息。它們在發佈 / 訂閱系統中可能被稱為訂閱者或讀取者。

消費者能訂閱一到多個 Topic 並依照資料生產的順序進行讀取，此外，他們能藉由消息的 Offset 持續追蹤哪些消息已被讀取完畢。

根據系統架構，一個應用程式可以同時是生產者和消費者。例如：一個資料倉儲能從 Kafka 消費資料，將其整理後的結果再透過 Kafka 提供給 ML 或 AI 應用程式的消費者訂閱。一般來說，資料庫、資料湖泊和資料分析應用程式在 Kafka 中扮演消費者的角色，因為它們需要儲存並分析從 Kafka 接收到的資料。

另外，Kafka 還提供進階的客戶端 API，例如用於資料整合的 Kafka Connect API 以及整理串流的 Kafka Stream，這類進階客戶端會將生產者與消費者做為基石，並打造更高階的應用功能。

四、Broker（代理器） & Cluster（叢集）：

在 Kafka 中， Broker 可以被理解為組成叢集的單元。

Broker 的主要職責是從生產者接收消息，為消息分配 Offset，並將消息儲存於硬碟系統。此外，Broker 也為消費者提供服務，負責處理 Partition 的串流讀取請求，並從硬碟中檢索並返回相應的消息。根據不同的硬體配置，單個 Broker 每秒能處理數以萬計的讀寫請求。

一個 Kafka Cluster 通常由多個 Broker 組成，開發者能透過每個 Broker 的 ID（Integer）進行識別，從而幫助 Kafka Cluster 實現負載平衡、資料備份和故障轉移等功能。

Kafka 採用 ZooKeeper 來管理 Broker。Zookeeper 是 Kafka Broker 和消費者間的協調接口。ZooKeeper 會在叢集中選出一個 Broker 作為叢集控制者（Controller）。控制者負責執行管理所有叢集和元數據（Meta Data）的訊息，控制者的職責包含：

管理 Broker 的運行狀態，包括管理 Broker 的自然下線、當機或網路通訊所造成的叢集變動。控制者需要即時更新叢集資訊，並將所發生的變動吿知所有 Broker。
在創建 Topic 或對其進行擴展時，控制者會重新分配 Topic 中 Partition 資料的備份副本（Replica），並且為每個 Partition 選出領頭 Broker；每個 Partition 的領頭 Broker 將主導各自 Partition 的資料讀寫動作。
管理叢集中所有 Replica 和 Partition 的運行狀態，透過監聽運行狀態事件，來做出相應的處置。

Kafka 的三個優勢

一、可擴展性（Scalability）

Kafka 的可擴展性讓開發者輕鬆管理巨量資料。在 Kafka 中，單一叢集可以橫跨多個資料中心和雲服務基礎架構。

一個 Topic 也能夠將不同 Partition 部署於不同 Broker 上。這種特殊架構讓 Kafka 更容易實現水平擴展，使用者只需在現有的基礎架構中加入新伺服器或資料中心就能處理更多資料。

實務上，開發者能部署單一 Broker 進行概念性驗證，再將其擴展成 3 至 5 台的小型叢集，並隨著服務規模的提升，最後轉移至由數百台 Broker 組成的大型 Kafka 叢集上。

Cluster 在進入正式環境後能在不影響系統可用性的清況下進行擴展，確保即使在某些 Broker 失效的情況下，由多個 Broker 構成的 Cluster 也能持續運行。

二、管理數個生產者和消費者

Kafka 的分散式架構確保無論生產者向相同或不同 Topic 發送資料，所有消息都能按順序儲存。該特性讓 Kafka 能有效聚合前端系統並長時間儲存消息，從而確保資料結構一致。

舉例來說，一個由數個微服務構成的網站，允許每個微服務將 Page View 事件以一致的格式寫入相同的 Kafka Topic。消費端即可從單一串流取得所有應用程式的 Page View 狀態，而不需要為每個應用建立個別 Topic。

除了能夠管理複數生產者，單一 Kafka 串流也能被多個消費者同時讀取，數個消費者也能組成消費者群組（Consumer Group）並行從不同 Partition 讀取消息，共享串流並提高吞吐量。

三、基於磁碟保存資料

Kafka 不僅能管理多個消費者，還能將消息長時間保存。這代表消費者不必即時處理串流資料。因為消息能留存於磁碟。

Kafka 允許消費者根據不同業務需求為資料保存期限配置合適的策略。透過長時間保留消息，即使是處理速度較慢或由消息吞吐量激增而導致進度落後的消費者，也能保證保不丟失任何數據。

此外，這一機制允許消費者在進行必要的維護時短暫下線，不需擔心遺漏生產者產出的消息。因為在消費者終止運行後，消息仍會保存於 Kafka，只需重啟就能繼續接收串流中的數據。

Kafka 的四個使用案例

一、行為追蹤

Kafka 的設計初衷是為了追蹤使用者行為。使用者於前端系統完成的任何行為，都會產生大量資料，包含被動資料（例如：Page View、 Search Result、Click 事件等等），或其他更複雜的行為（例如：帳號註冊事件）。

這些事件會被發佈到專門的 Kafka Topic 上，隨後被後端應用程式消費，並應用於監控、分析、報表製作、個人化推薦系統等領域。

例如，電商平台可以將使用者行為事件發送到 Kafka，然後使用 Logstash 從 Kafka 消費這些事件，並將其轉發到 Elasticsearch 中進行索引和儲存。接著，可以使用 Kibana 來視覺化和分析這些使用者行為資料，例如：使用者訪問路徑、熱門商品、轉化率等，從而更好地了解使用者行為，並優化產品和服務。

行為追蹤應用場景

電商平台即時追蹤訪客活動。每個訪客觸發的事件，例如：Page View、Add to Cart、Purchase、Search Result 等，都可以作為事件並發佈到特定的 Kafka Topic。這些事件隨後被消費者訂閱，並能夠用於推薦、個人化折扣、報告和詐欺檢測。

二、消息傳遞

Kafka 允許應用程式向使用者傳遞消息（如：電子郵件）時，無需擔心資料格式或消息是否已確實送出。

開發者只需透過 Kafka 就能夠讀取所有送出的消息，並統一管理，例如：將消息整理成常見格式、將收集的大量消息於一次通知時同時傳送或利用開發者偏好的方式傳送。

消息傳遞應用場景

使用微服務架構的叫車系統透過 Kafka 在不同程式間傳送消息，例如：當客戶預訂叫車行程時，行程預訂程式可透過 Kafka 向司機匹配程式發送一條消息，然後司機匹配程式再匹配到附近司機後迅速回傳消息，而這些消息傳遞都是即時進行的。

三、量測值與日誌

Kafka 也能追蹤系統量測值與監控系統日誌，當生產者將消息發佈到 Kafka Topic 後，這些消息會在 Kafka Cluster 上被聚合，集中存放於文件伺服器或 HDFS，方便後續存取。

這些消息能被監控或告警系統消費，也同時適用於離線系統（如 Hadoop）執行長期趨勢分析的任務，例如：成長率預估。此外，Kafka 也允許將日誌檔案寫入 Elasticsearch 這類日誌搜尋系統或資安分析應用程式。

在使用 Kafka 處理日誌和量測值時，安全性非常重要。HashiCorp Vault 可以幫助您保護 Kafka 的安全性，例如：使用 Vault 來管理 Kafka 的連線憑證，例如使用者名稱、密碼、SASL / Kerberos 金鑰等，並提供動態 secrets 生成和租用功能，降低安全風險。此外，Vault 還可以加密 Kafka 的資料，確保日誌和量測值的機密性。

量測值與日誌應用場景

雲端供應商利用 Kafka 聚合和監控來自各服務的運營指標。例如：由數百台伺服器回傳的 CPU 使用率、記憶體使用率、請求次數、錯誤率等指標可以發佈到 Kafka 上，再將其應用於即時視覺化、偵測告警事件以及檢測異常情況。

四、即時資料處理

許多系統需要在接收消息後立即處理，Kafka 能以極低的延遲時間（ 5 毫秒內）將消息從生產者傳送到消費者，這對以下領域至關重要：

金融機構：使用 Kafka 即時收集和處理支付及金融交易，一但檢測詐欺交易就立即終止，或即時更新報價單。

物聯網（IOT）：通過預測性維護（Predictive Maintenance）模型持續分析設備回傳資料；當模型檢測到帶有故障風險的異常資訊時，即可觸發系統警告。

物流業：利用監控程式追蹤貨船航行位置以提供即時的到貨進度。

例如，金融機構可以使用 Kafka 和 EDB PostgreSQL 來構建實時交易處理系統。Kafka 可以用於接收和處理大量的交易資料，EDB PostgreSQL 可以用於儲存和分析這些資料。通過 Kafka 和 EDB PostgreSQL 的整合，可以實現交易的即時監控、風險管理和欺詐檢測。

即時資料處理應用場景

金融業透過 Kafka 實現即時交易處理。每筆客戶交易資料都會作為事件發佈到 Kafka Topic 上供消費端應用程式讀取，這些資料會被用於分析、追蹤並偵測金融市場活動。

歐立威科技致力成為全方位開源軟體解決方案與資料分析專業建置商，我們提供 Kafka 平台的規劃部署、架構整合、教育訓練與技術服務，幫助客戶利用 Kafka 打造良好的資料流架構，讓他們專注於發展核心業務。如果想要獲得更多資訊，歡迎與我們聯繫。

加入歐立威 LINE 好友，了解更多產品資訊

Pentaho ETL 實作技巧：無共通欄位資料合併 Merge join & Multiway merge join

Omni — Fri, 17 Nov 2023 10:21:37 +0000

對於使用 Pentaho (或者類似產品 Kettle / Hop) 這類 ETL 工具的開發人員來說，總有一些藏在角落、鮮為人知的方便功能。
筆者在此將講解有關 Pentaho 流程中，Merge join 與 Multiway merge join 的資料合併做法。

資料合併步驟

Merge join

萬一要合併的兩個資料來源，不屬於同一個資料庫伺服器，甚至不是資料庫來源呢?

這時 Merge join 就派上用場了。

Merge join 會合併兩個步驟傳遞的資料(包含資料庫來源、檔案來源等)，可選擇 INNER JOIN 或多種 OUTER JOIN。

Merge join流程示意圖

Merge join設定視窗

設定需合併資料的步驟：
First step
Second step

選擇合併方式：
INNER, LEFT OUTER,
RIGHT OUTER, FULL OUTER

設定合併關聯鍵：
Keys for 1st step:
Keys for 2nd step:
(可用 Get key fields 快速加入)

Multiway merge join

糟糕，Merge join 只能合併兩個資料來源，但是來源有三個，該怎麼辦？

別急，這裡還有 Multiway merge join 可以幫忙。

步驟 Multiway merge join 會合併兩個以上步驟傳遞的資料(包含資料庫來源、檔案來源等)，可選擇 INNER JOIN 或

FULL OUTER JOIN。

Multiway merge join流程示意圖

Multiway merge join設定視窗

設定輸入步驟：Input Step（n）
※ 欄位數量隨連結步驟而增減

設定合併關聯鍵：Join Keys
※ 必須點選 Select Keys 按鈕、開啟小視窗填寫關聯鍵名稱

選擇合併方式：Join Type: （INNER 或 FULL OUTER）

「常值膠帶」與「序列膠帶」

看過標準的 join 步驟，可能有人會問：每次都要設定共通欄位，有沒有更便利的方法?

方法有，而且步驟連起來就可以。

情境：兩股資料來源、資料欄位組成相同

資料來源A (左側ABC字樣)

資料來源B (右側JKL字樣)

兩個來源都由欄位 name, score 組成

預期結果：
合併資料、每列資料呈現所有資料來源欄位

「常值膠帶」：利用 Add constants 步驟追加固定常值，合併多股來源資料

※ 注意：資料合併順序受資料來源步驟建立順序影響，可後續追加 Sort rows 步驟重新排序

「序列膠帶」：利用 Add sequence 步驟追加固定序列，合併多股來源資料

※ 注意：資料合併順序受資料來源步驟建立順序影響，可後續追加 Sort rows 步驟重新排序

無共通欄位情境處理

看過前面的介紹，資料合併動作都在「有共通欄位」的前提下完成。如果有兩股以上、沒有共通欄位的資料載入 Pentaho，如何實現欄位合併？

那就自己製造共通欄位！

「常值雙面膠」：配合 join 一對多合併

情境：兩股資料來源、資料量不同、沒有共通欄位可以對照

資料來源A：欄位 group

資料來源B：欄位 name, score

預期結果：合併資料、每列資料呈現所有資料來源欄位

合併資料：欄位 group, name, score

利用 Add constants 步驟添加相同內容欄位，配合 Merge join 步驟指定新欄位、完成合併

※ 如果來源超過兩項，可改用 Multiway merge join 步驟執行合併

「序列雙面膠」：配合 join 多對多合併

情境：兩股資料來源、資料量相同、沒有共通欄位可以對照

資料來源A (左)：欄位 group

資料來源B (右)：欄位 name, score

預期結果：合併資料、每列資料呈現所有資料來源欄位

利用 Add sequence 步驟添加序列，配合 Merge join 步驟指定新欄位、完成合併

※ 如果來源超過兩項，可改用 Multiway merge join 步驟執行合併

Pentaho ETL 實作技巧：SQL 動態內容引用 Table input & Execute SQL scripts

Omni — Fri, 17 Nov 2023 10:09:34 +0000

對於使用 Pentaho（或者類似產品 Kettle / Hop）這類 ETL 工具的開發人員來說，總有一些藏在角落、鮮為人知的方便功能。

在此講解有關 Pentaho 流程中，使用 Table input 與 Execute SQL scripts 兩種流程步驟的動態內容引用。

什麼是動態內容?

在 Pentaho 的各項流程步驟中，雖然 Table Input 與 Execute SQL Script 都可以直接填寫 SQL 語句，但固定條件值往往需要 ETL 流程設計者手動調整，這不僅降低效率，也增加出錯風險。若將 SQL 語句設定為「動態內容」，流程就能轉換為函式（function）結構，取代人工調整，並可透過使用者輸入或上游步驟查詢的資料獲得結果，大幅提升效率並減少錯誤發生！

由於不同資料庫產品的特性各異，Pentaho 提供了兩種方式將「動態內容」引入 SQL 查詢中。本文將以變數與參數來區分，並詳細說明各種引入方法。

定義「變數」與「參數」

在進入操作說明之前，為避免 Pentaho 介面上的名詞造成混淆，本文先釐清在 Pentaho 應用範圍內，「變數」與「參數」的差異：

變數 (variables)

通過流程步驟 Set variables 與 Get variables 載入的 SQL 動態內容，稱為「變數」。

「變數」可以在 Transformation / Job 流程的屬性 (Properties) 設定中，利用「Parameters」區域進行定義（如欄位名稱、預設值、欄位說明等）

※在畫面空白處可用滑鼠右鍵（或左鍵連續點擊）點選「Properties…」選項進入屬性設定（上圖紅框處），選擇「Parameters」區域即可定義「變數」（下圖）

「變數」的利用方法有二：

1. 呼叫 Transformation / Job 流程時指定內容

1. 利用流程步驟 Set variables 與 Get variables 指定流程中產生的目標內容

受到 Pentaho 當中 Transformation 流程特性[1]影響，所有步驟「幾乎同時執行」，當一個 Transformation 設定「變數」後，該流程無法使用「變數」，必須透過 Job 流程傳送到另一個 Transformation，才能利用先前設定的「變數」。

※Set variables 步驟確認離開時，會出現提示：同一 Transformation 內無法使用新增「變數」

參數（parameters）

通過 Transformation 流程中繼資料欄位 (fields) 取用的 SQL 動態內容，稱為「參數」；「參數」出現在 Spoon 執行流程後、執行結果（Execution Results）的 Preview data 頁籤：

※ （圖A）Pentaho 流程執行後，下方的執行結果可選 Preview data 查看不同步驟的「參數」呈現

和「變數」不同的是，「參數」可以直接在同一 Transformation 當中進行利用，由於「參數」本質仍是 ETL 流程的中繼資料，因此經過其它步驟，內容仍會因為篩選而變化（如 Select values、Filter rows）或者遺失（如 Table input）。

※ （圖B）相對於圖 A，「參數」經過流程步驟 Select values，欄位可能減少或更換名稱

（圖C）相對於圖 A，「參數」經過流程步驟 Filter rows，受到篩選條件影響、產生資料列數量變化

※ （圖D）相對於圖 A，「參數」經過流程步驟 Execute SQL scripts，由於該項步驟不輸出內容，故不會變化

※ （圖E）相對於圖 A，「參數」經過流程步驟 Table input，由於該項步驟必定輸出內容，故內容被步驟輸出替代

「變數」文字替代

變數文字替代（Variable substitution）需要在 SQL 語法中填寫 ${variable} 標記[2]，括號內名稱自訂，以流程屬性定義為主，且字串內容必須追加單引號；之所以叫做「文字替代」，是因為動態內容會直接替代變數標記，才送出語法執行。

- 勾選選項「Replace variables in script?」啟用變數文字替代[3]

- SQL 語法動態內容位置填寫「${variable}」標記（字串內容必須添加單引號，數值、布林值除外）

Execute SQL script 變數文字替代方法

- 勾選選項「Variable substitution」啟用變數文字替代[4]

- SQL語法動態內容位置填寫「${variable}」標記（字串內容必須添加單引號，數值、布林值除外）

「參數」綁定

相對於變數文字替代，參數綁定（Bind parameters）只要在SQL語法中填寫「?」標記即可，不過需要「參數」的數量、順序，必須與語法結構保持一致。

以效能角度比較，變數文字替代產生的SQL語法，儘管架構相同，資料庫掃描語法時，卻因為動態內容「一字之差」，視為不同的查詢，每次查詢便重做執行計畫，屬於美中不足；

參數綁定產生的 SQL 語法不同，語法、動態內容分開送出，資料庫掃描後，即可套用首次掃描的執行計畫，才引入動態內容，大幅增進查詢效能。實際設計流程時，流程步驟 Table input 與 Execute SQL script 對「參數」的影響也有所不同：
前者會傳回查詢結果、替代「參數」欄位，後者則保持原樣，「參數」可以繼續利用[5]。

Table input 參數綁定方法

- 屬性「Insert data from step」選擇流程上一步驟，啟用參數綁定[6]

- 勾選選項「Execute for each row?」確保動態內容通過「資料列逐一輸入」執行

- SQL語法動態內容位置填寫「?」標記即可
  - - 注意：由於參數綁定對數量、順序要求，上一步驟應使用Select values進行欄位排序、複製與重新命名

Execute SQL script參數綁定方法

- 先後勾選選項「Execute for each row?」以及「Bind parameters?」，啟用參數綁定[7]（必須勾選「Execute for each row?」，選項「Bind parameters?」才能操作）

- SQL語法動態內容位置填寫 ? 標記即可，參數可在左下角”Parameters」表格填寫（須按照標記順序；欄位可重複填寫）

「參數」綁定SQL語法的限制

利用參數綁定執行 SQL 腳本時，可能遭遇下面的狀況：

腳本存在多段分號間隔語法

儘管參數綁定可以增進查詢效能，但不代表可以處理結構複雜的腳本。
如果有一段SQL腳本具有下面的結構：

“

UPDATE… SET… WHERE = ? AND = ? ;

SELECT… FROM… WHERE = ? AND = ? ;

“

按照前述解說，參數可能按照「ABAB」格式做綁定、順利完成作業，然而實際執行流程後，Pentaho 可能會回覆異常訊息：

“

：Unable to set value on prepared statement on index 4.

欄位索引超過許可範圍：3，欄位數：2。

“

或者

“

Error setting value #1 on prepared statement

欄位索引超過許可範圍：1，欄位數：0。

“

這是因為 Execute SQL scripts 步驟只會執行分號間隔最後一段語法，如果指派參數數量超過最後一段語法指定數量，或者最後一段語法沒有指定參數，就會出現上述異常訊息。

腳本需要利用暫存表 (temp table)

腳本內容在 Pentaho 執行時，可能遭遇效能較差，需要利用暫存表的情形。需要注意的是，前述 Transformation 流程特性當中，不只所有步驟「幾乎同時執行」，而且是各個步驟「執行完畢即釋放資源」。

因此，不僅建置暫存表、查詢暫存表的語法無法寫在同一步驟，即使分開執行，由於ETL步驟的工作階段(session)完成後馬上結束，暫存表建立完成的當下，也會馬上被消滅[8]。

參考資料

[1] StackOverflow問答 “Am I using switch/case wrong here to control?”，2022-05-30

[2] Pentaho官方文件 “Variables – Hitachi Vantara Lumada and Pentaho Documentation”，2021-10-08

[3] Pentaho官方文件 “Table Input – Hitachi Vantara Lumada and Pentaho Documentation”，Options段落，2021-10-08

[4] Pentaho官方文件 “Execute SQL Script – Hitachi Vantara Lumada and Pentaho Documentation”，Options段落，2021-10-08

[5] StackOverflow問答 “Pentaho Transformation “Execute SQL Statements” vs “Table Input” step”，2018-07-12

[6] 同[3]，Example段落

[7] 同[4]

[8] StackOverflow問答 “How to create a Temporary Table using (Select * into ##temp from table) syntax(For MS SQL) using Pentaho data integration”，2014-03-04

加入歐立威 LINE 好友，了解更多產品資訊

PB 級 ETL 獨門秘器 – Greenplum GPFDIST 介紹與使用情境

Omni — Mon, 12 Dec 2022 10:43:21 +0000

誰適合看這篇文章

正在使用 Greenplum 或有意了解 Greenplum 的工程師

對 GPFDIST 有興趣的使用者

可以得到什麼收穫

了解 GPFDIST 基本介紹

創建透過 GPFDIST 協定的外部表語法

什麼是 GPFDIST

GPFDIST 是 Greenplum Database parallel file distribution program，專門用於處理 Greenplum 對外部檔案進行讀取或寫入。由於 GreenPlum 將自身定位為可處理 PB 等級資料的數據倉儲產品，因此在實際應用場景中，必然會有 ETL 大量資料匯入的需求，此時就可以透過 GPFDIST 以平行處理、協同作業的方式進行極為快速的資料處理。

一般來說，要將外部資料匯入資料庫的方法主要有下面兩種：
(1) 單純一筆一筆資料 insert
(2) COPY from File

而上述方法都需要仰賴 Master (主節點) 耗費資源來獨立處理，因此可以想像當有大量資料待處理時，不但耗時甚久更可能影響到其他作業程序。

為了解決上述問題並且加速匯入流程，Greenplum 提供了一個基於其 MPP 架構 (Massively Parallel Processor) 的內部套件，也就是 GPFDIST。透過 GPFDIST 可以驅動各個 SEGMENT 平行讀寫來源檔案，進而增加匯入效率。

GPFDIST 特點介紹

由於 GPFDIST 與各 SEGMENT 是透過 HTTP 協定進行溝通，因此我們可視 GPFDIST 將為 HTTP SERVER 專門處理資料的傳輸發送，而各 SEGMENT 則扮演 HTTP CLIENT 的角色，對 GPFIDST 發送 GET/POST 等請求，受益於這樣的架構概念，帶來了下面幾項特點：

(1) 支援各種來源檔案

由於 ETL 或其他來源的資料格式都各不同，因此 GPFDIST 支援了常見的 TEXT、CSV 之外，也能透過 yaml 檔來進行JSON、XML 的轉置導入，而且在建立外部表時，透過 wildcard(*) 來代替完整檔名，在有多份文件匯入時，相當的方便。

除此之外，ETL 時常產出數百 GB 的資料，而這樣龐大的資料直接佔據硬碟空間，其實是很不明智的，因此針對被壓縮過的 ETL 資料檔 (gzip bzip2 bz2 zstd)，GPFDIST 能夠自動解壓縮並且成為外部表的來源，透過 CPU 的運算能力來降低對空間的使用率，使其在各項考量中取得良好的平衡。

(2) 彈性部署支援

為了讓 Greenplum 主機的資源發揮到最大，通常會規劃將非必要的 loading 放在 ETL 主機執行，此時就可以根據資源的考量，GPFDIST 不只可以隨著 Greenplum 安裝在主機上之外，也能夠部署到 ETL 主機群上，並且透過建表時指定不同網卡 (NIC) 來讓 SEGMENT 們平行讀取/傳輸檔案。讓資料匯入的效率可以大幅提升，而不再將 loading 都依賴 Master 主機上。

而要將 GPFDIST 部署到 ETL 主機上也相當簡單，只要確認好 OS 有相依的套件，就可以直接將 GPFDIST 執行檔複製到 ETL 主機上執行。

# gpfdist version "6.22.0"
[root@mdw ~]# ldd ./gpfdist
        linux-vdso.so.1 (0x00007ffd0705d000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb00ec37000)
        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fb00e9a3000)
        libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fb00e4ba000)
        libyaml-0.so.2 => /lib64/libyaml-0.so.2 (0x00007fb00e29a000)
        libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fb00dff6000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fb00ddde000)
        libevent-2.1.so.6 => /lib64/libevent-2.1.so.6 (0x00007fb00db85000)
        libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007fb00d94b000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb00d72b000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb00d366000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fb00d162000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fb00cf5a000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb00cd31000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb00ee48000)

語法範例

此處提供了上圖內三種常見情境的對應建表語法(以可讀表為例)，並且將兩組 GPFDIST 運行於 ETL SERVER 中。

模擬資訊如下：

Host_NIC_Name	IP
etl_NIC_1	192.168.0.10
etl_NIC_2	192.168.0.11

ETL 主機運行 GPFDIST 指令：

#透過nohup讓GPFDIST在背景常駐執行
# -p       //指定PORT
# -d    //匯入或讀取資料的目錄路徑
# -l    //GPFDIST執行時的log存放目錄

nohup gpfdist -p 8080 -d /home/gpadmin/ext_folder/ -l /home/gpadmin/gplog1 &
nohup gpfdist -p 8081 -d /home/gpadmin/ext_folder/ -l /home/gpadmin/gplog2 &

情境 1 – 單 GPFDIST，單檔案

檔名: ext_file.csv

CREATE EXTERNAL TABLE ext_omni_1 (id int, name char(10)) 
LOCATION ('gpfdist://etl_NIC_1:8080/ext_file.csv') 
FORMAT 'csv';

情境 2 – 單 GPFDIST，多檔案

檔名: ext_file1.csv , ext_file2.csv

CREATE EXTERNAL TABLE ext_omni_2 (id int, name char(10)) 
LOCATION ('gpfdist://etl_NIC_1:8080/ext_file1.csv', 
          'gpfdist://etl_NIC_1:8080/ext_file2.csv') 
FORMAT 'csv';

-- 利用wildcard，指定相關檔案 
CREATE EXTERNAL TABLE ext_omni_3 (id int, name char(10)) 
LOCATION ('gpfdist://etl_NIC_1:8080/ext_file*.csv') 
FORMAT 'csv';

情境 3 – 多 GPFDIST，多檔案

檔名: ext_fileA.csv ext_fileB.csv

-- 在/home/gpadmin/ext_folder/下有兩個子目錄: folder_A 及 folder_B
CREATE EXTERNAL TABLE ext_omni_4 (id int, name char(10)) 
LOCATION ('gpfdist://etl_NIC_1:8080/folder_A/ext_fileA.csv', 
          'gpfdist://etl_NIC_2:8081/folder_B/ext_fileB.csv') 
FORMAT 'csv';

[注意] 每張外部表在 location 內的 url 數量，不可以超過 primary instance 的個數。

匯入資料

#讀取外部表 ext_omni_1
 SELECT * FROM ext_omni_1;
 
#將外部表 ext_omni_1 匯入到內部表 omni_table 當中
 INSERT INTO omni_table SELECT * FROM ext_omni_1;

結論

GPFDIST 做為一款 Greenplum 當中能支援多面向的平行資料傳輸工具，不但相當輕量化而且也能和其他 ETL 系統、服務進行資料流的串接整合。對於需要處理大量資料的 ETL 開發端，更是相當的好上手並且支援多種功能。

除此之外，若是有資料安全的考量，也能支援 SSL 的 gpfdists://Protocol，而當要對匯入的資料內容做更細微處理，Greenplum 更有提供一個以 GPFDIST 為基礎的工具 -GPLOAD，來滿足相應的資料轉置需求。因此在 Greenplum 的環境下，相當推薦使用 GPFDIST 來代替過往單靠 Master 來匯入資料的功能。

[REF]

https://cn.greenplum.org/greenplum-external-table/

https://greenplum.org/greenplum-etl/

https://docs.vmware.com/en/VMware-Tanzu-Greenplum/6/greenplum-database/GUID-admin_guide-external-g-using-the-greenplum-parallel-file-server–gpfdist-.html

Pivotal 產品介紹: Greenplum Stream Server

Omni — Fri, 18 Jun 2021 11:37:31 +0000

概述

Greenplum Stream Server (GPSS) 是一個 ETL 工具，用於提取、轉換、加載數據。

從單個或數個用戶端擷取數據流，並藉由 Greenplum 資料庫的可讀式分類表轉換數據並新增至選定 Greenplum 表格中，而資料的來源和格式則專於客戶端 ── 以上為 GPSS 實例。

GPSS 包括 gpss 命令列工具 (command-line utility)，這也代表當用戶使用 gpss 時， GPSS 的一個實例會被開啟── 也就是會無限期的等待來自客戶端的數據。

此外，GPSS 也擁有 gpsscli 命令列工具── 一個向 GPSS 實例回報數據加載工作並管理作業的客戶端工具。

架構

Greenplum Stream Server 是一個 gRPC 服務器，不論是連接到 Greenplum 資料庫和檢查 Greenplum metadata ，或是將數據從客戶端寫入 Greenplum 資料庫表過程中所需的操作和資訊，都屬於 GPSS gRPC 的業務範疇。

Gpsscli 公用程式是 GPSS 的一個 gRPC 客戶端，而 Greenplum-Kafka 整合和 Greenplum-Informatica 連接器也是如此，這讓使用者能夠透過 GPSS API 開發自己的 GPSS gRPC 客戶端。

圖示. Greenplum Stream Server 架構

使用 GPSS 執行 ETL 任務的常見事件順序如下：

使用者透過客戶端應用程式啟動一個或多個 ETL 負載任務

客戶端應用程式藉由 gRPC 協議向執行中的 GPSS 服務實例提交數據並啟動加載作業。

GPSS 服務實例向 Greenplum 資料庫集群中的主管實例提交每一個加載要求事項，並創建或重新使用外部表格以儲存數據。

GPSS 服務實例將來自客戶端的數據直接寫入 Greenplum 資料庫集群的分段中。

限制

Greenplum Stream Server 不支援將多個 Kafka 主題數據加載至單一 Greenplum 資料庫表中。

若 GPSS 遭遇此情況，所有作業將停止。

更多 Greenplum 資訊請至產品專區。

聯絡我們

Expedia 利用 MongoDB 打造個人化的線上旅遊服務

Omni — Mon, 22 Jan 2018 09:12:05 +0000

Expedia 的 Scratchpad 應用程式替上百萬客戶重塑旅遊體驗

規劃假期是很難的。您需要處理出行日期、目的地、航班、汽車租賃和酒店訂位等等的問題。價格與可用性隨時在變，而您還得和其他旅客不停競爭。

一個典型的消費者在訂購機票之前，會搜索48個不同的網站，從筆電用到手機，又從手機繞回筆電，反覆不斷。這種零零散散不時開始又停止的研究，可以持續好幾天的時間。在一系列操作中，大多數人都會忘記自己有普搜過某些訊息，因此多次重複同樣的搜尋。另一些人則會用紙筆記下筆記，來好幫自己下決定。

對於企圖追求旅程的百萬名顧客，Expedia有一個更好的方法。

忘記便利貼吧！來看看 Scratchpad，Expedia 用 MongoDB 建立全新程式

旅行者們以不同的方式尋找它們的理想之旅。有些人可能會從一間酒店開始，其他人則從他們偏好的航空公司動手，另一些人則依照使用日期和目的地來列表下決定。有了Scratchpad，Expedia的會員們可做出它們的最佳選擇。

Scratchpad會自動化筆記的過程、有智慧的記住過往的線索，它會尋找最低價格，並讓購物期間各種切換設備的嘗試變得很容易。您可以一開始在筆記型電腦上查找資料，接著在地鐵上用你的智慧型手機，等到明天再透過平板和您的同行者一起交換檢視這些訊息。

沒有 MongoDB，它會需要一個大的多的團隊，才足以讓這個應用程式如此快的出現在市場上

Scratchpad 讓搜索過程變得快速、方便和個人化。它使人們可在不同的旅遊網站間交叉切替。並戲劇性的提高了Expedia的轉換率。這替Expedia帶來巨大的競爭優勢。而這一切沒有MongoDB是不可能完成的。

快速提供個人化

線上旅遊市場是複雜且經常劇烈變動的。一方面是供應商不斷變更庫存與價格資訊。另一方面，購物者經常交叉混用各種不同的裝置與瀏覽器來參觀網站。這造成了數量龐大且高度變異的訊息。

「線上旅遊服務是一塊難啃的骨頭。」Expedia的技術工程主任Mirari Gopalan是這麼說的。像Scratchpad這種應用程式的需求出現已久，而傳統RDBMS資料庫的硬性限制卻偏偏堵住了開發。

MongoDB打開這扇新的大門。讓Expedia能夠使願景成為現實。而且比預期還要快。只有三個人的開發者小組，只用不到兩個月時間就做出Scratchpad的原型。

用 MongoDB 達成即時個人化

Expedia的搜索橫跨多個不同的業務領域，從航班、酒店到活動全都包括在內。而這些所有項目都具有截然不同的屬性：航班有班機時間和轉機數，租車則有款式大小的不同。客戶可能被登入或是匿名。它們會看不同的產品，圖片和各種評論。並會想針對它們的發現輸入一些文字筆記。而所有這一切，全都與大量的非結構化資料有關。

在關聯式資料庫中，用ETL來標準化所有客戶、session和產品資料，並將其放入只能應對預定義查詢操作的資料倉儲中，是既困難又緩慢。這不是Scratchpad所做的選擇。

在線上旅遊服務的領域中，客戶需要的是即時性強且高度關聯的結果。

MongoDB的彈性文件儲存結構，和簡潔的橫向擴展結構，讓Expedia足已提供一個相關性強且流暢平滑的購物體驗。它能收集快速變化的客戶訊息，並提供即時的個人化報價資訊。這一切都是透過能縮放規模的技術所完成的。

MongoDB的彈性資料模型可以方便的儲存城市、日期與地點的混合資訊。Expedia還允許用戶在當前的會話結束後一就能繼續購物。當用戶回來時，所有它們先前搜尋結果的最新價格與可用性資料，都會並排顯示在它們的Scratchpad畫面裡。

MongoDB豐富的索引機制適合在用戶購物時進行即時分析，並提供相應的個人化建議。Expedia還可以透過分析模式來更好的理解並交出客戶所期待的東西。

對於消費者而言，個性化節約了時間和金錢，並讓他們逐步接近它們真正想要的東西:一個美好的假期。對Expedia來說，MongoDB提供的個人化查詢帶來了更高的客戶忠誠度、更大的轉換率和更強的競爭優勢，讓他們能直抵目標。

讓痛苦更少，即時完成激進的資料結構變化

情勢會變，願景會演進。如果資料庫沒有彈性，創新就會撞上牆。Scratchpad發布後沒多久，Expedia就收到大量的客戶回應。鑒於這些回應，Expedia針對資料結構進行了三次巨大的改變。業務的快速變動是預料中的事。但這不意味著這是份簡單的任務，至少對大部分資料庫來說不是如此。通常情況下，Expedia必須被迫忍受網站上出現可怕的「停機維護」頁面。

幸運的是，MongoDB讓Expedia可以一邉從根本上激進修改資料架構，一邊如常運行，對客戶體驗豪無影響。而且三次都是如此。

這種能適應變更的能力，是Expedia得以用迭代模式發展的關鍵。透過測試中學習的開發方法，Expedia很高興能在將它們的產品變成一個大規模解決方案前，先一步看到用戶會如何與新功能互動。大多數關聯式資料庫無法使用這種方法來達成目標。而MongoDB可以。

容易使用、容易變更、容易規模化。MongoDB正是現代開發團隊所需要的。

自由的創新

Expedia已經破解了線上旅遊服務的秘密。假期搜尋不再讓用戶痛苦煩憂。而把構想變成服務對開發者來說也不再是難事。

Scratchpad目前在美國、英國、日本等其它30個國家市場推出。在MongoDB原生的分片功能支援下，這種全球規模的增長也同樣得到支持。讓Expedia可以將資料橫向擴展到多個跨國的資料中心中。

資料量將增加。應用程序將繼續演化。Expedia已經準備好了，和允許它們自由創新成長的資料庫一起。