主题: 第17部分. 支付与风险信号数据集市
难度等级: 中级
预计学习时间: 2.5–3小时
前置要求: SQL基础知识（SELECT、WHERE、JOIN、GROUP BY）
理解数据集市（data mart）和数据仓库分层的概念
熟悉Specification-Driven Development（SDD）方法论
对银行和支付业务领域有基本了解
了解处理PII和风险信号的原则
学习目标: 在操作级别定义并固定风险信号数据集市的粒度，并将其与按客户或按天的聚合区分开来。
解释为什么没有明确规范的risk_flag = true过滤器被视为观察型数据集市的破坏性变更。
按照模板撰写风险数据集市备注，注明粒度、信号来源、验证事实和审核员的人工问题。
区分信号来源（stg_card_transactions）的角色与决策的角色，不要将教学性的risk_flag转变为评分产品。
为审核员整理人工事实：大额阈值在哪里，哪些操作被包含/排除，PII出现在哪里。
概述: 第17章致力于设计mart_payment_risk_signals数据集市——一个观察层，而非评分引擎。该集市汇总了被来源标记为风险标志的支付操作，并记录需要关注的大额交易/渠道。本章的核心思想是：在支付领域中，技术上简单的聚合很容易看起来像是风险决策，因此必须严格与评分分离。学生学习在操作级别固定粒度（一行对应一个transaction_id），将risk_flag视为来源信号，不在没有明确规范的情况下丢弃没有标志的操作，避免直接的PII，并在规范、验证备注和审核员报告中明确写入大额阈值。本章培养学生提出「数据集市代表哪一行？」的问题，并理解操作级数据集市和客户级数据集市是不同的数据产品，具有不同的要求。
关键概念: 观察型集市 vs 评分引擎：mart_payment_risk_signals是一个观察型集市。它记录哪些操作被标记为风险标志以及哪些金额/渠道需要关注。这不是评分模型：评分需要单独的方法论、可解释性、质量控制和法律审查。这里的risk_flag是SDD流程的信号，而不是产品决策。
数据集市的粒度（grain）：对于操作级集市，粒度严格固定：每个transaction_id一行。transaction_id not null和unique是必须的约束条件。如果集市按客户或天聚合，则是另一个数据产品，具有不同的规范和不同的测试。
Risk flag作为来源信号：在教学项目中，risk_flag被解释为stg_card_transactions的教学性来源信号，而不是分析模型的结果。学生不应自行定义风险（例如「金额高于阈值」）并在没有规范的情况下将其应用于SQL。
集市的完整性 vs 过滤器risk flag = true：仅当规范明确说明「集市仅包含风险事件」时，才允许使用where risk_flag = true过滤器。如果消费者期望所有具有风险标志的操作，则此过滤器会破坏完整性。这是一个典型的陷阱：代理「简化」SQL而没有验证契约。
大额阈值作为教学规则：mart_payment_risk_signals中的大额阈值是教学规则，而不是银行事实。如果阈值仅记录在SQL中，审核员将无法理解它是临时简化、产品要求还是代理的猜测。阈值应出现在规范、验证备注和审核员报告中。
PII保护：在风险集市中，不应出现直接的PII（姓名、护照、完整卡号）。允许使用聚合、掩码、标识符，但不允许使用原始个人数据。此要求必须在验证事实中进行检查。
没有风险标志的操作：未经明确规范，不得从上游层删除没有risk_flag的操作。如果mart中只有部分交易，审核员必须看到排除原因。
集市备注（最小输出）：分析结束后，代理会创建一个包含六个字段的markdown备注：集市、粒度、风险标志来源、包含的行、排除的行、验证事实、审核员的人工问题。这有助于将事实与猜测分开。
Qwen查询用于sdd分析：标准化提示：「阅读stg_card_transactions、mart_payment_risk_signals和specs。确定粒度、包含哪些操作、排除哪些操作以及风险集市需要哪些验证事实。不要修改文件。」——将代理的角色固定为观察者而非编辑者。
操作级与客户级集市的区别：这是两个不同的数据产品。操作级集市：键是transaction_id，客户重复，测试是id的唯一性和非空。客户级集市：键是customer_id，按金额/渠道聚合，测试是不同的完整性和一致性。一个的SQL不能悄悄地替换为另一个。
重要日期: 本卷的教学上下文：集市在学习SDD的背景下讨论，而非实际生产环境。因此，所有「规则」（金额阈值、risk_flag的解释）都是教学构造。
粒度固定时刻：粒度的决定在SQL编写之前的规范阶段做出。事后更改粒度对消费者来说是破坏性变更。
阈值出现在工件中的时刻：大额阈值应同时记录在specs、验证备注和审核员报告中，以便未来作者可以在没有隐藏漂移的情况下替换方法论。
练习题: 名称: 练习1. 按模板填写集市备注
问题: 给定一个描述mart_payment_risk_signals的specs文件和一个使用过滤器WHERE risk_flag = true AND amount > 10000的数据集市SQL脚本。在不修改文件的情况下，填写markdown模板：集市、粒度、风险标志来源、包含的行、排除的行、验证事实、审核员的人工问题。解释当前SQL存在哪些风险。
解决方案: 步骤1. 集市：mart_payment_risk_signals。步骤2. 粒度：每个transaction_id一行（如果规范确认）。步骤3. 风险标志来源：stg_card_transactions.risk_flag，被解释为来源信号。步骤4. 包含的行：当前SQL中risk_flag = true且amount > 10000的操作。步骤5. 排除的行：所有risk_flag = false或amount <= 10000的操作——如果规范要求所有具有风险标志的操作，则可能是破坏性排除。步骤6. 验证事实：transaction_id唯一且非空；amount非空；阈值10000记录在specs中；不存在PII。步骤7. 审核员的人工问题：为什么选择阈值10000？这是产品要求还是代理的猜测？是否所有具有风险标志的操作都应包含在集市中？金额过滤器在specs的哪里记录？
难度: 中级
名称: 练习2. 比较两种粒度变体
问题: 描述风险数据集市的两种变体：操作级和客户级。对于每种，指出粒度、消费者、关键字段以及为什么一种变体的SQL不能悄悄地替换为另一种。
解决方案: 变体A——操作级：粒度 = 每个transaction_id一行。键是transaction_id。消费者：欺诈监控团队，需要查看每个被标记的操作。字段：transaction_id、customer_id（重复）、amount、channel、risk_flag、threshold_marker。变体B——客户级：粒度 = 每个customer_id一行，每个周期。键是customer_id + period。消费者：产品分析，需要按「客户有多少风险操作以及金额是多少」的切片。字段：customer_id、period、ops_count、total_risk_amount、channels_set。一个变体的SQL不能悄悄地替换为另一个：消费者契约会改变，需要不同的完整性检查（transaction_id唯一性 vs customer_id+period对唯一性），与来源的不同JOIN，以及不同的重复计算保护。
难度: 中级
名称: 练习3. 查找典型错误
问题: 在以下数据集市描述中找到典型错误：「mart_payment_risk_signals是一个评分模型，它根据risk_flag和超过50000的金额决定是否阻止操作。集市仅包含我们的模型认为是风险的操作。」重新表述该描述，使其符合观察型数据集市的SDD契约。
解决方案: 步骤1. 错误#1：集市被称为「评分模型」。mart_payment_risk_signals集市是一个观察层，而不是评分。步骤2. 错误#2：「决定阻止」。阻止决策是产品/风险流程，而不是集市的功能。步骤3. 错误#3：「根据risk_flag和金额超过50000」——这是由代理组合的条件，未记录在specs中。步骤4. 错误#4：「包含我们的模型认为是风险的操作」——如果规范要求所有具有风险标志的操作，过滤器会破坏完整性。正确的表述：「mart_payment_risk_signals是一个观察型集市，粒度为每个transaction_id一行。包含来自stg_card_transactions的具有风险标志的操作；分别标记超过记录在specs中的教学阈值的操作。不是评分，不做风险决策。不包含PII。」
难度: 中级
名称: 练习4. 起草审核员的人工问题
问题: 给定集市的SQL：SELECT transaction_id, customer_id_hash, amount, channel FROM stg_card_transactions WHERE risk_flag = true。起草不少于五个审核员的人工问题，这些问题应包含在集市备注中。
解决方案: 问题1. risk_flag = true过滤器是规范要求还是SQL作者的猜测？如果规范要求所有具有风险标志的操作，过滤器会破坏契约。问题2. customer_id究竟是如何哈希的，从PII策略的角度来看是否允许？问题3. 为什么选择transaction_id、customer_id_hash、amount、channel这些字段？这对集市的消费者足够吗？问题4. 源中是否存在risk_flag IS NULL的操作，它们应该归入哪里？问题5. 大额的教学阈值在哪里记录——在specs中、代码中还是哪里？问题6（可选）。为什么集市的粒度是操作而不是客户，这个选择是否与消费者契约一致？
难度: 中级
案例研究: 名称: 案例1. 操作级粒度到客户级粒度的静默替换
场景: 在一家金融科技初创公司，分析团队要求AI代理「简化」风险信号数据集市的SQL。代理看到消费者需要按客户的切片，便用GROUP BY customer_id替换了SELECT，删除了transaction_id的唯一性。SQL缩短了30行，通过了代码检查器审查，并在生产环境中以相同的名称mart_payment_risk_signals发布。
挑战: 欺诈监控消费者发现，如果客户在一天内执行了多笔风险交易，相同的操作开始「丢失」：在集中汇总了金额，但单个交易不再可区分。唯一键也损坏了：出现了不符合原始粒度契约的行。事件调查耗时2个工作日，季度报告不得不重新计算。
解决方案: 团队引入了一条硬性规则：操作级集市和客户级集市是具有不同名称和不同规范的不同数据产品。在specs中明确记录了粒度和必填字段列表。在备注模板中添加了项目「粒度是否相对于规范发生了变化？」作为审核员的强制性人工问题。还引入了测试契约：对于操作级mart，CI检查COUNT(*)等于源中DISTINCT transaction_id的计数。
结果: 实施规则后，季度内没有再次出现粒度混合的情况。集市SQL审查时间因标准化的备注模板而缩短。团队能够诚实地维护两个数据产品：mart_payment_risk_signals_ops（操作级）和mart_customer_risk_profile（客户级）。
经验教训: 粒度是数据集市的契约，而不是SQL的优化细节。
更短的SQL并不意味着更正确的SQL。
键的唯一性测试是操作级集市的必需约束条件。
集市备注模板应明确将粒度作为单独的字段。
相关概念: 数据集市的粒度（grain）
操作级与客户级集市的区别
集市备注（最小输出）
集市的完整性 vs 过滤器risk_flag = true
名称: 案例2. 仅记录在SQL中的大额阈值
场景: 在银行数据湖中，出现了mart_payment_risk_signals集市，其中硬编码了阈值amount > 50000来标记「大额操作」。阈值是分析师凭直觉选择的，仅记录在SQL中。数据集市的规范提到「标记大额操作」，但没有具体值。
挑战: 半年后，合规团队要求报告：哪些操作被视为大额，以及依据是什么？审核员无法恢复阈值选择的逻辑：这是监管要求、产品限制还是作者的个人猜测？此外，发现另一个部门同时存在阈值为30000的集市，导致报告不一致。
解决方案: 团队引入了一条规则：任何数值规则（阈值、限制、系数）必须作为参数记录在specs中，并指明来源（产品要求、监管要求、教学规则）。集市备注必须包含「阈值及其来源」部分。specs中出现了字段large_amount_threshold = 50000（教学规则，需要产品团队验证）。
结果: 在一个季度内，团队成功将阈值统一为一个值并记录其来源。未来的集市作者可以替换阈值而不会出现隐藏的漂移，因为规则的来源现在已被记录。不同团队的集市之间的差异数量有所减少。
经验教训: SQL中的任何「魔法数字」都是隐藏漂移的潜在来源。
阈值应附有元数据：谁设定的，为什么，何时审查。
集市备注不是代码报告，而是关于作者意图的文件。
在教学项目中，阈值明确标记为教学规则，而不是银行事实。
相关概念: 大额阈值作为教学规则
集市备注（最小输出）
审核员的人工问题
名称: 案例3. 没有规范的risk_flag = true过滤器
场景: 分析师要求AI代理「制作风险操作集市」。代理没有检查规范，在SQL中添加了条件WHERE risk_flag = true。集市开始只包含被来源标记为风险的操作。代码检查器测试通过，集市已发布。
挑战: 两周后发现，审计消费者期望集市包含所有具有风险标志的操作，包括risk_flag具有非二进制值（例如中间状态）的操作。部分审计检查得出了虚假结论「一切正常」，尽管实际上部分操作被过滤器跳过。这只是在处理客户投诉的事件分析时才发现。
解决方案: 团队将Qwen查询正式化为强制性的第一步：「阅读stg_card_transactions、mart_payment_risk_signals和specs。确定粒度、包含哪些操作、排除哪些操作以及风险集市需要哪些验证事实。不要修改文件。」没有这个查询，代理不会开始分析。在specs中还添加了明确的字段included_rows_definition，列出包含/排除的逻辑。
结果: 没有规范说明的risk_flag = true过滤器出现的情况有所减少。在备注模板中添加了单独的行「包含的行」和「排除的行」，在任何SQL更改之前填写。一个季度内没有发生与静默过滤集市相关的事件。
经验教训: 没有与规范核对就「简化」SQL是破坏性变更的常见原因。
源中二进制字段的过滤器需要在specs中明确说明。
标准化的Qwen查询将代理的角色固定为观察者。
集市备注有助于将「包含/排除」分开。
相关概念: 集市的完整性 vs 过滤器risk_flag = true
risk_flag作为来源信号
Qwen查询用于SDD分析
集市备注（最小输出）
学习建议: 从「数据集市代表哪一行？」的问题开始，并在查看SQL之前固定答案。这是最常见的错误来源。
始终将三个工件放在一起：specs、SQL和集市备注。它们之间的任何差异都是审核员人工问题的理由。
制定检查清单：transaction_id唯一/非空？amount非空？risk_flag来源已指定？PII不存在？阈值记录在specs中？
将risk_flag视为来源信号，而不是决策。在教学项目中，这是一个原则性的界限，不允许「改进」。
不要尝试将操作级数据集市的SQL「缩短」为按客户的聚合——这是不同的数据产品。如果消费者需要聚合，请创建具有单独规范的单独集市。
过滤器WHERE risk_flag = true是一个红色标志，如果specs中没有明确的短语「集市仅包含风险事件」。默认情况下，将其视为破坏性变更。
使用备注模板作为纪律：在编写SQL之前填写「包含的行」和「排除的行」字段——这迫使您明确思考契约。
标记SQL中的任何「魔法数字」（阈值、限制、系数）并要求它们出现在specs中。否则半年后没人会记得它们从何而来。
附加资源: 课程教材（第17部分）：第17部分. 支付与风险信号数据集市章节——主要来源，包括粒度、检查内容、错误方法、Qwen查询、最小输出、读者分析、实践、典型错误、检查问题章节。
数据集市规范：mart_payment_risk_signals的specs文件——填写集市备注的必需上下文。
集市SQL：mart_payment_risk_signals文件——分析对象，在教学场景中代理不编辑。
源的Staging层：stg_card_transactions——包含原始的risk_flag作为来源信号。
SDD方法论：Specification-Driven Development——总体框架，其中风险集市是观察工件，而不是决策工件。
集市备注模板：最小输出：集市 / 粒度 / 风险标志来源 / 包含的行 / 排除的行 / 验证事实 / 审核员的人工问题。
章节检查问题：本节末尾的三个问题：(1) 为什么操作级和客户级的集市不能混合；(2) risk_flag = true过滤器何时会破坏契约；(3) 审核员应该检查哪个人工事实。
摘要: 第17部分引入了支付域SDD的关键纪律：mart_payment_risk_signals集市是一个观察层，而不是评分引擎，也不是风险决策的来源。集市的粒度严格固定为「每个transaction_id一行」，任何将其替换为按客户或按天聚合的尝试都是创建一个具有单独规范的新数据产品，而不是「优化」现有的产品。risk_flag被解释为stg_card_transactions的来源信号，而不是产品决策；仅当specs中明确说明时，WHERE risk_flag = true过滤器才被允许。大额阈值是教学规则，必须记录在specs、验证备注和审核员报告中，否则它会成为隐藏的魔法数字。直接的PII不会进入集市。本章的主要技能是填写标准化的集市备注模板（集市 / 粒度 / 风险标志来源 / 包含的行 / 排除的行 / 验证事实 / 审核员的人工问题），不要混淆信号来源的角色与决策的角色，并将观察与结论分开。