Day47-01｜综合训练：Lambda、Kappa与大数据平台选择

一、先看数据处理特征

大数据架构选择不能从流行技术开始，而要分析数据量、速度、种类、实时性、准确性、重算需求和团队能力。批处理擅长全量重算和复杂分析，流处理擅长低延迟响应，湖仓或统一存储负责沉淀原始数据和治理元数据。

二、Lambda与Kappa

Lambda通过批处理层保证准确和重算，通过速度层提供实时结果，再在服务层合并；优点是兼顾准确性和实时性，缺点是两套逻辑重复。Kappa以事件流为核心，通过重放实现重新计算，结构更简单，但对事件留存、回放能力和流处理复杂度要求更高。

数据源 → 事件日志 → 流处理 → 实时服务
         ↘ 批处理/重算 → 统一结果层

三、案例

广告平台需要实时竞价和离线归因，采用Lambda；设备监控只需要持续处理事件且回放能力完善，可采用Kappa。论文应写选择依据、数据质量、幂等、乱序、迟到、回放和成本。

四、练习与答案

问：为什么Kappa仍需要数据重放？答：模型变更、规则修订或故障恢复时，需要从可靠事件日志重新计算。问：Lambda最大代价是什么？答：批处理和流处理逻辑重复，结果口径和维护成本较高。

五、小结

大数据架构题的核心是处理语义与业务时效，而不是简单比较组件数量。

六、数据平台的分层设计

数据平台通常包括采集层、传输层、存储层、计算层、服务层和治理层。采集层处理数据库、日志、设备和文件等来源；传输层保证缓冲、顺序和可靠；存储层保留原始、明细、汇总和主题数据；计算层同时提供批处理和流处理；服务层面向查询、报表、推荐和接口；治理层负责元数据、血缘、质量、权限和成本。

数据架构设计必须区分原始事实和派生结果。原始事件应尽量保留，以便重算和审计；派生宽表可以提升查询效率，但需要记录生成逻辑和版本。迟到数据、重复数据、乱序数据和口径变化要有处理策略，否则实时结果和离线结果会长期不一致。

七、Lambda/Kappa选择矩阵

需要复杂全量重算、历史规则频繁变更且已有成熟批处理体系时，Lambda更合适；数据天然是连续事件、计算逻辑能够流化、事件日志可长期保存和重放时，Kappa更合适。两者都需要数据质量、幂等、监控、回放和成本控制。

八、案例：实时风控平台

交易事件进入日志后，流处理在秒级计算设备、账户和行为特征，风险分数超过阈值时进入人工审核；每日批处理重新计算历史特征，校正迟到和异常数据。若使用Lambda，批层和速算层需要统一口径；若使用Kappa，则把事件日志保留足够长并支持模型回放。选择取决于实时要求、重算复杂度和团队能力。

九、练习与答案

数据湖为什么保留原始数据？便于审计、重算、模型迭代和问题追溯。
如何处理重复事件？使用事件ID、业务键和幂等状态，必要时结合去重窗口。
为什么流处理需要监控水位线和延迟？它们反映事件时间推进和迟到数据状况，直接影响结果完整性。

十、论文落点

大数据论文应同时写数据特征、分层架构、批流处理、质量治理、服务方式、容错和成本，并说明为什么选择某种架构。

十一、数据质量与治理

数据质量至少包括完整性、准确性、一致性、及时性、唯一性和有效性。采集时校验格式和必填字段，传输时记录偏移和校验码，计算时处理迟到和重复，落库时进行分区、去重和血缘登记，服务时标注指标口径和更新时间。质量规则应产生告警和隔离数据，而不是静默丢弃。

元数据管理记录数据集、字段、责任人、来源、更新频率、敏感等级和使用范围；数据血缘帮助定位指标变化和故障；权限控制应区分原始数据、明细数据和汇总数据。大数据平台的规模越大，治理越不能靠个人记忆。

十二、容错和重算

流处理需要保存检查点、消费位点和状态快照，失败后从一致位置恢复；批处理需要任务重跑、分区重算和结果幂等；对象存储和事件日志应设置保留周期和归档策略。重算时要固定代码、模型和参数版本，避免同一批数据每次计算出不同结果却无法解释。

十三、练习

实时指标比离线报表高出20%，请列出排查顺序。参考：确认时间窗口和口径；检查重复、迟到和乱序；比较过滤条件和维表版本；核对时区和时间戳；检查流批代码差异；回放同一批原始事件并对比中间结果。先验证事实，再修改架构。

十四、数据服务与查询架构

不同用户对数据的访问方式不同。实时看板需要低延迟宽表，分析人员需要灵活查询，机器学习需要特征和样本，监管场景需要可追溯原始记录。因此可以采用主题数据集、服务化查询、预聚合、索引和缓存组合，而不是让所有用户直接扫描原始数据。查询层还要控制并发、资源组和成本，避免一个复杂分析拖垮在线服务。

十五、数据安全与生命周期

数据从采集、传输、存储、加工、共享到销毁都要有责任和策略。敏感字段应分类分级，生产和测试环境脱敏，跨域共享经过审批，访问行为可审计；原始数据和派生数据设置不同保存周期，过期数据归档或删除。大数据平台的安全设计必须与权限、血缘和质量治理结合。

模型和算法也属于数据架构的一部分。特征数据要记录生成口径和版本，训练集与线上特征保持一致，模型发布要有灰度、回滚和效果监控；推荐或风控结果出现异常时，应能够追溯输入数据、特征、模型版本和规则。论文中写出这一点，可以把大数据架构从“数据管道”提升到“数据产品和决策闭环”。

只要能把数据特征、处理语义、架构选择、治理责任和验证指标连成闭环，就能覆盖大数据架构题的主要得分点；不要把平台文章写成产品清单。

最后还应写明数据平台的可追溯性：每个指标能够回溯到来源、处理逻辑和版本，并能在异常时重放或修正。

这也是数据治理闭环的终点。

复习时务必结合案例。

并完成习题。

再复盘错题和设计取舍。

形成自己的答案模板。

只要能把数据特征、处理语义、架构选择、治理责任和验证指标连成闭环，就能覆盖大数据架构题的主要得分点；不要把平台文章写成产品清单。

容量规划要估算事件速率、单条大小、保留周期、分区数量、计算并发、存储增长和查询峰值。流处理积压时先区分生产突增、消费者变慢、下游限流和异常重试，再分别扩容、批量化、背压或降级；文章结尾还应说明数据生产方、平台方、业务方和安全方的治理责任。

容量规划要估算事件速率、单条大小、保留周期、分区数量、计算并发、存储增长和查询峰值。流处理积压时先区分生产突增、消费者变慢、下游限流和异常重试，再分别扩容、批量化、背压或降级，不能盲目增加实例。处理语义也要结合业务选择：统计场景可以通过重算纠正，扣款场景必须保证幂等和可核对。

容量规划要估算事件速率、单条大小、保留周期、分区数量、计算并发、存储增长和查询峰值。流处理积压时先区分生产突增、消费者变慢、下游限流和异常重试，再分别扩容、批量化、背压或降级，不能盲目增加实例。