如何利用資料湖整合實現傳統大型主機的現代化

許多大型企業仍依賴傳統大型主機來運行處理大量交易資料的關鍵任務工作負載。數十年的投資使這些系統穩定、安全，並深度嵌入核心業務營運。同時，企業面臨越來越大的壓力，需要利用這些數據進行現代分析、人工智慧計畫和即時決策。

現代資料湖提供了一種靈活且經濟高效的方法來集中來自不同來源的資料。它們支援讀取時模式存取、可擴展的物件存儲，並與強大的雲端原生分析服務整合。將大型主機資料整合到資料湖中，可以打破傳統的資料孤島，支援高級分析模型，並為資料科學家和業務用戶提供自助訪問，從而釋放新的價值。

然而，將大型主機資料與現代資料湖整合絕非易事。 遺留系統 通常使用專有儲存格式，例如 VSAM、IMS 或帶有 COBOL Copybook 的 DB2，並且通常使用 EBCDIC 而非 ASCII 或 UTF-8 編碼資料。以批次為導向的模型必須與串流架構和即時分析需求相協調。安全性、合規性和資料沿襲方面的考慮進一步增加了複雜性，需要周密的規劃和強大的治理模型。

尋求連接這些環境的組織面臨著關於整合模式、技術選擇和營運要求的重要設計決策。從批次 ETL 作業到變更資料擷取和基於 API 的微服務，不同的方法在以下方面存在著不同的權衡： 潛伏、複雜性和成本。選擇正確的策略取決於工作負載特徵、資料新鮮度需求和監管限制等因素。

成功的整合工作能夠將業務目標與技術架構結合，充分利用合適的工具和平台，並建立可重複的營運實務。最終形成一個混合環境，其中遺留系統能夠繼續提供關鍵的交易功能，同時將其資料貢獻給現代化、可擴展的分析平台。

了解傳統大型主機

數十年來，大型主機一直是企業運算的支柱。它們以可靠性、可擴展性和處理大量事務工作負載的能力而聞名，在銀行、保險、醫療保健和政府等行業中至關重要。

這些系統通常基於 IBM z/OS 或 Unisys 等成熟平台構建，並支援經過多年開發的高度最佳化的應用程式。其運作特性包括可預測的效能、強大的安全性和廣泛的稽核功能。儘管它們穩定，但它們通常依賴較舊的設計模式，這些模式很難與現代架構整合。

大型主機上的資料通常以專有或傳統格式儲存。常見的儲存機制包括 VSAM 資料集、IMS 層次資料庫和 DB2 關係表。許多此類系統使用 COBOL 副本來定義複雜的記錄佈局，並且資料通常採用 EBCDIC 編碼，而不是大多數現代系統使用的 ASCII 或 UTF-8 標準。

從操作角度來看，大型主機主要面向批次處理。夜間或定期的批次作業會根據長期制定的計畫提取、轉換和載入資料。雖然一些大型主機也支援線上事務處理 (OLTP) 和基於訊息佇列的集成，但主流集成模式仍然是面向批次的。

這種環境雖然穩健，但在與強調靈活的讀取模式存取、分散式物件儲存和即時分析的現代資料湖整合時，卻面臨著巨大的挑戰。在嘗試任何整合工作之前，了解底層大型主機資料結構和操作模型至關重要。成功的策略需要透過精心的資料映射、轉換和編排來處理這些差異，以確保遺留系統能夠與現代分析平台可靠且安全地共享資料。

現代資料湖架構

現代資料湖旨在將各種資料來源整合到可擴展的儲存庫中，以服務各種分析和營運用例。與嚴格遵循「寫入時模式」要求的傳統資料倉儲不同，資料湖遵循「讀取時模式」原則。這種方法允許以原始數據原生形式提取數據，並在查詢時靈活地進行解釋，從而實現快速實驗並滿足不斷變化的分析需求。

大多數資料湖架構的核心是物件存儲，它為結構化、半結構化和非結構化資料提供幾乎無限的可擴展性和經濟高效的存儲。熱門選項包括 Amazon S3、Azure Data Lake Storage、Google Cloud Storage 以及 Hadoop 分散式檔案系統 (HDFS) 等本機解決方案。這些系統針對高耐用性和低成本存檔進行了最佳化，支援大規模提取和檢索模式。

資料湖通常採用 Parquet、ORC 和 Avro 等現代資料格式。這些列式格式能夠實現高效率的儲存和檢索，尤其適用於分析工作負載。它們支援進階壓縮技術和謂詞下推，從而顯著提升查詢效能並降低儲存成本。

元資料管理是資料湖設計的關鍵組成部分。 AWS Glue 資料目錄、Azure Purview 等服務，以及 Apache Hive Metastore 等開源解決方案，提供了集中式架構定義、資料沿襲追蹤和治理控制。元資料層可以大規模組織資料、強制執行存取策略，並為使用者和分析工具提供一致的視圖。

與處理框架的整合是另一個定義特徵。資料湖是分散式運算引擎（例如 Apache Spark、AWS Athena、Azure Synapse 和 Google BigQuery）的基礎。這些工具使資料科學家和分析師能夠運行複雜的查詢、建立機器學習模型，並直接針對資料湖開發即時儀表板。

隨著企業尋求資料架構現代化，資料湖已成為打破資料孤島、實現資料存取民主化以及釋放高階分析能力的策略賦能者。然而，實現這一願景取決於能否以既能保持資料品質、沿襲性和安全性的方式整合包括大型主機在內的遺留系統，同時又能使資料能夠被現代處理和分析工具存取。

