Janus：Myntra 的資料處理框架

資料是什麼
檢視 1000 個表，每個表都有 100 個列是令人生畏的。因此，對於資料消費者而言，重要的是找到正確的資料集，促進重用以避免重複處理並消除知識孤島。

查詢資料
資料定位之後，就是查詢資料和實驗的能力。資料儲存、計算框架、儲存服務的聯結器在新版本中變得更好。在這裡，重要的是提供介面/sdk 來訪問資料，同時平臺團隊維護基礎架構、版本升級、表格格式等。

確定計算基礎設施
spark、presto、flink、ray、hive 等框架可以將大型資料集的處理分佈到多個分割槽/任務上。這些工具中的每一個都是專門構建的，因此確定適合的地方至關重要。此支援必須有足夠的計算能力（記憶體和 CPU）來支援作業。如果資源不足，則作業將受到限制或失敗。對於計劃作業，每次執行的最佳資源可用性對於滿足 SLA 很重要。

資料管道開發
低程式碼和程式碼優先
低程式碼需要一個應用程式，消費者可以使用該應用程式以最少的開銷編寫管道。如果使用 SQL 驅動方法，低是有利的。程式碼優先可以由標準 IDE 或膝上型電腦提供支援。程式碼優先適用於高階使用者，例如正在試驗統計庫的資料科學家或透過 API 或訊息佇列使用資料的服務開發人員。

測試驅動開發
在沒有測試驅動開發方法的情況下編寫多步驟資料管道將限制生產力。Python 實際上已被資料科學界採用，主要是因為它的解釋能力有助於測試驅動開發。在構建資料管道的同時進行測試驅動開發對於使用者有效使用該平臺至關重要。

作業依賴
作業依賴性對於操作相互依賴的管道來說絕對是至關重要的。隨著資料管道數量和複雜性的增加，資料集依賴性的深度和廣度被放大。沒有依賴關係，未捕獲的延遲會導致部分執行需要昂貴的回填，並且對上游故障的影響半徑視而不見。

部署和驗證
構建和部署
打包程式碼和部署可執行檔案可能是一個耗時的過程。如果要重複多次迭代以獲得正確的結果，則更是如此。我們都同意盯著構建和部署螢幕並希望它很快！這是資料工程中一個嚴重且經常被忽視的問題。因此，透過有效的 CI-CD 縮短開發時間是一個重要的考慮因素。
資料驗證和準確性
驗證處理資料的完整性需要預期輸出的功能知識。業務團隊是執行驗證的最佳判斷。因此，提供正確的工具來促進線上和離線模式下的這些驗證會增加對資料的信任。在自信地交付資料驅動的決策之前，對資料的信任是最重要的一個指標。

操作
監控和警報
管道健康狀況的可見性應透明地傳達給所有租戶。在組織內設定正確的流程以傳達資料質量可構建值得信賴的資料驅動文化。維護處理生態系統所花費的時間比開發多很多倍。部署的任何管道都必須遵循標準指導原則，至少可以集中監控資料可用性、計算和儲存資源消耗。警報的結果應遵循手動或自動恢復。

基礎設施的擴充套件
電子商務中的處理基礎設施必須處理遵循季節性趨勢、銷售活動期間激增、有機和無機增長的資料。識別系統負載並調整規模以滿足 SLA，從而避免過度配置和最佳化雲端計算成本是一個重要的驅動引數。

修改和回填
修改管道和執行資料回填是常見的操作問題，應該可以在沒有開銷的情況下完成。

作業最佳化
“總有改進的餘地”
採用更新的高效能技術可以極大地最佳化工作效能，從而節省計算和儲存基礎設施的費用。

Janus 處理平臺架構
Janus 處理框架整合了使用一個應用程式編寫處理作業的生命週期中的所有步驟。它是可擴充套件的，可以使用支援的語言新增更多聯結器、處理引擎和多雲支援，以滿足分析師和資料科學等方面的需求。在瞬息萬變的資料工程世界中，保持系統敏捷性以便為組織採用新的更好的技術非常重要。下面是平臺的高階架構，其中包含每個元件的細分。

​

