Day38-01｜19.1 传统数据处理系统存在的问题：为什么架构必须走向大数据

对应教材目录：第 19 章 大数据架构设计理论与实践 → 19.1 传统数据处理系统存在的问题

学习目标：理解传统数据处理系统在数据规模、速度、类型、质量、价值和治理方面的局限；掌握这些问题如何推动分布式存储、流式计算、批处理、数据湖和云原生数据架构发展；能够在案例题中从业务需求反推架构演进方向。

一、传统数据处理系统的基本假设

早期信息系统通常围绕关系数据库、集中式服务器和周期性批处理建设。数据规模相对可控，来源较少，结构稳定，业务主要是交易录入、查询和报表统计。系统可以在夜间将当天数据汇总到数据仓库，再由报表工具生成管理信息。

这种架构在一定范围内非常有效：事务一致性清晰，数据模型容易理解，运维边界相对集中，开发人员可以通过 SQL 完成大量分析工作。但随着互联网、移动终端、物联网和智能化业务发展，传统假设逐渐被打破。

传统假设：数据量可控 + 结构稳定 + 来源有限 + 批处理足够
                           |
                           v
       互联网/物联网/移动化/智能化打破假设
                           |
                           v
规模、速度、类型、质量、价值、治理全面复杂化

大数据架构并不是单纯把数据库换成更大的服务器，而是重新思考数据采集、存储、计算、服务、治理和安全边界。

二、数据规模快速增长

1. 存储容量压力

传统数据库依靠纵向扩展，即提升单机 CPU、内存、磁盘和存储阵列性能。当数据从 GB、TB 增长到 PB 甚至更大时，单机扩容成本急剧增加，设备能力也存在物理上限。全量数据长期保留、备份和副本进一步放大存储成本。

2. 计算规模压力

复杂查询、关联分析、机器学习和图计算会消耗大量 CPU 和内存。集中式数据库在高峰期可能出现资源争用：在线交易影响报表查询，批处理影响实时服务，数据导入影响用户访问。

3. 分布式扩展需求

面对持续增长的数据，系统需要通过分布式存储、水平扩展、数据分片和并行计算增加容量。分布式架构同时带来网络、节点故障、数据一致性、任务调度、数据倾斜和运维复杂度，不能简单认为“加机器”就解决问题。

三、数据产生速度与实时性问题

传统系统擅长按小时、天或月批量处理，但现代业务要求秒级甚至毫秒级响应。支付风控、推荐、设备告警、实时营销、交通监控和交易监测都需要在数据产生后快速计算。

1. 批处理的延迟

批处理要等待数据收集、清洗、装载和调度，无法及时发现异常。对于欺诈检测，第二天才发现异常已经失去阻断价值；对于设备预测性维护，故障发生后再分析也无法预防停机。

2. 流式数据处理

实时场景需要消息队列、事件流、流计算、窗口、状态存储和实时服务。架构需要处理乱序、重复、迟到、断点恢复、背压和状态一致性。

事件产生 -> 消息接入 -> 分区与持久化 -> 流式计算 -> 实时存储/告警/服务
       \-----------------------------------------------> 离线归档

实时处理并不意味着所有数据都必须秒级计算。架构师应按业务价值区分实时、准实时和离线链路，避免为了追求低延迟而显著增加成本和复杂度。

四、数据类型越来越复杂

传统关系数据库主要处理结构化表格数据，但现代系统还产生文本、图片、音频、视频、日志、传感器序列、网络流量和半结构化事件。

1. 结构化数据

结构化数据字段和关系相对稳定，适合关系数据库、数据仓库和 SQL 分析。但在业务快速变化时，频繁修改表结构可能影响生产和下游系统。

2. 半结构化数据

JSON、XML、日志和消息通常具有一定结构但字段可变。传统固定模式装载会导致模式变更频繁、空字段增多和数据丢失。需要采用模式注册、兼容性规则和灵活存储。

3. 非结构化数据

文档、图片、视频和音频无法直接用二维表表达，通常需要对象存储、内容索引、元数据管理和专用分析能力。文件本身与元数据、权限、版本和生命周期必须协同管理。

五、数据来源异构和集成困难

企业数据可能来自 ERP、CRM、生产系统、移动端、第三方平台、传感器和合作伙伴。不同来源使用不同编码、时间格式、主键、业务口径和更新频率。

1. 数据语义不一致

不同系统对“客户”“订单”“收入”和“有效用户”的定义可能不同。简单拼接表格不能得到可信指标，必须建立主数据、数据标准和指标口径。

2. 数据同步不一致

批量 ETL 可能产生延迟，实时 CDC 可能出现重复、乱序和删除捕获问题。跨系统同步要明确源系统、目标系统、延迟、冲突处理、重试和对账规则。

3. 接入方式多样

传统数据库可通过批量导出，现代服务可能通过 API、消息、日志和流式协议提供数据。采集平台需要统一连接器、断点续传、限流、格式校验和失败重试。

六、数据质量问题

数据量增加并不自动产生价值，低质量数据反而会放大错误决策。常见质量问题包括缺失、重复、错误、过期、冲突、口径不一致和异常值。

数据采集 -> 校验 -> 清洗 -> 标准化 -> 质量评分 -> 追踪与修复

质量管理应明确规则、责任人、监控指标和修复流程。例如客户手机号格式错误可以在接入时拦截；历史数据中的重复客户需要主数据匹配；传感器异常值需要结合设备状态判断，不能简单删除。

七、传统架构中的性能与资源争用

1. OLTP 与 OLAP 冲突