集成挑戰

將傳統大型主機系統與現代資料湖整合是一項複雜的任務，需要仔細分析技術和組織方面的挑戰。這些挑戰源自於資料格式、處理範例、安全模型和營運預期的根本差異。

主要技術障礙之一在於資料格式不相容。大型主機通常以專有格式儲存數據，例如 VSAM 檔案、IMS 分層資料庫或帶有 COBOL 副本定義的 DB2 表。這些記錄佈局與 Parquet 或 ORC 等現代資料湖格式並非原生相容。此外，大型主機資料通常採用 EBCDIC 編碼，必須轉換為 ASCII 或 UTF-8 才能確保與當代工具和平台的互通性。

批次與串流整合範式的對比帶來了另一個重大挑戰。大型主機傳統上依賴計劃的批次作業（通常整夜運行）來處理和導出資料。雖然批次週期對許多營運工作負載有效，但它可能會引入延遲，這對於現代即時分析或機器學習應用程式來說是不可接受的。要彌補這一差距，需要重新思考整合模式，以支援變更資料擷取 (CDC) 或事件驅動的串流架構。

安全性和合規性考量進一步增加了複雜性。大型主機是值得信賴的記錄系統，通常包含受 GDPR、HIPAA 或 SOX 等嚴格監管控制的敏感資料。整合工作必須確保資料在傳輸和靜止狀態下均經過加密，透過 IAM 策略妥善管理存取權限，並保留稽核追蹤和沿襲以保持合規性。任何違規或配置錯誤都可能使組織面臨重大的法律和聲譽風險。

數據品質和沿襲要求也使整合項目變得複雜。大型主機資料結構可能非常複雜，包含密集嵌套的記錄佈局和嵌入式業務邏輯，必須仔細解碼和轉換。確保資料映射正確、轉換可驗證且沿襲可追踪，對於維護整合平台的信任至關重要。

營運挑戰不容小覷。整合工作必須可靠地編排、有效地監控，並設計得能妥善處理錯誤。大型主機團隊和資料工程團隊通常擁有不同的技能組合和工具偏好，從而形成組織孤島，阻礙協作。讓這些團隊在共同的目標、流程和平台上保持一致，對於成功至關重要。

應對這些挑戰需要採取一種策略方法，結合對現有系統的仔細評估、選擇適當的整合模式和工具，以及對確保長期安全性、可靠性和可維護性的營運實踐的投資。

整合模式與策略

將傳統大型主機與現代資料湖集成，絕非簡單地將資料從一個地方移動到另一個地方那麼簡單。它需要精心的架構選擇，以充分考慮資料結構、處理模型、延遲預期和安全要求的差異。

大型主機的建置旨在實現可靠性、穩定性和高容量批次處理，而現代資料湖則優先考慮靈活的讀取時模式儲存、可擴展計算和即時分析。連結這些環境意味著選擇既尊重大型主機營運現實又支援現代雲端原生資料消費的整合模式。

這些模式涵蓋傳統的批量卸載、高級即時串流以及基於 API 的微服務。每種方法都針對特定的業務需求和技術限制。金融機構可能需要每日批量報告以滿足合規性，同時透過 CDC 和串流管道實現近乎即時的詐欺偵測。保險公司可以使用 API 提供自助式保單查詢，而無需大量複製敏感資料。

因此，整合並非單一模式，而是根據資料新鮮度要求、工作負載特性和成本考量量身定制的多種方法的組合。設計這種整合策略對於釋放大型主機數據在分析、人工智慧和業務創新方面的價值至關重要。

下面，我們將詳細研究四種常見的整合模式，並提供實際的程式碼範例來說明如何在實際環境中實現這些解決方案。

大量卸載

批次卸載是最成熟的整合方法，利用大型主機友善的批次作業按預定間隔提取大量資料。組織通常已經擁有成熟的 FTP 或基於檔案的流程來匯出資料。

對於資料湖，批次處理不僅涉及行動數據，還涉及將傳統編碼（如 EBCDIC）和格式（COBOL 抄本）轉換為現代讀取模式格式，如 Parquet 或 Avro。

COBOL Copybook 程式碼片段範例
此程式碼片段定義了主機上客戶記錄的結構。

01 CUSTOMER-RECORD.
   05 CUST-ID         PIC 9(5).
   05 CUST-NAME       PIC X(30).
   05 CUST-BALANCE    PIC 9(7)V99.

此類抄本被解析並映射到 ETL 管道中的現代模式。

映射到 Parquet 模式（JSON 範例）
抄寫簿結構被轉換成適合寫入資料湖中的 Parquet 的 JSON 模式。

{
  "fields": [
    {"name": "cust_id", "type": "int"},
    {"name": "cust_name", "type": "string"},
    {"name": "cust_balance", "type": "decimal(9,2)"}
  ]
}

ETL 工具或自訂程式碼讀取導出的平面文件，解析副本佈局，並將記錄轉換為 Parquet 以實現高效的儲存和分析。

Airflow DAG 任務範例
Airflow 通常用於編排批量整合作業。以下是透過 FTP 擷取匯出的大型主機資料的簡單任務：

extract_task = BashOperator(
    task_id='extract_mainframe_batch',
    bash_command='ftp get mainframe_server VSAM_EXPORT.DAT /tmp/VSAM_EXPORT.DAT',
    dag=dag
)

實際上，DAG 可能包括格式轉換、模式驗證和載入到雲端儲存等其他任務。

大量卸載相對容易採用，因為它適合現有的大型主機流程。然而，它會帶來數小時到一整天的數據延遲，因此不太適合時間緊迫的分析。

