Feature Store將成為機器學習與資料工程的基礎架構 - KDnuggets

Provectus的團隊  已建立了多個功能庫，我們希望分享我們的經驗和教訓。在本文中，我們將探討功能儲存區如何幫助消除返工並增強團隊之間從源到模型的資料可追溯性。我們將研究構建可擴充套件功能儲存的細節，並討論如何實現實時功能與訓練功能之間的一致性，以及如何提高資料隨時間傳播的可重複性。
 

什麼是Feature Store（功能儲存）
功能儲存是用於機器學習功能的資料管理層。機器學習功能是觀察中的現象的可測量屬性，例如原始單詞，畫素，感測器值，資料儲存中的資料行，CSV檔案中的欄位，聚合（最小，最大，總和，均值）或派生表示（嵌入或簇）。
從業務角度來看，Feature Store具有兩個主要優點：

1. 透過降低每個模型的成本，從要素工程中獲得更好的投資回報，從而促進要素的 協作，共享和重用
2. ML工程師提高了生產率，從而加快了新模型的上市時間。這使組織能夠將ML工程師的儲存實現和服務API的功能分離開來，使他們可以在模型上工作，而不是在延遲問題上工作，以實現更有效的線上服務。

Feature Store概念
標準化功能儲存具有圍繞它的某些關鍵概念。這些概念是：

1. 線上功能儲存。線上應用程式尋找特徵向量，該特徵向量被髮送到ML模型進行預測。
2. ML特定後設資料。啟用發現和重複使用功能。
3. ML特定的API和SDK。用於獲取培訓功能集和線上訪問的高階操作。
4. 物化版本化資料集。維護用於訓練ML模型的功能集的版本。

上圖中顯示了所有概念。分析資料是從資料湖中獲取的，並透過功能要素工程管道傳輸，輸出儲存在功能要素儲存中。從那裡，ML工程師可以發現功能，將其用於訓練新模型，然後重新使用這些功能進行服務。
這四個概念得到多種產品的支援。市場的領導者是Feast，Tecton，Hopsworks和 AWS SageMaker Feature Store。
 

現代資料平臺的挑戰
在研究構建功能儲存的細節之前，必須考慮現代資料平臺的挑戰。無法將要素儲存與其餘資料和ML基礎結構隔離地進行檢查 。
傳統上，規範的資料湖架構如下所示：

圖片由作者提供。
這種高階體系結構具有用於採購，提取，處理，持久化，查詢和使用者元件的元件。儘管它對於大多數任務都可以正常工作，但並不理想。

• 資料訪問和可發現性 可能是一個問題。資料分散在多個資料來源和服務中。這曾經幫助保護資料，但現在只增加了一層新的複雜性並建立了資料孤島。這種架構需要繁瑣的過程來管理AWS IAM角色，Amazon S3策略，API閘道器和資料庫許可權。在多帳戶設定中，這甚至變得更加複雜。結果，由於預設情況下無法發現後設資料，工程師對存在哪些資料以及實際上可以訪問哪些資料感到困惑。這將建立一個環境，其中由於資料訪問問題而減少了對資料和機器學習的投資。
• 整體資料團隊 是另一個要考慮的問題。由於資料和機器學習團隊非常專業，因此它們通常必須在上下文之外進行操作。所有權和域上下文的缺乏在資料生產者和資料消費者之間造成了孤島，使積壓的資料團隊很難滿足業務需求。資料和ML Engineering成為複雜依賴關係的受害者，無法同步其操作。在這種情況下，不可能進行任何快速的端到端實驗。
• 機器學習實驗基礎設施 是未知領域。傳統架構缺少實驗元件，這不僅導致資料發現和資料訪問問題，而且使維護資料集，ML管道，ML環境和離線實驗的可重複性變得更加複雜。儘管Amazon SageMaker和Kubeflow在這裡取得了一些進展，但可重複性還是有問題的。生產實驗框架尚不成熟，不能完全依賴。結果，可能需要三到六個月的時間才能將一個端到端實驗從資料推向生產ML。
• 在生產中擴充套件ML 很複雜，需要大量時間和精力。儘管機器學習主要被視為離線活動（例如，資料收集，處理，模型訓練，評估結果等），但實際使用模型和線上服務模型的方式才是真正重要的。使用傳統架構，您無法在模型服務期間以統一且一致的方式訪問功能。您也不能在多個培訓管道和ML應用程式之間重用功能。ML應用程式的監視和維護也更加複雜。結果，在生產中從1個模型擴充套件到100個模型所需的時間和成本成倍增長，這限制了組織以所需的步伐進行創新的能力。

