订单表涨到几千万行，一条 GROUP BY 查询要跑几分钟，老板还要看实时的当日成交大屏。到这一步，单机数据库撑不住了，该上大数据处理这套东西了。先别急着装组件，把整条链路搞清楚再动手。

先认清问题特征

大数据的几个 V 说的是：体量大到 TB、PB 级，来源杂，日志、点击流、传感器、订单库都有，增长快，价值密度低。对应到工程上就一个矛盾：数据量和一台机器的计算、存储能力不匹配，所以核心思路永远是分而治之，把任务拆到一群机器上。

通用五步流程

  • 采集：日志用 Flume 或脚本收集，业务埋点数据先进 Kafka 这类消息队列削峰。
  • 存储：底层放 HDFS 或对象存储，原始数据先落地，后面算错了还能重算。
  • 计算：离线任务用 Spark，要求秒级延迟的实时任务用 Flink，一个管批、一个管流。
  • 分析：数据整理成分层的数据仓库，用 Hive 写 SQL 做主题汇总，追求亚秒响应再上 ClickHouse 这类 OLAP 引擎。
  • 可视化：结果接进 BI 工具或大屏，报表要能下钻，不是只贴个总数。

分层常用 ODS、DWD、DWS、ADS 四层的叫法，贴源、明细、汇总、应用各管一段，报表查汇总层，要回溯明细就往下钻，层次定清楚，治理就成功了一半。

新手最常见的三个坑

一是一上来搭全家桶，Hadoop、Spark、Flink、Kafka 全装，最后没人会运维。先解决当前瓶颈，数据量不大时 MySQL 加定时任务也许就够了。二是数据不分层，所有任务直接扫原始表，一个任务改逻辑全链路重跑。三是只建管道不做治理，字段口径没对齐，同一指标两个部门算出两个数。

离线和实时怎么选

判断标准是业务能接受多久延迟。T 加 1 的经营日报，离线批处理便宜又稳；风控和监控告警必须秒级，才值得为流计算付出更高的开发和运维成本。多数中小团队的合理路线是先批后流。

给个实在的收尾：大数据处理的价值在回答业务问题，不在组件数量。五步里最值得投入的是存储分层和数据治理，计算引擎换得再勤，底子乱了照样出不了可信的数。