變更資料擷取 (CDC)

CDC 透過僅複製對大型主機資料所做的變更來減少延遲。 CDC 解決方案無需重複移動整個表，而是監控日誌或日記中的插入、更新和刪除操作，然後將這些變更串流傳輸到資料湖。

這種方法最大限度地減少了資料移動，並實現了近乎即時的分析。它對於營運報告、機器學習管道或維護同步資料集市尤其有價值。

在 DB2 上啟用 CDC 的範例 SQL（概念）：

ALTER TABLE CUSTOMER
ENABLE CHANGE DATA CAPTURE;

此命令說明了啟動 CDC 的資料庫級配置，允許工具從交易日誌中讀取。

Kafka Connect CDC 連接器設定範例：
許多 CDC 解決方案與 Kafka 等訊息代理程式集成，以持續傳輸變更。以下是範例配置：

{
  "name": "mainframe-cdc-connector",
  "config": {
    "connector.class": "com.ibm.mainframe.cdc.Connector",
    "tasks.max": "1",
    "topics": "mainframe-changes",
    "mainframe.hostname": "mainframe.example.com",
    "mainframe.port": "5000",
    "mainframe.user": "cdc_user",
    "mainframe.password": "****",
    "poll.interval.ms": "1000"
  }
}

此設定將大型主機變更串流傳輸至 Kafka 主題，使其可供下游消費者使用，例如 Spark Structured Streaming 或寫入 S3 的 Kafka Connect Sinks。

CDC 顯著降低了延遲，但在確保一致性、排序和錯誤恢復方面帶來了複雜性。此外，它還需要仔細監控以處理日誌截斷或模式漂移等問題。

串流資料集成

串流整合透過即時處理變更事件，擴展了 CDC 的功能。它支援將大型主機更新持續傳輸到雲端分析系統的架構，從而支援詐欺檢測、個人化和營運儀表板等用例。

資料可以被提取到訊息佇列或流平台（例如 Kafka 或 IBM MQ）。然後，Apache NiFi、Spark Streaming 或 Flink 等處理框架可以將資料轉換並載入到資料湖中。

NiFi Flow 範例（偽 JSON）：
使用 NiFi 監視新的大型主機匯出並將其發佈到 Kafka 的簡化範例：

{
  "processor": "GetFile",
  "properties": {
    "Input Directory": "/mainframe/exports",
    "Polling Interval": "5 secs"
  },
  "next": {
    "processor": "PublishKafka",
    "properties": {
      "Topic Name": "mainframe-stream"
    }
  }
}

該流程自動拾取新的大型主機生成的檔案並將其作為事件發送到 Kafka，在那裡可以即時處理它們。

流式整合功能強大，但運維要求較高。它需要在監控、擴展以及處理延遲或亂序資料方面進行投入，以確保正確性。

公開 API 和微服務

移動批量資料的另一種方法是透過 API 公開大型主機資料和業務邏輯。此模式支援即時、按需訪問，無需複製整個資料集，從而減少了資料治理方面的顧慮。

可以使用 IBM z/OS Connect 等工具建立 API，該工具透過 REST 或 SOAP 介面實現對 CICS 事務或 DB2 查詢的存取現代化。

範例 z/OS Connect API 描述符 (YAML)：
此描述符定義了一個用於從大型主機檢索客戶資料的 REST 端點。

swagger: "2.0"
info:
  title: Customer API
  version: "1.0"
paths:
  /customer/{id}:
    get:
      summary: Retrieve customer data
      parameters:
        - name: id
          in: path
          required: true
          type: string
      responses:
        200:
          description: Successful response

cURL 呼叫範例：

curl -X GET "https://api.example.com/customer/12345" 
     -H "Authorization: Bearer TOKEN"

此呼叫直接從主機取得特定客戶的資料。

API 特別適合事務用例和外部整合。它們允許現代應用程式與大型主機系統交互，而無需大規模資料複製。然而，必須精心設計 API，以確保效能、安全性和可維護性。

選擇正確的模式

有效的整合策略通常會結合這些模式。大量卸載或許能夠滿足監管報告需求，持續數據驅動 (CDC) 和串流管道可以為近乎即時的分析模型提供數據，而 API 則可以為面向客戶的應用程式提供支援。

選擇合適的組合取決於業務優先順序、資料新鮮度要求、現有系統功能以及預算限制。成功的整合能夠使技術選擇與策略目標保持一致，同時確保大型主機系統作為企業資料格局的核心組件持續提供價值。

整合技術選項

將傳統大型主機與現代資料湖整合不僅需要架構規劃，還需要選擇合適的技術來處理大規模資料擷取、轉換、傳輸和載入的複雜性。

整合生態系統非常廣泛，涵蓋了從具有大型主機連接器的商業 ETL 套件到雲端原生服務、開源框架以及專門的供應商解決方案。每種方案都提供不同層級的抽象、自動化和控制，使組織能夠根據特定需求和約束條件來匹配工具。

商業 ETL 和整合工具

許多企業級 ETL 平台提供了強大的大型主機整合功能。這些工具旨在處理遺留資料結構、EBCDIC 編碼、COBOL 腳本以及複雜的批次作業調度。

譬如：

• IBM DataStage 和 InfoSphere Information Server：深度支援 VSAM 和 DB2 等大型主機來源，並具有高階元資料管理。
• Informatica PowerCenter：提供大型主機連線、資料品質功能和工作流程編排。
• Talend：其統一整合套件包含大型主機連接器和轉換元件。