資料目錄
資料目錄使用確保質量和策略實施所需的工具來顯示錶定義和工作流的後設資料。這是作為資料生態系統一部分的表定義的真實來源。它是設定訪問控制策略、啟用質量檢查和保留/清除策略的聯絡點。跨不同工作流程的資料流可以使用沿襲功能在資料目錄上視覺化。

​

管道建​​模
如何開發ETL pipeline是下一個要解決的問題。這也是我們所說的“設計時”階段。在這裡，開發人員使用多步方法編寫轉換程式碼。這些步驟連線形成有向無環圖（DAG） 使用 Myntra 開發的低程式碼應用程式平臺或使用 IDE 和筆記本的標準程式碼優先方法，編寫 DAG 是可行的。設計階段的重點是開發人員關注邏輯，而不是資料量和頻率等執行時方面。但是，不能完全否定執行時方面，因為技術的選擇決定了處理需求的效率。例如，spark-streaming 和 flink 是流處理的合適選擇，而 spark 和 trino 是批處理的合適選擇。接下來還有更多注意事項，以深入研究適用於用例的正確技術。資料平臺應該提供正確的介面來訪問、轉換和寫入資料，以便未來的升級、程式碼修改、易於維護。這必須伴隨著測試驅動的環境和程式碼的迭代開發。

​

管道部署
為可執行檔案打包和部署程式碼在資料工程方面的討論並不多。多租戶使用、程式碼版本控制、部署期間的治理取決於轉換對資料訪問的敏感性以及可執行檔案的生成，這些都是部署應該解決的問題。降低部署的週轉時間可以減少迭代測試、修改、回填和通常維護資料管道的時間。Janus 為低程式碼配置生成和指令碼部署提供 CI-CD 層。它可以擴充套件到開發人員使用 Janus 載入他們的可執行檔案和編排資料管道。

​

流水線執行
來自可執行檔案的管道的計劃或臨時執行構成管道執行，也稱為“執行時”。
執行時應提供工具，將執行重定向到多個計算引擎，而無需耦合到供應商或雲。因此，重要的是提供介面，將工作重定向到開發人員根據用例請求的計算技術。資料平臺應透過有助於作業最佳化、除錯和治理的配置啟用此重定向。例如，限制叢集使用的佇列規範、有效查詢執行的調整引數、垃圾收集、日誌記錄級別等。Janus 平臺可擴充套件為具有多雲支援的多計算引擎。
從計算引擎訪問資料層決定了領域的靈活性。例如，像 kafka 這樣的訊息佇列的生產者和消費者將有助於為近乎實時的工作流開發流媒體管道。接收器到 redis 或特徵儲存對於 ML 模型起作用的特徵生成用例是必要的。將資料推送到 Druid 和 HBase 將實現低延遲聚合用例。
有關 Myntra 近實時處理的更多資訊，請閱讀QuickSilver。
在資料湖上進行批處理和當日使用的處理將需要連線到 Azure blob 或 S3 上的檔案和表格格式，其中所有資料集都集中儲存。因此，執行時的資料訪問層構成了 Janus 處理平臺的核心部分。

​

操作
運營涉及基礎設施的監控、警報和擴充套件的核心工程卓越功能。對於資料工程，它更進一步。其中包括為複雜的資料管道網路維護資料新鮮度和作業依賴性。資料回填以防資料損壞。定期升級開源版本以提高執行效率。瞭解管道中的最佳化範圍以提高效能，從而降低運營成本。根據目錄上的策略設定在熱資料、冷資料和歸檔資料之間進行分層。PB 級資料湖上的資料分層可顯著節省儲存成本。
由於移動資料的本質，資料工程活動消耗的運營開銷比開發大很多倍，確保了緊延遲的正確性。Janus 將運營視為一流的模組，而不是開發和部署後的卓越工程活動。

接下來
我們已經看到了資料處理平臺及其元件的高階概述。在後續文章中，我們將詳細介紹支援低程式碼和程式碼優先資料管道的平臺設計。一定要關注這個空間，瞭解 Myntra 如何開發下一代可持續資料平臺，以推動其作為印度頂級時尚電子商務的發展。