在 Dataiku DSS 里做數(shù)據(jù)處理可視化 Recipes 是我們每天都要打交道的東西。不管是 Prepare、Group、Join 還是 Window Recipe大家打開界面后往往會發(fā)現(xiàn)雖然每個 Recipe 的核心邏輯不一樣但左側(cè)或右側(cè)的面板里總有那么幾個步驟長得差不多——其中出鏡率最高的就是 Pre-filter預(yù)過濾、Post-filter后過濾和 Computed columns計算列。很多人在這三個地方吃過虧。有人把過濾條件寫在了 Pre-filter 里結(jié)果后面算出來的新列根本沒法用有人在 Computed columns 里寫了一大串表達(dá)式卻因?yàn)閿?shù)據(jù)類型沒轉(zhuǎn)對整列算出來全是 null還有人把本該在 Post-filter 里做的行篩選硬塞進(jìn)預(yù)過濾導(dǎo)致 Join 的時候關(guān)聯(lián)鍵出了問題。這篇文章我就把這幾個通用步驟徹底講透從設(shè)計思路到實(shí)操細(xì)節(jié)再到我這些年踩過的坑一次性說清楚。1. 內(nèi)容整體設(shè)計與思路拆解先說設(shè)計思路。Dataiku DSS 把 Recipe 界面設(shè)計成“三步走”的通用框架不是拍腦袋定的而是基于一個很樸素的邏輯你先決定要處理哪些數(shù)據(jù)再決定怎么處理最后再決定留下哪些結(jié)果。這個邏輯說起來簡單但實(shí)際用起來很多人會混淆。我見過不少用戶在 Prepare Recipe 里先做了過濾然后又想用過濾后的數(shù)據(jù)去算一個平均值結(jié)果發(fā)現(xiàn)平均值算出來不對——因?yàn)轭A(yù)過濾是在每個獨(dú)立行進(jìn)入處理流程之前就生效的它影響的是整個 Recipe 的輸入數(shù)據(jù)范圍。而后過濾是在所有計算完成之后才執(zhí)行的它只影響最終輸出到下一個數(shù)據(jù)集的行集合不會影響前面任何一步的計算結(jié)果。我把這個關(guān)系梳理成一個簡單的對照表步驟執(zhí)行時機(jī)影響范圍典型用途Pre-filter預(yù)過濾Recipe 開始處理前影響后續(xù)所有步驟的輸入數(shù)據(jù)剔除無效行、縮小數(shù)據(jù)范圍、減少計算量Computed columns計算列過濾之后、聚合或輸出之前只影響當(dāng)前 Recipe 內(nèi)部的計算結(jié)果創(chuàng)建新字段、轉(zhuǎn)換數(shù)據(jù)格式、計算衍生指標(biāo)Post-filter后過濾所有計算完成后、輸出前只影響最終輸出的行集合根據(jù)計算結(jié)果篩選、條件化保留數(shù)據(jù)這個順序不是隨便排的。預(yù)過濾放在最前面是為了讓后續(xù)的計算跑得更快、更準(zhǔn)——你想想看如果你有 1 億行日志數(shù)據(jù)其中 30% 是無效記錄不做預(yù)過濾就讓計算機(jī)硬算純粹是浪費(fèi)資源。計算列放在中間是為了讓它能消費(fèi)預(yù)過濾后的干凈數(shù)據(jù)同時給后過濾提供篩選依據(jù)。后過濾放在最后是因?yàn)橛行┖Y選條件依賴于計算列的結(jié)果——比如你算完了客單價之后想只保留客單價大于 100 元的訂單這種條件在預(yù)過濾階段根本寫不出來因?yàn)槟隳菚r候還沒有客單價這個字段。這個設(shè)計的精髓在于每一層只做自己該做的事不能越界。預(yù)過濾不該去依賴計算列的結(jié)果后過濾也不該去改變計算邏輯否則整個 Recipe 的執(zhí)行順序就亂了。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 預(yù)過濾數(shù)據(jù)進(jìn)入處理管線之前的第一道閘門預(yù)過濾寫起來很簡單就是在 Recipe 的 Filters 區(qū)域加條件但它背后的執(zhí)行邏輯有很多講究。第一預(yù)過濾是在數(shù)據(jù)讀取之后、任何處理步驟開始之前執(zhí)行的。這意味著它看不到你在 Recipe 里創(chuàng)建的任何新列因?yàn)槟切┝羞€不存在。所以你在預(yù)過濾里只能引用數(shù)據(jù)集中原有的字段。如果你試圖在預(yù)過濾里引用一個計算列DS 會直接報錯或者更隱蔽的是——不會報錯但條件永遠(yuǎn)不成立導(dǎo)致輸出全空。第二預(yù)過濾的語法用的是 DSS 的標(biāo)準(zhǔn)過濾表達(dá)式。默認(rèn)情況下你可以在界面上選擇字段、操作符、值比如“status equals closed”“amount greater than 100”。但真正靈活的方式是用高級模式直接寫表達(dá)式。我給大家一個我自己常用的寫法isNotNull(email) (amount 100 || priority high)這個表達(dá)式的意思是email 不能為空并且金額大于等于 100或者優(yōu)先級是 high。注意括號的用法在 DSS 的過濾表達(dá)式里邏輯優(yōu)先級有時候跟你想的不一樣建議不確定的時候都加括號。第三預(yù)過濾對性能的影響非常明顯。如果你的數(shù)據(jù)量是千萬級別預(yù)過濾能砍掉一半的數(shù)據(jù)那么后續(xù)所有步驟——不管是 Join、Group 還是窗口計算——都會快上一倍不止。反過來如果你把所有過濾都放在后過濾那計算引擎就得先把所有數(shù)據(jù)算完再篩性能差距可能達(dá)到數(shù)倍。我有一個經(jīng)驗(yàn)?zāi)芮爸玫倪^濾盡量前置。但這里有個度的問題——前置過濾是有限制的它只能基于原始字段。如果你需要基于衍生字段比如計算列的結(jié)果來過濾那只能在后過濾里做。這個問題會在后面詳細(xì)展開。2.2 后過濾在大門關(guān)閉之前做最后的甄別后過濾的界面和預(yù)過濾幾乎一模一樣只是位置不同因此在概念上很容易被混淆。但它們的能力邊界完全不同。后過濾的最大價值在于它可以引用整個 Recipe 生命周期內(nèi)產(chǎn)生的所有字段包括計算列、聚合結(jié)果、窗口函數(shù)結(jié)果。舉個例子你在 Prepare Recipe 里用計算列算出了“訂單金額 - 退款金額 凈收入”然后你想只保留凈收入為負(fù)的異常訂單——這個條件在預(yù)過濾里鐵定寫不了但在后過濾里輕輕松松net_revenue 0另一個典型場景是 Group Recipe。你在 Group Recipe 里按用戶分組然后算出每個用戶的總消費(fèi)額、訂單數(shù)、平均客單價。后過濾就可以直接寫total_spend 1000 order_count 5把所有高價值用戶篩出來。這個邏輯如果用預(yù)過濾來做得先 Join 回原始表再用 Join 后的結(jié)果去過濾麻煩不說還容易出錯。還有一個細(xì)節(jié)后過濾不只是用來篩行它還能幫你做數(shù)據(jù)質(zhì)量檢查。比如你算完凈收入后發(fā)現(xiàn)有一批記錄凈收入是 null可能是因?yàn)樵磾?shù)據(jù)里退款金額是 null。你可以在后過濾里寫net_revenue ! null把這些臟數(shù)據(jù)直接擋在輸出之外。這種做法是保證下游數(shù)據(jù)質(zhì)量的一個非常實(shí)用的招數(shù)。2.3 計算列Recipe 內(nèi)部最強(qiáng)大的字段加工工具計算列是視覺化 Recipe 里最靈活、但也是最容易寫錯的部分。在 Prepare Recipe 里叫 Computed Columns在 Group Recipe 里叫 Aggregated Columns本質(zhì)上也是計算列只不過用的是聚合函數(shù)在 Join Recipe 里則可以通過“Add new columns”來生成基于兩側(cè)字段的新列。計算列的核心是用表達(dá)式語言Formula Language來生成新的字段值。這個表達(dá)式語言看著像 SQL 和 Excel 公式的混合體但有不少自己的脾氣。首先最基本的寫法是用號開頭 abs(amount) 10其次如果你要處理字符串可以用各種字符串函數(shù)。比如把 customer_name 轉(zhuǎn)成大寫 upper(customer_name)或者從 email 里提取域名 substring(email, position(email, ) 1)再比如處理時間字段。時間字段在 DSS 里有三種類型Date、Timestamp 和 string 形式的日期。如果你直接拿一個 string 形式的日期去跟另一個 Timestamp 比較大概率會得到錯誤結(jié)果或者直接被當(dāng)字符串處理了。所以我一直強(qiáng)調(diào)寫計算列之前先確認(rèn)字段類型。你可以用dataType()函數(shù)檢查類型也可以用parseDate()把字符串轉(zhuǎn)成日期再運(yùn)算。這里我要重點(diǎn)說一個函數(shù)if條件。它的語法是if(條件, 真值, 假值)舉例 if(revenue 0, 盈利, 虧損)這個函數(shù)寫起來很簡單但嵌套多了就很容易亂。我自己一般會拆成多步先在一步里算出一個中間結(jié)果再在下一步里基于中間結(jié)果做分類。這樣邏輯清楚出錯了也好排查。還有一個很多人不知道的小技巧在計算列里可以直接引用前面步驟已經(jīng)創(chuàng)建的計算列。這意味著計算列可以鏈?zhǔn)揭蕾囈粚訉盈B加。比如第 1 步 quantity * unit_price生成gross_amount第 2 步 gross_amount - discount生成net_amount第 3 步 if(net_amount 0, 0, net_amount)生成final_amount這種鏈?zhǔn)綄懛ū纫徊綄懗鲆粋€巨大的嵌套表達(dá)式要清晰得多后期維護(hù)的時候也省心。2.4 三種操作的執(zhí)行順序和潛在誤區(qū)打個簡單的比方預(yù)過濾像是進(jìn)考場前的安檢計算列像是考場里做題后過濾像是交卷時的檢查。安檢階段你只能檢查身上帶的東西原始數(shù)據(jù)集里的字段做題階段你可以使用草稿紙上的所有東西前面算出來的所有中間結(jié)果交卷檢查階段你可以決定哪些題目算數(shù)哪些行留到最終輸出。這個比喻看起來很順但實(shí)操中有一個很容易翻車的細(xì)節(jié)預(yù)過濾雖然看不到計算列但它會影響到計算列的輸入。什么意思呢假設(shè)你有 100 行數(shù)據(jù)預(yù)過濾篩掉了 20 行剩下的 80 行參與計算列的計算。那么計算列的結(jié)果是基于這 80 行算出來的。如果你在預(yù)過濾前就想好要用某個計算列的均值來做歸一化那么實(shí)際上這個均值是基于過濾后的 80 行算出來的而不是全量 100 行的均值。這個邏輯有時候是有意為之比如你想只看已支付訂單的均值但有時候是無心之失比如你本來想用全量數(shù)據(jù)的均值做歸一化卻忘了預(yù)過濾已經(jīng)改變了輸入范圍。我建議大家在設(shè)計 Recipe 的時候強(qiáng)制自己在心里過一遍執(zhí)行順序預(yù)過濾 → 計算列 →聚合/Join/窗口→ 后過濾 →輸出。每一步都明確知道自己面對的是哪些數(shù)據(jù)。另一個常見誤區(qū)是在同一個 Recipe 里反復(fù)切換預(yù)過濾和后過濾卻不清楚自己到底想篩什么。比如有人先是預(yù)過濾status closed然后計算列算出days_to_close又后過濾days_to_close 30結(jié)果發(fā)現(xiàn)輸出的行數(shù)很少就開始懷疑是不是計算列算錯了。其實(shí)沒算錯只是兩個過濾條件疊加之后符合條件的數(shù)據(jù)本來就少。這時候要用到的排查技巧我會在第 4 節(jié)詳細(xì)講。3. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 場景設(shè)定與數(shù)據(jù)準(zhǔn)備講完了理論我們用一個具體的例子把整個流程串一遍。假設(shè)我有一份電商訂單數(shù)據(jù)模擬數(shù)據(jù)包含以下字段字段名類型說明order_idstring訂單 IDcustomer_idstring客戶 IDorder_datedate下單日期statusstring訂單狀態(tài)closed / pending / cancelledquantityint商品數(shù)量unit_pricedouble單價discountdouble折扣金額refund_amountdouble退款金額emailstring客戶郵箱我的業(yè)務(wù)需求是統(tǒng)計每個客戶的凈消費(fèi)金額商品總價 - 折扣 - 退款然后找出凈消費(fèi)金額 500 且訂單數(shù) 3 的活躍高價值客戶。最后只要這些客戶的訂單記錄。這個需求如果不用預(yù)過濾、計算列、后過濾直接硬寫Recipe 會亂成一鍋粥。我們按部就班來。3.2 預(yù)過濾先把無效訂單擋住打開 Prepare Recipe第一步就是加預(yù)過濾條件。我這里的原始數(shù)據(jù)有 100 萬行其中包含大量status cancelled的訂單和 email 為空的匿名訂單。這些記錄在后續(xù)計算里都是噪音應(yīng)該直接剔除。預(yù)過濾表達(dá)式status ! cancelled isNotNull(email)注意到?jīng)]有我沒有直接把status closed作為預(yù)過濾條件因?yàn)闃I(yè)務(wù)上pending狀態(tài)的訂單雖然還沒完成但后續(xù)可能變成closed目前階段先保留它們等后過濾的時候再根據(jù)計算列結(jié)果來篩選。這一步的效果100 萬行 → 85 萬行。跑數(shù)時間直接少了 15%。提示預(yù)過濾里如果寫isNotNull(email)效率會比email ! null更高寫法也更標(biāo)準(zhǔn)。在 DSS 的表達(dá)式里判斷空值要用isNull()/isNotNull()用 null有時候會被解析成字符串比較結(jié)果永遠(yuǎn)為 false。3.3 計算列分步構(gòu)建凈消費(fèi)金額有了干凈的 85 萬行數(shù)據(jù)之后我創(chuàng)建三個計算列。第 1 列g(shù)ross_amount計算原始金額 quantity * unit_price第 2 列net_amount扣除折扣和退款 gross_amount - discount - refund_amount第 3 列customer_status打標(biāo)客戶類型 if(net_amount 500, high_value, if(net_amount 100, medium_value, low_value))注意第三列我用了嵌套if。這里有個經(jīng)驗(yàn)嵌套 if 的括號非常容易寫錯所以我個人更建議大家拆成兩步——先算net_amount再基于net_amount寫個簡單的if如果還要細(xì)分就再算一列。寧可多建一列不要用一個巨型嵌套表達(dá)式。創(chuàng)建完這三列之后你的數(shù)據(jù)集中就有了新的可用字段。這時候你可以先點(diǎn)一下 Run看看結(jié)果是否如預(yù)期。我習(xí)慣每加一個關(guān)鍵計算列就跑一次不攢到最后才驗(yàn)證這樣問題能盡早暴露。3.4 后過濾等所有計算都完成后再拍板計算列跑完后我要做的核心篩選就是基于net_amount來過濾。先臨時加一個后過濾條件看看行數(shù)net_amount 500跑完之后我發(fā)現(xiàn)符合這個條件的記錄有 18 萬行。但業(yè)務(wù)需求還要求“訂單數(shù) 3”這個條件是針對同一個客戶維度來統(tǒng)計的在一個行級別的 Prepare Recipe 里沒法直接做——因?yàn)槊啃写淼氖且粋€訂單不是客戶。所以我需要把數(shù)據(jù)先按客戶聚合再判斷訂單數(shù)。這里是實(shí)操中一個重要的分岔口在 Prepare Recipe 里做完行級計算后應(yīng)該接一個 Group Recipe 來做客戶維度的聚合。具體步驟Prepare Recipe 輸出包含customer_id、net_amount、訂單數(shù)可以用一個恒等計數(shù)列或者在 Group 里直接 count。新建 Group RecipeGroup bycustomer_id。聚合指標(biāo)total_net_amount SUM(net_amount)order_count COUNT(order_id)avg_discount AVG(discount)在 Group Recipe 的后過濾里寫total_net_amount 500 order_count 3輸出高價值客戶列表再把這個列表 Join 回原始的訂單明細(xì)拿到這些客戶的完整訂單記錄。這個流程的好處是每一步都只做一件事邊界清晰出問題的時候很容易定位。而如果你試圖在一個 Recipe 里把所有邏輯都做完往往會陷入“這個過濾條件到底是在哪個階段生效”的混亂中。3.5 完整流程的 Recipe 串聯(lián)我這里用一個簡單的圖示來描述一下 Recipe 的串聯(lián)關(guān)系跟 DSS 界面的實(shí)際流向一致原始數(shù)據(jù)集 → Prepare Recipe預(yù)過濾狀態(tài)與 email → 計算 gross_amount → 計算 net_amount → 計算 customer_status → 后過濾 net_amount 0→ Group Recipe按 customer_id 聚合 → 計算 total_net_amount、order_count → 后過濾 high-value 條件→ Join Recipe拿高價值客戶列表關(guān)聯(lián)回訂單明細(xì)→ 最終數(shù)據(jù)集這個串聯(lián)方式我實(shí)測下來非常穩(wěn)。它不僅滿足了業(yè)務(wù)需求而且中途任何一步的結(jié)果都可以單獨(dú)查看、驗(yàn)證比一個巨大的 Recipe 硬算到底要容易排查得多。注意這里需要強(qiáng)調(diào)一下在上述第二個 RecipeGroup Recipe里的后過濾用到的total_net_amount和order_count是在同一個 Recipe 里由聚合計算產(chǎn)生的字段——這正是后過濾最擅長的場景。預(yù)過濾做不到這一點(diǎn)因?yàn)樵诰酆现案緵]有這兩個字段。4. 常見問題與排查技巧實(shí)錄在這個部分我把自己平時被問得最多、以及自己踩過的坑整理成一份速查表每一個問題都對應(yīng)的有排查思路和解決辦法。4.1 為什么我的過濾條件一跑就報錯最常見的原因是字段類型不匹配。比如unit_price在源表里是字符串類型你直接寫unit_price 100DSS 不會像 SQL 那樣幫你隱式轉(zhuǎn)換而是直接報類型比較錯誤。解決辦法先看字段類型如果是 string 類型且內(nèi)容確實(shí)是數(shù)字先用parseDouble(unit_price)轉(zhuǎn)成 double 再比較parseDouble(unit_price) 100又或者如果你那個字段的值里混著貨幣符號或空格比如$100.00直接用parseDouble會失敗需要先清洗。我在實(shí)操中用得比較多的寫法是parseDouble(trim(replaceAll(unit_price, $, ))) 1004.2 為什么我寫了計算列但結(jié)果全部是 null這個問題的原因大概率是數(shù)據(jù)類型不匹配或者函數(shù)名寫錯。在 DSS 的 Formula 語言里字符串拼接用的是而不是concat()字符串取長度用的是len()而不是length()判斷是否包含用的是contains()而不是includes()。這些細(xì)節(jié)跟很多編程語言的習(xí)慣不一樣很容易寫錯。另一個常見原因是你要引用的字段名字里包含了特殊字符比如空格、中劃線。DSS 在表達(dá)式里引用字段名需要用反引號或者方括號包裹。比如字段名是unit price你應(yīng)該寫unit price * quantity如果字段名里帶有中劃線在 DSS 內(nèi)部生成的新列含-很常見一定要用反引號包裹否則表達(dá)式的減法語義會被誤解。排查方法是在計算列編輯器里輸入字段名的時候看編輯器是否自動彈出字段名提示。如果沒有彈出說明這個字段名還沒被正確識別檢查一下拼寫和特殊字符。4.3 預(yù)過濾和后過濾的篩選結(jié)果對不上很多人發(fā)現(xiàn)自己把相同的條件從預(yù)過濾挪到后過濾輸出行數(shù)卻不一樣。這是正常的因?yàn)閮蓚€階段的執(zhí)行位置不同。預(yù)過濾發(fā)生在所有計算之前所以它的輸入是原始數(shù)據(jù)后過濾發(fā)生在所有計算之后所以它的輸入包含了計算列的結(jié)果而計算列本身可能會改變行的數(shù)量嗎不會改變數(shù)量但計算列可能計算出 null 值如果你后過濾里有類似column 0的條件null 值會被過濾掉導(dǎo)致行數(shù)變少。舉一個具體的例子我在預(yù)過濾里寫refund_amount 0因?yàn)槲蚁肱懦丝顬樨?fù)值的異常數(shù)據(jù)。但計算結(jié)果出來后我發(fā)現(xiàn)有些記錄 net_amount 是負(fù)數(shù)——因?yàn)?discount 比 gross_amount 還大。然后在后過濾我寫net_amount 0這樣就把那些“打折打到虧本”的訂單也排除了行數(shù)自然比預(yù)過濾后還要少。這不是 bug是業(yè)務(wù)邏輯的疊加。排查技巧當(dāng)你發(fā)現(xiàn)行數(shù)對不上的時候不要慌先在后過濾前加一個臨時步驟把當(dāng)前的行數(shù)打出來再逐步加后過濾條件看是哪一步篩掉的。這個“二分定位法”在 DSS 里很好用。4.4 如何在不改變 Recipe 結(jié)構(gòu)的情況下查看中間數(shù)據(jù)DSS 有一個很方便的輔助功能你可以臨時禁用某個 Recipe 輸出的下游依賴或者直接在 Recipe 結(jié)果面板里查看當(dāng)前步驟的中間數(shù)據(jù)。在 Prepare Recipe 里每一步的右側(cè)都有該步執(zhí)行后的數(shù)據(jù)預(yù)覽。很多人沒注意到的是你可以在“步”級別點(diǎn)擊右鍵選擇 disable這樣 Recipe 會臨時跳過這一步運(yùn)行非常方便做對比排查。另外在 Recipe 輸出面板的頂部有個“Add new step”和“Filter”快捷入口你可以快速加一個臨時的后過濾來看看數(shù)據(jù)分布確認(rèn)之后再決定最終要不要保留。這個習(xí)慣能省掉很多事后的返工。4.5 性能問題Recipe 越跑越慢怎么優(yōu)化在數(shù)據(jù)量很大的場景下預(yù)過濾是性價比最高的優(yōu)化手段。少讀了數(shù)據(jù)后面每一步都快。其次計算列里的函數(shù)也有性能差異——用簡單的四則運(yùn)算比調(diào)用復(fù)雜的文本解析快得多。如果某個計算列只是用來篩選用完后其實(shí)可以只在輸出時保留必要的列不需要把中間列全部輸出到下游數(shù)據(jù)集這樣可以減少后面 Recipe 的 IO 壓力。我有一次跑一個包含 5000 萬行日志數(shù)據(jù)的 Recipe用戶在每個計算列里都調(diào)用了parseDate把字符串時間轉(zhuǎn)成時間戳結(jié)果跑了 40 分鐘沒跑完。后來我把時間解析提前到數(shù)據(jù)導(dǎo)入時的數(shù)據(jù)類型定義階段改成在 Dataset 的 schema 層面就把該列定義為 timestamp結(jié)果整個 Recipe 從 40 分鐘壓縮到了 6 分鐘。這個經(jīng)驗(yàn)告訴我能在大階段比如數(shù)據(jù)集 schema解決的轉(zhuǎn)換就不要放到小階段Recipe 計算列里做。提前在源頭把數(shù)據(jù)類型定義好比在每一步里去兼容各種臟數(shù)據(jù)要高效得多。4.6 后過濾里能不能用多個條件混合完全可以邏輯跟預(yù)過濾一樣。DSS 的過濾表達(dá)式支持AND、||OR、!NOT以及小括號控制優(yōu)先級。給一個綜合的例子(status closed || status pending) total_net_amount 500 !(customer_id in (C001, C002))其中in操作符用于判斷字段值是否在給定集合內(nèi)非常實(shí)用。注意括號的使用如果條件太多建議分行寫保持可讀性。5. 案例實(shí)戰(zhàn)完整 Recipe 的配置過程為了讓大家看得更具體我把第 3 節(jié)中的完整流程細(xì)化成一份可以直接照著點(diǎn)擊的配置清單。5.1 步驟一創(chuàng)建 Prepare Recipe選中原始訂單數(shù)據(jù)集點(diǎn)擊右側(cè)的“Prepare”按鈕創(chuàng)建 Prepare Recipe。在 Step 1原始數(shù)據(jù)上點(diǎn)擊加號選擇“Filter”添加預(yù)過濾條件高級模式中輸入status ! cancelled isNotNull(email)繼續(xù)在 Filters 下方添加“Formula”步驟計算列。輸出列名填gross_amount公式填quantity * unit_price再添加一個“Formula”步驟。輸出列名填net_amount公式填gross_amount - discount - refund_amount再添加一個“Formula”步驟。輸出列名填customer_status公式填if(net_amount 500, high_value, if(net_amount 100, medium_value, low_value))切換到 Recipe 輸出面板在 Post-filter 區(qū)域添加條件net_amount 0點(diǎn)擊 Run保存輸出數(shù)據(jù)集。這個輸出的數(shù)據(jù)集里每個訂單行都帶上了凈金額和客戶價值標(biāo)簽完全可以作為后續(xù)分析的基礎(chǔ)寬表。5.2 步驟二創(chuàng)建 Group Recipe 做客戶聚合在剛才輸出的數(shù)據(jù)集上選擇“Group”按鈕。Group by 選擇customer_id和customer_status。新增聚合列total_net_amount聚合方式選SUM來源選net_amountorder_count聚合方式選COUNT來源選order_idavg_quantity聚合方式選AVERAGE來源選quantity在 Group Recipe 的輸出面板中添加后過濾條件total_net_amount 500 order_count 3Run輸出高價值客戶聚合表。5.3 步驟三Join 回去拿完整訂單明細(xì)在聚合表上新建一個 Join Recipe。右數(shù)據(jù)集選擇原始訂單明細(xì)。Join 鍵選擇customer_id。輸出中保留原始訂單的所有字段加上聚合表的total_net_amount和customer_status。Run得到最終數(shù)據(jù)集。這樣一套流程跑下來你的分析表里每一行都是凈消費(fèi)達(dá)標(biāo)、訂單量達(dá)標(biāo)的高價值客戶的每一筆訂單并且還帶了客戶的總消費(fèi)額和訂單數(shù)。后續(xù)做 RFM 分析、客戶分層、流失預(yù)警這張表都能直接打底。6. 常見問題速查表問題原因解決辦法過濾條件報錯字段類型與比較值不匹配先用parseDouble()、parseDate()轉(zhuǎn)類型再比較計算列結(jié)果全為 null函數(shù)名寫錯、字段名含特殊字符檢查字段名、確認(rèn)函數(shù)寫法、用反引號包裹特殊名字段預(yù)過濾行數(shù)和后過濾行數(shù)不一致兩個階段輸入范圍不同明確每個階段基于哪些字段、哪些行在做判斷Formula 里寫字段 null無效DSS 的判空要用 isNull()改為isNull(field)或isNotNull(field)字段名含空格導(dǎo)致表達(dá)式報錯字段名需要轉(zhuǎn)義使用反引號包裹unit price聚合 Recipe 里后過濾引用新聚合列失敗聚合字段尚未創(chuàng)建確認(rèn)聚合列已經(jīng)在 output 中定義且拼寫正確性能越來越慢計算列里做了過多復(fù)雜解析盡量在 Dataset schema 階段定義好類型避免在 Formula 里反復(fù) parseDate、parseDouble這張表基本覆蓋了我日常被問到的高頻問題。當(dāng)然DSS 的版本迭代很快某些界面的名稱和位置可能略有不同但核心的執(zhí)行邏輯和函數(shù)語義是相對穩(wěn)定的。你在用的時候如果發(fā)現(xiàn)界面跟我描述的有差異優(yōu)先觀察面板上的字段類型和執(zhí)行順序提示思路對了就不會走偏。7. 我的一些實(shí)操心得最后再分享幾個實(shí)戰(zhàn)中沉淀下來的經(jīng)驗(yàn)這些都不太會寫在官方文檔里但確實(shí)能幫你省不少事。第一養(yǎng)成“小步快跑”的習(xí)慣。很多人喜歡把 Recipe 寫到一半再運(yùn)行結(jié)果一出錯就要從頭排查。我更建議大家每寫完一個關(guān)鍵步驟就點(diǎn)一次 Run看看這個步驟的輸出是否符合預(yù)期。損失幾分鐘的運(yùn)行時間換來的是調(diào)試時候的大把節(jié)省非常劃算。第二在 Recipe 里給計算列起名字的時候一定要用“業(yè)務(wù)可讀 技術(shù)規(guī)范”并重的命名方式。比如net_amount比col4好一萬倍。因?yàn)槟愫筮^濾、Join 的時候都要引用這些名字名字混亂會讓你自己也看不清。我見過有的人算了幾列都是col1、col2結(jié)果后過濾條件寫出來是一長串?dāng)?shù)字字母組合根本沒法檢查邏輯對不對。第三不要迷信一步到位的“大長公式”。DSS 的計算列支持鏈?zhǔn)揭媚憧梢园褟?fù)雜的邏輯拆成多個簡單步驟每步都能驗(yàn)證結(jié)果。這比一次性寫一個四層嵌套的if要可靠得多。在團(tuán)隊協(xié)作中步驟分的越細(xì)別人 review 你的 Recipe 的時候也越容易看懂。第四如果數(shù)據(jù)量大一定要注意輸出列的數(shù)量。很多人做 Recipe 的時候原始表有多少列就輸出多少列導(dǎo)致下游數(shù)據(jù)集體積膨脹好幾倍。在做完所有計算以后可以在輸出面板里把不必要的列刪掉只保留后續(xù)需要的字段。這個習(xí)慣對整體性能的提升非?？捎^尤其在數(shù)據(jù)管道有多個 Recipe 串聯(lián)的時候。第五善用樣本模式。在 Recipe 開發(fā)階段可以把運(yùn)行模式調(diào)成“Sample”先跑一小部分?jǐn)?shù)據(jù)驗(yàn)證邏輯。等邏輯沒問題了再切回全量運(yùn)行。這樣既保證了正確性又不會因?yàn)槿繑?shù)據(jù)運(yùn)行時間太長而影響開發(fā)效率。我在實(shí)際使用中發(fā)現(xiàn)真正把 Pre-filter、Post-filter、Computed columns 用熟練之后寫 Recipe 的感覺會變得非常順暢。你不再會被一堆條件繞暈而是清楚地知道每一層在干什么、為什么在這里、數(shù)據(jù)流經(jīng)過它之后變成了什么樣子。這套思維方式才是 Visual Recipe 能帶給你的最大價值——不只是點(diǎn)鼠標(biāo)而是對數(shù)據(jù)加工流程本身有清晰的掌控感。如果你是剛接觸 Dataiku DSS我特別建議你現(xiàn)在就打開一個自己的數(shù)據(jù)集把這三個功能挨個試一遍。先不追求復(fù)雜的業(yè)務(wù)邏輯就單純感受一下預(yù)過濾、計算列、后過濾的執(zhí)行順序和相互影響。這個基本功打好了后面處理再多再復(fù)雜的數(shù)據(jù)場景你都不會慌。