這些工具透過視覺化設計器、可重複使用元件和企業級監控簡化了開發流程。對於已投資商業 ETL 解決方案的大型組織而言，它們通常是首選。

雲端原生服務

主要的雲端供應商提供託管整合服務，可以提取大型主機資料並以最少的基礎設施管理將其移至其儲存平台。

譬如：

• AWS 大型主機現代化資料複製：支援基於 CDC 將 DB2 或 VSAM 資料複製到 S3 或其他 AWS 服務中。
• Azure 資料工廠：為大型主機資料庫提供預先建置的連接器，並可協調批次或串流擷取至 Azure 資料湖儲存體。
• Google Cloud Dataflow：可與訊息佇列或自訂 CDC 串流集成，將大型主機資料轉換並載入到 BigQuery 或 Cloud Storage 中。

這些服務可降低營運開銷，並與下游雲端分析服務原生整合。它們非常適合混合雲端策略，即大型主機系統保留在本地，而分析工作負載則遷移至雲端。

開源解決方案

對於尋求靈活性或成本控制的組織來說，開源工具可以成為整合管道的寶貴組成部分。

譬如：

• Apache NiFi：提供視覺化、拖放資料流設計，支援提取檔案、轉換記錄以及發佈到 Kafka 或物件儲存。
• Apache Kafka 和 Kafka Connect：基於 CDC 的複製和串流整合模式的常用方案。大型主機 CDC 連接器（商用或客製化）可以將變更事件發佈到 Kafka 主題。
• Apache Spark：用於對提取的大型主機資料進行大規模轉換，包括解析副本並寫入 Parquet 或 ORC 格式。

雖然開源提供了自由和成本優勢，但它通常需要在配置、監控和維護方面進行更大的工程投資。

供應商特定的連接器和適配器

一些供應商專門從事大型主機集成，提供專用工具，以最少的客製化開發連接大型機系統和現代資料湖。

譬如：

• Precisely Connect（以前稱為 Syncsort）：提供從大型主機到雲端儲存的最佳化資料移動，並為 COBOL 副本、EBCDIC 轉換和 CDC 提供原生支援。
• IBM z/OS Connect：將大型主機應用程式公開為 REST API，因此無需大規模資料複製即可實現基於 API 的整合。
• GT Software Ivory Service Architect：用於 CICS 和 IMS 交易的類似 API 支援工具。

這些解決方案通常滿足特殊要求，例如從 VSAM 或 IMS 進行高效能提取、即時事務 API 或以合規性為重點的資料沿襲追蹤。

定制解決方案

在某些情況下，組織會建立客製化的整合管道以滿足特定需求。客製化解決方案可能包括 COBOL Copybook 解析器、編碼轉換器和客製化的調度腳本。

示例：

• 基於 Python 的 ETL 腳本使用 Pandas 和 PySpark 讀取導出的平面檔案、解析抄本、將 EBCDIC 轉換為 UTF-8 以及將 Parquet 寫入 S3。
• 客製化的 NiFi 處理器可即時解析大型主機特定的格式。

自訂管道提供了最大的靈活性，但可能會增加開發和維護成本。當現成的解決方案不支援獨特的業務規則或資料結構時，自訂管道通常是合理的。

技術與戰略的匹配

選擇正確的技術組合取決於所選的整合模式、資料新鮮度要求、可用技能和預算。

• 批量卸載可能依賴現有的 ETL 工具或雲端原生編排。
• CDC 和串流媒體整合受益於 Kafka、託管複製服務和 NiFi 管道。
• 基於 API 的整合依賴大型主機特定的支援工具，例如 z/OS Connect。

成功的整合策略將這些工具與業務目標相匹配，確保資料管道穩健、可維護且經濟高效，同時滿足監管和安全要求。

Smart TS XL 作為整合解決方案

將大型主機與現代資料湖整合通常需要專門的工具來處理遺留資料結構、編碼方案和操作工作流程的複雜性，同時將它們橋接到雲端原生儲存和處理環境。 Smart TS XL 就是這樣一種解決方案，它專為應對這些挑戰而構建，專注於大規模大型主機資料的提取、轉換和加載。

Smart TS XL 專為需要卸載大量以 COBOL 副本、VSAM 資料集、DB2 表或其他傳統格式建構的大型主機資料並以現代、可分析的形式（例如 Parquet 或 Avro）在物件儲存系統（如 Amazon S3、Azure Data Lake Storage 或 Google Cloud Storage）中交付這些資料的企業而設計。

Smart TS XL 概述

Smart TS XL 的核心是一種自動化的大型主機到雲端整合解決方案，能夠理解大型主機資料的獨特特性。它支援解析和映射 COBOL 副本、處理 EBCDIC 到 UTF-8 的轉換，以及管理複雜的嵌套記錄佈局。

Smart TS XL 通常用於簡化大量卸載工作流程，同時使組織能夠逐步實現其資料架構的現代化，而不會中斷核心大型主機工作負載。

大型主機整合的關鍵功能

• COBOL Copybook 解析：自動解釋 COBOL 字帖佈局並產生映射配置以將平面文件轉換為結構化的現代格式。
• EBCDIC 轉換：處理從 EBCDIC 到 ASCII 或 UTF-8 的字元集轉換，確保與雲原生分析工具相容。
• 模式映射：支援豐富的資料類型轉換和巢狀模式定義，以符合 Parquet、ORC 或 Avro 要求。
• 工作自動化：協調從大型主機中提取的預定數據，並可選擇與企業排程器或 Apache Airflow 等雲端原生編排工具整合。
• 高效能表現：經過最佳化，可處理大型主機工作負載中典型的超大資料集，具有平行處理和高效 I/O 功能。

