返回文章列表
玄貓（BlackCat）

雲端資料工程實務與未來趨勢

本文探討雲端資料工程的實務應用與未來趨勢，涵蓋 AWS 平台上的資料處理流程、機器學習模型建構、實際案例研究（Spotify 與 Netflix），以及 DataOps 的實踐。文章深入分析了 VPC FlowLogs 的處理與豐富化，並探討了 Amazon SQS

雲端運算 資料工程
AWS 資料湖 DataOps 機器學習 人工智慧 VPC FlowLogs

隨著資料量的爆炸性增長，雲端資料工程的重要性日益凸顯。本文從 Amazon Comprehend 的情感分析應用開始，逐步引導讀者瞭解 AWS 平台上的資料處理流程，並以 Python 程式碼示範如何使用 Amazon SageMaker 構建機器學習模型。接著，文章透過 Spotify 和 Netflix 的實際案例，深入剖析了大規模資料處理的挑戰與解決方案，例如 Spotify Wrapped 十年資料匯總和 Netflix 的 VPC FlowLogs 處理。DataOps 的實踐經驗，包含基礎設施即程式碼（IaC）和持續整合/持續交付（CI/CD），也被詳細闡述。最後，文章展望了資料工程領域的未來趨勢，例如 ACID 交易在資料湖上的應用、多雲策略的興起，以及分散式資料工程團隊的協作模式。

實作人工智慧與機器學習的未來趨勢與實務應用

在測試並驗證Amazon Comprehend能夠可靠地從已發表的評論中檢測情感後，您可能會決定將此解決方案投入生產使用。如果您決定這樣做，您可以使用Amazon Step Functions建立一個工作流程，執行Lambda函式進行情感分析。然後，根據分析結果（正面、負面、中立或混合），Step Functions的狀態機可以執行不同的Lambda函式，以決定下一步的行動（例如，將負面評論傳送給客戶服務部門，以便跟進客戶，或將混合評論傳送給經理，以決定下一步的行動）。

Amazon Comprehend 的實際應用與體驗

透過這個實作練習，您可以體驗到Amazon Comprehend如何檢測書面文字中的情感和實體。如果您有時間，可以直接在控制檯中探索其他Amazon AI服務的功能，包括Amazon Rekognition、Amazon Transcribe、Amazon Textract和Amazon Translate。

機器學習與人工智慧的多元應用場景

我們討論了ML和AI服務如何應用於廣泛的使用案例，無論是專門的（如早期檢測癌症）還是通用的（如業務預測或個人化推薦）。我們檢視了不同的AWS服務與ML和AI相關的功能，並研究了Amazon SageMaker的不同功能如何用於準備ML資料、構建模型、訓練和微調模型，以及佈署和管理模型。SageMaker使沒有ML專業知識的開發人員更容易構建自定義的ML模型。

程式碼範例：使用 Amazon SageMaker 構建 ML 模型

import sagemaker
from sagemaker import get_execution_role

# 初始化 SageMaker session
sagemaker_session = sagemaker.Session()

# 取得執行角色
role = get_execution_role()

# 定義 SageMaker 估計器
estimator = sagemaker.estimator.Estimator(
    image_uri='your-docker-image-uri',
    role=role,
    instance_count=1,
    instance_type='ml.m4.xlarge',
    sagemaker_session=sagemaker_session
)

# 開始訓練任務
estimator.fit('s3://your-bucket/train-data')

內容解密：

  1. 首先，我們匯入必要的sagemaker模組並初始化SageMaker session。
  2. 然後，我們取得執行角色，這是SageMaker用於存取其他AWS服務的IAM角色。
  3. 接下來，我們定義一個SageMaker估計器，指定Docker映像URI、執行角色、例項數量和型別。
  4. 最後，我們呼叫fit方法開始訓練任務，將訓練資料儲存在S3桶中。

AWS 人工智慧服務的多元應用

我們還檢視了一系列提供預建和訓練模型的AWS AI服務，用於常見的使用案例。我們研究了用於從音訊檔案中轉錄文字（Amazon Transcribe）、從表格和手寫檔案中提取文字（Amazon Textract）、識別影像（Amazon Rekognition）和從文字中提取洞察（Amazon Comprehend）的服務。我們還簡要討論了其他導向業務的AI服務，例如Amazon Forecast和Amazon Personalize。

未來趨勢與進一步學習

