在Dataiku DSS里摸爬滚打了一段时间后你会发现一个现象不管打开Prepare、Group还是Window这些可视化recipe的编辑界面里总有几个功能长得特别像——预过滤Pre-filter、后过滤Post-filter、计算列Computed columns。很多人最初以为这只是几个零散的功能按钮直到我在某个用户行为项目里反复调整数据流程时才意识到它们其实是所有可视化recipe共用的“三步走”骨架。这篇内容就围绕这三个通用步骤展开说清楚它们各自管什么、按什么顺序执行、以及如何组合起来派上用场。如果你刚接触DSS或者已经会用但总觉得流程写得不够顺手这篇值得花十分钟读完。1. 三个通用步骤的定位与配合逻辑1.1 为什么可视化recipe都要有这三步DSS的可视化recipe遵循一个非常朴素的管线思想先框定要处理的数据范围再做中间加工最后验证输出结果。预过滤承担“框定范围”计算列承担“加工”后过滤承担“验证输出”。这不是某个recipe特有的设计而是整个DSS在交互处理层面沉淀出来的统一模式。相比写代码这种可视化方式把每个动作都变成一个可观察、可回退的步骤尤其适合团队协作——旁边的人打开你的recipe不需要读一堆脚本就能看出你干了什么。我在实际项目里发现很多新人以为预过滤就是把SQL里的WHERE子句搬到界面里后过滤就是把HAVING搬过来计算列就是SELECT里加一个新字段。这么理解不算错但忽略了三者的层级关系和执行时机等数据量一上来、逻辑一复杂很容易在排查问题时绕进死胡同。1.2 执行顺序与数据流视角从数据流顺序来看三个步骤的固定执行顺序是输入数据集 - 预过滤 - 中间处理包括各类计算列- 后过滤 - 输出数据集。预过滤一定先于计算列后过滤最后执行。这个顺序看起来理所当然实际影响却很大。比如你的数据里有event_type test的测试流量如果不在预过滤阶段清掉后面的计算列会照样给这些行计算统计口径就会被污染更麻烦的是下游的Group或Join也会把这些行算进去等到汇总时发现问题再回头追根溯源就很费劲。另一个值得留意的点是DSS对预过滤的下推优化。当数据源是SQL数据库时预过滤条件会被尝试翻译成SQL里的WHERE条件直接推到数据库执行从而减少读入DSS引擎的数据量。理解这个机制对排查性能问题很有帮助——如果某个预过滤条件用到了自定义函数或特殊的表达式下推可能失败数据就会全量拉到引擎端过滤任务时间会肉眼可见地变长。2. 预过滤在数据进门之前先做减法2.1 预过滤的核心使用场景预过滤解决的是“有些行根本不该进入后续处理”的问题。我在项目里总结出几类最常用的场景字段缺失且无意义的行比如user_id is null的记录在用户分析中注定无法归因留着只会污染后续join。测试流量或标记数据比如event_type test这类数据在开发环境里有用在正式分析里必须剔除。与本次分析无关的时间范围比如只分析近30天就把30天之前的数据挡在门外。明显异常的值域比如页面停留时长超过24小时、金额为负等不合理数据。这些都是典型的预过滤场景。核心判断标准是如果某类行在后续所有步骤里都不需要那就把它挡在入口。我见过不少项目把所有清洗逻辑都压在预过滤上条件越堆越多最后变得很难维护也见过完全不用预过滤、把过滤散落在各个下游步骤里的情况那会导致同一个过滤条件在多个recipe里重复出现改一处漏一处。2.2 预过滤的配置方法与参数选择在DSS中打开任意可视化recipe后你能在输入数据的面板上看到Filters配置区。点击Add Filter就可以添加条件。配置时要注意“Match all conditions”与“Match any conditions”的区别Match all行必须满足所有条件才保留逻辑上相当于AND。Match any行只要满足其中一个条件就保留逻辑上相当于OR。我见过一个真实案例某同学在预过滤里写了user_id is not null和event_type ! test两个条件本来想表达“排除无效用户也排除测试事件”结果切成了Match any模式导致只要满足其中一个条件就被保留了——测试流量全都漏了进来。这类错误在界面操作中特别容易忽略因为预览结果不会立刻显眼地报错只有看统计指标波动时才会发现。操作层面DSS的过滤条件支持简单的字段条件也可以切到Advanced模式写表达式。我个人的建议是能用普通条件就先用普通条件因为它可读性更强表达式模式适合日期偏移、多字段联动等复杂判断。例如保留近7天数据可以写成event_time today() - 7之类的表达式这比每次手工改日期高效得多。2.3 预过滤的注意事项第一预过滤会改变数据口径这是必然的。下游看到的行数会比原始数据少做数据对比时不要惊讶也不要为了让数字好看而放松过滤。第二预过滤应该在真正需要时使用。如果某个条件只在个别下游分析里需要它就属于该下游的后过滤或查询筛选而不是所有数据管线的公共预过滤。放进预过滤意味着所有基于此recipe的数据都会被影响。第三如果数据源在SQL数据库里尽量让预过滤条件保持简单以支持下推。条件里频繁使用regex、自定义函数、跨字段复杂运算时可能要谨慎评估下推能力否则全表扫描会拖慢任务。第四注意采样与预过滤的先后关系。DSS界面中默认会对超大数据集做采样预览采样行为可能发生在预过滤之前或之后这取决于数据源类型和配置。因此你看到的预览行数与实际运行结果可能不一致跑任务前最好用全量数据或调整采样策略确认一遍。3. 后过滤在结果出门之前把好最后一道关3.1 后过滤和预过滤的本质差异预过滤针对输入行后过滤针对输出行这是两者最核心的区别。很多人在学习时会忽略“输出行”这三个字的分量——它意味着后过滤能看到中间处理后的结果包括由计算列生成的新字段。在Prepare这类行级转换recipe中后过滤作用在每一行上本质上就是“先算完再筛选”。而在Group这类聚合recipe里后过滤作用的是聚合结果行。这时候输出字段已经变成了分组键和聚合指标后过滤条件只能引用这些字段。举个具体例子按渠道统计用户数后后过滤写count_distinct(user_id) 100就可以把活跃度不足的小渠道一次性清掉这种用法在SQL里等价于HAVING子句。我一直用生活化的类比来记这两个步骤预过滤是进货验货后过滤是发货前终检中间的转换步骤是加工线。进货的时候把石头挑出去加工完再检查成品有没有瑕疵顺序错了就会导致加工资源浪费或者不合格产品流向市场。3.2 后过滤的配置方法与典型用法后过滤在DSS中的操作位置一般在recipe的输出区域配置。界面里会列出“输出前筛选”之类的选项你可以像设置预过滤一样添加条件。配置逻辑完全一致仍然要注意Match all和Match any的区别。典型的后过滤场景有三种聚合后的阈值筛选Group recipe里按维度分组后只保留满足条件的组比如用户数、订单数、总额达到某个门槛。基于计算列的行筛选Prepare里先算出一个标记字段再通过后过滤只保留标记字段符合条件的行。这样做的好处是让筛选口径和计算口径集中在同一处修改时只需改计算列。窗口计算后的截断处理Window recipe算完排名或累计值后用后过滤截取Top N或累计占比80%以内的行。这些用法里都体现了一个共同的设计思路先让统计逻辑在计算列或聚合指标里完成再把筛选放在最后一步让过滤条件尽量简单、直白。3.3 后过滤容易踩的几个坑后过滤第一个坑是“引用不存在的字段”。在聚合recipe中如果后过滤条件里有某个原始字段而这个字段没有出现在聚合结果里运行时会直接报字段不存在。解决方法是把该字段加进分组键或者先用聚合函数把它变成一个输出指标。第二个坑是空值导致的组别消失。比如按channel分组后过滤channel is not null看起来合理实际上null渠道会被过滤掉。有些业务场景里渠道为空恰恰代表自然流量或未知来源反而需要单独统计。所以在写后过滤前先想清楚null值在当前分析里的业务含义。第三个坑是Sysy预览与执行结果不一致。后过滤配置好之后如果输出数据量很大界面显示的可能仍是采样后的预览。想确认全量结果需要实际运行一次recipe或查看运行后的dataset统计。第四个坑是后过滤无法访问未输出的计算列。假如你在Prepare里算了一个score列但输出时没有把它包含进来那么后过滤虽然可能在当前步骤还能引用它但下游recipe完全看不见这个字段。维护时很容易忘记这一点导致下游想再筛选score时找不到字段。我的习惯是需要用于后续筛选的辅助列要么保留在输出集中要么明确在文档里注明它已在该steps完成后被丢弃。4. 计算列把“想算的值”变成“可用的列”4.1 计算列在可视化recipe中的位置计算列是可视化recipe里最常见的一类中间加工步骤。从概念上讲它解决的是“数据里没有但分析需要”的问题——时间戳需要拆成年月日、设备类型需要归并成移动端和PC端、订单金额需要扣除退款、高价值用户需要打标这些都靠计算列完成。在DSS中计算列出现的形式不完全一样。Prepare recipe里有专门的Compute Formula步骤Group recipe里可以添加聚合计算指标Window recipe里可以添加窗口函数结果。不管形式怎么变核心逻辑都是基于已有字段、通过公式或表达式生成新字段。理解这一点后你在不同recipe之间切换时会发现思路完全可以复用。我比较推荐在流程早期就把计算列集中建立。比如分析用户行为先把hour、weekday、is_mobile、is_new_user这些衍生维度算好后续所有Group、Join、过滤都能直接引用整个流程会清爽很多。如果每个下游recipe各自重复计算同样的逻辑等口径需要调整时工作量会成倍增加。4.2 计算列公式写法与常用函数示例DSS的公式编辑器采用类似Excel的函数风格对大多数从业者来说上手很快。我在实际项目里最常用的几类写法时间字段提取hour(event_time) weekday(event_time) date(event_time)条件字段归类if(device in (iOS, Android), Mobile, Other)空值兜底ifNull(channel, unknown)数值处理round(total_amount, 2)这些公式在编辑器里会实时显示返回类型和部分预览值写起来比SQL盲写要直观得多。建议新手先点开函数列表看几遍DSS里的日期函数、字符串函数、聚合函数分类很清晰很多功能你以为是SQL里才能写的其实公式编辑器都内置了。写计算列时有一个细节容易忽略列名如果包含空格、中文或特殊字符在公式里需要用引号包裹。我见过有人在公式里写if(列名 1, a, b)结果一直解析报错加上引号之后就正常了。另一个细节是公式结果的类型要尽量保持稳定。有的函数在输入为null时返回的类型和正常值不一致导致字段类型变成混合型后续排序或过滤时会出现很诡异的错误。4.3 计算列的性能与可读性计算列本质上是逐行计算数据量大时成本不低。我在处理亿级行数的日志时对计算列的使用有一条原则能用简单算术和内置函数解决的绝不引入正则能拆分成多个简单计算列的绝不写一个超长公式。正则和字符串复杂运算在行数大的表上会显著拖慢任务而且排查问题时很难定位是哪一段逻辑出了问题。可读性方面给计算列命名时最好带统一前缀比如calc_、flag_、dim_这样下游引用时一眼就能看出字段来源。也可以选中计算列后在DSS里补充字段描述把计算口径写清楚。这个习惯在项目交接时特别有价值——别人看到flag_high_value_user再点开描述看到“近30天消费金额大于1000且下单次数大于5次”就不用再翻文档了。5. 实战案例从原始点击日志到可分析样本5.1 业务需求与原始数据情况用一个虚构但很典型的需求来说明白这三步的组合用法。假设某项目需要统计App的日活跃用户数并对比工作日和周末的差异但只看移动端设备同时要把测试流量排除在外。原始数据是一份点击日志表字段大致如下user_id、event_time、event_type、device、page、duration。数据质量并不完美存在三类明显问题部分行的user_id为空有event_type test的测试流量少量device不在目标设备列表内。5.2 第一步配置预过滤在Prepare recipe里配置预过滤条件user_id is not nullevent_type ! test这两个条件都放在预过滤里原因很简单后续所有分析都不需要这些行早剔除既能减少计算量也能避免测试数据污染统计口径。特别是user_id is not null这个条件如果留到后面Group时再过滤聚合计算就会白跑大量无效行。配置完成后可以先看一眼过滤后的行数变化。如果原始数据有几千万行这一步通常能砍掉一小部分“坏数据”。这里有个小技巧把预过滤和数据质量视图结合起来先查看各字段的空值比例和取值分布再决定过滤条件比盲目添加条件更靠谱。5.3 第二步添加计算列接着添加三个计算列为下游聚合做好准备。第一列提取日期作为后续按天聚合的分组键date(event_time)第二列标记工作日还是周末。注意不同DSS版本中weekday()的返回值可能是0到6或1到7可以直接在公式编辑器里看预览确认if(weekday(event_time) in (6, 7), Weekend, Weekday)第三列标记是否为移动端设备if(device in (iOS, Android), Mobile, Other)这三个计算列有清晰的分工一个服务于日期分组一个服务于工作日/周末对比一个服务于设备类型筛选。把它们放在一起计算下游就可以直接用这些字段不必重复推导。5.4 第三步配置后过滤在Prepare recipe的输出侧配置后过滤条件为is_mobile Mobile可能有人会问既然最终只看移动端为什么不直接在预过滤里写device in (iOS, Android)我特意在案例里这么设计是想说明一个细节当“是否移动端”的标准可能需要调整时比如后续把webview也归为移动端把口径放在计算列里只需要改一处if条件预过滤不用动。这比在多个过滤条件里同步修改更不容易出错。后过滤还承担了一个任务它能看到计算列的结果。也就是说这个过滤执行在is_mobile生成之后所以条件可以直接引用该字段。这一层逻辑放到后过滤比放到下游的SQL查询里更规范。5.5 第四步接Group recipe做聚合后过滤从上述Prepare输出新建一个Group recipe按calc_date和is_weekend分组计算distinct(user_id)得到每个日期、每天是工作日还是周末的去重用户数。这时候如果只想看活跃度达到一定规模的日子就在Group recipe的后过滤添加条件distinct_user_count 100这个案例展示了两层后过滤在Prepare里对行级结果过滤在Group里对组级结果过滤。两者的执行位置不同但配置方式几乎一样理解了这个区别就不会再把行级和组级条件混在一起写。6. 常见问题排查与避坑速查6.1 高频问题与排查思路我在实际使用DSS的过程中整理了几个出现频率较高的问题做成速查表供大家参考。现象可能原因排查与解决预过滤后行数没有变化条件逻辑写成了Match any或配置后未保存检查过滤模式确认recipe已保存后过滤报字段不存在引用了聚合输出中没有的字段打开输出字段列表改用分组键或聚合指标计算列结果出现大量空值源字段类型不匹配或包含空字符串先用数据质量视图检查源字段再用ifNull兜底任务运行速度突然变慢预过滤下推失败或计算列用了复杂表达式简化条件避免正则和高成本函数预览结果和运行结果不一致采样导致预览数据范围不同改用全量数据运行一次确认实际统计后过滤条件对null组无效null值在过滤中直接被排除显式处理null或用ifNull先转换这张表里的问题我基本都踩过。特别是“预览结果和运行结果不一致”这条最容易被新人误判为DSS的bug。其实绝大多数情况下只是采样机制在起作用而不是计算逻辑出错。6.2 我踩过的一些坑与习惯做法分享几个我后来固化成习惯的做法。第一个习惯是新建任何recipe之前先花两分钟看输入数据的字段质量和分布。DSS的数据集浏览页面能直接展示每列的类型、空值率、取值分布这些信息比直接开写recipe重要得多。很多过滤条件、计算列的设计其实在看了一眼数据质量之后就自然清楚了。第二个习惯是所有过滤条件尽量集中到recipe中同一片区域。预过滤就放在预过滤区后过滤就放在后过滤区不要一会儿在Prepare里过滤一会儿又跑到下游SQL里过滤同一批条件。集中管理的最大好处是维护口径时有一个确定的修改位置。第三个习惯是计算列命名一定要带上语义前缀。我用calc_表示计算字段flag_表示标记字段dim_表示维度规整字段。这样下游在引用时不会把原始字段和衍生字段搞混。尤其当同一个源表被多个recipe使用时字段命名规范直接影响协作者的理解成本。第四个习惯是每次修改过滤条件或计算列后顺手记一笔变更原因。不用写长篇只要在字段描述里写一句“排除测试流量口径与某需求一致”就够。几个月后回来看这些备注能帮你快速回忆当初为什么这么设计避免因为忘记口径而误改。最后分享一点我的个人体会在实际项目里摸爬滚打之后我越来越觉得预过滤、后过滤和计算列不是三个孤立的按钮而是一套围绕数据流的“三段式”控制逻辑。能前置的判断放到预过滤让进入计算环节的数据更干净衍生逻辑集中到计算列让口径修改有一个确定的地方对最终结果的把关放到后过滤让输出质量最后被守一遍。至少在我维护的这个点击日志项目里后来新增的所有清洗需求几乎都能顺着这三段快速定位到修改点。刚开始接触DSS的朋友可以先分别把这三个步骤的用法练熟再组合到同一个流程里你会发现它比零散地用各种SQL查询要直观得多也更适合在团队里传阅和复用。