在資料湖的建置過程中，資料轉換是不可或缺的環節。從 GUI 工具到程式碼撰寫，選擇合適的工具和策略能顯著影響資料處理效率。AWS Glue 和 DataBrew 等服務提供視覺化介面，簡化 ETL 流程，適合不熟悉程式碼的使用者。更進一步的效能提升則仰賴資料準備轉換的最佳化，例如將資料轉換為 Parquet 格式，利用其欄位導向儲存和壓縮特性提升查詢速度。此外，合理的資料分割策略能有效減少查詢掃描的資料量，例如按日期分割，但需注意避免產生過多小檔案。資料清理則著重於資料品質，包含欄位名稱統一、資料型別校正、格式標準化、重複資料移除和缺失值處理。最後，針對特定商業分析需求，可能需要進行反正規化，將多個正規化表格整合，以簡化查詢和分析流程。
資料轉換工具的型別
另一種常見的資料轉換方法是使用圖形使用者介面（GUI）工具，這些工具大大簡化了建立轉換作業的過程。目前有多種雲端和商業產品提供拖曳式方法來建立複雜的轉換管道，這些方法被廣泛使用。
GUI 工具的優缺點
這些工具通常無法提供像使用程式碼設計轉換那樣高的多樣性和效能，但它們使 ETL 型轉換的設計變得更容易，對於沒有高階程式設計技能的人來說尤其如此。其中一些工具還可以用於自動生成轉換程式碼（例如 Apache Spark 程式碼），為使用者提供一個良好的起點，以便進一步開發程式碼，從而減少 ETL 作業的開發時間。
AWS 的視覺化資料準備工具
在 AWS 中，Glue DataBrew 服務被設計為視覺化資料準備工具，使用者可以輕鬆地對一組檔案套用轉換。透過 Glue DataBrew，使用者可以從超過 250 種常見轉換的函式庫中選擇，並對輸入的原始檔案套用相關的轉換。該服務允許使用者透過易於使用的視覺化設計器清理和標準化資料，以準備進行分析或機器學習模型開發，而無需撰寫任何程式碼。
AWS Glue Studio
另一個提供視覺化 ETL 設計方法的 AWS 服務是 AWS Glue Studio，該服務提供了一個開發 Apache Spark 轉換的視覺化介面。這個服務既可以被沒有 Spark 經驗的人使用，也可以被熟悉 Spark 的人作為開發自定義轉換的起點。使用 AWS Glue Studio，可以建立複雜的 ETL 作業，連線和轉換多個資料集，然後檢閱生成的程式碼，並在具備適當程式設計技能的情況下進一步改進它。
商業產品
除了 AWS 之外，還有許多商業產品提供視覺化 ETL 設計方法。流行的產品包括來自 Informatica、Matillion、Stitch、Talend、Panoply、Fivetran 等公司的工具。
資料準備轉換
我們要探討的第一組轉換是那些有助於為稍後在管道中的進一步轉換準備資料的轉換。這些轉換旨在對我們正在擷取到資料湖中的個別資料集套用相對通用的最佳化。對於這些最佳化，您可能需要了解來源資料系統和上下文，但通常不需要了解資料集的最終業務使用案例。
保護 PII 資料
通常，我們擷取的資料集可能包含個人身份資訊（PII）資料，並且可能存在有關哪些 PII 資料可以儲存在資料湖中的治理限制。因此，我們需要在擷取後盡快進行保護 PII 資料的處理。
常見的 PII 資料保護方法
有多種常見的方法可以用於此處（例如令牌化或雜湊），每種方法都有其自身的優缺點。無論使用哪種策略，其目的都是從原始資料中移除 PII 資料，並將其替換為一個值或令牌，以便我們仍然可以使用該資料進行分析。
執行 PII 資料匿名化的工具
根據用於轉換 PII 資料以進行匿名化的方法，可能有多種不同的工具集可以使用。這包括開源函式庫，以建立 Apache Spark 作業來進行匿名化，並且正如您已經知道的那樣，可以在 AWS Glue 或 Amazon EMR 上執行。如果您的需求只是對某個列進行簡單的 SHA-256 雜湊，您可以透過使用 Amazon Athena 建立一個新表格來實作這一點，如 AWS 部落格文章《使用 Amazon Athena 和 AWS Lake Formation 對資料湖中的資料進行匿名化和管理》所述。但請注意，SHA-256 雜湊通常不被視為一種安全的匿名化資料的方法 - 例如，德國的一家法院裁定，使用 SHA-256 雜湊來匿名化資料不足以符合隱私要求。對於更安全的匿名化資料方法，或更複雜的使用案例，您可以使用在 AWS 中執行的商業供應商提供的專門構建的管理服務，例如來自 PKWARE 公司的 PK Privacy。
import hashlib
def anonymize_pii_data(data):
# 使用 SHA-256 雜湊函式對 PII 資料進行匿名化
anonymized_data = hashlib.sha256(data.encode()).hexdigest()
return anonymized_data
# 示例用法
pii_data = "敏感資訊"
anonymized_data = anonymize_pii_data(pii_data)
print("匿名化後的資料：", anonymized_data)
內容解密：
此段程式碼展示瞭如何使用 Python 中的 hashlib 函式庫對 PII 資料進行 SHA-256 雜湊，以達到匿名化的效果。首先定義了一個名為 anonymize_pii_data 的函式，該函式接受一個字串型別的 data 引數。然後，使用 hashlib.sha256() 函式對輸入的 data 進行雜湊處理，並將結果轉換為十六進位制字串。最後，傳回這個雜湊值作為匿名化後的資料。在示例用法中，將一個包含敏感資訊的字串傳遞給 anonymize_pii_data 函式，並列印出匿名化後的結果。
未來趨勢與實務應用評估
隨著資料保護法規的日益嚴格，對 PII 資料進行適當的匿名化處理變得越來越重要。未來，我們可以預期會有更多先進的技術和工具出現，以支援更有效和更安全的資料匿名化。實務上，選擇適合的匿名化方法和工具需要根據具體的業務需求和技術條件進行綜合評估。例如，對於需要高安全性的場景，可以考慮使用商業供應商提供的專門管理服務；而對於一些簡單的應用場景，使用開源工具或內建於雲端服務的功能（如 AWS Glue 或 Amazon Athena）可能就足夠了。無論採用何種方法，確保 PII 資料的安全性和合規性始終是首要任務。
資料準備轉換 201：最佳化分析效能
最佳化檔案格式
在現代資料湖環境中，有多種針對資料分析進行最佳化的檔案格式可供選擇。目前最受歡迎的檔案格式是 Apache Parquet。Parquet 檔案採用欄位導向儲存，意味著檔案內容按欄位分組，而非按列分組（如大多數檔案格式，包括 CSV）。這種儲存方式使得查詢特定欄位時，無需讀取整個檔案，從而提升效能。
Parquet 檔案還包含有關所儲存資料的中繼資料，包括結構描述資訊（每個欄位的資料型別）以及統計資料，如欄位的最大值、最小值和列數等。此外，Parquet 檔案針對壓縮排行了最佳化。一個 1 TB 的 CSV 資料集在轉換為 Parquet 格式後，壓縮後的大小可減少至約 130 GB。Parquet 支援多種壓縮演算法，其中 Snappy 是最廣泛使用的壓縮演算法。
這些最佳化措施大幅節省了儲存空間並加快了查詢速度。例如，Amazon Athena 的查詢費用根據掃描的壓縮資料量（撰寫本文時為每 TB 掃描資料 5 美元）。如果只查詢 Parquet 檔案中的特定欄位，由於壓縮和只需讀取特定欄位的資料區塊，能夠大幅減少需要掃描的資料量。
內容解密：
- 欄位導向儲存：將資料按欄位分組儲存，提高查詢特定欄位時的效率。
- 中繼資料：包含結構描述資訊和統計資料，如最大值、最小值和列數，幫助查詢最佳化。
- 壓縮最佳化：支援多種壓縮演算法，Snappy 最為常用，大幅減少儲存空間。
資料分割最佳化
另一種常見的最佳化方法是對資料進行分割，這與資料湖中的資料檔案組織方式有關。Hive 分割根據資料集中的一個或多個欄位，將資料分組存放在不同的資料夾中。常見的分割策略是按日期進行分割。
例如，假設有過去四年的銷售資料，包含 Day、Month 和 Year 欄位。可以選擇按 Year 欄位進行分割。資料寫入儲存時，所有年份的資料將按以下結構組織：
datalake_bucket/year=2021/file1.parquet
datalake_bucket/year=2020/file1.parquet
datalake_bucket/year=2019/file1.parquet
datalake_bucket/year=2018/file1.parquet
當執行 SQL 查詢並包含 WHERE Year = 2018 子句時，分析引擎只需開啟 datalake_bucket/year=2018 資料夾中的單一檔案。由於需要掃描的資料量減少，查詢成本降低且執行速度加快。
選擇分割欄位需要對資料集的使用方式有深入瞭解。如果按年份分割，但大多數查詢是按業務單位（BU）欄位進行，則分割策略將無效。
內容解密：
- Hive 分割：根據特定欄位將資料分組存放在不同資料夾中。
- 按日期分割：常見的分割策略，能夠提高按日期查詢的效率。
- 選擇分割欄位：需要根據資料集的實際使用方式進行選擇，以達到最佳化效果。
分割策略的影響
未使用分割欄位的查詢可能會因分割數量過多而執行較慢，因為分析引擎需要讀取所有分割區的資料，並且在不同資料夾之間切換存在額外開銷。如果沒有明確的共同查詢模式，可能不適合進行分割。但如果大多數查詢遵循共同模式，則分割能夠提供顯著的效能和成本優勢。
內容解密：
- 未使用分割欄位的查詢：可能會因分割數量過多而執行較慢。
- 額外開銷：分析引擎需要在不同資料夾之間切換，存在額外開銷。
- 共同查詢模式：如果大多數查詢遵循共同模式，則分割能夠提供顯著的效能和成本優勢。
內容解密：
- 最佳化措施：轉換為 Parquet 格式和採用適當的分割策略。
- 瞭解資料集使用方式：對於選擇合適的分割欄位非常重要。
- 效率和成本效益：正確的最佳化措施能夠大幅提升資料分析的效率和成本效益。
資料準備轉換的最佳化策略
在資料湖（Data Lake）環境中，資料準備（Data Preparation）是資料處理流程中的關鍵步驟。適當的資料準備可以大幅提升後續資料分析的效率與準確性。本章節將探討如何透過資料分割（Partitioning）、資料清理（Data Cleansing）等轉換任務來最佳化資料，以滿足商業分析的需求。
資料分割策略
資料分割是一種重要的資料最佳化策略，其根據資料的使用方式進行設計。適當的分割策略可以顯著減少查詢時需要掃描的資料量，從而提升查詢效能。例如，如果經常需要處理每日的資料，可以採用以下分割策略：
datalake_bucket/year=2021/month=6/day=1/file1.parquet
這種分割方式不僅能提升每日查詢的效率，也能支援按月或按年進行查詢。然而，需要注意的是，分割策略應避免產生大量的小檔案。理想的Parquet檔案大小應介於128 MB至1 GB之間。因為Parquet檔案格式支援分割，多個節點可以平行處理同一個檔案中的資料，但大量的小檔案會增加開啟、讀取後設資料、掃描資料和關閉檔案的負擔，嚴重影響效能。
內容解密：
- 分割策略的設計：根據資料的使用模式設計分割策略，例如按日期、地區等進行分割。
- 避免大量小檔案：保持檔案大小在128 MB至1 GB之間，以最佳化查詢效能。
- Parquet檔案的優勢：支援多節點平行處理，提升資料處理效率。
資料清理
資料清理是另一項重要的轉換任務，其目的是確保資料的有效性、準確性、一致性、完整性和統一性。來源資料集可能存在缺失值、重複記錄、欄位名稱不一致或格式不統一等問題。資料清理過程旨在解決這些問題，使資料更適合進行分析。
常見的資料清理任務包括：
- 確保欄位名稱的一致性：統一不同資料集中的相同欄位名稱，例如將
date_of_birth統一為birthdate。 - 更改欄位資料型別：確保欄位的資料型別一致，例如將包含字串的整數欄位轉換為空值，以避免查詢失敗。
- 統一欄位格式：將不同格式的日期欄位統一為企業標準格式，例如將
MM-DD-YYYY統一為DD-MM-YYYY。 - 移除重複記錄：識別並移除或標記重複的記錄，以保證資料的唯一性。
- 填補缺失值：根據具體情況，使用平均值、中位數或特定值填補缺失值，或移除含有缺失值的記錄。
內容解密：
- 欄位名稱統一：確保不同資料來源的相同欄位名稱保持一致。
- 資料型別校正：修正欄位中的錯誤資料型別，例如字串出現在整數欄位中。
- 格式統一：將不同格式的資料統一為企業標準，例如日期格式。
- 重複記錄處理：移除或標記重複記錄，確保資料唯一性。
- 缺失值處理：根據具體情況選擇適當的方法填補或移除缺失值。
商業案例轉換
在資料湖環境中，初始的資料轉換任務主要集中在最佳化檔案格式、分割資料和清理資料。完成這些任務後，需要根據特定的商業案例對多個資料集進行進一步的轉換，以滿足業務需求。
資料反正規化
來源系統中的資料，尤其是來自關聯式資料函式庫的資料，通常是高度正規化的。這意味著每個表格都設計為包含特定實體或主題的資訊，並透過外部索引鍵與其他相關表格連結。在某些情況下，為了滿足特定的商業分析需求，需要對這些正規化的資料進行反正規化處理，以豐富和彙總資料。
例如，將客戶資訊和業務人員資訊整合到一個表格中，以便更方便地進行客戶分析和銷售業績評估。
內容解密：
- 反正規化的目的：為了滿足特定的商業分析需求，將多個正規化表格整合或彙總。
- 反正規化的應用：例如，將客戶和業務人員資訊整合，以簡化分析和查詢。
資料轉換以最佳化分析效能
在資料湖中，資料的結構和儲存方式會對分析查詢的效能產生重大影響。以客戶和業務人員資料為例，標準化的客戶表格可能如下所示：
標準化表格的優缺點
標準化的表格結構具有寫入效能優勢，特別是線上上交易處理（OLTP）系統中，並且有助於確保資料函式庫的參考完整性。此外，標準化表格佔用的磁碟空間較少，因為資料不會在多個表格中重複。
然而，在執行線上分析處理（OLAP）查詢時，多表連線會導致效能下降。因此，資料通常會被反標準化以最佳化分析查詢。
反標準化客戶表格範例
如果有一個使用案例需要定期查詢客戶及其業務人員的詳細資訊，則可以建立一個新的表格，這是客戶和業務人員表格的反標準化版本。
反標準化轉換的優勢
透過這種表格，我們現在可以進行單一查詢，而無需任何連線操作，即可確定特定客戶的業務人員詳細資訊。
雖然這是一個簡單的反標準化使用案例，但一個分析專案可能涉及數十甚至數百個類別似的反標準化轉換。反標準化轉換也可能涉及多個來源表格的資料，並最終建立非常寬的表格。
業務使用案例轉換
瞭解使用案例的需求以及資料將如何被使用，然後確定正確的表格結構和所需的連線操作是非常重要的。
執行反標準化轉換的方法
可以使用 Apache Spark、根據 GUI 的工具或 SQL 來執行這些型別的反標準化轉換。AWS Glue Studio 也可以用於使用視覺化介面設計這些型別的表格連線。
資料豐富化
與前面的範例類別似，另一個常見的轉換是連線表格以豐富原始資料集。
豐富資料的方法
透過將組織擁有的資料與來自第三方的資料或其他業務部門的資料相結合，可以使資料變得更有價值。例如，一家希望向消費者推銷信用卡的公司可能會購買消費者信用評分的資料函式庫，以便與其客戶資料函式庫進行匹配。
AWS 提供了一個名為 AWS Data Exchange 的資料市集，其中包含透過付費訂閱可用的資料集目錄，以及一些免費的資料集。一旦訂閱了資料集，就可以使用 Data Exchange API 將資料直接載入到 Amazon S3 登入區。
資料預聚合
資料湖的一個好處是，它提供了一個低成本的環境來儲存大型資料集，而無需預先處理資料或確定資料模式。可以從多種資料來源中擷取資料，並以低成本長期儲存詳細的原始資料。
預聚合轉換的好處
隨著業務發展出特定的問題，他們希望定期詢問這些資料，透過臨時 SQL 查詢可能不容易獲得答案。因此，您可能會建立轉換作業，以便按照排程執行所需的重計算。
例如，您可能會建立一個轉換作業，建立一個包含每個交易的商店編號、城市和州等欄位的銷售資料反標準化版本。然後，您可能會執行一個預聚合轉換，每天讀取這個反標準化銷售資料（可能包含每天數千萬行和數十或數百個欄位），並按類別、商店、城市和州級別計算銷售額，並將這些結果寫入新的表格中。
從非結構化資料中提取後設資料
資料湖也可能包含非結構化的資料，例如音訊或影像檔案。雖然這些檔案無法直接使用傳統的分析工具進行查詢，但我們可以建立一個使用機器學習（ML）和人工智慧（AI）服務來提取這些非結構化檔案中的後設資料的管道。
提取後設資料的方法
例如，一家僱用房地產代理（房仲）的公司可能會拍攝所有待售房屋的影像。其中一名資料工程師可以建立一個使用 Amazon Rekognition 等 AI 服務來自動識別影像中的物件並識別房間型別（廚房、臥室等）的管道。
處理變更資料捕捉（CDC）資料
在資料湖環境中，處理現有資料的更新（如變更資料捕捉（CDC）資料）是最具挑戰性的任務之一。CDC 資料包含對現有資料集的更新。
CDC 資料的操作
來自關聯式資料函式庫系統的資料就是一個很好的例子。在初始載入資料到資料湖之後，像 Amazon DMS 這樣的系統可以讀取資料函式庫交易日誌，並將所有未來的資料函式庫更新寫入 Amazon S3。對於寫入 Amazon S3 的每一行，CDC 檔案的第一列將包含以下字元之一：
- I – 插入：表示該行包含新插入表格的資料。
- U – 更新：表示該行包含更新現有記錄的資料。
- D – 刪除：表示該行包含已從表格中刪除的記錄的資料。
# CDC 資料處理範例
import pandas as pd
# 假設 cdc_data 是從 Amazon S3 載入的 CDC 資料
cdc_data = pd.read_csv('cdc_data.csv')
# 定義處理 CDC 資料的函式
def process_cdc_data(data):
for index, row in data.iterrows():
operation = row['operation'] # 假設第一列是操作型別
if operation == 'I':
# 處理插入操作
print("Insert operation")
elif operation == 'U':
# 處理更新操作
print("Update operation")
elif operation == 'D':
# 處理刪除操作
print("Delete operation")
# 處理 CDC 資料
process_cdc_data(cdc_data)
內容解密：
此程式碼範例展示瞭如何使用 Python 和 pandas 函式庫來處理 CDC 資料。首先，我們載入 CDC 資料到 DataFrame 中。然後，我們定義了一個函式 process_cdc_data 來處理每一行 CDC 資料。根據操作型別（插入、更新或刪除），我們可以執行相應的操作。在實際應用中，您需要根據具體需求修改此函式，以實作正確的資料處理邏輯。