在醫療領域，機器學習正在對自動檢測嚴重疾病產生重大影響。有興趣進一步瞭解的讀者可以參考相關文章：

  • Machine Learning and Deep Learning Approaches for Brain Disease Diagnosis: Principles and Recent Advances
  • AI Algorithm Can Accurately Predict Risk, Diagnose Alzheimer’s Disease
  • Implementing AI models has made critical disease diagnosis easy
  • Apple hiring machine learning scientist for early disease detection

清理您的 AWS 帳戶

重點回顧

本文探討了資料工程角色的多個方面，包括常見的架構模式、設計資料工程管道的方法，以及使用各種AWS服務進行資料攝取、轉換和管道協調。我們還討論了資料安全和治理的重要問題，並介紹了資料湖倉的概念。

資料消費者與資料視覺化工具

我們瞭解了資料消費者——資料工程管道產物的終端使用者——以及他們用來消費資料的工具（包括用於即席SQL查詢的Amazon Athena和用於資料視覺化的Amazon QuickSight）。然後，我們簡要探討了機器學習和人工智慧的主題，並瞭解了一些在這些領域中使用的AWS服務。

結語

在本文的最後一章，我們將介紹一些重要的現實世界概念，以幫助管理資料基礎設施/管道開發過程，並檢視一些現實世界的資料管道示例。我們還將討論該領域的新興趨勢。希望本文能夠為您提供對資料工程領域的全面瞭解，並激發您進一步探索的興趣。

資料分析全貌與DataOps實踐

在資料工程領域中，單一資料工程師的視角固然重要，但大多數情況下，資料工程師都是作為更大團隊的一部分共同合作。不同的團隊或團隊成員可能會專注於資料工程管道的不同方面，但所有團隊成員都需要協同工作。

大多陣列織內部通常存在多個環境，例如開發環境、測試/品質保證（QA）環境和生產環境。資料基礎設施和管道必須首先在開發環境中佈署和測試，然後將更新推播到測試/QA環境進行自動化測試，最後才會被批准佈署到生產環境。

資料工程團隊與環境複雜性

在下圖中，我們可以看到有多個團隊負責資料工程資源的不同方面。同時，資料工程資源在多個不同的環境（通常是不同的AWS賬戶）中重複出現，例如開發環境、測試/QA環境和生產環境。每個組織可能會以不同的方式構建其團隊和環境，但這是現實生活中資料工程複雜性的典型例子。

此圖示展示了資料工程團隊和環境之間的複雜關係。

使用DataOps管理複雜的資料環境

DataOps是一套流程和原則，用於管理資料基礎設施（包括管道）如何佈署到生產環境。其目的是為資料轉換過程帶來可重複性和可靠性，從而提高資料價值，並使資料盡快以最高的品質投入使用。

與DataOps相反的手動流程缺乏正式的控制機制，無法確保資料品質和生產環境中的變更審核。

DataOps根據著名的DevOps流程和原則，將類別似的流程應用於資料領域。透過將基礎設施佈署自動化，DataOps提高了資料工程的效率和可靠性。

基礎設施即程式碼

基礎設施即程式碼（IaC）是指使用程式碼或定義範本來控制基礎設施的佈署和組態。在AWS中，AWS CloudFormation（CFN）服務使用範本檔案來指定要佈署到AWS賬戶的基礎設施的定義和組態。

例如，可以建立一個CFN範本，用於自動佈署以下資源到AWS賬戶：

  • 一個組態了阻止公共存取的S3儲存桶
  • 一個EventBridge規則，用於監控寫入該儲存桶的檔案，並在新檔案寫入時觸發Lambda函式
  • 一個用於傳送失敗通知的SNS主題
  • 一個驗證接收到的新檔案的Lambda函式，並啟動Step Function狀態機
  • 一個啟動Glue作業來處理檔案的狀態機，該作業執行Glue爬蟲來更新Glue目錄，並在出現故障時傳送SNS通知

建立範本定義檔案後，可以將其提交到原始碼倉函式庫，如AWS CodeCommit、Azure DevOps（ADO）、BitBucket或GitLab。原始碼倉函式庫使其他團隊成員能夠存取和修改提交的範本檔案，並幫助管理不同版本範本檔案的變更和衝突。

連續整合/連續交付

連續整合（CI）指的是當原始碼倉函式庫中有新版本的檔案被提交時，自動執行的流程，用於構建程式碼並將其整合到目標系統中。

連續交付（CD）指的是自動將程式碼變更佈署到目標環境，通常伴隨著額外的自動化端對端測試。

DataOps將原始碼倉函式庫和CI/CD流程結合在一起，採用敏捷方法開發和佈署資料基礎設施、轉換管道和協調。開發程式碼的團隊也負責監督程式碼佈署到生產環境的過程，並管理出現的問題。