資料映射和轉換功能

Smart TS XL 的一大亮點是其視覺化或配置驅動的映射介面，用於定義大型主機資料如何對應到現代模式。這消除了解析 COBOL 腳本和應用複雜轉換時通常需要進行大量手動且容易出錯的編碼工作。

範例映射配置（概念）：

{
  "source": {
    "format": "COBOL_COPYBOOK",
    "encoding": "EBCDIC"
  },
  "target": {
    "format": "PARQUET",
    "encoding": "UTF-8",
    "schema": [
      {"name": "cust_id", "type": "int"},
      {"name": "cust_name", "type": "string"},
      {"name": "cust_balance", "type": "decimal(9,2)"}
    ]
  }
}

此對應可確保匯出的大型機平面檔案自動轉換為資料湖中易於分析的列式格式。

與現代資料湖集成

Smart TS XL 旨在與主流雲端物件儲存原生相容。資料擷取與轉換後，可直接寫入：

• Amazon S3，採用 Parquet 或 Avro 格式
• Azure 數據湖存儲 Gen2
• 谷歌雲存儲服務
• 本地 HDFS 集群

這種直接整合消除了中間的手動步驟，並減少了維護自訂 ETL 管道的運作負擔。

優點和局限性

優點：

• 專為大型主機整合用例而建置。
• 可靠地處理 COBOL 抄書和 EBCDIC。
• 自動映射、轉換和載入到雲端儲存。
• 可適應大型、高容量的批次工作負載。
• 減少整合專案的開發時間。

限制：

• 主要針對批量卸載模式進行最佳化；近即時 CDC 和串流整合可能需要補充工具。
• 對於大規模部署來說，授權和商業支援成本可能非常高。
• 需要培訓並融入現有的工作流程。

示例用例

• 金融服務：每晚提取 VSAM 客戶記錄，轉換為 Parquet，並載入到 S3，以便在 Amazon Athena 中進行監管報告和分析。
• 醫療保健：將大型主機索賠處理資料批次卸載到 Azure Data Lake，以進行 ML 驅動的詐欺偵測。
• 政府：透過以自動化的 Smart TS XL 工作流程取代基於 FTP 的管道來實現傳統批次作業的現代化，為 BigQuery 提供人口統計分析。

Smart TS XL 是一款實用的專業工具，適合希望降低風險並加速大型主機到資料湖整合的組織。它提供對傳統數據格式的強大支持，並自動轉換為現代模式，使團隊無需進行大量自訂開發即可解鎖大型主機數據，用於高級分析和 AI。

設計和實施注意事項

成功地將傳統大型主機與現代資料湖集成，不僅需要選擇正確的工具或模式，還需要周密的設計和營運規劃，以確保資料的完整性、安全性、合規性和長期可維護性。

仔細考慮這些因素對於避免代價高昂的意外、確保遵守法規以及滿足企業對及時、高品質數據的期望至關重要。

資料映射和模式轉換

遺留的大型主機資料通常採用數十年來定義的高度客製化格式。 COBOL 副本描述了具有壓縮十進位欄位的巢狀記錄佈局，並重新定義了子句和條件名稱。

將這些結構轉換為現代的列式格式（例如 Parquet）需要詳細的映射：

• Copybook 解析：工具必須準確解釋記錄佈局，處理巢狀組和可變長度記錄。
• 數據類型轉換：壓縮十進位或二進位欄位必須轉換為現代數字類型。
• 編碼翻譯：對於現代分析引擎，EBCDIC 必須可靠地轉換為 UTF-8 或 ASCII。

自動映射工具或預建連接器可以顯著減少開發工作量，但它們仍然需要嚴格的測試以確保正確處理資料中的所有邊緣情況。

調度和編排

大型主機環境通常依賴成熟的作業排程程序，例如 Control-M 或 IBM Workload Scheduler。整合工作流程需要與這些調度系統保持一致，或與 Apache Airflow 等雲端原生編排器整合。

主要做法包括：

• 定義明確的工作依賴關係以避免競爭條件。
• 確保發生故障時的恢復和重新啟動能力。
• 協調大型主機提取與下游轉換和資料湖負載。

整合作業應設計為冪等的，以確保在發生部分故障時能夠安全地重新處理。

這種 DAG 以明確的依賴關係協調提取和轉換的順序步驟。

安全性和 IAM 集成

大型主機資料通常包含高度敏感的信息，例如個人身分證號碼、金融交易或醫療記錄。將這些資料遷移到基於雲端的資料湖會引發關鍵的安全問題：

• 傳輸中和靜態加密：對所有網路傳輸強制執行 TLS，並為物件儲存啟用加密。
• 身份和訪問管理：與企業 IAM 系統整合以強制實施最小權限存取。
• 審計和日誌記錄：捕獲所有整合步驟的詳細日誌，以支援法醫分析和合規性審查。
• 資料屏蔽或標記化：如有需要，請在將敏感區域放入控制較弱的環境之前對其進行遮蔽。

安全性必須從一開始就建立起來，而不是事後才增加。

監控、日誌記錄和可觀察性

整合管道必須嚴格的監控，以確保可靠性和效能。生產就緒型設計包括：

• 健康檢查：監控 ETL 作業的成功/失敗、延遲和吞吐量。
• 詳細記錄：包括轉換步驟、記錄計數和用於故障排除的錯誤訊息。
• 警示：觸發故障或異常通知。
• 血統追踪：使用資料目錄工具來保持對來源到目標映射和轉換的可見性。

