DBT 繼承了我們?cè)?SQL 上的工作，在數(shù)據(jù)工程師、數(shù)據(jù)分析工程師和任何數(shù)據(jù)角色之間構(gòu)建了一個(gè)優(yōu)雅、通用的、操作友好的環(huán)境。工具和工作流的統(tǒng)一在數(shù)據(jù)組織內(nèi)為不同團(tuán)隊(duì)之間創(chuàng)建了互操作性。

就像在接力賽中一樣，在過程的各個(gè)階段都有明確的交接點(diǎn)和明確的所有權(quán)。但截止目前，還有一個(gè)環(huán)節(jié)仍然痛苦且不確定：機(jī)器學(xué)習(xí)（ML）工程師和數(shù)據(jù)分析工程師之間的銜接。

根據(jù)我的經(jīng)驗(yàn)，ML工程和數(shù)據(jù)分析工程之間的初始協(xié)作工作流程開始時(shí)很強(qiáng)大，但最終在維護(hù)階段變得混亂。這最終導(dǎo)致項(xiàng)目變得無法使用和被遺忘。

在本文中，我們將探討 ML 工程和數(shù)據(jù)分析工程之間的現(xiàn)實(shí)接力棒，并強(qiáng)調(diào)哪里容易出問題。ML工程和數(shù)據(jù)分析工程工作流程中存在所有權(quán)問題。幸運(yùn)的是，現(xiàn)代數(shù)據(jù)堆棧MDS使接力棒傳遞更加順暢。這篇文章將引導(dǎo)您完成最近的一個(gè)項(xiàng)目，在那里我能夠親眼看到這些系統(tǒng)如何協(xié)同工作，以提供為長期準(zhǔn)確性和可維護(hù)性而構(gòu)建的模型。

一、以前的工作銜接是什么樣子的？

作為一名數(shù)據(jù)分析工程師，我與一位 ML 工程師配對(duì)，以分析確定公司客戶流失趨勢(shì)，以及我們可以采取哪些措施來防止這種情況。我們努力尋找一個(gè)解決方案，并向客戶業(yè)務(wù)主管展示，1 個(gè)月后我們滿懷希望完成了方案，但最新的數(shù)據(jù)更改導(dǎo)致模型漂移，因此 ML 工程師找到一些問題供數(shù)據(jù)工程師/數(shù)據(jù)分析工程師修復(fù)...循環(huán)往復(fù)，3個(gè)月后，沒有人記得我們這樣做了。這聽起來熟悉嗎？

發(fā)生這種情況是因?yàn)椤罢！钡淖鍪路绞饺狈﹂L期和明確的所有權(quán)。但是這些故障是如何發(fā)生的呢？

事情是這樣的

經(jīng)過一些初步規(guī)劃，我知道我們將這些原始數(shù)據(jù)存在于數(shù)據(jù)倉庫，我們共同努力的這個(gè)起點(diǎn)很容易理解。我編寫了 dbt 轉(zhuǎn)換來調(diào)整這些原始數(shù)據(jù)并加入了幾個(gè)表一起基于對(duì)重要變量的直覺：每日活躍使用情況、用戶數(shù)量、支付金額、歷史使用情況等。

ML工程師從這里介入。她習(xí)慣于在Python、 pandas和scikit-learn中進(jìn)行統(tǒng)計(jì)和預(yù)處理。在她打開她的Jupyter Notebook之前，我們進(jìn)行了一次對(duì)話，意識(shí)到可以通過dbt完成相同的工作。預(yù)處理可以通過這個(gè)開源dbt包dbt-ml-preprocessing來完成。

ML 工程師完成了預(yù)處理步驟（想想：one-hot encoding, feature scaling, imputation）。她使用 SQL 將 dbt 模型（表）讀入 Jupyter Notebook以執(zhí)行模型訓(xùn)練。在迭代機(jī)器學(xué)習(xí)模型和跟蹤模型擬合（想想：AUC/Precision/Recall (用于分類)）之后，她在 dbt 創(chuàng)建的表上運(yùn)行模型，并將預(yù)測結(jié)果作為數(shù)據(jù)庫中的表輸出。為了保持文檔整潔，她在 dbt 項(xiàng)目中配置了一個(gè)源來反映此預(yù)測結(jié)果表。它并不直觀，但比將其排除在 dbt 文檔之外要好。

最后，她在此表的頂部創(chuàng)建了一個(gè)儀表板，以向最終用戶宣傳模型隨時(shí)間推移的準(zhǔn)確性。為了安排這個(gè)，我們?nèi)フ覕?shù)據(jù)工程師，每天早上8點(diǎn)在Airflow中將上述內(nèi)容串在一起，并完成。

過程哪里出了問題

讓我們分析一下我們?cè)诠适轮锌吹降拇瓿傻墓ぷ鳌?/p>

