如何評估數據管道的成本性能

從德國#1天氣門戶網站了解設計和評估成本-性能基準的最佳實踐。

當然我們也會進行幾次基準，我們知道最好的基準是您的查詢在您的數據上運行。但是你在評估中參照的是什麼呢?答案似乎很明顯——成本和與雲架構路線圖的集成。

然而，我們發現許多企業隻是度量工作流中單個服務的成本，而不是整個工作流的成本。當比較不同的架構時，運行一個完整的工作流將展示所消耗的總資源(數據引擎+計算+輔助支持功能)。

如果不知道每個體係結構的持續時間、作業失敗率以及支持作業所需的人工工作量，比較兩個體係結構中單個組件的列表價格最多隻會產生誤導。

Wetter.com案例分析

wetter.com是DACH地區排名第一的B2C天氣門戶網站，每月擁有高達2000萬的獨立用戶，以及完整的跨媒體生產。為了利用數據並將其貨幣化，wetter.com創建了一個名為METEONOMIQS的新業務部門。有了METEONOMIQS，該公司現在可以通過開發和銷售數據產品給商業客戶，從他們的數據中產生新的收入流。beplay体育app下载地址METEONOMIQS提供天氣和基於地理的數據科學服務，以解碼天氣、消費者行為和零售、快消品、電子商務、旅遊、食品和廣告客戶使用的許多其他因素之間的相互關係。

METEONOMIQS的挑戰

METEONOMIQS選擇了亞馬遜EMR來處理他們的數據，從原始攝入到清洗和彙總，為下遊API用戶服務。最初，EMR顯然是同類中最好的基於雲的Spark引擎，適合他們的AWS堆棧。

然而，這種體係結構很快就達到了它的極限。數據管道需要大量的手工工作來更新行和清理表，需要大量的DevOps工作來維護，並且由於長時間的開發周期限製了使用ML的潛力。在將ML模型從DS轉移到DE時，糟糕的筆記本體驗和錯誤風險使得同時支持多個模型變得更加困難。

然而，業務麵臨的最大風險是無法實現符合gdpr的自動化工作流，例如，輕鬆刪除單個客戶。beplay体育app下载地址相反，METEONOMIQS不得不手動清理數據，導致停機數天。GDPR的罰款高達母公司的4%全球這給母公司ProSiebenSat.1帶來了很大的風險。

構建測試

METEONOMIQS求助於Databricks，看看是否有更好的方法在Amazon S3上構建數據攝取、處理和管理。與Databricks合作，他們設置了一個測試，以查看在Databricks上運行該管道的情況:

矢量分析	功能要求
設置	用戶能夠設置iam訪問角色 能夠集成到他們現有的AWS Glue數據目錄作為一個亞礦
管道遷移	能夠將代碼從現有的管道直接遷移到Databricks，而無需進行重大的重新設計。注意:他們沒有在這個測試中處理代碼優化
GDPR合規	能夠使用(測試)客戶/應用程序id構建一個表，可以刪除以滿足GDPR要求(被遺忘的權利)。 能夠設置自動刪除作業，從所有中間和結果表中刪除id，並驗證結果
清理/更新	能夠重新構造先前更新/清理過程的示例。 根據上麵的例子建立一個清理程序，並對受影響的記錄進行更新
易用性	通過使用內置功能和外部繪圖庫(如matplotlib)，可以輕鬆地在databrick -notebook中構建可視化。 能夠通過將兩個筆記本電腦連接到一個集群來處理多個項目/流
ML模型管理	從當前環境中選擇一個現有模型，並將訓練過程的代碼遷移到Databricks 進行培訓運行，並使用MLFlow跟蹤服務器跟蹤所有參數、指標和工件 可選:以當前使用的專有格式存儲工件 在MLflow model Registry中注冊(最佳)模型，將其設置為“生產”狀態並演示批準過程 通過MLflow模型注冊表演示從數據領域(模型構建)到業務領域係統(模型生產)的切換
總成本	使用PoC生成的數據和其他信息(進一步的管道/數據大小/用戶數量/…)來預測基礎設施成本，包括Databricks、計算和存儲。

基準測試結果