操作可見性對於滿足 SLA 和合規性要求以及讓業務用戶對資料充滿信心至關重要。

測試和數據驗證

由於複雜的遺留格式，大型主機資料轉換容易出現細微錯誤。可靠的測試對於在問題影響下游分析之前發現問題至關重要：

• 模式驗證：確保輸出符合目標模式。
• 記錄級協調：比較來源和目標記錄數、關鍵字段總和或總哈希數。
• 自動回歸測試：防止整合管道發展過程中出現重大變化。
• 取樣和人工檢驗：對於首次遷移或複雜的記錄佈局尤其重要。

這種程序檢查有助於確保整個管道的資料完整性。

作戰準備

除了技術管道之外，還要考慮組織和流程因素：

• 明確整合工作的所有權。
• 為營運團隊創建運行手冊。
• 對員工進行工具和工作流程訓練。
• 隨著來源系統的發展，制定變更管理計畫。

可持續的整合策略將大型機到資料湖管道視為一流的生產工作負載，並提供適當的支援、文件和生命週期管理。

符合業務需求

最後，所有設計決策都應以業務需求為基礎：

• 在 SLA 中定義資料新鮮度要求。
• 根據商業價值對資料集進行優先排序。
• 平衡雲端儲存和處理的成本與效能。
• 儘早與利害關係人接觸以協調期望。

僅憑技術卓越並不能保證成功。整合工作必須與業務目標緊密結合，才能創造真正可衡量的價值。

案例研究和實例

成功的大型機到資料湖整合並非紙上談兵，而是企業為實現實際業務目標而執行的關鍵高風險專案。以下是一些實際案例和代表性案例研究，闡述了不同行業如何應對這一複雜的整合挑戰。每個案例都重點介紹了一些模式、工具選擇和設計考量，可以為其他規劃類似轉型的組織提供參考。

金融服務：監理報告的批量卸載

一家跨國銀行需要遵守不斷變化的監管報告要求，收集其全球業務的整合、詳細的歷史交易資料。其核心銀行平台託管在 IBM z/OS 上，交易資料儲存在 VSAM 資料集中，而關聯表則儲存在 DB2 中。

整合模式： 大量卸載

• 每晚的批次作業將 VSAM 和 DB2 表擷取到平面檔案中。
• COBOL 抄本定義了記錄版面。
• EBCDIC 資料已轉換為 UTF-8。
• 資料被轉換為 Parquet 格式並載入到 Amazon S3。
• AWS Glue Catalog 管理架構定義。

關鍵工具：

• IBM DataStage 用於擷取和轉換。
• Airflow 用於協調夜間工作流程。
• AWS S3 和 Glue 用於儲存和元資料。

結果：

• 每日資料刷新支援合規性報告和內部分析。
• 為審計員提供集中、可查詢的歷史交易資料。
• 減少手動報告工作量和錯誤率。

此範例示範如何在不中斷現有大型主機操作的情況下對傳統批次流程進行現代化改造以提供資料湖。

醫療保健：用於詐欺檢測的即時 CDC

一家大型醫療保健支付機構希望對儲存在運行 IMS 和 DB2 的大型主機上的理賠資料實施即時詐欺偵測。由於需要快速識別可疑模式，因此批量整合方案無法實現。

整合模式： 使用串流傳輸進行變更資料擷取 (CDC)

• CDC 工具讀取 DB2 日誌來擷取插入、更新和刪除。
• 更改幾乎即時發佈到 Apache Kafka 主題。
• Spark Structured Streaming 使用這些主題，轉換資料並以 Parquet 格式將其寫入 Azure Data Lake Storage。
• 下游 ML 模型分析新的索賠資料以進行詐欺評分。

關鍵工具：

• IBM Infosphere CDC 用於基於日誌的擷取。
• Apache Kafka 用於訊息傳遞。
• Azure Data Lake Storage Gen2 用於儲存。
• 用於 Spark 串流和 ML 的 Azure Databricks。

結果：

• 顯著減少詐欺偵測延遲—從幾天縮短到幾分鐘。
• 提高詐欺模型的準確性和回應能力。
• 近乎即時地查看索賠提交情況。

此用例展示了將 CDC 與串流媒體相結合以提供傳統批次範例無法實現的營運分析的強大功能。

政府：統計分析的混合方法

一家國家統計機構需要對其人口數據處理進行現代化升級，此前，這些數據處理工作主要依靠大型主機進行，並執行複雜的批次作業。分析師需要更輕鬆地存取精細數據，同時確保嚴格的安全性和沿襲性。

整合模式： 混合批次 + API

• 夜間批次作業將大型資料集以 Avro 格式卸載至 Google Cloud Storage。
• 自訂 NiFi 管道解析 COBOL 抄本定義並轉換記錄。
• z/OS Connect 將選定的大型主機交易公開為隨選查詢的 REST API。

關鍵工具：

• NiFi 用於解析和資料移動。
• z/OS Connect 用於 API 支援。
• Google Cloud Storage 和 BigQuery 用於分析。

結果：

• 分析師可以使用 BigQuery 中的 SQL 查詢歷史資料。
• 安全 API 提供了對關鍵大型主機系統的受控即時存取。
• 維護嚴格的資料沿襲和可審計性以確保合規性。

這個例子表明，混合整合模式可以在單一的、有凝聚力的架構中解決多種用例——大規模報告的批次、事務存取的 API。

架構圖和模式

雖然具體圖表取決於組織選擇，但這些案例的典型高階架構具有共同的元素：