要完成的工作預(yù)期成果角色提取原始數(shù)據(jù)并將其加載到數(shù)據(jù)庫中SQL 就緒數(shù)據(jù)數(shù)據(jù)工程師轉(zhuǎn)換數(shù)據(jù)以供業(yè)務(wù)用戶使用數(shù)據(jù)是連貫的，可以從中做出決策分析工程師、機(jī)器學(xué)習(xí)工程師使用結(jié)構(gòu)化的表格數(shù)據(jù)統(tǒng)一實(shí)用的工作流程分析工程師、機(jī)器學(xué)習(xí)工程師在 SQL 中工作統(tǒng)一實(shí)用的工作流程分析工程師、機(jī)器學(xué)習(xí)工程師為用戶提供文檔，以了解數(shù)據(jù)輸出是如何創(chuàng)建的以及如何使用它們數(shù)據(jù)的信任和上下文分析工程師、機(jī)器學(xué)習(xí)工程師測試轉(zhuǎn)換后的數(shù)據(jù)輸出可信數(shù)據(jù)分析工程師測試預(yù)處理數(shù)據(jù)輸出可信數(shù)據(jù)機(jī)器學(xué)習(xí)工程師訓(xùn)練和部署機(jī)器學(xué)習(xí)模型（主要使用 python）做出預(yù)測性決策機(jī)器學(xué)習(xí)工程師隨時(shí)間推移測試和維護(hù)機(jī)器學(xué)習(xí)表輸出證明預(yù)測結(jié)果與現(xiàn)實(shí)相符，即使數(shù)據(jù)輸入隨時(shí)間變化數(shù)據(jù)工程師、分析工程師、機(jī)器學(xué)習(xí)工程師???

接力棒隨著時(shí)間的推移而發(fā)展，需求分析和敘事是數(shù)據(jù)分析工程師和ML工程師引以為豪的容易達(dá)成共識(shí)的事情，但機(jī)器學(xué)習(xí)輸出工作流的維護(hù)和驗(yàn)證是我們并不引以為豪的事情。發(fā)生這種情況是因?yàn)槲覀冨e(cuò)過了一些關(guān)鍵的東西：從長遠(yuǎn)來看，我們沒有統(tǒng)一誰應(yīng)該做什么（想想：源數(shù)據(jù)變化通過轉(zhuǎn)換>預(yù)處理>訓(xùn)練步驟級(jí)聯(lián)>監(jiān)控性能。難怪最終用戶在 1 個(gè)月后對(duì)我們的結(jié)果聳了聳肩。

讓我們把這個(gè)簡單化：

• “當(dāng)數(shù)據(jù)發(fā)生變化時(shí)，誰使數(shù)據(jù)和機(jī)器學(xué)習(xí)管道隨著時(shí)間的推移可維護(hù)？”

如果我們把這個(gè)問題做好了，機(jī)器學(xué)習(xí)投入適用將變得更容易。

二、技術(shù)發(fā)展如何彌合數(shù)據(jù)分析工程和機(jī)器學(xué)習(xí)之間的差距？

讓我們進(jìn)一步關(guān)注這個(gè)問題：對(duì)于工作流程中的“隨時(shí)間推移的維護(hù)”問題，

ML 模型漂移是由數(shù)據(jù)質(zhì)量還是模型邏輯引起的?

將機(jī)器學(xué)習(xí)引入 SQL 工作流

如果。。。SQL可以做的比我們認(rèn)為的更多，甚至應(yīng)該做的更多？

• http://mindsdb.com：MindsDB是使用SQL語法創(chuàng)建預(yù)測模型的基于數(shù)據(jù)庫之上的開源產(chǎn)品，機(jī)器學(xué)習(xí)計(jì)算發(fā)生在MindsDB層。

• Continual.ai：直接創(chuàng)建 dbt 模型來預(yù)測結(jié)果。根據(jù)您的 dbt 模型配置評(píng)估要使用的 ML 模型，機(jī)器學(xué)習(xí)計(jì)算發(fā)生在這一層和數(shù)據(jù)倉庫中。

• fal.ai：fal使 dbt 和 python 可互操作。

這將如何改變我的故事？

數(shù)據(jù)分析工程師和ML工程師會(huì)在SQL上更加團(tuán)結(jié)。無論長管道在何處破裂（ELT-ML），SQL將是我們一起找出問題的切入點(diǎn)。對(duì)于簡單的機(jī)器學(xué)習(xí)問題（例如，線性回歸，分類），在ML工程師的建議和審查下，數(shù)據(jù)分析工程師會(huì)更容易理解甚至擁有完整的管道。

除了在出現(xiàn)問題后解決問題之外，此工作流還將避免構(gòu)建 ML 運(yùn)維工作所涉及的大部分復(fù)雜性：大量額外的基礎(chǔ)設(shè)施（想想： python 代碼在哪里運(yùn)行？）作為一名 ML 工程師，我希望生活在一個(gè)可以從一個(gè)控制平面管理探索、訓(xùn)練、版本控制和推理的世界里。在數(shù)倉內(nèi)進(jìn)行機(jī)器學(xué)習(xí)有可能使之成為現(xiàn)實(shí)。

數(shù)據(jù)分析工程師和ML工程師將在整個(gè)工作流程的同一個(gè)dbt項(xiàng)目中工作，而不僅僅是其中的一部分。我們會(huì)將 python 腳本與 dbt 配置對(duì)齊，以獲得更好的譜系。

當(dāng)事情出錯(cuò)時(shí)，弄清楚SQL更改如何通知python更改，反之亦然。不需要關(guān)心python代碼在哪個(gè)基礎(chǔ)設(shè)施上運(yùn)行。將機(jī)器學(xué)習(xí)邏輯與 dbt 邏輯保持一致會(huì)更容易。