實際案例研究

本文中使用的資料管道示例相對簡單，但實際上，大型組織中的資料管道可能更加複雜，需要處理極其龐大的資料集。

Spotify與Netflix的資料工程實踐

Spotify和Netflix都是非常著名的組織，它們在公開的部落格中分享了關於軟體和資料工程的實踐經驗。下面我們將研究這兩個組織的複雜資料工程管道示例，它們的詳細資訊來自於公開的部落格文章和文章。

這些實際案例展示了現實世界中資料工程管道的複雜性和多樣性，為我們提供了寶貴的學習機會。

深入剖析真實世界中的資料管道：Spotify 與 Netflix 的例項分析

Spotify Wrapped：十年資料匯總的挑戰與創新

Spotify 每年都會為使用者提供一份名為 Spotify Wrapped 的年度回顧報告，彙總使用者過去一年的音樂聆聽資料，包括總播放分鐘數、年度最愛歌手、歌曲和音樂型別等。這個看似簡單的功能背後，卻需要多個團隊的協同合作，包括行銷、前端工程和資料工程團隊。

2019 年，Spotify 決定進一步挑戰自我，推出「十年回顧」功能，匯總使用者過去十年的聆聽資料。根據 Spotify 官方部落格的文章，這個功能的實作過程並非一帆風順。資料工程團隊面臨的主要挑戰包括：

  • 如何處理龐大的使用者資料（當時 Spotify 的月活躍使用者已達 2.48 億）
  • 如何擴充套件資料處理規模以滿足十年資料的需求

為瞭解決這些問題，Spotify 採用了 Google BigTable（一種 NoSQL 資料函式庫）來儲存中間資料和最終結果。每位使用者在 BigTable 中對應一行資料，包含多個欄位代表不同的資料維度（如最愛歌手、歌曲等），每個欄位再細分為每年的資料。這種設計帶來了多個好處：

  1. 資料預先分組：將不同資料維度按照使用者進行分組，大幅簡化了後續的資料處理流程。
  2. 作業解耦：不同的資料維度可以透過獨立的作業進行處理，並且可以平行執行，提高了整體處理效率。
  3. 靈活擴充套件：利用 BigTable 的擴充套件能力，Spotify 能夠輕鬆應對龐大的資料量。

內容解密：

Spotify 的做法展現了資料工程中的幾個重要原則：

  • 持續迭代：不斷最佳化資料管道的架構和處理方式。
  • 模組化設計：將大型作業拆解為小型、獨立的作業，提高效率和可維護性。
  • 工具選擇的多樣性：根據具體需求選擇合適的工具，如 NoSQL 資料函式庫對於處理大規模資料的優勢。

Netflix 的串流媒體檔案處理：大規模網路流量監控

Netflix 是全球最大的串流媒體服務提供商之一，擁有超過 2 億全球使用者。其基礎設施主要建立在 AWS 之上，需要大量的運算資源和微服務來支撐如此龐大的使用者群。為了維護服務的穩定性和提升使用者經驗，Netflix 需要監控網路流量在不同微服務之間的流動。

AWS 的 VPC FlowLogs 功能可以捕捉 VPC 內網路介面之間的網路流量細節。Netflix 利用這一功能來：

  • 維護服務彈性
  • 瞭解服務之間的依賴關係
  • 進行故障排查
  • 識別改進使用者經驗的機會

內容解密：

Netflix 的案例再次強調了以下幾點的重要性：

  • 大規模資料處理能力：能夠處理和分析海量的網路流量日誌。
  • 微服務架構下的監控：在複雜的微服務架構中，監控網路流量對於維護整體系統的穩定性至關重要。
  • 雲端服務的靈活運用：Netflix 充分利用 AWS 提供的服務（如 VPC FlowLogs）來實作其監控需求。

檢視真實世界中的資料管線範例

大多數AWS服務使用動態IP位址，這意味著系統使用的IP位址可能會頻繁變更。因此，雖然VPC FlowLogs提供了豐富的IP位址之間的網路通訊資訊，但如果不知道哪些應用程式或服務在特定時間使用了被報告的IP位址，那麼這些流量日誌基本上是毫無意義的。

用應用程式資訊豐富VPC FlowLogs

為了獲得有意義的資料，Netflix決定用特定時間點的應用程式資訊來豐富VPC FlowLogs，以記錄特定IP位址的使用情況。為了捕捉這些資訊，Netflix建立了一個名為Sonar的內部系統，該系統使用CloudWatch Events、Netflix Events、API呼叫和其他各種方法來捕捉IP變更事件流。