• 數據源： 大型主機系統（VSAM、IMS、DB2）。
• 提取層： 批次作業或 CDC 工具。
• 運輸： 安全文件傳輸、訊息佇列（Kafka）或 API。
• 轉型： ETL 工具（DataStage、Informatica）、Spark 作業、NiFi 流。
• 貯存： Parquet 或 Avro 格式的物件儲存（S3、ADLS、GCS）。
• 消費： 基於 SQL 的分析、BI 儀表板、ML 管道。

這些案例研究強調，將大型主機與資料湖整合並不存在單一「正確」的方法。成功的設計需要適應特定的業務需求、遺留系統的限制以及目標分析平台。

大型主機到資料湖整合的未來趨勢

雖然許多組織專注於解決當前的整合挑戰，但具有前瞻性的團隊也在規劃未來幾年大型主機到資料湖架構的演進。這些新興趨勢反映了企業IT領域更廣泛的轉變——向雲端原生設計、即時分析、AI/ML驅動的工作負載以及去中心化資料治理的轉變。

了解這些趨勢可以幫助組織設計出不僅在當前有效而且在未來具有彈性和適應性的整合策略。

大型主機現代化和微服務

正在發生的最大轉變之一是大型主機工作負載本身的逐步現代化。企業不再只是簡單地卸載數據，而是在探索如何將遺留應用程式重構或重新平台化為微服務架構。

這種現代化方法可以透過標準化 API 公開核心業務邏輯和數據，從而降低長期整合的複雜性。現代化的應用程式無需導出整個資料集，即可提供即時資料訪問，並具備細粒度的安全性和治理能力。

IBM z/OS Connect 等工具是這一趨勢的早期推動者，它們可協助團隊逐步為現有的 COBOL 或 CICS 程式啟用 API，而無需進行大規模重寫。隨著時間的推移，更多大型主機工作負載可能會完全遷移到雲端原生平台，進一步簡化與資料湖和分析服務的整合。

雲端原生 CDC 和複製管道

隨著雲端平台的成熟，它們越來越多地提供託管 CDC 和資料複製服務，專門用於連接內部大型主機和雲端儲存。

AWS、Azure 和 Google Cloud 正在大力投資低延遲、可擴展的 CDC 管道，這些管道可以處理大型主機交易日誌的細微差別。這些服務減少了自訂 ETL 開發的需求，並提高了可靠性和監控能力。

未來的架構可能會將來自大型主機的變化資料流視為統一的雲端原生資料平台中的另一個來源，更容易支援即時分析、人工智慧模型訓練和營運報告。

用於數據豐富的人工智慧和機器學習

一旦大型主機資料進入資料湖，組織就會越來越多地應用機器學習和人工智慧來創造商業價值。

• 根據歷史索賠資料訓練的詐欺偵測模型。
• 由操作日誌提供的預測性維護演算法。
• 由交易歷史驅動的客戶細分和個人化模型。

隨著機器學習平台變得越來越容易訪問，整合管道將越來越多地不僅包括資料移動和轉換，還包括特徵工程、模型推理和返回作業系統的反饋循環。

整合設計需要考慮這些要求，確保資料品質、譜系和新鮮度達到適合訓練和評分 ML 模型的水平。

無伺服器和事件驅動的 ETL

無伺服器和事件驅動範式正在改變組織對資料整合的看法。

企業正在轉向基於無伺服器平台建構的事件觸發管道，而非單一的夜間批次作業或長時間運行的 ETL 伺服器。 AWS Lambda、Azure Functions 和 Google Cloud Functions 可以對物件儲存中的新資料或訊息佇列中的新事件做出反應，按需啟動轉換作業。

這種模式透過消除閒置基礎設施來降低成本，並提高對時間敏感用例的回應速度。大型主機整合將越來越多地利用這些無伺服器模式，尤其是在 CDC 和串流場景中。

資料網格與聯邦治理

隨著資料湖的成長，對強大的資料治理和避免中心瓶頸的組織模型的需求也在增長。

資料網格範式鼓勵將資料視為產品，面向領域的團隊負責其資料集的品質、文件和可存取性。對於大型主機整合而言，這意味著：

• 明確定義大型主機衍生資料產品的所有權。
• 強大的元數據和沿襲追蹤。
• 跨儲存層的標準化存取策略。

聯合治理確保即使是受到嚴格監管的大型主機資料也可以在組織內負責任地民主化，避免孤島並保持合規性。

為未來做準備

這些趨勢強調，大型機到資料湖的整合不僅是行動數據，還能使企業更快、更有效地創新。

建築師和工程團隊需要規劃：

• 支援混合批次、CDC、串流和 API 的混合工作負載。
• 設計可用於 ML 和即時分析的可擴展管道。
• 將元資料、血統和安全性作為首要關注點進行投資。
• 將整合策略與更廣泛的現代化和雲端策略相結合。

預測這些趨勢的組織可以確保他們今天的投資明天仍然有價值，為支持未來不斷發展的分析需求和業務重點奠定基礎。

建議和最佳實踐

將傳統大型主機與現代資料湖整合是一項關鍵舉措，可以釋放巨大的商業價值，但如果沒有明確的策略，它也會變得複雜且有風險。

根據行業經驗和成功案例研究，以下是幫助組織有效地完成這趟旅程的關鍵建議和最佳實踐。

儘早評估數據敏感性

大型主機通常儲存組織中最敏感的數據，包括財務交易、個人健康資訊和客戶帳戶詳細資訊。在設計整合管道之前，團隊應進行全面的資料敏感度和分類評估。

