Day38-03｜19.2.2 大数据处理系统架构特征：用平台化能力承载规模与变化
Day38-03｜19.2.2 大数据处理系统架构特征：用平台化能力承载规模与变化
对应教材目录：第 19 章 大数据架构设计理论与实践 → 19.2 大数据处理系统架构分析 → 19.2.2 大数据处理系统架构特征
学习目标：掌握大数据处理系统在分布式、可扩展、批流融合、数据服务、容错、弹性、安全治理和开放生态方面的典型特征；能够从业务场景判断架构特征是否真正适用；能够在案例题中由“特征”落到组件职责和验证指标。
一、从“数据系统”到“数据处理平台”
传统数据系统往往围绕某个应用或某张数据库建设，而大数据处理系统通常要服务多个业务域、多个数据源和多种计算任务。它不仅保存数据，还要提供采集、传输、存储、计算、分析、服务、治理和运营能力。
数据源 -> 接入与消息 -> 存储与目录 -> 批处理/流处理/交互查询
|
v
数据服务、报表、算法、应用
|
安全、质量、血缘、监控、成本“平台化”不是把所有工具堆在一起，而是通过标准接口、资源管理、元数据和治理机制，为不同团队提供可复用、可运营的能力。
二、分布式架构特征
1. 横向扩展
大数据系统通常通过增加普通节点扩展存储和计算能力，而不是无限依赖高性能单机。数据和任务按分区分布到多个节点，系统通过并行处理提升吞吐。
2. 数据分区与并行计算
合理的分区键决定数据是否均匀、查询是否高效和扩展是否顺畅。用户、设备、时间和业务区域都可能成为分区维度，但要防止热点、跨分区查询和数据倾斜。
3. 分布式协调
节点注册、选主、任务调度、锁、租约和元数据管理需要协调机制。协调服务本身必须高可用，不能成为新的单点瓶颈。
4. 分布式带来的代价
分布式并不免费。网络通信、序列化、数据复制、故障检测、重试和一致性维护都会增加复杂度。架构设计要判断哪些数据和计算值得分布式，避免为小规模、强事务场景引入不必要的复杂性。
三、可扩展性与弹性
1. 容量扩展
存储节点、计算节点、消息分区和查询服务应能独立扩展。存储和计算解耦后，可以让存储长期保留数据，让计算按任务弹性使用资源，但需要控制网络和访问成本。
2. 负载弹性
实时流量、批处理任务和临时分析具有不同峰值。平台应支持队列、资源组、优先级、配额、自动扩缩容和隔离，避免高峰期互相争抢。
3. 无状态与有状态服务
查询网关和部分计算服务可以设计成无状态，便于水平扩展；流计算、窗口、用户画像和会话需要状态管理。状态应可持久化、迁移和恢复，不能只依赖单个节点内存。
四、批处理、流处理和批流融合
1. 批处理
批处理适合历史数据、全量重算、复杂关联和周期性报表，优势是吞吐高、结果可重复；缺点是延迟较高。批任务应有分区、增量、重试、检查点和结果校验。
2. 流处理
流处理适合实时监控、告警、风控、推荐和设备状态。需要处理事件时间、窗口、水位线、乱序、迟到、状态和幂等。
3. 批流融合
很多业务既需要实时结果，也需要历史重算。批流融合可以共享数据模型、业务规则和服务接口，避免同一逻辑在批任务和流任务中重复实现并产生口径差异。
实时事件 -> 流计算 -> 实时结果
| |
+--> 原始存储 -------> 历史重算/校正
|
统一数据服务五、数据湖、数据仓库与湖仓特征
1. 数据湖
数据湖通常以低成本存储保存多类型、较原始的数据，支持探索和重处理。优势是灵活和保留原始信息，风险是模式不清、质量不一、权限复杂和数据湖沼泽。
2. 数据仓库
数据仓库强调结构化模型、指标口径、历史分析和稳定报表。优势是查询和治理较成熟，缺点是模式变更和非结构化数据适应性相对弱。
3. 湖仓融合
湖仓试图把低成本存储、开放格式、事务能力、模式治理和分析性能结合起来。无论使用何种产品，核心仍是数据目录、版本、事务、质量、权限、血缘和生命周期。
六、数据处理层次化
大数据平台常分为接入层、存储层、计算层、服务层和治理层。层次化有助于职责分离和技术替换。
接入层：API、文件、CDC、消息、设备流
存储层：对象存储、分布式文件、NoSQL、数仓
计算层：批处理、流处理、SQL、机器学习、图计算
服务层：查询、指标、标签、推荐、实时接口
治理层：目录、质量、血缘、安全、成本、监控层之间应通过数据契约、元数据和服务接口协作，避免上层直接依赖底层内部实现。治理层不能只在项目末尾补上，而应在数据接入和建模时就参与。
七、数据服务化与复用
数据处理结果不应只以离线文件存在，还要通过查询服务、指标服务、标签服务、特征服务和事件服务向业务提供能力。服务化能够隐藏底层存储和计算差异，统一权限、缓存、限流和审计。
1. 结果服务
实时指标、画像和推荐结果可以通过 API 或低延迟存储服务提供。服务要明确新鲜度、准确性、降级和缓存策略。
2. 数据产品
每个重要数据集或指标应有责任人、说明、口径、质量目标、更新频率、权限和下线计划。数据产品化能减少重复开发和口径冲突。
3. 特征服务
机器学习特征需要保证训练和在线推理的一致性，避免离线计算的特征口径与实时服务不同。应管理特征定义、版本、来源、延迟和质量。
八、容错与可恢复特征
大数据系统默认节点会故障，因此要通过副本、检查点、重试、幂等、断点续传和重算保证任务和数据可恢复。
任务执行 -> checkpoint -> 节点故障
|
从最近检查点恢复 + 重放未确认数据
|
幂等提交最终结果重试不能无限进行，应该有次数、退避、死信、人工处理和故障隔离。恢复后要验证结果是否重复、遗漏或乱序，并通过校验和对账确认。
九、开放性和生态兼容
数据平台常整合多种存储、计算、消息和分析工具。开放格式、标准协议、插件机制和 API 有助于减少厂商锁定，但过度追求兼容也会增加测试和治理成本。
架构设计应明确核心稳定接口与内部实现边界，统一数据格式、时间、编码、错误和权限语义。更换底层组件时，要确保数据契约、质量指标和服务 SLA 不被破坏。
十、安全、治理与可观测性内建
1. 安全内建
平台应在接入、存储、计算、服务和导出环节设置身份、权限、加密、脱敏和审计。治理不能只依赖管理员手工操作，要支持策略化和自动化。
2. 数据治理
包括元数据、目录、标准、质量、血缘、主数据、生命周期、责任人和合规。原始数据、加工数据、汇总数据和对外数据应有不同权限。
3. 可观测性
系统监控不应只看节点 CPU 和内存，还要观察数据延迟、积压、质量、任务成功率、状态大小、查询扫描量、成本、权限拒绝和异常导出。
十一、资源和成本治理
平台应支持存储分层、压缩、分区、合并小文件、计算弹性、资源配额、查询限流和生命周期清理。通过项目、租户、任务和数据集标签分摊成本。
成本治理不能损害关键业务。实时风控、交易核算和生产告警可以获得更高优先级，低价值临时查询则应限额或排队。
十二、案例分析：企业统一大数据平台
某集团有电商、物流、会员和生产四类数据源，希望建设统一平台提供实时指标、历史报表和机器学习特征。
架构可按以下方式设计：
- 通过 API、CDC、文件和消息统一接入，建立数据契约和失败重试。
- 原始数据进入统一存储，保留来源、时间、版本和质量信息。
- 实时链路计算告警和核心指标，批处理完成历史汇总和重算。
- 数据仓库提供标准报表，数据湖保留原始和多类型数据，服务层提供指标和特征。
- 通过目录、血缘、质量评分和责任人管理数据产品。
- 平台统一提供租户隔离、行列权限、脱敏、审计、密钥和生命周期。
- 资源层按实时、批处理、交互查询和训练任务隔离并弹性扩展。
- 使用 checkpoint、幂等、对账和恢复演练确保故障后结果可信。
十三、案例题答题模板
遇到“大数据处理系统架构特征”类题目，可以从以下方面展开：
- 分布式和水平扩展：分区、副本、并行和协调。
- 弹性和资源隔离：队列、配额、优先级和自动扩缩容。
- 批流一体：实时、离线、重算和结果统一。
- 数据湖仓：开放存储、事务、模式和数据治理。
- 数据服务化：指标、画像、特征和查询服务。
- 容错和恢复：checkpoint、重试、幂等、重放和对账。
- 安全治理：身份、权限、加密、脱敏、审计和生命周期。
- 可观测与成本：延迟、质量、积压、资源和成本指标。
十四、课后练习
练习 1
大数据平台为什么需要同时支持批处理和流处理？
参考答案：流处理满足实时告警和服务需求，批处理适合历史分析、复杂计算和全量重算。两者结合可以兼顾低延迟、准确性和可修正性。
练习 2
列举大数据系统的六个典型架构特征。
参考答案：分布式、水平扩展、弹性、批流融合、容错可恢复、数据服务化、开放兼容、安全治理、可观测和成本治理，任意六项即可。
练习 3
为什么数据服务层有助于架构演进？
参考答案：它隔离底层存储和计算实现，统一权限、缓存、限流、审计和 SLA；底层组件替换时，上层业务不必直接适配所有变化。
练习 4
论文题：论“企业级大数据平台的架构特征与设计”。
参考答案要点：分布式、弹性、批流融合、湖仓、数据服务、容错、开放生态、安全治理、可观测性、成本管理，并结合数据契约、质量、血缘和实际业务验证。
十五、今日复盘
- 我能否说明大数据架构与普通数据库系统的差异？
- 我是否理解分布式、弹性、批流融合和服务化的关系？
- 我能否解释数据湖、数仓和湖仓的架构重点？
- 我是否把安全、质量、血缘、成本和可观测性作为内建能力？
- 我能否针对不同业务选择合适的架构特征？
- 我能否把“架构特征”写成具体组件职责和验证指标？
大数据处理系统架构的核心结论是：通过分布式和弹性能力承载规模与变化，通过批流融合获得实时性和可修正性，通过数据服务和治理把原始数据转化为可复用的数据产品，并用容错、安全、可观测和成本机制保证平台能够长期运行。