在线事务处理强调短事务、并发和一致性；在线分析处理强调大范围扫描、聚合和复杂关联。两者共享同一数据库会导致锁竞争、缓存污染、IO 争用和响应时间抖动。

2. 报表和临时查询风险

业务人员的临时查询可能扫描大表，影响所有在线交易。传统系统常通过增加索引和定时汇总缓解，但索引和汇总也会增加写入成本和维护复杂度。

3. 计算与存储耦合

集中式系统通常把计算和存储绑在一起，资源不能按业务需求独立扩展。数据湖、分布式计算和云平台可以让存储与计算分离，按任务弹性使用资源，但需要治理数据格式、权限和生命周期。

八、可靠性、可扩展性和故障影响

集中式系统的某个关键节点故障可能影响所有业务。硬件升级、存储阵列故障、数据库主备切换和批处理失败都会造成大范围中断。

分布式系统可以通过副本、分区和弹性节点降低单点影响，但引入了新的故障模式：网络分区、节点失联、数据倾斜、部分任务失败、版本不兼容和一致性降低。架构演进不是从“没有故障”变成“不会故障”，而是把故障影响范围缩小，并增强发现和恢复能力。

九、数据安全和隐私治理不足

传统数据平台经常出现共享账号、全库权限、备份明文、测试使用生产数据、日志记录敏感字段和数据导出不可追踪等问题。数据集中后，一次账号泄露可能造成大规模影响。

大数据环境还会产生更多副本：原始数据、清洗数据、特征数据、缓存、搜索索引、报表和模型训练集。安全治理需要覆盖数据分级、访问控制、行列权限、脱敏、加密、密钥、审计、血缘和销毁，而不能只保护主数据库。

十、数据价值发现能力不足

传统系统通常围绕已知报表和固定需求建设，面对新业务问题需要先改表、建 ETL、建数仓和开发报表，周期较长。大量半结构化和非结构化数据被丢弃，因为系统没有低成本保存和分析能力。

大数据架构强调先保存原始数据和元数据，再通过批处理、流处理、交互式查询、机器学习和图分析挖掘价值。但“先存再说”也会导致数据湖沼泽，因此必须建立目录、标准、质量、权限和生命周期治理。

十一、传统数据处理系统问题总结

十二、案例分析：传统零售数据平台升级

某零售企业使用集中式数据库保存订单、会员和库存，每晚生成报表。随着门店、移动端和线上商城增加，出现报表影响交易、库存更新延迟、会员数据重复、促销效果无法实时分析和数据泄露风险。

改造思路如下：

1. 在线交易库继续承担核心事务，分析任务迁移到独立的数据处理平台。
2. 通过 CDC 和消息流采集订单、库存和会员变化，实时链路用于库存告警和促销监测。
3. 原始事件进入对象存储或数据湖，经过清洗、标准化和质量校验后进入分析层。
4. 建立会员、商品、门店和订单主数据，统一编码和指标口径。
5. 通过批处理完成历史汇总，通过流计算生成实时指标，避免所有场景都强行实时化。
6. 敏感会员数据分级、脱敏和加密，分析人员只能访问必要字段。
7. 通过目录、血缘、质量评分、生命周期和访问审计避免数据湖沼泽。
8. 以对账、延迟、数据质量和报表准确率验证改造效果。

十三、案例题答题模板

面对“传统系统无法支撑大数据需求”的题目，可以按以下方式回答：

1. 从数据规模、速度、类型、来源、质量和价值说明问题。
2. 拆分在线交易、实时处理、离线分析和数据服务边界。
3. 设计采集、消息、存储、批处理、流处理和查询服务。
4. 说明数据标准、主数据、质量、血缘、权限和生命周期治理。
5. 说明副本、备份、容错、监控、对账和恢复机制。
6. 说明安全、实时性、成本、复杂度和一致性的权衡。
7. 给出数据延迟、吞吐、质量、可用性和恢复等验证指标。

十四、课后练习

练习 1

传统集中式数据库为什么难以同时满足在线交易和复杂分析？

参考答案：两类负载对并发、事务、扫描、缓存和 IO 的需求不同，共享资源会产生锁竞争和性能抖动。通常需要读写分离、数据仓库、分布式计算或独立分析平台解耦。

练习 2

列举大数据架构需要解决的六类问题。

参考答案：规模、速度、类型、来源、质量、价值、可靠性、安全和治理，任意六项并说明即可。

练习 3

为什么“把所有数据直接放进数据湖”可能产生数据湖沼泽？

参考答案：没有目录、标准、质量、责任人、权限、血缘和生命周期的数据会难以发现、理解和使用，重复、过期和敏感数据也会增加治理和安全风险。

练习 4

论文题：论“传统数据平台向大数据平台演进的架构设计”。

参考答案要点：分析传统系统的规模、实时性、异构和治理问题；设计采集、消息、湖仓、批流计算、服务化、数据质量、主数据、权限、审计和灾备；说明分阶段迁移、双写对账和性能成本权衡。

十五、今日复盘

• 我能否从六个以上维度说明传统数据处理系统的问题？
• 我是否能区分 OLTP、OLAP、批处理和流处理？
• 我能否解释数据湖为什么需要治理？
• 我是否考虑数据副本、质量、安全和生命周期？
• 我能否根据业务实时性选择批、流或混合处理？
• 我能否写出传统平台向大数据平台的演进路径？

传统数据处理系统问题的核心结论是：当数据规模、速度、类型和业务价值超过集中式批处理的能力时，系统必须走向分布式、实时化和平台化。但架构升级不能只增加存储和计算组件，还必须同步建立数据标准、质量、安全、血缘、生命周期和可验证的业务价值闭环。