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