1. 從Data Lake到Hudi / Delta湖泊。資料湖不僅僅是Amazon S3中的資料夾。它是功能豐富的，完全託管的層，用於資料攝取，增量處理以及與ACID事務和時間點查詢一起使用。
2. 從資料湖到資料網格。資料域，資料管道，後設資料和API的所有權正在從集中式團隊轉移到產品團隊。另一個有效的好處是將資料視為一個完整的產品並擁有，而不是沒有人關心的副作用。
3. 從資料湖到資料基礎設施平臺。如果資料所有權分散，則平臺元件必須統一併打包到可重用的資料平臺中。
4. 從端點保護到全球資料治理。作為向集中式資料平臺轉變的一部分，組織正在從Endpoint Protection遷移到Global Data Governance，這是用於跨可用資料來源管理安全性和資料訪問策略的高階控制計劃。
5. 從後設資料儲存到全域性資料目錄。像Hive元儲存這樣的後設資料儲存不能聚合許多資料來源。業界需要一個全球資料目錄來支援有關資料發現，沿襲和版本控制的使用者體驗。
6. 功能儲存。功能儲存是ML堆疊中新出現的元件，它透過為ML功能新增單獨的資料管理層來實現ML實驗和操作的擴充套件。

現代資料基礎架構
現在讓我們看一下現代資料基礎架構。

圖片由作者提供。
我們對原始資料進行批處理，對事件資料進行流處理。我們將處理過的工件儲存在用於業務報告的冷儲存中，並在API中以近實時，增量更新的熱索引儲存。在兩種情況下都可以使用相同的資料，為了使資料一致，我們使用不同的釋出/子系統。
這是資料平臺的傳統架構。它的目標是提供冷儲存和熱儲存之間的一致性，並允許透過其上的細粒度控制從資料目錄，資料質量和全域性安全性中發現資料。

如果我們看一下功能儲存設計，我們將看到功能和基礎架構元件幾乎與資料平臺中的功能和基礎元件相同。在這種情況下，要素儲存不是一個單獨的筒倉，它帶來了另一個攝取系統，儲存，目錄和質量門。它充當我們資料平臺和ML工具之間的輕量級API。它可以很好地與您的資料基礎架構中已經完成的一切整合在一起。它應該是可組合的，輕巧的，並且沒有過分的設計。

在開始設計和構建資料基礎結構時，請考慮以下“經驗教訓”：

1. 首先設計一個一致的ACID Data Lake，然後再投資Feature Store。
2. 現有開源產品的價值不能證明對整合及其帶來的依賴性進行投資的合理性。
3. 功能儲存不是新的基礎結構和資料儲存解決方案，而是整合到現有資料基礎結構中的輕量級API和SDK。
4. 資料目錄，資料治理和資料質量元件對於包括功能儲存在內的整個資料基礎架構都是水平的。
5. 對於全球資料目錄和資料質量監控，還沒有成熟的開源或雲解決方案。

該圖表描述了我們一直為客戶使用的參考體系結構。它具有我們選擇使用的服務，但您不應受到我們選擇的限制。這裡的想法是，您必須 根據資料工作負載和業務需求選擇冷 儲存和熱儲存。
對於熱儲存，您可以選擇DynamoDB，Cassandra，Hbase或傳統的RDBMS，例如Mysql，PostgreSQL甚至Redis。重要的是，熱儲存應可組合，可插入並與資料基礎結構策略保持一致
對於冷藏，Apache Hudi和Delta湖是我們的最愛。它們提供諸如“時間旅行”，“增量攝取”和“物化檢視”之類的功能。
圖上有一些空白，我們希望儘快填充。例如，到目前為止，資料目錄還沒有現成的領導者。資料質量工具也處於早期階段。目前，您可以從“ Great Expectations”或“ Apache Deequ”中選擇，這是很棒的工具，但是它們並不能提供完整的解決方案。

詳細點選標題見原文