2. 平台总体架构设计：分层架构与技术选型原则
好，咱们直接进入正题。环境大数据平台，说白了就是把天上飞的、地上跑的、水里流的各种环境数据，全都收上来、存起来、算明白，最后变成能用的东西。那这个平台到底长什么样？我习惯从架构说起。
2.1 分层架构：四层模型
我个人习惯把平台拆成四层。为什么是四层？你想想看，数据从采集到应用，中间要经过多少道工序？每一道工序的职责、技术栈、运维方式都不一样。硬塞在一起，后期维护就是灾难。我在项目中遇到过好几次，就是因为早期没分层，改一个采集逻辑把整个计算集群搞挂了。
这四层分别是：
- 数据采集层：负责从各种源头把数据捞上来。
- 数据存储层：把捞上来的数据找个地方安顿好。
- 数据计算层：对存储的数据进行加工、分析、挖掘。
- 数据应用层：把计算结果以各种形式呈现给用户。
嗯，这里要注意，层与层之间是解耦的。采集层不知道存储层用的是MySQL还是HBase，计算层也不关心应用层是Web页面还是大屏。这样每一层都可以独立演进、独立扩缩容。
核心原则：每一层只做一件事，并且把这件事做好。层间通过标准接口通信，比如Kafka、API网关。
下面这张图，是我画的一个简化版架构图，你可以直观感受一下数据是怎么流动的。
2.2 各层详解
2.2.1 数据采集层
这一层是平台的入口。环境数据源五花八门，有传感器每隔几秒上报的实时数据，有环保局每天导出的Excel文件，还有卫星遥感影像这种大块头。采集层要做的就是把这些不同格式、不同频率的数据，统一接入到平台里。
我常用的技术栈是 Flume + Kafka。Flume负责从各种源头拉数据，Kafka作为缓冲层，削峰填谷。举个例子，某个监测站突然上报频率从1分钟一次变成1秒一次，如果没有Kafka缓冲，后面的存储和计算层直接就被冲垮了。我曾经遇到过这种情况，当时整个集群的CPU直接飙到100%，报警电话被打爆了。
小技巧：采集层一定要做数据校验。比如传感器上报的温度是-999，这明显是异常值。在入口处就过滤掉，别让脏数据污染后面的层。
2.2.2 数据存储层
存储层是平台的基石。环境数据有几个特点：数据量大（一个城市一天可能产生TB级数据）、类型多（结构化、半结构化、非结构化）、时效性强（有些数据需要快速查询）。
所以，单一数据库搞不定。我一般会采用混合存储方案：
| 数据类型 | 存储方案 | 适用场景 |
|---|---|---|
| 原始传感器数据（时序） | HBase 或 InfluxDB | 高并发写入，按时间范围查询 |
| 结构化业务数据 | MySQL 或 PostgreSQL | 用户信息、设备台账、配置信息 |
| 文件/影像数据 | HDFS 或 MinIO | 卫星图、报告PDF、视频监控 |
| 中间计算结果 | Redis | 缓存、实时排行榜、计数器 |
2.2.3 数据计算层
计算层是平台的大脑。数据存好了，怎么用？靠计算层。环境大数据场景下，计算任务分两类：
- 实时计算：比如空气质量指数（AQI）的分钟级更新，一旦超标立即报警。我用的是 Flink，它的状态管理和事件时间处理能力很强。
- 离线计算：比如月度环境质量报告、年度趋势分析。这种任务数据量大，对实时性要求不高，用 Spark 或者 Hive 跑批处理就行。
嗯，这里有个坑。实时计算和离线计算的计算逻辑一定要统一。我见过一个项目，实时算出来的AQI和离线算出来的对不上，业务方天天扯皮。后来我们统一了计算模型，两边用同一套代码，问题才解决。
2.2.4 数据应用层
这一层是面向用户的。说白了，就是把计算层的结果，变成业务人员能看懂的东西。常见的应用形式有：
- 大屏展示：实时显示全市空气质量、水质状况、污染源分布。
- 报表系统：生成日报、周报、月报，支持导出PDF。
- 预警平台：当某个指标超过阈值时，自动发送短信、邮件通知。
- 数据API：对外提供标准接口，供第三方系统调用。
2.3 技术选型原则
技术选型是个头疼事。市面上的组件太多了，选错了后面全是坑。我总结了三句话：开源优先、高可用、可扩展。
2.3.1 开源优先
为什么？因为环境大数据平台通常预算有限，而且需要定制化开发。商业软件虽然省事，但一旦遇到特殊需求，你连改代码的权限都没有。开源组件社区活跃，遇到问题百度一下，基本都能找到解决方案。
我个人的技术栈偏好：
- 消息队列：Kafka（开源，吞吐量高）
- 计算引擎：Spark / Flink（开源，生态完善）
- 存储：HDFS / HBase / MySQL（开源，稳定）
- 调度：Apache DolphinScheduler（开源，可视化DAG）
注意：开源不等于免费。运维成本、学习成本、二次开发成本都要算进去。选型时要做个TCO（总拥有成本）评估。
2.3.2 高可用
环境数据是7x24小时不间断产生的。平台不能宕机，哪怕只宕5分钟，中间的数据就丢了。高可用怎么做？
- 组件本身的高可用：比如Kafka的副本机制、HDFS的NameNode HA、Spark的Master HA。
- 架构层面的冗余：关键节点至少部署两台，避免单点故障。
- 数据备份：定期做快照，万一数据损坏，能快速恢复。
我曾经吃过亏。有一次HDFS的NameNode挂了，因为没配HA，整个集群停了6个小时。从那以后，我所有项目都强制要求关键组件必须配HA。
2.3.3 可扩展
环境数据量是增长的。今天可能只有100个监测站，明天可能就变成1000个。平台必须能平滑扩展，不能因为数据量大了就推倒重来。
可扩展体现在两个方面：
- 水平扩展：加机器就能提升性能。比如HDFS加DataNode，Kafka加Broker。
- 功能扩展：新增一种数据类型或计算逻辑时，不需要修改现有代码。这要求层间接口设计得足够通用。
总结一下：分层架构是骨架，技术选型是血肉。骨架搭好了，血肉选对了，这个平台才能跑得稳、跑得久。别贪图一时的方便，把所有的东西都揉在一起。后期维护的时候，你会感谢当初分层的自己。
公众号:蓝海资料掘金营，微信deep3321