不停機的數據更正/增強

矢量分析	EMR-based架構	Databricks-based架構
設置	✔	✔
管道遷移	- - - - - -	✔
GDPR合規	✘ GDPR在停機時間內刪除數小時/數天	✔ GDPR在幾分鍾內刪除，沒有停機時間
清理/更新	✘ 需要停機數天	✔
易用性	✘	✔
ML模型管理	✘	✔ 改善數據科學家和數據工程師/開發團隊之間的協作
總成本	80%的EMR成本來自專門的開發和分析集群，導致不可預測的計算成本。 DataOps需要大量開發人員資源來維護。	通過集群共享，METEONOMIQS可以更有效地使用雲資源 但更重要的是，他們現在可以做新的用例，如自動化GDPR合規，並以以前不可能的方式擴展他們的ML。

對於METEONOMIQS, Databricks架構的主要收益是:

1. 添加由於高水平的開發成本而沒有部署在EMR上的用例(例如，自動數據更正和增強)
2. 大大減少了管道所需的人工維護量
3. 簡化和自動化GDPR合規流程，現在可以在幾分鍾內完成，無需停機，而以前需要停機數小時/數天

此外，該團隊在EMR體係結構中有很高的AWS資源消耗，因為在EMR上不可能實現共享環境。因此，團隊成員必須使用專用的集群。Databricks為所有開發人員提供的共享環境，加上在共享項目(即筆記本)上工作的能力，從而更有效地利用人力和基礎設施資源。

從數據科學家到數據工程團隊的ML模型交接非常複雜，導致ML代碼出現分歧。有了MLflow，團隊現在可以輕鬆地移交模型並隨時間跟蹤更改。

此外，由於Databricks筆記本電腦更容易使用，METEONOMIQS可以使更廣泛的受眾訪問數據湖，例如，移動應用程序團隊。

作為他們的下一步之一，METEONOMIQS將尋求優化他們的代碼，以進一步節省基礎設施和提高性能，並考慮其他管道過渡到Databricks架構。

外賣

團隊成功基準測試的關鍵依賴於

1. 知道他們在衡量什麼:在評估不同的架構時，客戶通常隻會比較單個服務的清單價格(例如，比較一個Spark引擎與另一個的成本)。我們試圖建議客戶不要隻看單個服務，而要看總作業成本(數據引擎+計算+團隊生產力)與所交付的業務價值之間的關係。在這種情況下，wetter.com的數據工程團隊將他們的測試與整體業務目標保持一致——確保他們的數據管道能夠支持業務和監管需求，同時減少基礎設施和開發人員開銷。
2. 選擇關鍵工作負載:團隊沒有嚐試一次遷移所有的管道，而是將範圍縮小到他們最緊迫的業務案例。通過這個項目，他們能夠驗證Databricks可以處理數據工程、機器學習，甚至是基本的業務分析，在規模、預算和及時的方式。
3. 快速交付價值:對於這個團隊來說，關鍵是要盡快從討論到poc再到生產，從而開始節省成本。討論拖上幾個月甚至更長的時間，既不可取，也不能很好地利用團隊的時間。與Databricks合作，他們在不到三周的時間內就建立了第一個基準poc。

準備好自己進行評估了嗎?

如果您希望運行自己的測試來比較不同雲數據管道的成本和性能，請給我們寫信(電子郵件保護)．我們可以根據您的完整工作流程為您提供定製評估，並幫助您獲得任何晉升機會。評估包括:

• 技術驗證:了解數據源、下遊數據使用以及當前運行管道作業所需的資源
• 業務價值分析:確定公司的戰略優先級，以理解技術用例(如ETL)如何驅動業務用例(如個性化、供應鏈效率、體驗質量)。這確保了我們的sa設計的解決方案不僅適合今天的需求，而且適合您業務的持續發展。

下麵是我們基於設計和評估數據管道基準測試的最佳實踐的一般方法的概要。

設計測試

