從德國第一天氣門戶網站學習設計和評估性價比基準的最佳實踐。
當然我們也會指揮一些基準，我們知道最好的基準測試是在數據上運行的查詢。但是，你的評估標準是什麼呢?答案似乎顯而易見——成本和與雲架構路線圖的集成。
然而，我們發現，許多企業隻測量工作流中單個服務的成本，而不是工作流的全部成本。當比較不同的架構時，運行一個完整的工作流將展示消耗的總資源(數據引擎+計算+輔助支持功能)。
如果不知道每個體係結構的持續時間、作業失敗率以及支持作業所需的手工工作，那麼比較兩個體係結構中各個組件的清單價格最多隻會產生誤導。
wetter.com的案例研究
wetter.com是DACH地區排名第一的B2C天氣門戶網站，每月擁有多達2000萬獨立用戶，並提供全麵的跨媒體產品。為了利用數據並將其變現，wetter.com創建了一個名為METEONOMIQS的新業務部門。有了METEONOMIQS，該公司現在可以通過開發和銷售數據產品給企業客戶，從他們的數據中產生新的收入流。beplay体育app下载地址METEONOMIQS提供基於天氣和地理的數據科學服務，解碼天氣、消費者行為和零售、快速消費品、電子商務、旅遊、食品和廣告客戶使用的許多其他因素之間的相互關係。
METEONOMIQS的挑戰
METEONOMIQS選擇了Amazon EMR來處理從原始攝入到清理和聚合的數據，以服務下遊API用戶。最初，EMR是最佳的基於雲的Spark引擎，適合他們的AWS棧。
然而，這種架構很快就達到了極限。數據管道需要大量的手工工作來更新行和清理表，需要大量的DevOps工作來維護，並且由於長時間的開發周期，限製了使用ML的潛力。當將ML模型從DS移交給DE時，糟糕的筆記本體驗和錯誤風險使得一次支持多個模型變得更加困難。
然而，業務麵臨的最大風險是無法實現自動化的符合gdprp的工作流，例如，通過容易地刪除單個客戶。beplay体育app下载地址相反，METEONOMIQS必須手動清理數據，導致停機數天。GDPR的處罰金額高達母公司的4%全球這給母公司prosiebensat帶來了很大的風險。
構建測試
METEONOMIQS轉向Databricks，看看是否有更好的方法在Amazon S3上構建他們的數據攝取、處理和管理。與Databricks合作，他們建立了一個測試，看看在Databricks上運行這個管道的情況:
| 矢量分析 | 功能要求 |
| 設置 |
|
| 管道遷移 |
|
| GDPR合規 |
|
| 清理/更新 |
|
| 易用性 |
|
| 毫升模型管理 |
|
| 總成本 |
|
基準測試結果
無需停機時間的數據修正/增強
| 矢量分析 | EMR-based架構 | Databricks-based架構 |
| 設置 | ✔ | ✔ |
| 管道遷移 | - - - - - - | ✔ |
| GDPR合規 | ✘ GDPR在停機時間內按小時/天刪除 |
✔ GDPR在幾分鍾內刪除，無需停機 |
| 清理/更新 | ✘ 需要幾天的停機時間 |
✔ |
| 易用性 | ✘ | ✔ |
| 毫升模型管理 | ✘ | ✔ 改善數據科學家和數據工程師/開發團隊之間的協作 |
| 總成本 | 80%的EMR成本來自於專門的開發和分析集群，這導致了不可預測的計算成本。 數據操作需要大量的開發人員資源來維護。 |
通過集群共享，METEONOMIQS可以更有效地使用雲資源 但更重要的是，他們現在可以做新的用例，比如自動遵從GDPR，並以以前不可能的方式擴展ML。 |
對於METEONOMIQS來說，Databricks架構的主要收獲是:
- 添加由於高開發成本而沒有部署在EMR上的用例(例如，自動數據更正和增強)
- 大大減少了對管道的人工維護
- 簡化和自動化管道的GDPR遵從性，因此現在可以在幾分鍾內完成，而以前需要停機的時間是幾小時/天
此外，該團隊在EMR架構中有很高的AWS資源消耗，因為在EMR上不可能實現共享環境。因此，團隊成員必須使用專用的集群。Databricks為所有開發人員提供的共享環境，以及在共享項目上工作的能力(例如，筆記本電腦)，導致更有效地使用人力和基礎設施資源。
ML模型從數據科學家到數據工程團隊的交接非常複雜，導致ML代碼產生分歧。有了MLflow，團隊現在有了一種舒適的方式來移交模型並隨著時間的推移跟蹤更改。
此外，由於Databricks筆記本電腦使用起來更容易，METEONOMIQS可以讓更廣泛的受眾訪問數據湖，例如，移動應用程序團隊。
作為他們下一步的行動之一，METEONOMIQS將著眼於優化他們的代碼，以進一步節省基礎設施和提高性能，同時著眼於其他渠道，以過渡到Databricks體係結構。
外賣
團隊成功基準的關鍵就在於此
- 知道他們測量的是什麼:當評估不同的架構時，客戶通常隻會比較單個服務的列表價格(例如，比較一個Spark引擎和另一個引擎的成本)。我們試圖給客戶的建議是，不要隻看單個服務，而要看總工作成本(數據引擎+計算+團隊生產力)與交付的業務價值的對比。在這種情況下，wetter.com的數據工程團隊將他們的測試與整體業務目標結合起來——確保他們的數據管道能夠支持業務和監管需求，同時減少基礎設施和開發人員的開銷。
- 選擇關鍵工作負載:團隊沒有嚐試一次遷移所有管道，而是將範圍縮小到他們最緊迫的業務案例。通過這個項目，他們能夠驗證Databricks能夠在規模、預算和及時的情況下處理數據工程、機器學習，甚至基本的商業分析。
- 快速交付價值:對該團隊來說，關鍵是盡快從討論轉向生產，從而開始節約成本。持續數月甚至更長時間的討論既不可取，也不能很好地利用團隊的時間。通過使用Databricks，他們能夠在不到三周的時間內完成第一個基準PoCs。
準備好運行自己的評估了嗎?
如果您希望運行自己的測試來比較不同雲數據管道的成本和性能，請與我們聯係sales@www.eheci.com．我們可以根據您的完整工作流程提供定製評估，幫助您獲得任何晉升機會。評估包括:
- 技術驗證:了解當前運行管道作業所需的數據源、下遊數據使用和資源
- 業務價值分析:識別公司的戰略優先級，了解技術用例(如ETL)如何驅動業務用例(如個性化、供應鏈效率、體驗質量)。這可以確保我們的情景應用程序設計的解決方案不僅能滿足當前的需求，還能適應業務的不斷發展。
下麵是基於設計和評估數據管道基準測試的最佳實踐的通用方法概要。
設計測試
給定同一企業中的數據管道，根據數據的來源和最終用途可能會有很大的不同——大型企業可能有跨越供應鏈、市場、產品和運營的數千個數據管道——如何測試架構以確保它能夠跨一係列場景、最終用戶角色和用例工作?更重要的是，如何在有限的時間內完成?您想要的是能夠從測試、驗證到跨盡可能多的管道快速擴展，以減少成本以及數據工程師的支持負擔。
我們看到的一種方法是選擇在體係結構上代表企業大多數管道的管道。雖然這是一個很好的考慮，但我們發現主要基於架構考慮來選擇管道並不一定會帶來最大的總體影響。例如，最常見的數據管道體係結構可能用於較小的管道，這些管道不一定會增加基礎設施成本或需要數據工程師提供最多的故障排除支持。
相反，我們建議客戶基於以下兩點考慮，將基準測試的範圍限製在3-5個數據管道內:
- 首先測試業務關鍵數據工作負載:通常情況下，第一個條件是從不太重要的工作負載開始，然後在體係結構證明自己時向上移動堆棧。但是，我們建議首先在戰略的、業務關鍵管道上運行測試，因為盡早知道體係結構是否能夠交付必要的業務sla比晚知道更好。一旦您證明您可以交付重要的工作，那麼將不那麼關鍵的管道轉移到一個新的架構就變得更容易了。但是反過來(從不那麼關鍵的到更關鍵的)將需要驗證兩次—首先在初始測試中，然後在重要的工作負載中再次驗證。
- 根據影響性能的主要壓力源選擇管道:是什麼導致了交貨期過長、工作延遲或工作失敗?在選擇測試管道時，確保您知道當前架構的壓力源是什麼，並選擇產生長延遲、高失敗率和/或需要數據工程團隊持續支持的代表性管道。例如，如果您是一家製造商，試圖獲得從零部件供應商到組裝到運輸的供應鏈的實時視圖，但您的物聯網管道需要數小時來批量處理大量小文件，這是一個理想的測試候選人。
評估結果
一旦選擇了要測試的數據管道，要評估的關鍵指標是:
- 運行一項作業的總成本:運行作業所需的總資源是多少?這意味著不僅要查看數據引擎攝取和處理的成本，還要查看完成數據查詢的總計算和支持功能成本(如數據驗證)。另外，你的管道失敗率是多少?頻繁的作業失敗意味著需要多次重新處理數據，這將顯著增加基礎設施成本。
- 運行作業的時間:添加集群啟動和數據處理後，運行作業需要多長時間，以及識別和糾正作業失敗所需的時間?這段時間越長，基礎設施成本越高，同時，您的數據推動真正的業務價值/見解所需的時間也就越長。企業依賴數據來做出重要的業務決策，而交付時間過長的僵化管道阻礙了業務的快速迭代。
- 生產力:作業失敗的頻率有多高，數據工程師查看日誌以查找根本原因、排除故障和解決問題需要多長時間?這種生產力的損失是一種實際成本，即員工數量的增加，以及讓數據工程師專注於基本的數據可靠性問題，而不是解決更高級別的業務問題的機會成本。即使作業正常運行，下遊用戶是否使用了最新的信息?在報表、分析和數據科學中使用數據之前，是否需要對數據進行重複數據刪除和清理?特別是對於可能出現無序文件的流數據，如何確保跨用戶擁有一致的數據?
- 可擴展性:添加新的用例或數據源是否需要對數據管道進行完全的重新設計，或者您是否有一個可以根據數據需求進行改進的模式?
此外，當企業希望創建一個更未來的證明架構時，他們應該注意:
- 實現的複雜性:這將是一個多大的遷移?所需的重新設計有多複雜?建立一個新的數據管道需要多少數據工程資源，需要多長時間?您的體係結構符合安全需求的速度有多快?當英國食品包裝盒公司Guosto重建他們通往Databricks三角洲湖的ETL管道時，他們指出“整個實施過程，從第一次接觸Databricks到將工作投入生產大約花了兩個月時間——考慮到Gousto技術的規模和適當的治理過程，這是驚人的快。”
- 可移植性:隨著越來越多的企業轉向多雲，它們的架構在雲上的可移植性如何?數據以專有格式保存是否會導致供應商被鎖定(也就是說，將來切換需要大量成本)?
