没系统学过大数据的人第一次面对这个技术栈的时候基本都会懵。Hadoop、Spark、Flink、Kafka、Hive、ClickHouse名字一个比一个抽象每个工具背后还有一堆概念光看官方文档就能劝退一大半人。我这套学习记录压了很久才整理完主要是想把这些常用工具的底层逻辑、适用场景和踩坑经验串成一条线而不是零散地记命令、记参数。先说清楚这篇文章是什么。它是一份以“大数据常用工具”为核心的学习复盘笔记从分布式存储、计算引擎、调度协调到消息队列、数仓建模和集群部署把主流程上的核心组件逐个拆开讲。适合两类人看一类是准备转行大数据开发、数据工程方向的朋友另一类是已经入行但总觉得知识碎片化、想系统梳理一遍的工程师。文章不会贴大段源码重点是讲清楚每个工具“为什么这么设计”以及“实际项目里怎么用”顺带把面试高频点和高频故障排查经验也放进去。1. 大数据技术全景先搞清楚要解决什么问题1.1 大数据的四个V落到工程上是三个核心问题很多新手学大数据第一件事就是背大数据的4V特征Volume数据量大、Velocity增长快、Variety类型多、Value价值密度低。背完以后依然不知道这些跟工具选型有什么关系。我自己的理解是这四个V归根结底指向工程上的三个核心问题数据存不下、计算太慢、任务难管理。数据存不下单台机器的硬盘有上限而且硬盘坏一次数据就没了所以需要把数据分散到多台机器上还要做冗余备份。这就是分布式文件系统的用武之地HDFS解决的就是这件事。计算太慢单台机器的CPU和内存有限即使数据能存下处理起来也要等很久所以需要把一个大任务拆成很多小任务分到多台机器上并行算。这就是MapReduce、Spark、Flink这批计算引擎的职责。任务难管理当你有几十个离线任务、十几个实时任务在跑谁先谁后、哪个失败要重跑、资源怎么分配这些问题需要一个统一调度层来管于是有了Yarn以及Airflow、DolphinScheduler这类调度工具。用生活化的方式理解HDFS是建仓库计算引擎是加工车间调度系统就是排产管理员。绝大多数大数据项目本质上都是在围绕这三个问题做方案选型。明白了这一点再去看各个工具就不会觉得它们是孤立的技术点了。1.2 完整技术栈的主流程从采集到可视化大数据项目的完整链路通常可以画成一条从数据采集到数据消费的管道我学习的时候习惯把它分成六段数据采集层负责从业务库、日志文件、消息队列等来源收集数据。离线场景常用Sqoop、DataX、Flume实时场景基本靠Kafka配合各种Connector。数据存储层原始数据落地的地方典型组件是HDFS也有对象存储如MinIO、云厂商的OSS和列式存储如ClickHouse、Doris。数据计算层对数据进行清洗、加工、聚合。离线批处理用Spark实时流处理用Flink两者也都在往批流一体方向收敛。数据仓库层把计算后的结果按主题组织起来Hive是最典型的数据仓库基础组件现在还有Iceberg、Hudi这类数据湖方案。任务调度层串起整个ETL流程好的调度工具能让你清楚看到每条数据流的依赖关系和运行状态。数据应用层面向业务提供查询服务常见的是BI报表、即席查询、数据大屏对应的工具有Presto/Trino、Doris、ClickHouse等。每一层都有至少一个“代表性选手”面试和项目里高频被问到的也就是这批选手。后面的内容我就按这条链路逐个拆解。2. 存储与计算基石HDFS、MapReduce与Spark/Flink2.1 HDFS分布式文件系统的设计逻辑HDFS全称是Hadoop Distributed File System它解决的核心问题是“如何把一个大文件拆成多个块分布在多台机器上并且保证数据不丢”。HDFS中有一个NameNode和多个DataNode。NameNode负责管理文件系统的元数据也就是“这个文件的目录结构长什么样、每个文件被切成了哪些块、这些块存在哪些节点上”DataNode负责真正存数据块。HDFS默认的块大小是128MB这个值不是拍脑袋定的。块越大NameNode维护的元数据条目就越少系统的扩展性越好但块太大也会导致任务粒度变粗、并行度下降。生产中一般保持128MB或256MB不用频繁改动。写入流程上客户端先把文件切分成块按顺序请求NameNode找到可用的DataNode列表然后以流水线方式写入第一个DataNode接收后传给第二个第二个传给第三个。每个块默认存3份副本分布在至少2个机架上这样既能容忍单节点故障也能容忍整个机架挂掉。实操中踩过的一个坑是“小文件问题”。如果每天有上万个几KB的小文件写入HDFSNameNode内存会被海量元数据占满集群性能肉眼可见地下降。解决办法通常是提前合并小文件或者在写入时用SequenceFile等格式做一次合并。另一个常见问题是在HDFS上频繁删除和重建目录这会导致NameNode发生大量编辑日志操作严重时会影响整个集群响应。2.2 MapReduce为什么被替代Spark赢在哪里MapReduce是Hadoop第一代计算引擎思想很简单Map阶段把任务拆开并行处理Shuffle阶段按Key重新分发数据Reduce阶段聚合结果。问题出在Shuffle上。Shuffle要把Map的输出落盘、排序、合并、再拉取到Reduce端每一步都有大量的磁盘I/O和网络传输。跑一个复杂作业大部分时间都耗在数据搬运上。Spark的核心创新是把中间结果尽量放在内存里。它提出了RDD弹性分布式数据集的概念把数据抽象成分布式的只读集合并记录了数据之间的依赖关系宽依赖、窄依赖。窄依赖可以直接在内存里做流水线计算宽依赖需要Shuffle但Spark的Shuffle做了很多优化包括按内存排序、合并小文件等整体速度比MapReduce快出不少。此外Spark提供了一套完整的API支持Scala、Java、Python、SQL生态上也有Spark SQL、Spark Streaming、MLlib、GraphX一个引擎覆盖批处理、交互式查询、机器学习和图计算场景。对比下来我的经验是如果只是跑T1的离线报表、离线特征加工Spark基本是首选如果计算链路里对延迟要求很高比如秒级风控、实时特征、实时大屏那Flink的流处理模型更合适。Flink真正的强项是状态管理和精确一次Exactly-once语义。它能记录每个算子处理到哪条数据配合Checkpoint机制把状态定期保存到外部存储故障后从最近的Checkpoint恢复保证数据不重不丢。2.3 调度与协调Yarn与Zookeeper各管什么Yarn是Hadoop的资源调度层负责给各种计算框架分配CPU和内存资源相当于大数据集群的“物业公司”。它的核心角色是ResourceManager和NodeManagerResourceManager管全局资源NodeManager管单台机器的资源。当Spark或Flink作业提交上来会先向ResourceManager申请一个ApplicationMaster再由它向NodeManager申请具体的Executor容器。Yarn支持三种调度器FIFO简单但易队头阻塞Capacity按队列划分资源适合多部门共享集群Fair则按需动态分配、追求公平。生产多租户环境我目前用得最多的是Capacity Scheduler每个业务线固定配额能有效防止某个任务把集群资源吃光。Zookeeper在大数据生态里的角色是“分布式协调者”。它做的事情很多维护配置信息、实现分布式锁、进行Leader选举。Kafka的Broker、HBase的RegionServer、HDFS的NameNode高可用很多都依赖Zookeeper来选主和感知节点状态。它的核心机制是ZAB协议能保证在多数节点存活的情况下提供一致性的服务。实际排障时Zookeeper最常见的坑是节点时钟不同步和文件描述符耗尽所以部署规范里一般会强制要求配置NTP时间同步并调大文件句柄上限。3. 数据仓库、数据湖与查询引擎数仓建模与选型实战3.1 Hive数仓分层ODS、DWD、DWS、ADSHive把SQL翻译成MapReduce或Spark作业运行在HDFS上让数据分析师不用写Java就能做分布式计算。单纯会写SQL还不够工程实践中真正重要的是数仓分层设计。我前后参与过几个数仓项目分层基本都遵循四层结构ODS层原始数据层直接存储从业务库同步过来的原始数据一般不做清洗保留完整历史便于回溯问题。DWD层明细数据层对ODS数据进行清洗、去重、标准化、维度退化得到干净的明细数据。DWS层汇总数据层按业务主题用户、商品、订单、流量做轻度汇总常见的是按天汇总的各种指标宽表。ADS层应用数据层面向具体报表和应用加工出可直接查询的结果表。分层的意义在于职责清晰、复用性高、容错性强。举个例子一个电商订单所有的原始信息在ODS层DWD层会把订单、商品、店铺、用户关联成一张宽表DWS层再按用户维度和日期维度把订单金额、订单量等指标汇总好ADS层直接出大屏数据。如果不分层每个报表都从原始日志开始算开发效率低而且一个需求改动会影响一片作业。Hive表设计上分区和分桶是两个高频考点。分区是按照某个字段如日期把数据分到不同目录查询时能直接裁剪掉无关数据大幅减少扫描量。分桶则是把数据按照某个字段的哈希值散列到固定数量的文件里主要用在join、抽样等场景。项目里我一般以日期做二级分区对经常关联的大表按关联键做分桶。3.2 数据湖与湖仓一体Delta Lake、Hudi、Iceberg传统数仓解决的是“结构化数据怎么组织、怎么高效查询”的问题但遇到非结构化数据日志文件、图片元数据、行为埋点、需要支持机器学习特征回溯的场景传统数仓就不够灵活了。数据湖方案因此出现核心思路是把数据以原始格式放在低成本存储上计算时才解析schema。目前最主流的是三大数据湖格式Delta Lake、Apache Hudi、Apache Iceberg。它们本质上是构建在HDFS或对象存储之上的一层表格式管理工具提供ACID事务、时间旅行、Upsert更新插入能力。三者的差别在于能力Delta LakeApache HudiApache Iceberg事务能力强基于日志强基于时间线强基于快照隔离Upsert支持支持Merge Into支持且有多种写入模式支持Merge Into与Spark集成深度集成深度集成深度集成Flink集成社区版在完善较早支持良好适合场景数据湖数仓Omnidirectional近实时摄入、增量处理大规模分析、多引擎集成选型上没有绝对标准。如果团队Spark技术栈比较多、希望快速搭建数据湖Delta Lake上手成本最低如果业务偏向近实时增量同步Hudi的MOR读时合并模型很合适如果公司已经有多引擎并存Spark、Flink、TrinoIceberg的开放性和生态兼容性更强。我个人的学习建议是三种格式不用全部精通理解它们解决的问题和核心机制项目里选一种深入用其他两种能说清差异就够了。3.3 查询引擎选型Hive on Spark、Presto/Trino、ClickHouse、Doris数仓建设好之后上层需要一个或者多个查询引擎来服务不同的业务场景。如果把整个数仓比作一个大商场Hive就是“库房管理员”负责跑重型加工任务而即席查询引擎就是“前台导购”要响应快、体验好。Hive on Spark算是Hive的改良版把底层执行引擎换成Spark适合跑大型批量加工任务但单次查询秒级响应它做不到。Presto/Trino强调跨数据源的分布式SQL查询可以同时查Hive表、MySQL、Kafka中的数据非常适合做BI即席查询。ClickHouse则是列式OLAP数据库单表聚合查询速度极快适合做用户行为分析、监控日志分析但它不太擅长多表关联复杂join容易内存爆掉。DorisApache Doris是另一类MPP架构的OLAP数据库聚合模型和更新模型设计得很适合做报表和多维分析近几年在数据大屏场景里非常火。选型经验上我通常会这样判断如果业务要的是秒级大屏指标优先考虑Doris或ClickHouse如果要做跨Hive、MySQL、Kafka的灵活查询用Trino如果是超大批量加工任务还是老老实实走Spark或Hive on Spark。很多公司会同时部署多个引擎用网关层做好转发前端用户根本感知不到背后用的是哪个引擎。这里需要提醒一句ClickHouse单表性能再好也不要把它当万能数据库用频繁更新删除、高并发点查都不是它的强项硬上的结果就是集群性能和稳定性一起崩。4. 数据采集与消息队列Kafka深入解析4.1 离线采集与实时采集工具怎么选数据采集是数据管道的起点。离线采集主要面对“定时把业务库数据同步到HDFS或数仓”的场景常用Sqoop、DataX、Flume。Sqoop是Apache的老牌工具使用简单但维护状态一般。DataX是阿里开源的数据同步中间件支持读端和写端的丰富插件性能和稳定性在国产工具里属于佼佼者我目前做离线同步优先推荐它。Flume侧重日志采集能从日志文件、网络端口持续读取数据然后写入HDFS或Kafka。实时采集目前几乎是Kafka的天下。业务数据库的变更日志Binlog通过Canal、Debezium、Maxwell等工具实时解析然后写入Kafka应用日志通过Filebeat或Flume采集也写入Kafka。Kafka作为消息中枢把各类数据源统一接入下游再由Flink或Spark Streaming消费这样能实现生产端和消费端的完全解耦。4.2 Kafka核心机制分区、副本、ISR与消费者组Kafka看似简单用起来处处是学问。它的核心抽象是Topic主题每个Topic可以有多个Partition分区每个分区是一个有序的消息日志。分区是Kafka并行度的基础分区越多同一Topic能被更多的消费者并行消费吞吐量越大。但分区多不代表一定要多。分区过多会带来两个问题一是文件句柄占用多每个分区对应磁盘上的一组日志文件二是故障恢复和leader切换的开销变大。生产环境我一般按目标吞吐量来估算分区数假设单个分区稳定吞吐能达到10MB/s业务预期峰值是200MB/s那分区数可以先定20到25个留出一定的缓冲。副本机制上Kafka每个分区可以配置多个Replica其中一个作为Leader负责读写请求其他副本从Leader拉取数据称为Follower。ISRIn-Sync Replica集合记录的是“跟得上Leader”的副本列表如果某个副本长时间不拉取数据落后太多就会被踢出ISR。生产配置中如果把acks设为all并确保min.insync.replicas2大部分场景可以做到消息不丢失。但要注意可靠性和性能是矛盾的acksall配合多副本时延迟会升高需要结合业务重要性做取舍。消费者组是Kafka实现单播和广播的关键机制。同一个消费者组里的多个实例共同消费一个Topic每个分区只会被组内一个消费者消费这是系统自动均衡的。消费时消费者把已消费的位置offset提交到Kafka内部主题上所以重启后能接着上次的位置消费。实际生产遇到的rebalance风暴多半是因为消费者处理太慢、心跳超时导致频繁触发再均衡。排查时先看消费端是否有热点Key、是否有大消息阻塞再看max.poll.interval.ms配置是否合理。4.3 Kafka生产实践消息可靠性、积压排查与性能调优消息不丢生产者设置acksall消费者关闭自动提交、业务处理成功后再手动提交offsetBroker端设置 unclean.leader.election.enablefalse防止没有同步完数据的副本成为Leader。消息积压先用消费组Lag监控定位哪些分区积压优先扩容消费者实例如果积压太深也可以紧急写一个临时消费程序直接写HDFS后续再回刷。性能优化生产者端批量大小batch.size和等待时间linger.ms要搭配调整别盲目调大batch消费者端如果单条消息处理耗时长考虑增加分区数和消费者数量。磁盘规划Kafka数据的重要特征是顺序写机械硬盘也能有不错的表现但生产还是建议SSD。日志保留时间按消息大小计算比如每天产生500GB数据要保留7天预留20%缓冲就是4.2TB磁盘这点在做集群容量规划时必须提前算清楚。5. 集群部署策略与大数据学习路线5.1 集群部署策略从单机学习到生产规划学习阶段不用追求大集群本地用Docker或者虚拟机搭一个3节点的Hadoop完全分布式环境就够了。比较稳妥的路径是先在单机跑伪分布式理解核心配置项的作用再扩展到3节点把HDFS、Yarn、Zookeeper、Hive全部手动部署一遍。这个过程会让你对配置文件、目录结构、启动顺序有真实体感比直接用一个装好的发行版要扎实得多。生产环境部署要考虑的问题更多。角色分离是第一条NameNode和ResourceManager属于“大脑”型组件要单独部署在性能稳定的机器上别和DataNode混布Zookeeper是强一致组件需要奇数台3或5部署保证选主可用。内存规划上NameNode通常给16GB到32GBResourceManager给8GB到16GBDataNode和NodeManager的剩余内存要结合并发任务量预估。如果业务规模不大也可以考虑云厂商的托管集群如EMR把扩缩容、故障恢复交给云平台团队专注在数据开发上但为了搞懂底层原理我还是建议至少学习阶段要手动部署一次Apache发行版。部署方式对比来看方式优势劣势适合场景Apache原生发行版灵活可控理解底层运维成本高学习、有专业运维的团队CDH/CDP商业版组件整合好界面友好授权费用高版本更新慢传统企业云托管EMR类部署快弹性伸缩有锁定风险费用持续产生中小团队、快速起项目5.2 大数据学习路线阶段拆解与书单大数据学习路线的坑在于“什么都要学”但体系又很松散。我踩过弯路之后整理出一条比较可行的路径阶段一Linux、Java、SQL。Linux至少会常用命令和Shell脚本Java重点学集合、多线程、JVM基础SQL要达到能写复杂窗口函数的水平。这阶段大概需要1到2个月。阶段二Hadoop、Hive、Zookeeper。把HDFS、MapReduce、Yarn调度机制弄明白Hive SQL上手做ETL理解数仓分层模型。这是最枯燥但最打基础的一步。阶段三Spark、Flink、Kafka。理解两类计算引擎的编程模型和运行原理重点搞懂RDD/DataStream、宽窄依赖、状态管理、Checkpoint配合Kafka实现实时数据处理链路。阶段四数仓建模、调度、OLAP。学习维度建模理论学会用DolphinScheduler或Airflow编排任务熟悉Doris/ClickHouse的选型和基本运维。阶段五项目实战。用真实数据集做一到两个完整项目把采集、存储、计算、调度、应用全链路跑通并整理成能写在简历上的项目描述和面试话术。书单方面Hadoop方向可以看《权威指南》Spark看《Spark快速大数据分析》数仓建模看《维度建模权威指南》Kafka看《Kafka权威指南》。视频课程和社区文章作为辅助不用贪多每个方向跟住一个系统性的学习资源就足够。5.3 面试高频点与项目复盘这套学习记录整理过程中我也对照了不少大数据面试题发现高频考点基本集中在几个点上HDFS写入流程、MapReduce中Shuffle的过程、Spark宽窄依赖与Stage划分、Flink的Checkpoint与精确一次语义、Kafka的高吞吐原因、数据倾斜排查、Hive数仓分层和常用优化手段。准备面试时别只背结论一定要能画图讲清流程。比如Spark的宽窄依赖面试官真正想看的是你能不能说出窄依赖如何支持pipeline计算、宽依赖为什么会触发Shuffle以及Stage是怎么切分的。项目经验这一块面试官最反感的是“项目用的技术点和我问的方向对不上”。如果你做的是数据大屏项目用ReactTypeScript做前端展示核心加分点一定是后台数据链路比如用Doris或ClickHouse支撑大屏的秒级查询用Flink实时计算PV/UV指标。所以简历上写项目时要画出完整的数据流图讲清楚每个环节的选型理由和优化方案而不是罗列一堆框架名称。6. 常见问题与排查技巧实录6.1 数据倾斜最经典也最头疼的问题数据倾斜几乎是每个大数据工程师都会遇到的问题。现象是某个任务运行特别慢大部分Executor都跑完了就剩一两个任务卡在那里甚至一直失败重试。原因是数据分布不均比如某个热门Key占了大头单机处理不过来人。排查分三步。第一步在Spark UI或Flink UI上看每个Task的处理数据量找出明显偏大的Task。第二步定位倾斜Key常见做法是写临时SQL按Key聚合统计大小找出Top N。第三步根据场景选择方案如果是聚合导致的倾斜可以用两阶段聚合加随机前缀后局部聚合再去掉前缀全局聚合如果是Join导致的倾斜可以把小表广播出去或者给大表的倾斜Key加随机前缀再和小表膨胀后的数据Join。6.2 OOM与GC调优经验OOM内存溢出出在Executor或TaskManager上很常见但原因往往是上层资源规划不合理。比如Spark作业把每个Executor的内存设得巨大但并行度很低结果少数几个Task占满了堆内存GC频繁到CPU被打满。我的调优经验是先调整并行度控制每个Task处理的数据量再用广播变量代替大表Join最后才是调内存比例。Spark内存参数里spark.memory.fraction和spark.memory.storageFraction需要配合调整给shuffle和聚合留够空间但别把所有内存都塞给执行要留出系统缓冲。Flink的OOM排查则要关注RocksDB状态后端如果状态里存了大量KeyRocksDB的磁盘占用会快速膨胀这时候要检查Key是否设计得过于细粒度或者需要开启状态TTL清理过期数据。6.3 集群常见故障速查表故障现象可能原因排查命令/工具处理思路NameNode进入SafeMode块丢失比例过高或手动设置hdfs dfsadmin -safemode get检查DataNode是否大面积掉线恢复后自动退出必要时手动leaveSpark作业一直PendingYarn资源不足或队列堵塞yarn application -list, yarn node -list检查队列使用情况释放低优任务或扩容Kafka消费组Lag暴涨消费者处理慢或分区数不足kafka-consumer-groups.sh --describe定位高Lag分区扩容消费者优化处理逻辑ZooKeeper会话超时频繁节点负载高或网络抖动jstat、dmesg、网络监控隔离高负载组件检查网络丢包增大session timeoutHive查询慢未走分区裁剪或数据倾斜explain查看执行计划补充分区条件优化join策略处理倾斜KeyClickHouse占满内存大数据量group by无索引下推system.query_log加索引、分批查询、调整max_memory_usage这里给一个小建议日常做集群运维时尽量把监控指标和日志集中到一套体系里比如Prometheus Grafana ELK不要等出故障了才去台机器上翻日志。我在实践中体会最深的一条是绝大多数“玄学”问题最后都能归结到资源不足、版本不兼容或者数据本身有问题这三类先按这三个方向排查往往能少走很多弯路。最后再分享一点个人体会。这套学习记录写下来我自己最大的收获不是记住了多少工具参数而是建立起了一个“选型思维”面对一个业务需求能快速判断它属于数据链路中的哪个环节应该由哪些组件配合完成以及每个组件在这个场景里起到什么作用。工具迭代很快新框架年年都有但这种基于底层原理的判断力是长期有效的也是面试官真正想从你身上看到的东西。