OpenMLDB Meetup No.7 回顧 | OpenMLDB＋AutoX：整合自動特征工程，擁抱高效機器學習

OpenMLDB Meetup No.7 回顧

會議内容

OpenMLDB 社群于 2022年10月29日舉行了第七期 meetup，會議相關視訊及資料如下：

OpenMLDB PMC core member 盧冕，以《開源機器學習資料庫 OpenMLDB：線上線下一緻的生産級特征平台》為題，為大家重點介紹了 OpenMLDB 社群 10月的工作進展。

• 視訊連結: https://www.zhihu.com/zvideo/1570865332234706945
• 連結：https://pan.baidu.com/s/1whJ7SR7YGw0E-2HH52wnjA
• 提取碼：open

第四範式進階科學家 蔡恒興，給大家介紹了表資料場景下自動機器學習的相關核心技術以及相應的開源産品 AutoX，讓希望能夠低門檻使用人工智能技術的朋友看到可以期待的未來。

• 視訊連結：https://www.zhihu.com/zvideo/1570865733248196608
• 連結：https://pan.baidu.com/s/1LHndaYCH-GbKXc87jo93Uw
• 提取碼：open

來自伊利諾伊大學的 OpenMLDB 社群貢獻者 徐鵬程，圍繞"OpenMLDB 整合自動特征工程" 課題，為觀衆講解 AutoFE 的流程原理，展示 AutoX 特征工程在 OpenMLDB 中的作用，并帶來精彩的現場示範。

• 視訊連結：https://www.zhihu.com/zvideo/1570865680102121472
• 連結：https://pan.baidu.com/s/1zIo_swMA3RH4caek2f9oHg
• 提取碼：open

讨論交流——OpenMLDB

Q1: 假如應用場景下走 spark 難度較大，是否可以繞過 spark 做批處理？這樣的使用場景吞吐量如何？

A1: OpenMLDB 0.6.4 版本正好做了最新的優化更新，可以滿足“不使用 spark 跑批”的需求。現在的 OpenMLDB 支援線上 batch 模式，使用者可以把 spark 完全丢掉，用線上引擎跑批。不過這樣操作需要注意控制資料量，因為我們的線上 batch 模式預設使用記憶體，資源消耗較多，可擴充性比起 spark 依然存在差距。如果隻做自學習、做批量跑批，完全可以承擔。

Q2: 模型要上線的話，固化模型支援哪些格式？

A2: OpenMLDB 專注特征部分，本身不處理模型。我們會把處理特征生産的大寬表直接喂給下遊的模型。模型一般使用大家比較熟悉的第三方開源軟體，如 LightBGM、XGBoost 等。是以模型格式取決于後續對接的架構，而不再 OpenMLDB 的考慮範圍。

Q3: 如何部署 OpenMLDB 可以支援資源動态擴容，保證服務的高可用？OpenMLDB 能否和 K8S 結合呢，這些内容有沒有相關的操作介紹呀？

A3: OpenMLDB 本身支援動态擴容，可以随意增加實體機，通過擴容操作做水準擴容。

OpenMLDB 是一個分布式系統，在多數條件下都支援高可用。在 OpenMLDB 線上子產品架構的文章介紹中有如何保證高可用的相關原理介紹。

關于 OpenMLDB 和 K8S 的結合，目前 OpenMLDB 離線引擎已經适配成功，但線上引擎還未做适配整合，後續會考慮。

如果使用者有生産上線的需求，為了服務的穩定性，我們還是建議部署在實體機上。

關于動态擴容可以檢視 ：

http://openmldb.ai/docs/zh/main/maintain/scale.html

線上子產品架構參考：

http://openmldb.ai/docs/zh/main/reference/arch/online_arch.html

Q4: 部署OpenMLDB需要的硬體資源（如CPU、記憶體）有沒有相關的參考呢？

A4: 可以參考這篇文章：OpenMLDB 線上引擎資源需求預估模型，助你快速預估資源消耗