• 識別 PII、PCI、HIPAA 監管或其他敏感資料元素。
• 在移動之前定義資料屏蔽或標記化要求。
• 確保加密策略（傳輸中和靜止時）定義明確。

早期評估有助於避免昂貴的重新設計，並從一開始就確保遵守法規。

從小規模的概念驗證開始

當團隊試圖在一個階段內替換數十年來的批次作業和自訂程式碼時，整合專案往往會失敗。相反：

• 選擇一個單一的、定義明確的用例來證明整合模式。
• 在具有代表性的資料子集上驗證工具和轉換。
• 讓大型主機團隊和資料湖工程師都參與設計和執行。

概念驗證可以降低風險、建立利害關係人的信心並創建可重複使用的模式以實現更廣泛的推廣。

投資自動化元資料和地圖

如果手動完成，解析 COBOL 抄寫本、處理 EBCDIC 轉換以及映射到現代模式可能會容易出錯且耗時。

最佳做法是：

• 使用支援自動抄本解析和模式映射的工具。
• 維護版本化元資料以追蹤隨時間發生的變化。
• 整合 AWS Glue 或 Azure Purview 等元資料目錄以強制一致性。

強大的元資料管理可以避免資料品質問題，並簡化整合規模的維護。

使 SLA 與業務期望保持一致

整合設計決策應始終與明確的業務需求相關，尤其是圍繞數據新鮮度。

• 批量卸載對於日常報告來說可能是可以接受的，但對於即時詐欺偵測來說則不夠。
• CDC 或串流媒體管道可以顯著減少延遲，但需要更多的營運投資。
• API 可以在沒有大規模複製的情況下提供事務查詢，但可能不支援分析案例。

儘早與業務利害關係人記錄並商定 SLA，以避免在專案生命週期後期出現意外。

優先考慮作戰準備

整合管道並非「設定完畢後就忘了」的系統。它們需要強大的操作設計，包括：

• 監控作業執行狀況、延遲和失敗率。
• 記錄足夠詳細的資訊以供審計和故障排除。
• 向營運團隊發出警報，以便主動解決問題。
• 為支援人員提供運作手冊和訓練。

將整合工作視為具有明確所有權和支援計劃的生產工作量。

漸進式現代化

雖然完全替換大型主機可能是長期目標，但大多數組織在短期內都會採用混合模型。

• 使用批量卸載來實現大規模歷史分析。
• 添加 CDC 和串流媒體以進行具有更嚴格 SLA 的營運分析。
• 使用 API 包裝大型主機服務，以便即時存取而無需複製。

增量方法可以快速提供價值，同時降低風險並讓團隊有時間適應。

從一開始就建立安全性和合規性

安全性必須從一開始就設計好，而不是後來添加。

• 對所有資料移動強制實施強式身份驗證和 IAM 整合。
• 將傳輸中的資料（TLS）和靜態資料（S3 SSE、Azure 儲存加密）進行加密。
• 在資料湖層實施存取控制以強制執行最小權限存取。
• 維護詳細的審計日誌以進行合規性報告。
• 應用資料沿襲追蹤來確保從來源到目標的轉換的透明度。

這些做法降低了風險並與監管機構和商業利益相關者建立了信任。

跨孤島協作

大型主機專家和雲端原生資料工程團隊通常擁有不同的工具、流程和文化。成功的專案強調協作：

• 跨職能設計評審以確保可行性和認同度。
• 共用文件和元資料標準。
• 聯合作戰支援模式。

彌合組織孤島與彌合技術孤島同樣重要。

注重長期可維護性

優先考慮可維護性，以避免創造成為未來遺留問題的新一代脆弱、不透明的管道。

• 自動化模式管理和轉換。
• 版本控制 ETL 配置和程式碼。
• 記錄端到端資料流和所有權。
• 將管道設計為模組化且可擴展以適應新的用例。

維護良好的整合框架支援不斷變化的業務需求，並降低適應即時分析、機器學習和雲端遷移等未來趨勢的成本。

將遺產轉化為機遇

將傳統大型主機與現代資料湖整合不僅僅是一個技術遷移項目，而是一項策略性舉措，可以釋放數十年來寶貴的數據，用於高階分析、即時決策和機器學習。成功完成這項工作的組織能夠將僵化、孤立的系統轉變為敏捷、數據驅動的平台，從而支援不斷變化的業務需求，從而獲得強大的優勢。

要實現這種整合需要周詳的規劃和嚴謹的執行。團隊必須應對各種挑戰，從專有資料格式和以批次為導向的流程，到安全性、合規性和營運複雜性。選擇正確的整合模式（無論是批量卸載、持續資料擷取 (CDC)、串流或 API）都取決於對資料新鮮度、延遲和存取控制等特定業務需求的理解。

技術選擇也至關重要。成熟的 ETL 工具、雲端原生服務、開源框架以及像 Smart TS XL 這樣的專業解決方案，在不同場景下都能發揮各自的作用。最佳架構通常結合多種模式和工具，以滿足整個企業的多樣化需求。

營運和組織層面也同樣重要。成功的整合專案從一開始就優先考慮元資料管理、自動化、監控和安全性。它們鼓勵大型主機專家和雲端資料工程團隊密切合作。它們建立可維護、可擴展且透明的流程和管道，以支援未來的成長。

歸根究底，將大型主機與現代資料湖整合並非用一個系統取代另一個系統，而是實現共存並釋放企業資料的全部潛力。憑藉清晰的策略、合適的技術以及對長期永續性的關注，企業可以將這項複雜挑戰轉化為競爭優勢和創新的基礎。