技術實作細節

在2017年，AWS在其網站上的案例研究中介紹了Netflix的解決方案，標題為《Netflix & Amazon Kinesis Data Streams Case Study》。在這項案例研究中，解釋了Netflix如何使用大型Kinesis Data Streams叢集（最多1,000個分片）來處理傳入的VPC FlowLogs。一個名為Dredge的內部Netflix應用程式被建立用於從Kinesis Data Stream讀取傳入的資料，並用Sonar流中的IP變更事件的應用程式元資料豐富VPC流量日誌資料，以識別與每個VPC流量日誌記錄相關的應用程式或微服務。這種豐富的資料然後被載入到一個名為Druid的開源、高效能、實時分析資料函式庫中，使用者可以在其中高效地分析網路資料，以進行故障排除和獲得對網路效能的深入洞察。

Amazon VPC增強功能與架構變更

在雲端環境中，情況經常變化，AWS不斷改進其服務並根據客戶反饋新增服務。2018年8月，AWS增強了VPC Flow Logs服務，使日誌可以直接交付到Amazon S3，而無需先透過Kinesis處理。

新架構的優勢

2020年5月，Netflix發表了一篇公開的部落格文章，標題為《How Netflix is able to enrich VPC Flow Logs at Hyper Scale to provide Network Insight》。這篇部落格文章展示了Netflix如何改變其架構，以充分利用VPC Flow Logs功能的更新。

處理新上傳的S3檔案

在這篇部落格文章中，Netflix討論了一個常見的模式，用於處理新上傳到S3的檔案。當新的檔案上傳到S3時，可以組態一個動作來回應新上傳的檔案。Netflix通常使用這種模式將新上傳檔案的詳細資訊寫入Amazon SQS佇列，然後可以從佇列中讀取事件以處理新到的檔案。這使他們能夠將S3事件與希望對此事件執行的動作分離開來。

技術挑戰與解決方案

在這種情況下，Netflix打算讀取SQS佇列中的條目，並使用事件通知中包含的檔案大小資訊來確定一批新攝入的VPC流量日誌檔案的數量（他們稱之為“一口檔案”）。他們打算使用Apache Spark作業來根據每個記錄中記錄的IP位址豐富VPC流量日誌的應用程式元資料。他們將調整Apache Spark作業以最佳地處理一定量的資料，這就是為什麼他們會讀取SQS訊息中包含的檔案大小資訊，以建立最佳大小的一口檔案送給Spark作業。

Amazon SQS服務限制與創新解決方案

使用Amazon SQS服務時，訊息會從佇列中讀取並處理。如果處理成功，則已處理的訊息將從佇列中刪除。在此處理期間，訊息被視為“在飛行中”，並將對佇列隱藏，以便其他應用程式不會嘗試處理相同的檔案。如果出現問題且檔案未成功處理和從佇列中刪除，則訊息將在一定時間後再次變為可見（稱為可見性超時期限），以便應用程式可以再次拾取它們進行處理。

克服SQS限制

在Netflix的案例中，他們會將一口檔案傳送給Apache Spark作業，一旦Spark作業成功處理了訊息，訊息就會從佇列中刪除。然而，Amazon SQS服務對任何時候可以視為“在飛行中”的訊息數量有限制（預設配額限制為120,000條訊息）。Netflix發現，由於Spark作業需要一段時間來處理檔案，他們經常最終會有120,000或更多的訊息在飛行中。因此，他們想出了一個創新的方法，透過使用兩個不同的SQS佇列來解決這個問題。

內容解密：

此段落主要闡述了Netflix如何利用Amazon SQS服務處理VPC FlowLogs，並克服SQS服務的限制。他們透過使用兩個SQS佇列來解決訊息在飛行中的數量限制，從而實作了高效的資料處理流程。這種創新的解決方案展現了Netflix在大規模資料處理方面的技術實力。

此圖示說明瞭 Netflix 處理 VPC FlowLogs 的流程，包括上傳日誌到 S3、觸發 SQS 佇列事件、使用 Apache Spark 豐富日誌內容，以及將結果儲存到 Druid 進行分析。

內容解密：

此圖示呈現了 Netflix 處理 VPC FlowLogs 的整體流程。首先，日誌被上傳到 S3，接著觸發 SQS 佇列事件。然後，透過讀取 SQS 佇列事件，使用 Apache Spark 對 VPC FlowLogs 進行豐富，最後將豐富後的資料儲存到 Druid 中進行分析。這種流程設計使得 Netflix 能夠高效地處理和分析網路日誌，從而獲得深入的網路洞察。

