一、大数据全景概述：发展史、应用场景与架构对比
各位同学，咱们今天聊点实在的。大数据这个概念，说实话已经被炒了十几年了。我最早接触大数据是在2012年，那时候Hadoop刚火起来，公司里能写个MapReduce程序就算是大神了。现在回头看，那会儿的数据量，搁今天也就是个零头。
1.1 大数据发展史：从数据库到数据湖
大数据的发展，我把它分成三个阶段：
- 萌芽期（2000-2010）：传统数据库撑不住了。我记得2008年在一家电商公司，单表数据到了几千万条，查询就开始慢得像蜗牛。那时候大家开始研究分布式存储，Google的三驾马车（GFS、MapReduce、BigTable）成了圣经。
- 爆发期（2010-2018）：Hadoop生态崛起。HDFS、Hive、HBase、Spark轮番登场。我2014年参与过一个金融项目，每天处理200GB的日志数据，用Hive跑个报表要半小时，但大家已经觉得很牛了。
- 成熟期（2018至今）：云原生+实时化。Flink、Kafka、数据湖（Delta Lake、Iceberg）成了标配。说白了，现在的大数据架构，追求的是「实时、弹性、统一」。
核心观点：大数据的发展，本质上是「存储成本下降」和「计算能力提升」共同推动的。你想想看，2008年1TB硬盘要多少钱？现在呢？
1.2 核心应用场景：电商、金融、物联网
我这些年做过的项目，基本覆盖了这三个领域。咱们一个一个说。
电商场景：用户画像与实时推荐
电商是大数据最成熟的应用场景。我在2016年帮某电商平台做过用户画像系统，每天处理的数据量大概在5TB左右。核心需求就两个：
- 实时推荐：用户点击一个商品，3秒内要推荐出相关商品。背后是Flink实时计算用户行为序列，再结合离线训练的模型。
- 精准营销：根据用户的历史购买、浏览、收藏行为，打上几百个标签。比如「高消费力」、「母婴偏好」、「价格敏感型」。
避坑指南：我曾经在电商项目中踩过一个坑——标签更新太频繁导致存储爆炸。后来我学乖了，离线标签每天更新一次，实时标签只保留最近7天。嗯，这里要注意，不是所有数据都需要实时。
金融场景：风控与反欺诈
金融行业对数据的要求就一个字：准。我2018年参与过一个银行的反欺诈系统，数据量不大（每天几百GB），但延迟要求极高——交易发生后100毫秒内要给出风险评分。
- 实时风控：用Flink CEP（复杂事件处理）检测异常交易模式。比如「短时间内多次小额转账」、「异地登录后大额消费」。
- 离线分析：用Spark MLlib训练信用评分模型，数据量在PB级别。
注意：金融场景的数据合规性要求极高。我曾经因为没处理好数据脱敏，被合规部门找去喝茶。个人建议：所有敏感字段（身份证、手机号）在入湖前必须加密或脱敏。
物联网场景：海量时序数据
物联网的数据量，说实话是最吓人的。我去年帮一家智能工厂做过项目，10万个传感器，每秒钟上报一次数据，一天就是8.6亿条记录。数据量级直接到了PB级别。
- 时序数据库：用InfluxDB或TimescaleDB存储传感器数据。
- 流式计算：用Flink做实时告警，比如温度超过阈值立刻通知。
- 批处理：用Spark做设备健康度分析，比如预测哪个传感器快坏了。
1.3 数据量级概念：TB、PB、EB
很多同学对数据量级没概念。我举个例子：
| 单位 | 大小 | 类比 |
|---|---|---|
| 1 TB | 1024 GB | 约等于50万部高清电影 |
| 1 PB | 1024 TB | 约等于5亿部高清电影 |
| 1 EB | 1024 PB | 约等于5000亿部高清电影 |
你想想看，一个中型互联网公司，每天产生的日志数据大概在10-50TB。一年下来就是几个PB。我2019年做过一个项目，光存储集群就用了200台服务器，总容量10PB。那会儿每天最怕的就是磁盘故障——200块硬盘，每天坏一块是常态。
个人经验：数据量到了PB级别，传统的「存算一体」架构就不行了。我建议采用存算分离架构，比如HDFS只存数据，计算用Spark或Flink弹性扩缩容。这样成本能降30%以上。
1.4 Lambda架构 vs Kappa架构
这两个架构，说白了就是「批流一体」的两种实现方式。我当年在选型时也纠结了很久。
Lambda架构：批处理+流处理两条路
Lambda架构的核心思想是：用批处理保证数据的准确性，用流处理保证数据的实时性。两条路径最终合并输出。
- 批处理层：用Spark或Hive处理全量数据，生成离线报表和模型。
- 流处理层：用Flink或Storm处理实时数据，生成实时指标。
- 服务层：合并批处理和流处理的结果，对外提供服务。
避坑指南：我曾经在Lambda架构中踩过一个坑——批处理和流处理的逻辑不一致，导致同一指标两个结果。后来我强制要求：批处理和流处理必须共用同一套业务逻辑代码。嗯，这里要注意，代码复用是Lambda架构的关键。
Kappa架构：只用流处理一条路
Kappa架构更激进：只用流处理，所有数据都走实时管道。如果需要重新计算，就重新消费Kafka里的历史数据。
- 数据源：所有数据进入Kafka。
- 流处理：Flink消费Kafka数据，实时计算。
- 结果存储：计算结果写入数据库或数据湖。
注意：Kappa架构对Kafka的存储能力要求极高。我建议Kafka的数据保留时间至少7天，方便回溯。另外，Flink的状态后端建议用RocksDB，不然内存撑不住。
如何选择？
我个人习惯这样选：
- 数据量大、对准确性要求极高（比如金融风控）：选Lambda。批处理做全量校验，流处理做实时告警。
- 数据量大、对实时性要求极高（比如物联网）：选Kappa。省去批处理那套逻辑，架构更简单。
- 中小型项目：我建议直接上Kappa。Lambda的维护成本太高，两个管道出问题排查起来很痛苦。
总结：没有完美的架构，只有适合的架构。我见过很多团队盲目追求「实时」，结果搞出一堆bug。记住：先保证数据准确，再追求实时。
好了，这一章的内容就到这里。下一章咱们聊聊「数据采集与传输」——Kafka到底该怎么用，才能扛住百万级QPS。