近日,螞蟻金服副 CTO 胡喜正式宣佈開源機器學習工具 SQLFlow,他在大會演講中表示:「將來三年,AI 能力會成爲每一位技術人員的基本能力。咱們但願經過開源 SQLFlow,下降人工智能應用的技術門檻,讓技術人員調用 AI 像 SQL 同樣簡單。」 SQLFlow 可以抽象出端到端從數據到模型的研發過程,配合底層的引擎及自動優化,具有基礎 SQL 知識的技術人員便可完成大部分的機器學習模型訓練及預測任務。程序員
SQLFlow 由何而來?螞蟻金服對於 SQLFlow 將來還有哪些規劃?一塊兒來深刻了解。算法
SQLFlow 的目標是將 SQL 引擎和 AI 引擎鏈接起來,讓用戶僅需幾行 SQL 代碼就能描述整個應用或者產品背後的數據流和 AI 構造。其中所涉及的 SQL 引擎包括 MySQL、Oracle、Hive、SparkSQL、Flink 等支持用 SQL 或其某個變種語言描述數據,以及描述對數據的操做的系統。而這裏所指的 AI 引擎包括 TensorFlow、PyTorch 等深度學習系統,也包括 XGBoost、LibLinear、LibSVM 等傳統機器學習系統。數據庫
SQLFlow 研發團隊認爲,在 SQLFlow 和 AI 引擎之間存在一個很大的空隙——如何把數據變成 AI 模型須要的輸入。谷歌開源的 TensorFlow 項目開了一個好頭,TFX Data Transform 和 feature column API 都是意圖填補這個空缺的項目。可是這個空缺很大,是各類 SQL 引擎和各類 AI 引擎的笛卡爾積,遠不是 TensorFlow 的這兩個子項目就足以填補的,須要一個開源社區才行。要填補好這個空缺,須要先讓用戶意識到其重要性,這也是螞蟻金服開源 SQLFlow 的意圖之一。編程
SQLFlow 位於 AI 軟件系統生態的最頂端,最接近用戶,它也位於數據和數據流軟件生態之上。json
其實,將 SQL 和 AI 鏈接起來這個想法並不是 SQLFlow 原創。谷歌於 2018 年年中發佈的 BigQueryML 一樣旨在「讓數據科學家和分析師只用 SQL 語言就能夠實現流行的機器學習功能並執行預測分析」。除了 Google 的 BigQueryML,微軟基於 SQL Server 的 AI 擴展,以及 Teradata 的 SQL for DL 一樣旨在鏈接 SQL 和 AI,讓人工智能的應用變得像 SQL 同樣簡單。而 SQLFlow 與上述各個系統最根本的差別在於:SQLFlow 是開源的,以上系統都不是。架構
螞蟻金服和不少互聯網公司同樣,不一樣產品背後有不少功能都依賴於 AI,好比用戶信用的評估就是一套預測模型。到目前爲止,每個這樣的功能的實現,都依賴一個工程師團隊開發多個子系統——讀取數據庫或者在線日誌流、這兩類數據的 join、各類數據篩選、數據到模型輸入(常說的 features)的映射、訓練模型、用訓練好的模型來作預測。整個過程下來耗時每每以月計,若是加班加點放棄寫 unit test 代碼,可能縮短到以週記。併發
以上問題正是 SQLFlow 系統但願替工程師們解決的問題。螞蟻金服擁有數千數據分析師,他們平常工做用的就是 SQL 語言。雖然數據分析師在互聯網行業每每不像用 Python、Java、C++ 的工程師那樣醒目,可是在不少有面向商業夥伴的業務的公司裏,好比 LinkedIn,他們的貢獻和人數都能與工程師相匹敵。SQLFlow 最先的初衷,就是但願解決分析師既要操做數據又要使用 AI、每每須要在兩個甚至更多的系統之間切換、工做效率低的窘境。機器學習
SQLFlow 旨在大幅提高效率,讓上述功能實現所花費的時間進一步縮短到能以日計,甚至以小時計的程度。編程語言
要達到這樣的效率,必須有一種效率極高的描述工做意圖的方式。SQL 是一種典型的描述意圖,而不描述過程的編程語言。用戶能夠說我要 join 兩個表,可是不須要寫循環和構造 hash map 來描述如何 join 兩個表。這個特性使得 SQL 能極大地提高開發效率,這正是 SQLFlow 選擇擴展 SQL 語法支持 AI 這條思路的緣由。分佈式
不過,高效率的背後是更大的工程技術挑戰。SQLFlow 須要作到能根據用戶的意圖,自動生成達到意圖的 Python、C++、Go 語言的程序。
設計目標
在鏈接 SQL 和 AI 應用這一方向上,業內已有相關工做。開發者可使用像 DOT_PRODUCT 這樣的運算符在 SQL 中編寫簡單的機器學習預測(或評分)算法。可是,從訓練程序到 SQL 語句須要進行大量的模型參數複製粘貼的工做。目前在一些商業軟件中,已經有部分專有 SQL 引擎提供了支持機器學習功能的擴展。
但上述已有的解決方案都沒法解決螞蟻金服團隊的痛點,他們的目標是打造一個徹底可擴展的解決方案。
應對上述挑戰的關鍵在於打造一套 SQL 擴展語法。研發團隊首先從僅支持 MySQL 和 TensorFlow 的原型開發開始,後續計劃支持更多 SQL 引擎和機器學習工具包。
從 SQL 到機器學習
SQLFlow 能夠看做一個翻譯器,它把擴展語法的 SQL 程序翻譯成一個被稱爲 submitter 的程序,而後執行。 SQLFlow 提供一個抽象層,把各類 SQL 引擎抽象成同樣的。SQLFlow 還提供一個可擴展的機制,使得你們能夠插入各類翻譯機制,獲得基於不一樣 AI 引擎的 submitter 程序。
SQLFlow 對 SQL 語法的擴展意圖很簡單:在 SELECT 語句後面,加上一個擴展語法的 TRAIN 從句,便可實現 AI 模型的訓練。或者加上一個 PREDICT 從句便可實現用現有模型作預測。這樣的設計大大簡化了數據分析師的學習路徑。
此外,SQLFlow 也提供一些基本功能,能夠供各類 submitter 翻譯插件使用,用來根據數據的特色,推導如何自動地把數據轉換成 features。這樣用戶就不須要在 TRAIN 從句裏描述這個轉換。
以上這些設計意圖在 SQLFlow 的開源代碼中都有體現。固然,SQLFlow 開發時間還比較短,仍然存在不少作的不夠細緻的地方。螞蟻金服將其開源的另外一個目的,就是但願可以和各個 SQL 引擎團隊和各個 AI 團隊一塊兒打造這座橫跨數據和 AI 的橋樑。
基於 Go 語言開發
SQLFlow 基於 Go 語言開發,Go 語言的衆多優勢使其成爲了 SQLFlow 研發團隊的首選。除了 Go 社區討論較多的優點之外,如下兩點被重點說起:
首先 Go 容易學習卻擁有極高的開發效率。它的 keyword 數量比 C 語言還要少,可是描述能力(平均每一行代碼能表示的意圖)接近 Python。
另外一個緣由是 Go 的代碼庫易於長期維護。一項工做用 Python 或者 C++ 來寫,會有不少種寫法,都能跑。用 Go 來寫,每每只有一種寫法。這就使得 Go 程序員社區裏不會有不少風格共存,也就不須要 Google C++ style 這樣的代碼規範來限制不準用 C++ 的哪些特性,也不會像 Python 代碼開發時那樣,各類代碼風格之間造成鄙視鏈,在 code review 過程裏帶來沒必要要的爭執。
與阿里 PAI 的關係
SQLFlow 研發團隊認爲,AI 和機器學習的生態能夠分爲不少層。其中 TensorFlow、PyTorch、XGBoost、LibLinear 這些系統位於最底層,距離終端用戶最遠,只有很硬核的用戶才能熟練掌握和使用,而這部分用戶在互聯網從業者裏佔的比例較小。
SQLFlow 和阿里推出的機器學習平臺 PAI 均位於生態的最頂層,須要調用下層的技術棧,兩者均直接面對最終用戶,而這些用戶中可能有大量並不具有 AI 背景知識。
PAI 系統經過先進的圖形用戶界面來解決 AI 難理解、難應用的挑戰——好比託拽基礎 AI 組件來構造複雜的模型和數據流。
SQLFlow 則經過寫 SQL 程序的方式來實現這一目標。有能寫下來的程序,就容易存檔,容易 Code Review,容易分享知識,容易集思廣益,容易高效率迭代。此外,敲鍵盤寫程序比動鼠標拖拽快。
SQLFlow 目前依賴 TensorFlow 等底層引擎來實現訓練和預測。爲了提高 SQLFlow 在機器學習模型的訓練和預測性能,螞蟻金服有一個團隊專門作硬件加速 AI 計算的工做,最近已經有了一些使人驚喜的成績,但願在不久的未來能夠和你們分享細節。另外還有一個兄弟項目專門維護螞蟻金服對 TensorFlow 的功能擴展,也和性能相關。
SQLFlow 項目負責人表示,訓練和預測只是整個 AI 產品功能長長的鏈條中的兩個環節。SQLFlow 這個項目是爲解決整個鏈條構建而打造的,其中有不少環節的耗時比 AI 的訓練和預測多得多,所以還有極大的性能提高的空間。好比不少 SQL 引擎並不支持讓一個分佈式 AI 程序併發讀取其中的數據,若是 SQLFlow 可以解決相似的吞吐量限制,AI 的整體效率能提升數倍甚至數十倍。
在對機器學習算法的支持方面,SQLFlow 設計的初衷就是要複用各個 AI 引擎各自的模型庫。目前 SQLFlow 支持 TensorFlow Estimator 規範的模型。好比 SQLFlow 擴展語法中 SELECT ... TRAIN DNNClassifier ... 這個寫法,DNNClassifier 就是一個 Python class 的名,在這個例子中是一個派生自 tf.Estimator 的 class。SQLFlow 研發團隊也正在作支持 Keras 模型的相關工做,團隊也在考慮規範 XGBoost 模型的程序寫做,使其能夠被 SQLFlow 用戶方便地調用。
這些工做背後的思路是但願互聯網行業常見的三類技術角色:分析師、研究員、工程師的分工更清晰,從而能更專一發揮各自特長:分析師由於瞭解數據因此寫 SQL,調用 DNNClassifier 這樣由研究員用 Python 寫的模型;研究員不用操心分佈式計算和模型究竟是如何被分佈式訓練(或預測)的,這部分工做留給工程師。與此同時,SQLFlow 做爲一種粘合劑,把這三類角色的產出有機結合,以便更加高效地構造產品。
SQLFlow 當前已經可以帶來研發效率的提高,但尚不完美,目前 SQLFlow 還存在如下問題有待解決:
第一個問題是 parsing。SQLFlow 目前已經對接 MySQL,正在對接 Hive 和 阿里雲上的 MaxCompute,未來還但願能對接更多公司正在使用的 SQL 引擎。這些引擎的 SQL 語法大都符合 SQL 標準,可是總有一些本身獨特的擴展,而用戶每每不知不覺地用到了這些特色。SQLFlow 但願用戶能在已有的 SELECT 語句以後,經過簡單地添加一個 TRAIN 或者 PREDICT 從句,便可實現數據和 AI 的互聯,這就要求 SQLFlow 支持各個 SQL 引擎獨到的語法特色。
第二個問題是數據到 feature 的映射的自動化。目前 SQLFlow 是根據 SQL 字段的類型(INT、FLOAT、TEXT、BLOB)來自動化映射到 feature column API,好比 numeric_column 或者 categorical_column_with_vocabulary 或者 bucketized_column。其實不少 TEXT 字段裏存儲的信息很複雜,多是一個 yaml 或者 json,因此須要掃描(至少一部分)數據,才能精準地判斷這個映射。相似的,一個 BLOB 字段裏多是 protobuf message 的 encoding,encode 的是一個 TensorFlow 的 tensor。
第三個問題是 AI 引擎。 TensorFlow、PyTorch、XGBoost、LibLinear 這些 AI 引擎的分佈式計算能力都有一些問題。TensorFlow 原生支持分佈式訓練,但不支持容錯,一個進程掛了,整個做業就掛了。雖然這還能夠經過 checkpointing 解決,可是不容錯就不能彈性調度,不能彈性調度就意味着集羣利用率可能極差。好比一個有 N 個 GPU 的集羣上在運行一個做業,使用了一個 GPU;此時一個新提交的做業要求使用 N 個 GPU,由於空閒 GPU 個數是 N-1,因此這個新的做業不能開始執行,而是得一直等數小時甚至數天,直到前一個做業結束、釋放那個被佔用的 GPU。這麼長時間裏,集羣利用率< 1/N。關於這個問題的解決方案,百度 PaddleEDL和阿里集團的 XDL作了一些頗有益的探索。但願業界把過度集中於 AI 運行時間優化的眼光,分一部分到減小等待時間上。
接下來螞蟻金服將致力於推進 SQLFlow 在螞蟻金服業務和螞蟻金服之外的公司的使用,讓 SQLFlow 項目成爲整個社區的共同工做,從中收穫更多的反饋,引導項目的發展方向,也幫助明確各項工做的優先級。
令 SQLFlow 團隊感到欣喜的是,雖然 SQLFlow 剛開源,但目前已經有來自美國和中國幾大互聯網公司的貢獻者參與到社區工做中來。因爲每一個公司使用的 SQL 引擎不一樣,若是 SQLFlow 核心團隊能提供比較好的數據層抽象,那麼來自不一樣公司的貢獻者就能比較容易地把 SQLFlow 適配到本身公司的引擎上。相似的,支持多種 AI 引擎的方式也是如此。
此外,SQLFlow 團隊但願各個公司的研究員們可以參與到開源項目中來,分享各自的模型,將來 SQLFlow 會支持各類形式的模型,以便分析師使用。
過去這幾年,螞蟻金服一直積極參與開源社區共建,自2011年宣佈第一波開源項目以來,開源項目數量每一年皆有增加。目前螞蟻金服已有 30 多個開源項目,其中,Ant Design項目已獲三萬多Star,有600 多人蔘與項目建設,EggJS和SOFA 系列也成爲了社區熱門。
在 SQLFlow 的 GitHub 項目中,螞蟻金服提供了 SQLFlow 的安裝指引以及快速入門的示例,對此項目感興趣的開發者不妨一試。
原文連接 本文爲雲棲社區原創內容,未經容許不得轉載。