檢視真實世界中的資料管道範例

處理 Amazon SQS 配額限制

Netflix 重新設計的解決方案會讀取包含 S3 事件的 SQS 佇列，並執行一個流程來建立一批檔案（評估每個檔案的大小以建立適合其 Spark 作業的最佳批次大小）。此流程可以很快完成，因為它不需要讀取或處理檔案，只需讀取 SQS 訊息中包含的元資料即可將一批檔案分組以供 Spark 作業處理。

第一個作業的輸出會將訊息寫入第二個 SQS 佇列，每個訊息包含一批檔案的清單。雖然部落格文章中沒有提供有關通常包含在這批檔案中的檔案數量的任何資訊，但如果我們假設平均約為 10 個檔案，則會將第二個 SQS 佇列中的訊息數量減少 90%。如果一批檔案平均為 100 個檔案，則寫入次要 SQS 佇列的訊息數量將減少 99%。

內容解密：

此段落描述了 Netflix 如何最佳化其資料處理流程。他們透過建立一個 Lambda 函式來讀取 SQS 佇列中的訊息，並根據檔案大小元資料建立最適當大小的批次（稱為一批檔案）。這個 Lambda 函式可以快速完成並從第一個 SQS 佇列中移除訊息，因為它只處理 SQS 訊息中的元資料，而不讀取或寫入 S3 檔案。

import boto3

sqs = boto3.client('sqs')

def lambda_handler(event, context):
    # 從 SQS 佇列中讀取訊息
    response = sqs.receive_message(
        QueueUrl='https://sqs.us-east-1.amazonaws.com/123456789012/my-queue'
    )
    
    # 處理訊息並建立一批檔案
    files_to_process = []
    for message in response['Messages']:
        # 解析訊息並取得檔案清單
        files = parse_message(message['Body'])
        files_to_process.extend(files)
        
    # 將一批檔案的清單寫入第二個 SQS 佇列
    sqs.send_message(
        QueueUrl='https://sqs.us-east-1.amazonaws.com/123456789012/my-secondary-queue',
        MessageBody=json.dumps(files_to_process)
    )

未來趨勢與新興技術

ACID 交易直接在資料湖上進行

目前正在發展的一個趨勢是為資料湖表格提供原子性、一致性、隔離性、永續性（ACID）屬性，這為資料集交易（平行讀取和寫入）提供了保證。此外，許多新技術都具備更新或刪除資料湖中個別記錄的能力。在這些新技術出現之前，缺乏 ACID 交易和更新、刪除資料湖中的記錄的能力是一個重大挑戰，每個資料湖的實作都需要建立方法來解決這個挑戰。

更多資料和串流攝取

預計未來幾年將繼續增長的一個趨勢是新資料的生成量。並非所有新生成的資料都會長期儲存，但預測表明儲存的資料將持續增長。

多雲策略

本文重點介紹使用 AWS 服務進行資料工程，但許多大公司採用多雲策略，使用多個雲提供商的服務。

分散式資料工程團隊、資料平台和資料網格架構

自公司內部設立電腦部門以來，始終存在著集中處理和分散處理之間的拉鋸戰。

VPC 流日誌處理和豐富化的潛在架構

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title VPC 流日誌處理和豐富化的潛在架構

rectangle "寫入事件" as node1
rectangle "觸發" as node2
rectangle "建立一批檔案" as node3
rectangle "執行 Glue 作業" as node4
rectangle "寫入" as node5

node1 --> node2
node2 --> node3
node3 --> node4
node4 --> node5

@enduml

此圖示顯示了 VPC 流日誌處理和豐富化的潛在架構。VPC 流日誌被寫入 Amazon S3，然後透過 EventBridge 觸發 Lambda 函式。Lambda 函式建立一批檔案並將其寫入第二個 SQS 佇列。另一個 Lambda 函式讀取第二個 SQS 佇列中的訊息並執行 Glue 作業來豐富 VPC 流日誌。

重點整理

  • 瞭解所使用的 AWS 服務的配額限制非常重要。
  • 跟上 AWS 的最新公告非常重要，因為新的服務和功能可能會簡化現有的架構並降低成本。
  • 未來趨勢包括 ACID 交易直接在資料湖上進行、更多資料和串流攝取、多雲策略和分散式資料工程團隊、資料平台和資料網格架構。