給定同一企業內的數據管道可能根據數據的來源和最終用途而有很大差異——大型企業可能有跨越供應鏈、營銷、產品和運營的數千個數據管道——您如何測試一個架構以確保它可以跨一係列場景、最終用戶角色和用例工作?更重要的是，你如何在有限的時間內完成它?你想要的是能夠盡可能快地從測試到驗證，再到跨盡可能多的管道進行擴展，以降低成本和數據工程師的支持負擔。

我們看到的一種方法是選擇在架構上代表企業大多數管道的管道。雖然這是一個很好的考慮，但我們發現主要基於架構考慮來選擇管道並不一定會帶來最大的整體影響。例如，您最常見的數據管道體係結構可能用於較小的管道，這些管道不一定會驅動您的基礎設施成本，也不需要數據工程師提供最多的故障排除支持。

相反，我們建議客戶將基準測試的範圍限製在3-5個數據管道，這主要基於以下兩點考慮:

• 首先在業務關鍵數據工作負載上進行測試:通常第一反應是從不太重要的工作負載開始，然後隨著體係結構的證明而向上移動。但是，我們建議首先在戰略上、業務關鍵管道上運行測試，因為盡早了解架構是否能夠交付必要的業務sla要好於晚些時候。一旦您證明了您可以交付重要的工作，那麼將不那麼關鍵的管道轉移到新的架構就變得更容易了。但是反過來(從不那麼關鍵到更關鍵)將需要驗證兩次——首先在初始測試中，然後在重要的工作負載中再次驗證一次。
• 根據影響性能的主要壓力源選擇管道:是什麼導致了長交貨時間、工作延誤或工作失敗?在選擇測試管道時，確保您知道當前架構的壓力源是什麼，並選擇產生長時間延遲、高失敗率和/或需要數據工程團隊持續支持的代表性管道。例如，如果您是一家製造商，試圖實時查看您的供應鏈，從零件供應商到組裝到運輸，但您的物聯網管道需要數小時才能批量處理大量小文件，這是一個理想的測試候選對象。

評估結果

一旦選擇了要測試的數據管道，要評估的關鍵指標是:

1. 運行一個作業的總成本:運行作業所需的總資源是多少?這意味著不僅要考慮攝取和處理的數據引擎成本，還要考慮完成數據查詢的總計算和支持功能成本(如數據驗證)。另外，你的管道的故障率是多少?頻繁的作業失敗意味著要多次重新處理數據，這會顯著增加基礎設施成本。
2. 運行作業的時間:在添加集群啟動和數據處理以及識別和修複作業故障所需的時間之後，運行作業需要多長時間?這段時間越長，基礎設施的成本就越高，但你的數據驅動真正的業務價值/洞察所需的時間也就越長。企業依賴數據來做出重要的業務決策，而交付周期長的剛性管道阻礙了業務的快速迭代。
3. 生產力:作業失敗的頻率是多少?數據工程師需要多長時間來查看日誌以找到根本原因、排除故障並解決問題?這種生產力的損失是一種真正的成本，它會增加員工數量，再加上讓數據工程師專注於基本數據可靠性問題而不是解決更高層次的業務問題的機會成本。即使作業正常運行，下遊用戶是否使用了最新的信息?在報告、分析和數據科學中使用數據之前，他們是否被迫重複刪除和清理數據?特別是對於流數據(其中可能有亂序文件)，如何確保跨用戶擁有一致的數據?
4. 可擴展性:添加新的用例或數據源是否需要完全重新設計您的數據管道，或者您是否擁有一個可以隨著數據需求而發展的模式?

此外，當企業希望創建一個更經得起未來考驗的架構時，他們應該關注:

• 實現的複雜性:這將是一次多大的遷徙?重組需要多複雜?建立一個新的數據管道需要多少數據工程資源，需要多長時間?您的體係結構能夠多快地滿足安全需求?當英國食品盒公司Guosto在Databricks上重建了到Delta Lake的ETL管道時，他們指出“整個實施，從第一次接觸Databricks到投入生產運行，花了大約兩個月的時間——考慮到Gousto技術的規模和適當的治理流程，這是驚人的快。”
• 可移植性:隨著越來越多的企業轉向多雲，他們的架構跨雲的可移植性如何?數據以專有格式保存是否會導致供應商鎖定(即，將來轉換是否需要大量成本)?