Q5: autox.fit_transform() 做的特征工程，如何與 OpenMLDB 結合保證線上線下特征的一緻性？

A5: OpenMLDB 和 AutoX 的整合更多是借鑒了 AutoX 算法，在 OpenMLDB 外部設定了一個自動生成 SQL 的 AutoFE 子產品。可以了解為，隻要把 AutoX 生成的 SQL 給到 OpenMLDB，後續的所有操作流程和原本保持一緻即可。隻是 SQL 的開發者由資料科學家變成了 AutoFE 子產品，而後續的線上線下一緻性通過 OpenMLDB 來保證。

讨論交流——AutoX

Q1: AutoX 自動特征工程是不是暴力窮舉嘗試實作的？特征的可解釋性如何、以及資源消耗、性能方面是怎樣的？

A1: AutoX 不是暴力窮舉實作的，而會根據具體情況降低複雜度，确定搜尋空間。我們實作的思路是：先提取資料元特征，再基于不同場景選擇判斷，利用經驗配置，在一定範圍内搜尋。

目前特征的可解釋性做的并不多，我們的可解釋性工作更側重模組化後的效果影響因素分析。

AutoX 使用時，常用單機或者單台伺服器去跑代碼。這裡可以舉例解釋消耗和性能：千萬級的資料、幾百列代碼去跑 AutoX，在 GPU 32 核，記憶體256 G 的設定下需要 12 個小時。和 OpenMLDB 合作後，性能和資源消耗方面會有進一步的優化。

Q2: 現在有很多端到端的深度學習模型也包含了特征工程的工作，AutoX 相比深度學習模型的特征 Encoder 有什麼差別和優勢呢？

A2: 兩者難做直接的比較。AutoX 中也內建了一些用深度學習 Encoder 模型來提取的特征。AutoX 是開放的，更專注于最後呈現的效果，不局限于某種特征構造方式。

Q3: 基于元特征定義産出的自動特征，其實本質上還是一種曆史經驗特征的遷移，這裡的自動其實展現的是 zero-code？

A3: 使用者不需要定義元特征，AutoX會根據已有的内部邏輯自動提取，并且比對模型。使用者隻需要定義基礎的資料路徑、标簽等。

Q4: AutoX 目前是支援分布式麼？

A4: 本身不支援。如果 AutoX 調用了 XGBoost、X-Boost，可以通過第三方工具實作分布式。

Q5: 想問線上效果的好壞能不能找到是由哪個特征導緻的？以便後續優化。

A5: 可以實作，AutoX-interpreter 的項目包含這種功能。我們內建了很多算法，你能通過它們找到具體會有哪些關鍵因素導緻模型效果不好，包括基于模型的可解釋、影響力樣本擷取等功能。

Q6: AutoX 依賴的庫數量較多，如 TF，torch 等。當 AutoX 不使用這些庫的時候，能不能先避免 import 操作？簡單說就是，不用 TF 的時候，AutoX 能否不 import？因為有些使用者不一定安裝了 TF，torch 這種深度學習架構。

A6: 謝謝這位同學的建議，我們之前也有發現這個問題，并且計劃在近期做優化。可以用 lazy import 解決。

Q7: 可以隻用 AutoX 的調參能力嗎？AutoX 對接分布式 hadoop 叢集，讀取 HDFS 或 hive 資料可以實作嗎？

A7: 可以單獨調用。結合 OpenMLDB 之後，對接 hadoop 叢集，讀取 HFDS 或hive 資料都可以實作。

AutoX 社群

想進一步了解 AutoX 社群或者與核心開發者做進一步的交流讨論，可以通過 Github 擷取更多聯系管道。

Github: https://github.com/4paradigm/AutoX

OpenMLDB 社群

在此感謝大家對于本次 meetup 的大力支援，如果想進一步了解 OpenMLDB 或者參與社群技術交流，可以通過以下管道獲得相關資訊和互動。

Github: https://github.com/4paradigm/OpenMLDB

Email: [email protected]

OpenMLDB 微信交流群：