聊大数据，很多人第一反应是Hadoop、Spark、Flink这些名词，再往后就说不清它们到底是干什么的、彼此之间什么关系了。我见过不少刚入行的朋友，简历上写“熟悉大数据技术栈”，但真要让他讲清楚一条数据从业务库到报表平台到底经历了什么，讲着讲着自己就乱了。这篇文章我就从一个实际落地过的项目视角，把大数据核心技术的骨架拆开讲一遍，从存储、计算到调度、查询，把每一层解决什么问题、为什么需要它、实际用的时候有哪些坑讲清楚。想系统入门或者准备面试梳理技术体系的，这篇应该能帮你把线串起来。
1. 大数据技术到底在解决什么问题
1.1 先想清楚：大数据的“大”指的是什么
很多教程一上来就堆名词，HDFS、MapReduce、Hive、Spark、Flink、Kafka，看得人头晕。但我觉得理解大数据，得先回到最朴素的问题：数据量大到一定程度之后，传统的方式到底哪里不行了？
举一个我做过的例子。某个业务系统的MySQL库，单表到了几亿行，做一次跨天汇总查询，慢的时候要跑几分钟甚至更久。这时候你加索引、换SSD、做主从分离，折腾一圈，发现也就那样了。为什么？因为单机的能力是有物理上限的，磁盘IO带宽、内存容量、CPU核数，都被摊薄在高并发查询里。大数据技术的核心思路其实特别朴素：一台机器扛不住，那就让一百台机器一起扛。但这句“一起扛”背后，牵扯出一大堆难题——数据怎么分到这么多台机器上？某台机器挂了怎么办？任务怎么拆成这么多台机器并行跑？跑完的结果怎么汇总？这些问题的答案，拼起来就是所谓的大数据技术栈。
所以大数据不是什么玄学，本质就是一套“在多台普通机器上处理海量数据”的工程方法论。理解了这一点，你再看那些组件，就像看一个大型工厂的各个车间一样：有负责原料仓储的，有负责流水线加工的，有负责调度排产的，有负责质检出报告的。
1.2 大数据核心技术的分层逻辑
做大数据架构设计，我心里一直有一张分层图。数据从产生到产生价值，基本会经过四个环节：数据接入、数据存储、数据计算、数据查询与可视化。每一层都有对应的核心组件，而且每一层都在解决上一层的遗留问题。
数据接入层，解决的是“数据怎么稳定地进来”的问题。业务库的binlog、服务器的日志、App埋点上报的JSON，这些数据来源五花八门，速率也不一样。接入口的数据积压了不行，丢了更不行。所以有了消息队列，充当一个削峰填谷的缓冲池。
数据存储层，解决的是“数据放在哪”的问题。PB级的数据不可能塞进MySQL，得有一种能横跨成百上千台机器、还能容忍机器故障的存储系统。这就得说HDFS，它把大文件切成一块块小副本散落在集群里，任何一台机器坏了都不影响整体数据可用性。
数据计算层，解决的是“怎么处理这些数据”的问题。早期的MapReduce能算，但太慢；后来来了Spark，把中间结果放内存，速度快了一个量级；再后来业务要实时看数据，Flink又把“批处理”和“流处理”统一了。这一层是技术含量最高、也是最容易让人迷失的地方。
数据查询层，解决的是“数据怎么被人用起来”的问题。底层文件格式对分析师太不友好了，于是有了SQL引擎，几百年积累的SQL功力不用废掉，一条SELECT扔出去，底层再复杂的分布式计算都被封装了。
你会发现，大数据技术栈不是凭空造出来的，而是被业务需求一层一层逼出来的。这也是为什么我建议学习的时候别死记组件名，先搞懂这条链路上每环的职责。
2. 存储层：HDFS与数据湖的底层逻辑
2.1 HDFS的设计哲学与核心机制
HDFS全称是Hadoop Distributed File System，它是整个大数据生态的地基。设计目标一句话就能概括：把超大文件可靠地存到一群廉价服务器上。它怎么做到的呢？核心是三个机制：块存储、副本机制、元数据管理。
文件被切成固定大小的块，默认128MB，每块在集群里存多份副本，默认3份。3份副本不是放在同一台机器上，而是分散在不同节点，甚至跨机架。这样做的目的是防止“机架断电”或者“磁盘损坏”这种单点故障把数据带走。我实操中遇到过两次磁盘故障，因为副本机制的存在，数据一点没丢，只需要把坏盘摘掉，系统会自动把副本数补回来。这个自愈能力，是传统单机文件系统完全没法比的。
元数据管理是HDFS最容易出问题的环节。块放在哪些节点上、文件目录长什么样，这些信息都存在NameNode内存里。NameNode是集群的大脑，它挂了整个集群就不可用了。所以生产环境必须配两个NameNode，一个Active一个Standby，中间通过共享编辑日志保持状态同步。我还记得有次给一个集群做滚动升级，Active和Standby切换的时候心跳超时参数没配好，导致脑裂，双主同时写元数据。那一次给我留下的教训就是，看似简单的“主备切换”，配置参数得逐项核对。
但HDFS也有它很明显的短板。存储的是不可变的文件块，不支持随机写；处理小文件效率极低，每一个文件、每一个块都会在NameNode里占一条内存记录，几千万个小文件能直接把JVM堆撑爆。所以后来才有了各种补充和演进。
2.2 从HDFS到对象存储与数据湖
HDFS虽好，但它有一个天然的问题：存储和计算是绑在一起的。集群扩了计算能力，存储也得跟着扩，成本不够灵活。现在云原生架构流行以后，很多公司把存储层换成了对象存储，比如云上的S3、OSS这类产品，HDFS只作为本地缓存层。数据放在对象存储里，计算集群按需启动，用完就释放，成本省很多。
数据湖概念这几年也很热。数据湖和传统数仓的区别在于：数仓存的是“加工好的数据”，schema是写入之前就定好的；数据湖存的是“原始数据”，什么格式都行，等到要用的时候再去定义结构。用我自己的话说，数仓是超市里分好类的货架，数据湖是堆满原材料的大仓库。现在主流的数据湖方案，像Iceberg、Hudi、Delta Lake，本质都是在HDFS或者对象存储之上加了一层表格式管理，解决了“文件级别的事务”和“元数据的一致性”问题。有了它们，数据湖里也能做到ACID，能对数据进行upsert操作，这在以前不可变文件的时代是想都不敢想的。
我个人的建议是，中小团队不要一上来就追数据湖。如果你们的数据量还没有到需要流批一体、跨引擎共享数据的程度，老老实实把数仓分层做好，把Hive表的管理规范定好，比换一个炫酷的数据湖框架实在得多。架构是跟着业务量走的，不是跟风走的。
2.3 存储层选型与常见配置
存储选型没有银弹，得看机房条件、预算、团队技术水平。我把常用的几种方式整理了一下，方便对照着判断：
| 方案 | 适用场景 | 优点 | 代价 |
|---|---|---|---|
| HDFS自建 | 机房规模大，离线批处理为主 | 可控性强，吞吐高，和Hive/Spark兼容好 | 运维成本高，NameNode需重点维护 |
| 对象存储+计算分离 | 云上部署，任务波动大 | 弹性伸缩，存计算分离，成本灵活 | 网络延迟稍高，需缓存层配合 |
| 数据湖表格式 | 流批一体，需要ACID与upsert | 支持事务，多引擎共享数据 | 学习曲线陡，小文件问题需要治理 |
存储层配置里，有两个容易被忽略的坑我提一嘴。一是块大小，很多人默认128MB就不动了。如果你的文件平均只有几十MB，那块的利用率很低；如果你的文件都是好几个GB的压缩大文件，可以考虑调到256MB甚至更大，减少块的个数，NameNode的压力也会小一些。二是副本数，默认3份，其实读多写少的数据可以调成2份，对成本敏感的场景很友好。当然，调整之前先确认机器故障恢复能力能不能兜住。
3. 计算层：从MapReduce到Spark再到Flink的演进脉络
3.1 为什么MapReduce被淘汰，但思想被继承
很多人学MapReduce是为了面试，但实际生产环境里，现在几乎没有团队会直接用MapReduce写业务了。它速度太慢，每跑完一个Map阶段、Reduce阶段，中间结果都要落一次磁盘。两次落盘，再加上任务调度开销，跑一个简单的聚合都可能要几分钟。但它提出了一个非常关键的思想：把计算拆成Map（映射）和Reduce（归约）两个阶段，分布式地把任务拆开，再分布式地把结果合并。这个思想是后面一切分布式计算框架的母体。
Spark的RDD、Flink的窗口计算，本质上都能看到Map和Reduce的影子。只不过它们把中间结果从磁盘搬到了内存，用更聪明的调度策略和优化器，把计算速度提升了几十上百倍。所以学习的时候，不建议跳过MapReduce直接看Spark源码，先搞懂MapReduce的shuffle过程，再去看Spark的shuffle优化，你会看得特别通透。
3.2 Spark为什么能快这么多
Spark的核心创新是RDD（弹性分布式数据集）和DAG调度器。我当初读Spark源码的时候，一个特别深的体会是，它把“计算”本身做成了一个有向无环图。每一步transformation都记录成图里的一个节点，真正要执行action的时候，Spark会对这个图做两个优化：一个是血缘关系重新组织，合并相邻的宽窄依赖，减少shuffle次数；另一个是惰性求值，同一个DAG里的多个操作能在一次调度里跑完，不用像MapReduce那样每步写一次盘。
还有一个让Spark快起来的功臣是钨丝计划，有一个钨丝项目把执行引擎从JVM的Java对象模型的约束里解放了出来，使用二进制格式直接在内存里做列式存储，压缩率更高、扫描更快。配合Tungsten优化后的代码生成，CPU的利用率提高了一大截。做Spark调优的人经常念叨“把shuffle减到最小”，因为shuffle意味着数据的跨节点搬运，网络IO是分布式计算里最贵的资源。能用broadcast join的小表，绝不用sort merge join，这是我在实际调优里贯彻最多的原则。
3.3 Flink与流批一体的定位
如果说Spark是批处理领域的王者，那Flink就是流处理领域的答案。这两者不是替代关系，而是定位不同。Spark Streaming虽然也支持流式处理，但它的方式是“微批”——把几秒内的数据攒一起，当成一个个小批来处理，天然有秒级延迟。Flink不一样，它是一条数据一条数据处理的，是真正的流式计算，延迟能做到毫秒级。
我做实时大屏的时候，用的就是Flink。数据从Kafka进来，Flink开窗口做聚合，结果直接写进ClickHouse或者Redis，大屏上的数字几乎是实时的。Flink还有一套我觉得特别值钱的机制，就是Checkpoint和Savepoint。Checkpoint是周期性地把状态快照存下来，机器挂了能恢复到最近的状态，保证数据算不丢、不重复。不夸张地说，没有这套机制，流式计算在生产环境里根本不敢跑。
“流批一体”这几年是趋势。以前离线一套任务、实时一套任务，逻辑写两遍，数据还可能对不上。Flink希望用同一套引擎把这俩统一了，批是有限的流，流是无限的批。但实际上做到完全统一还有距离，工程落地的时候通常还是分开跑，只是底层的表格式和数据存储统一了。
3.4 计算引擎选型实战建议
计算引擎选型，我一般看几个硬指标：延迟要求、吞吐量、状态规模、团队Java/Scala水平。为了让你抄作业方便，我直接整理成建议：
- 每天T+1跑离线报表、数据清洗任务，选Spark，稳且生态成熟。
- 需要秒级甚至毫秒级响应，做实时监控、实时大屏、实时推荐特征，选Flink。
- 既要有批量历史回刷，又要有实时流式消费，可以看Flink的批模式，但如果历史回刷量巨大，我建议还是用Spark，Flink跑超大批量任务的稳定性调优成本不低。
- 团队是Java背景的，Flink更友好；团队是Scala/Python背景的，Spark更顺手。
还有个小提醒，Spark和Flink都建议用Yarn或者K8s做资源调度，不要让它们直接靠自带Standalone模式跑生产，资源没法精细化隔离，出问题的时候排查也麻烦。
4. 查询与分析层：数仓建模与SQL引擎
4.1 Hive到Spark SQL的SQL化之旅
2008年Facebook开源了Hive，把SQL翻译成MapReduce任务。从那一刻起，大数据处理和数据分析师之间那堵墙被拆掉了。写SQL这个能力，人类积累了几十年，不用重新发明。后来Spark SQL把SQL引擎优化得更彻底，直接走Catalyst优化器生成执行计划，再经过Tungsten优化的物理计划，性能远超早期Hive。
但SQL化也给底层带来了新的压力：一份SQL写下去，引擎得知道去哪找数据、怎么分区裁剪、怎么选择join策略。这就是为什么数据仓库的建模如此重要。一个建得好的数仓，表的分区都是按日期、按业务域、按维度清晰划分的，一张SQL查询能精准地只扫到它需要的那一小片数据；一个建得烂的数仓，动不动就全表扫描，几百G的数据一查就是几分钟起。
4.2 数仓分层建模的心法：ODS、DWD、DWS、ADS
数仓分层的设计，是查询层快不快的根源。标准的分法一般是四层：
ODS层，操作数据存储层，把业务系统的数据原封不动地搬过来，保持和源系统一致，主要是为了“留底”。
DWD层，明细数据层，把ODS里的数据做清洗、去重、规范化，把多张表拉宽成一张事实表，这一层是明细粒度的。
DWS层，汇总数据层，按业务主题做轻度汇总，比如每天的用户维度聚合、商品维度聚合。这一层数据量大幅缩减，查询速度会有质的提升。
ADS层，应用数据层，面向具体的报表、大屏、分析应用，做最后一步的指标加工。
有些朋友问我，小公司到底要不要做这么复杂的分层？我的答案是看数据规模和查询频率。如果你每天的数据量连百万行都不到，直接一张宽表查也没太大问题。但如果你要做用户行为分析、要做实时大屏、要支撑多个业务方的取数需求，分层不是为了好听，是为了让团队成员各管一段，口径统一，查询互不干扰。
4.3 查询引擎选型：Presto/Trino与ClickHouse、Doris
数仓数据建好后，用什么引擎去查，又是一门学问。
Presto/Trino是大数据SQL查询引擎里的老牌选手，擅长跨数据源联邦查询，一个SQL能同时关联Hive表、MySQL表、对象存储上的文件。它的定位是“大数据量、秒级到分钟级的交互式查询”，不太适合高并发场景。
ClickHouse是列式存储数据库，主打极致性能。我在实时大屏项目里用它，单表几十亿行，聚合查询秒出。但ClickHouse不擅长多表关联，JOIN是它的软肋，它的设计哲学是“预计算、宽表、单表查”，和数仓的星型模型天然不太搭。
Apache Doris是近几年火起来的MPP数据库，更符合国内团队的数仓使用习惯，支持标准SQL、支持高并发点查、支持实时更新。我用Doris做用户标签服务，体验很不错，它的Unique模型做实时更新的场景很顺手。
选型的核心原则我总结一下：需要大规模明细数据的即席探索，用Trino；需要超高并发、极速聚合的看板、报表，用ClickHouse；需要兼顾实时更新和高并发查询的应用，看Doris。
5. 数据接入与管道：消息队列的削峰填谷
5.1 Kafka如何成为数据接入的事实标准
数据接入是整个数仓的生命线，数据进不来，后面全是空转。业内现在事实标准就是Kafka。为什么是它？因为它能在“高吞吐”和“数据可靠性”之间找到一个不错的平衡。
Kafka的核心模型是分区，一个主题拆成多个分区，每个分区内的消息是有序的，多个分区之间是并行的。生产者可以按key哈希分发，保证同一个key的消息都进同一个分区，这样就能保证局部有序。消费者以组的形式消费，一个分区只会被组内一个消费者消费，这样每个消费者的负载是相对均衡的。
Kafka的性能很强，一个普通的集群支撑几十万甚至上百万的每秒写入量没问题，但这数据不是白来的。Kafka的设计里，性能的核心是顺序写磁盘和页缓存。传统的随机写磁盘很慢，但Kafka持续往磁盘尾部追加写，利用了顺序IO的高吞吐；读的时候优先走页缓存，热数据根本不用碰磁盘。
5.2 Kafka生产环境的核心参数与排查
Kafka在生产环境里踩坑是家常便饭。我最常被问到的两类问题，一类是消费积压，一类是数据丢失。
消费积压的排查思路，第一步看消费者是否在正常心跳，第二步看单条消息的处理耗时，第三步看分区数和消费者线程数是否匹配。很多时候消费积压不是Kafka本身的问题，而是下游的消费者处理逻辑太慢，比如每条消息都同步去查一次MySQL。解决的方式一般有两个方向：加大并行度（增加消费者实例数和分区数）或者优化下游处理逻辑，比如批量写入。
数据丢失这个事更吓人。Kafka的ack机制里有三个关键参数，acks=0表示生产端发出去就不管了，有可能丢；acks=1表示leader写入成功就返回，但leader挂了可能丢；acks=all表示所有副本都写入成功才返回，最安全。副本同步还有一个ISR机制，ISR里是跟得上的副本集合。如果生产环境核心链路，请把acks设成all，或者至少all加min.insync.replicas来兜底。我见过不止一个团队，默认配置跑上线，偶发丢数据，查半天找不到原因，最后一看acks还是默认的1。这种坑是最心累的。
5.3 实时链路中的数据管道设计
一条典型的实时数仓链路长这样：业务库的binlog变更被实时捕获工具（比如Canal或Debezium）捕获，写入Kafka；Flink消费Kafka，做清洗、关联、聚合、维表补全，再把结果写入Doris或ClickHouse供查询端使用。
这条链路里有一个容易被人忽略的关键设计：Kafka在中间既当缓冲，又当解耦层。上游业务系统的波动不会直接影响下游分析任务，下游查询引擎的故障也不会倒灌回业务系统。这就是消息队列“削峰填谷”的价值。比如双十一大促，业务系统那几亿条订单数据，如果直接打到数仓，瞬间就把数仓打挂了；但是经过Kafka这个缓冲池，Flink可按自己消费能力慢慢消化，峰值被削平，链路稳如泰山。
我在设计管道的时候，有个习惯：中间的每一条Kafka topic都统一带一个分区时间戳字段，方便做数据延迟监控。数据从业务库到Kafka到Flink到结果表，每个环节都埋了监控指标，任何一个环节延迟超过阈值就报警。流式链路里最怕的是“水还没到，大坝先塌了”，早发现5分钟，能拯救半天排障时间。
6. 调度与资源管理：让任务稳定跑起来的底座
6.1 分布式调度框架的选择
大数据任务不是人肉去点的，得有调度系统定时跑。Spark任务凌晨2点跑、Flink任务7x24小时跑、数据同步任务每小时跑，全得靠一套可靠的调度框架统一管起来。
我最早用的是Azkaban，后来换成了Apache DolphinScheduler，原因很简单：DolphinScheduler用DAG方式定义任务依赖，界面可以直观看到任务之间的上下游关系，而且支持任务失败自动重试、超时告警。现在有些团队直接用Apache Airflow，Python生态更友好，但国内大数据场景里DolphinScheduler用的人更多，和Hadoop/Spark生态集成得比较顺。
调度系统选型有一个容易被忽略的细节：任务依赖不只是“时间到了就触发”，更多时候是“上游跑完才触发”。比如用户行为ETL任务依赖日志采集任务的完成状态，用DAG去描述这种依赖是最清晰的，而不是在代码里判断“当前时间是否过了几点”。
6.2 资源管理与隔离：Yarn、K8s与动态队列
计算引擎跑起来，总得有人给它们分CPU和内存。这就是资源管理器的作用。传统Hadoop生态里就是Yarn。Yarn把资源分成一个个Container，任务在里面跑，互不干扰。
Yarn的队列设计是我觉得很多团队没用好的一块。生产环境我建议按照业务线划分队列，比如离线队列、实时队列、数据测试队列，队列之间做资源隔离和权限控制。这样即使有人跑了一条疯狂的任务，把整个队列的资源吃光了，也不会影响实时链路。我经历过一次血泪教训：当时实时Flink任务和离线Spark任务混在同一个队列，深夜一个大回刷任务把资源全占了，第二天早晨实时大屏的数据延迟了快一个小时。后来专门拆了实时队列，加上资源上限，再没出过这种幺蛾子。
K8s目前在Spark/Flink的部署上越来越流行，尤其是云原生的架构，任务按需启动Pod，资源用多少申请多少。如果团队K8s能力扎实，这确实是很好的方向。但如果你自建机房、团队没有成熟K8s运维体系，Yarn可能还是最省心的选择。别为了追新把整个运维复杂度拉上去了。
6.3 任务调度的实战注意事项
调度和资源管理这里，我整理几个自己踩过的坑，分享给你：
- 时区问题。调度平台一般默认服务器时区，最好显式指定为Asia/Shanghai，尤其集群跨地域部署时，时区不一致会导致任务触发时间对不上，数据分区晚一个小时，排查一圈最后发现是时区配置问题，真想拍自己。
- 任务并发上限。公共调度集群一定要配任务并发数和实例数上限，不然某人配错参数启动了上百个并发实例，直接把集群压死。
- 失败重试策略要合理。重试不是越多越好。幂等性好的任务，比如SQL任务，重试3次问题不大；非幂等的任务，比如某些数据同步后再触发下游的任务，重试时可能重复触发下游，造成数据重复。这种任务宁可不自动重试，改成报警后人工介入。
- 补数据要谨慎。调度系统通常都有“补数据”功能，一键把过去一个月的数据都跑一遍。这个功能是大杀器，也是集群资源瞬断的万恶之源。批量补数前一定要先估算资源，分批限流执行。
7. 常见故障与排查经验实录
7.1 数据倾斜：离线任务慢的隐形杀手
数据倾斜真的是分布式计算里最经典的坑了。表面的现象很简单：一个任务怎么跑都跑不完，进度卡在99%，或者有个Reduce一直拖着不结束。背后的原因是数据分配不均，某个key的数据量远大于其他key。举例来说，统计全国用户地域分布，上海这个key有3亿条，其他省份只有几百万条，那对应的Reduce任务就要处理几十倍于其他任务的数据，自然拖慢整个作业。
排查方法我一般分三步走：第一步看Spark UI里各个Task处理的数据量，找出那个明显异常的Task；第二步定位是哪个key倾斜；第三步选方案。进阶里有个很有用的经验：如果是JOIN带来的倾斜，优先用小表广播，把大表join小表变成map端完成；如果是大表join大表，给热点key加随机前缀再拆分；如果是纯聚合的倾斜，可以用两阶段聚合，先加随机key局部聚合，再去掉随机key全局聚合。
7.2 小文件问题：元数据压力的定时炸弹
HDFS最怕小文件，Spark写数据默认一个分区一个文件，如果分区粒度过细、又频繁调度，日积月累会产生海量小文件。小文件一多，NameNode内存爆掉，任务元数据查询变慢，整个HDFS性能都会被拖垮。
治理手段主要是两类：一类是从源头控制，写入时用coalesce或repartition控制输出文件数量，减少无谓的分区数；另一类是事后合并，用工具定期把小文件合成大文件，比如给Hive表做一次insert overwrite，重新按分区写一遍。我在实践中更倾向于源头控制，因为事后合并要额外消费资源，而且操作不当会短暂影响线上查询。
7.3 上面那些配置之外的独门经验
技术文档上的配置都能查，但很多经验是文档里不会写的。
写SQL和pipeline的时候，我强烈建议把“分区裁剪”当作一个核心性能指标来要求自己和团队。所谓分区裁剪，就是查询尽量只扫描需要的分区，理想情况下从一个月的分区里只扫3天的数据，而不是扫全部30天。审视一条慢SQL，第一个问题就该问：分区裁剪生效了吗？
监控告警这一块，也有个特别实用的建议：告警别全铺开，选真正能反映系统健康度的核心指标就好。比如实时链路重点看消费延迟和checkpoint失败次数；离线任务重点看失败率和队列资源使用率。告警阈值设得太灵敏，天天半夜被叫醒，人会疯的；设得太迟钝，出问题半小时后才知道，人也疯。
最后还有一点，我觉得是每个大数据工程师都应该刻在心里的：分布式架构里，网络的稳定性比单机性能重要得多。排查诡异的数据不一致、偶发超时问题时，优先怀疑网络抖动、慢连接、反压。很多问题重启能好，但重启三次，那就绝不是运气问题了，得认真看日志、看网卡丢包、看GC停顿。
8. 一点个人感触和后续方向
这些年做大数据项目，最深的一个体会是：技术栈更新得再快，底层的逻辑是不变的——先想清楚数据和业务的关系，再选技术；遇到性能问题先看数据分布，再看执行计划，最后才去调参数。很多人喜欢一上来就对着配置手册调，调了半天还是慢，其实问题出在数据建模上。
如果让我给后来者一个学习顺序的建议，那一定是先把存储和计算这两块吃透，再用SQL去串整个链路，最后再动手玩实时。看再多博客，都不如自己搭一个三节点的集群，丢进去几亿条模拟数据，亲眼看一次数据倾斜和任务重试是怎么发生的。
大数据这个方向的后续，我觉得有两个值得关注的点。一个是云原生架构下存算分离会成为绝对主流，资源弹性带来的成本优势太明显了；另一个是实时数仓会越来越普遍，业务的决策反馈周期不断缩短之后，“离线分析一个人，实时分析所有人”这个趋势挡不住。工具会一直变，但“用数据解决问题”这件事本身，永远不会过时。
