1. 这不是教科书里的概念图而是一张真实生产环境的“数据动脉解剖图”你打开招聘网站搜“大数据工程师”90%的JD里都列着HDFS、Spark、Flink、Yarn这些词——但它们真正在系统里是怎么咬合运转的不是孤立模块而是像人体循环系统一样HDFS是血管网络存着全量血液原始数据Yarn是骨髓造血中心动态分配计算资源MapReduce是老式输血泵稳定但慢Spark是新一代体外循环机内存加速支持流批一体Zookeeper是神经反射弧保障集群节点间心跳同步Storm和Flink则是两种不同设计哲学的“实时神经突触”一个追求极致低延迟毫秒级一个兼顾状态一致性与容错精确一次语义Lambda和Kappa架构则像两套并行的免疫系统——前者用批处理流处理双通道应对不同精度需求后者用统一引擎简化运维复杂度。Giraph是专攻图计算的“脑神经建模器”处理社交关系、推荐路径这类强连接问题DataFlow是谷歌提出的编程模型抽象后来被Flink深度借鉴把“数据如何流动”从代码里显式剥离出来。我带过三个不同行业的数据平台项目从某高校科研计算平台到某制造企业IoT时序分析系统再到某电商用户行为中台发现真正卡住落地的从来不是单个组件会不会装而是搞不清“为什么这里必须用Zookeeper而不是etcd”、“为什么Flink的Watermark机制比Storm的Trident更适配订单超时场景”、“为什么Yarn的CapacityScheduler在多租户环境下比FairScheduler更可控”。这篇内容不讲API怎么写不贴Hello World代码只拆解每个组件在真实数据链路中的不可替代性、协作边界、故障传导路径以及我在压测20TB日志、支撑5000并发实时任务时踩出的硬核经验。2. 系统设计逻辑为什么不是“堆砌组件”而是构建“数据契约链”2.1 分布式系统的本质矛盾一致性、可用性、分区容忍性CAP的动态权衡所有分布式大数据组件的设计本质上都是在CAP三角中寻找业务可接受的平衡点。这不是理论题而是每天要做的实操选择。比如HDFS默认采用强一致性CPNameNode主备切换时会短暂拒绝写入牺牲A保CP因为文件系统元数据错误会导致整个作业失败而Zookeeper为保障强一致性要求过半节点写成功才返回ZAB协议所以3节点集群最多容忍1节点宕机5节点才能容忍2节点故障——这直接决定了你集群的最小合理规模。再看Flink它通过Chandy-Lamport算法实现分布式快照Checkpoint在保证“精确一次”语义的同时允许部分算子异步快照这是对CAP的工程化妥协用短暂的计算延迟降低A换取状态强一致保C。而Storm的At-Least-Once语义则偏向AP通过消息重发保障可用性但需业务层去重。我曾在一个金融风控场景中吃过亏初期用Storm做交易反欺诈因网络抖动导致同一条告警重复触发三次下游短信网关被刷爆。后来切到Flink后通过配置checkpointingMode EXACTLY_ONCE和enableCheckpointing(60000)配合RocksDB状态后端彻底解决重复计算问题。关键不是组件好坏而是你的业务能否容忍“少算一次”还是“多算一次”。2.2 数据生命周期驱动的分层架构存储、调度、计算、协调、流控五层解耦真实的大数据平台不是扁平化堆叠而是按数据流转阶段垂直分层每层解决特定问题存储层HDFS/Giraph专用图存储核心诉求是“海量、廉价、可靠”。HDFS的块大小默认128MB非64MB新版本已升级是因为磁盘顺序读写吞吐远高于随机IO大块能摊薄寻道开销。我们实测过处理10GB日志文件用128MB块比分成100个100MB小文件MapReduce作业总耗时降低37%因为减少了NameNode元数据压力和TaskTracker调度次数。调度层Yarn本质是“资源银行”。ResourceManagerRM不执行任务只管资源借贷NodeManagerNM是“分行网点”管理本地CPU/内存ApplicationMasterAM是“贷款申请人”向RM申请容器Container再让NM启动任务。这里的关键陷阱是Yarn默认使用FairScheduler但多租户场景下A部门提交的Spark作业可能抢占B部门的Flink任务资源。我们最终切到CapacityScheduler为每个部门划分独立队列如queueA最大资源80%queueB固定20%并通过yarn.scheduler.capacity.root.queueA.minimum-user-limit-percent50限制单用户占用上限避免“一人大户吃垮全家”。计算层MapReduce/Spark/Flink/Storm差异在于“计算模型抽象粒度”。MapReduce是函数式编程的物理实现map()处理单条记录生成key,value对reduce()聚合相同key的value列表。它的瓶颈在磁盘IO——中间结果全落HDFS。Spark用RDD弹性分布式数据集抽象把计算图缓存在内存transformations如map/filter只是定义血缘actions如count/collect才真正触发执行。Flink更进一步用DataStream抽象把“数据流”作为一等公民keyBy()后每个key的状态可独立维护天然支持事件时间Event Time和水位线Watermark——这才是处理乱序日志的根本解法。协调层Zookeeper不是“注册中心”而是“分布式锁配置中心选主服务”的三合一。HDFS HA模式下ZKFCZK Failover Controller进程通过ZK的临时节点ephemeral znode监听NameNode状态一旦主NN心跳丢失ZK自动删除其znode备用NN立即创建同名节点完成抢主。我们曾因ZK集群时间不同步NTP未校准导致假脑裂两个NN都认为自己是active引发HDFS写入冲突。解决方案是强制所有ZK节点启用tickTime2000且initLimit10并用chrony替代ntpd做高精度时钟同步。流控层Storm/KafkaFlinkStorm的Spout-Bolt拓扑是推模型push-basedSpout主动拉取数据并分发给BoltFlink是拉模型pull-basedSourceFunction从Kafka消费时由Flink Runtime控制拉取速率和offset提交时机。这导致Storm在流量突增时容易Bolt积压OOM而Flink可通过setBufferTimeout(100)和setMaxParallelism(256)精细调控背压。某次大促期间Storm Topology因上游Kafka分区数从12扩到48Spout并发数未同步调整导致单个Spout线程消费4个分区CPU打满下游延迟飙升至分钟级。换成Flink后只需配置properties.setProperty(partition.discovery.interval.ms, 30000)自动感知分区变化并均衡负载。2.3 架构演进的底层驱动力从“批处理优先”到“实时性刚需”的范式迁移Lambda架构批流双通道的诞生源于早期技术局限Hadoop生态缺乏低延迟计算引擎。它用HDFSMapReduce跑T1离线报表用Storm跑实时大屏结果存储在HBase供查询。但双份代码、双份ETL、结果不一致成为运维噩梦。Kappa架构纯流式的出现本质是Flink/Kafka成熟后的必然选择——用同一套Flink Job处理历史数据replay Kafka Topic和实时数据consume Kafka Topic通过--fromDate 2023-01-01参数指定起始时间。我们迁移某用户画像系统时发现Lambda方案需维护23个Spark离线Job和17个Storm Topology而Kappa方案仅需4个Flink Job运维复杂度下降68%。但Kappa并非万能当需要复杂窗口聚合如“过去30天用户活跃度滑动窗口”且历史数据量极大时Flink的RocksDB状态后端可能面临磁盘IO瓶颈此时仍需用Spark SQL预计算宽表再用Flink做实时增量更新——这就是混合架构的现实主义选择。3. 核心组件深度解析参数、原理与生产级配置实录3.1 HDFS不只是“分布式文件系统”而是“数据底座的承重墙”HDFS的可靠性不靠单点而靠“冗余快速恢复”组合拳。默认副本数3但生产环境必须根据机架拓扑调整。我们部署在跨机房的5节点集群时将dfs.hosts配置为包含机房标签的文件# /etc/hadoop/conf/dfs.hosts node1.rack1 # 机房A node2.rack1 # 机房A node3.rack2 # 机房B node4.rack2 # 机房B node5.rack3 # 机房C再设置dfs.replication3和topology.script.file.name/path/to/rack-aware.sh确保3个副本分布在至少2个机房如rack1×2 rack2×1避免单机房断电导致数据不可用。NameNode的元数据fsimageedits log必须异地备份dfs.namenode.name.dirfile:///data/nn,viewfs://backup-nn/nn其中viewfs是Hadoop联邦文件系统指向另一套HDFS集群。最致命的配置陷阱是dfs.datanode.du.reserved——它预留磁盘空间给非HDFS进程如系统日志若设为0当磁盘写满时DataNode会自动退出引发副本不足告警。我们线上设为1073741824010GB并配合监控脚本每5分钟检查df -h /data/dn | awk NR2 {print $5} | sed s/%//超90%即触发告警。NameNode的JVM堆内存配置有严格公式Xmx 1GB 1MB × 元数据对象数。一个10亿文件的集群元数据对象约12亿含block、inode、lease等需Xmx1200g——显然不现实。因此必须开启NameNode联邦HDFS Federation将命名空间水平拆分/user目录由nn1管理/data目录由nn2管理每个NN只承载部分元数据压力。我们实测联邦后单NN堆内存从800GB降至200GBFull GC频率从每小时3次降至每天1次。3.2 Yarn资源调度的“交通管制系统”而非简单的“任务分发器”Yarn的Resource Model资源模型是理解调度的关键。它不识别CPU核心数只认vcores虚拟CPU和memory-mb。yarn.nodemanager.resource.cpu-vcores默认值常被误设为物理CPU数但实际应设为物理CPU数 × 超线程系数 × 安全冗余系数。例如32核64线程服务器设vcores48留16核给系统和ZK再配yarn.nodemanager.resource.memory-mb122880120GB则单Container最大可申请vcores4, memory-mb3072030GB。这里有个反直觉点Spark on Yarn的spark.executor.cores参数实际申请的是Yarn Container的vcores而非物理核。若设executor-cores5而Yarn单Container最大vcores4则Spark Driver会报Requested 5 vcores exceeds maximum allowed 4。CapacityScheduler的队列配置是运维重点。以下是我们生产环境的核心配置capacity-scheduler.xmlproperty nameyarn.scheduler.capacity.root.queues/name valuedefault,etl,ml,streaming/value /property property nameyarn.scheduler.capacity.root.etl.capacity/name value40/value !-- ETL队列固定占40%资源 -- /property property nameyarn.scheduler.capacity.root.ml.maximum-capacity/name value60/value !-- ML队列最多可用60%但平时只用20% -- /property property nameyarn.scheduler.capacity.root.streaming.user-limit-factor/name value2/value !-- streaming队列单用户最多用2倍队列容量 -- /property关键技巧user-limit-factor用于应对突发需求。比如streaming队列基础容量10%当某实时风控Job需要瞬时扩容可临时占用20%资源而不影响其他队列。但必须配合yarn.scheduler.capacity.root.streaming.maximum-am-resource-percent0.5限制ApplicationMasterAM最多占用50%队列资源防止单个AM吃光队列。3.3 Spark内存计算的“精密仪器”调优本质是“平衡GC与序列化开销”Spark性能70%取决于内存管理。spark.executor.memory和spark.executor.memoryFraction默认0.6共同决定执行内存Execution Memory。但真正关键的是spark.memory.fraction默认0.6和spark.memory.storageFraction默认0.5——前者是堆内存中用于执行存储的比例后者是存储内存中可被抢占的比例。我们曾遇到Shuffle阶段OOMExecutor堆内存32GBmemoryFraction0.6→ 执行内存19.2GB但storageFraction0.5→ 存储内存9.6GB。当Broadcast变量过大如10GB特征矩阵存储内存不足触发Eviction频繁GC拖慢Shuffle。解决方案是调低storageFraction至0.2释放更多空间给执行内存并改用spark.sql.adaptive.enabledtrue开启自适应查询执行AQE让Spark在运行时动态合并小文件、优化Join策略。序列化是另一大瓶颈。Java序列化默认体积大、速度慢。我们强制使用Kryo序列化val conf new SparkConf() .set(spark.serializer, org.apache.spark.serializer.KryoSerializer) .registerKryoClasses(Array(classOf[User], classOf[Order]))但Kryo需提前注册类否则反序列化失败。更激进的方案是spark.sql.adaptive.coalescePartitions.enabledtrueAQE自动合并Shuffle后的小分区减少Task数量——某次ETL作业从1200个Task降至280个耗时从42分钟压缩到11分钟。3.4 Flink流处理的“实时操作系统”状态管理是灵魂Flink的State Backend选择决定生死。MemoryStateBackend仅用于测试FsStateBackend基于HDFS适合中小状态生产环境必须用RocksDBStateBackend因为它把状态存磁盘仅热数据放内存突破JVM堆内存限制。但RocksDB有隐藏成本每个KeyGroup对应一个ColumnFamily若Key数量达亿级ColumnFamily过多会耗尽Linux文件句柄。解决方案是state.backend.rocksdb.options-factory自定义配置public class CustomRocksDBOptionsFactory implements ConfigurableRocksDBOptionsFactory { Override public DBOptions createDBOptions(DBOptions currentOptions, CollectionAutoCloseable handlesToClose) { return currentOptions.setIncreaseParallelism(4); // 增加RocksDB线程数 } Override public ColumnFamilyOptions createColumnFamilyOptions(ColumnFamilyOptions currentOptions, CollectionAutoCloseable handlesToClose) { return currentOptions.setWriteBufferSize(67108864) // 64MB写缓冲区 .setMaxWriteBufferNumber(4); // 最多4个缓冲区 } }Watermark机制是处理乱序的核心。假设订单日志的event_time字段可能延迟5分钟到达需设置env.getConfig().setAutoWatermarkInterval(5000); // 每5秒生成Watermark DataStreamOrder stream env.addSource(kafkaSource) .assignTimestampsAndWatermarks( WatermarkStrategy.OrderforBoundedOutOfOrderness(Duration.ofMinutes(5)) .withTimestampAssigner((event, timestamp) - event.getEventTime()) );但注意forBoundedOutOfOrderness是全局Watermark若不同分区延迟差异大如北京分区延迟1分钟广州分区延迟8分钟需用PunctuatedWatermarks按事件生成Watermark或改用IngestionTime摄入时间——后者由Flink Source端打时间戳规避事件时间乱序问题。3.5 Zookeeper分布式协调的“神经系统”会话超时是最大雷区ZK会话超时session timeout不是心跳间隔而是客户端最后一次收到响应后等待下一次响应的最大时间。默认tickTime2000msinitLimit10即20秒syncLimit510秒。但生产环境必须调大tickTime3000initLimit20syncLimit10避免网络抖动导致假失效。更关键的是客户端配置zookeeper.session.timeout.ms必须≤服务端tickTime×initLimit否则连接直接被拒。我们曾因客户端设timeout60000而服务端initLimit1030秒导致ZKFC频繁失联。ZK的maxClientCnxns参数常被忽略。默认0无限制但单节点ZK最多支撑2000个连接。当Flink JobManager、Kafka Broker、HDFS ZKFC同时连接极易超限。我们设为1000并用echo stat | nc zk1 2181 | grep Connections实时监控连接数。4. 实战部署与排障从集群搭建到故障定位的完整链路4.1 集群部署黄金 checklist避开90%的“安装即崩溃”部署前必须完成的7项硬性检查时间同步所有节点执行chronyc tracking确认System time误差10msLeap status为Normal。禁用ntpd因其步进式校时会引发ZK会话中断。主机名解析/etc/hosts中必须用FQDNFully Qualified Domain Name如node1.cluster.local禁用localhost或IP直连。HDFS HA依赖DNS解析否则ZKFC无法识别NameNode身份。SSH免密登录不仅是主节点到从节点还要从节点到主节点HDFS Balancer需要反向连接。用ssh-copy-id -i ~/.ssh/id_rsa.pub usernode批量部署并验证ssh node1 date ssh node2 date输出时间一致。ulimit调优/etc/security/limits.conf中添加* soft nofile 65536 * hard nofile 65536 * soft nproc 65536 * hard nproc 65536否则Yarn NodeManager启动时因文件句柄不足报Too many open files。JDK版本锁定Hadoop 3.x要求JDK 8u191或JDK 11但Spark 3.2推荐JDK 11。统一用JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64并在hadoop-env.sh和spark-env.sh中显式声明。磁盘IO隔离HDFS DataNode、Yarn NodeManager、Zookeeper dataDir必须分盘。ZK的dataDir和dataLogDir事务日志必须挂载到不同物理盘否则日志刷盘阻塞数据读写。内核参数优化/etc/sysctl.conf追加vm.swappiness1 # 降低swap倾向 net.core.somaxconn65535 # 提升TCP连接队列 fs.file-max6553600 # 增大系统文件句柄上限执行sysctl -p生效。部署后必跑的3个验证命令hdfs dfsadmin -report检查DataNode是否全部在线Configured Capacity与DFS Remaining比例是否正常10%为安全线yarn node -list -all确认NodeManager状态为RUNNINGHealth Report为Healthyecho ruok | nc localhost 2181返回imok表示ZK服务存活注意这是ZK四字命令非HTTP4.2 故障排查实战手册从现象到根因的决策树现象1HDFS写入缓慢hdfs dfs -put耗时超预期排查路径Step1hdfs fsck / -files -blocks -locations检查块分布确认无大量under-replicated blocks副本不足Step2iostat -x 1 3查看DataNode磁盘%util是否持续90%若是则检查dfs.datanode.max.transfer.threads默认4096调高至8192Step3jstack NN_PID搜索BLOCKED线程若大量线程阻塞在FSNamesystem.writeLock说明NameNode写锁竞争激烈需开启dfs.namenode.enable.retrycachetrueHadoop 2.6现象2Spark Job卡在stage N: Shuffle ReadExecutor日志出现FetchFailedException根因与解法网络层netstat -s | grep -i retransmit检查重传率1%需排查交换机丢包Shuffle层spark.shuffle.io.maxRetries10默认3spark.shuffle.io.retryWait60s默认5s增大重试容忍度磁盘层spark.local.dir指向SSD盘避免HDD成为瓶颈spark.shuffle.compresstrue减小网络传输量现象3Flink Job重启后状态丢失Checkpoint报CheckpointDeclinedException关键检查点state.checkpoints.dir路径权限Flink JobManager用户必须有写权限且HDFS需开启dfs.permissions.enabledfalse或正确配置ACLstate.backend.rocksdb.predefined-options必须设为SPINNING_DISK_OPTIMIZED_HIGH_MEM机械盘或FLASH_SSD_OPTIMIZEDSSDexecution.checkpointing.tolerable-failed-checkpoints3允许连续3次Checkpoint失败后才Fail Job避免瞬时IO抖动导致重启现象4Zookeeper集群出现Not enough votesLeader选举失败决策树若3节点集群2节点宕机 → 无法选举过半原则需人工介入rmr /hadoop-ha强制清理ZK状态若所有节点zkServer.sh status显示Mode: follower→ 检查myid文件内容是否与zoo.cfg中server.x定义一致如server.1node1:2888:3888则myid必须为1若zkCli.sh连接后ls /超时 → 检查4lw.commands.whitelist*是否在zoo.cfg中配置否则四字命令被禁用4.3 性能压测标准流程用真实数据说话拒绝“纸上谈兵”我们采用三级压测法Level 1单组件基准测试HDFS用TestDFSIO写入100个1GB文件hadoop jar hadoop-test.jar TestDFSIO -write -nrFiles 100 -fileSize 1000Yarn用SleepJob模拟CPU密集型任务hadoop jar hadoop-mapreduce-client-jobclient-tests.jar SleepJob -m 100 -r 50 -mt 1000 -rt 1000结果指标HDFS吞吐MB/s、Yarn任务调度延迟msLevel 2混合负载测试同时运行Spark SQL扫描1TB Parquet表 Flink实时消费Kafka 10万QPS订单流 MapReduce统计HDFS文件数监控重点Yarn RM的AppsPending队列长度、ZK的Latency_avg应10ms、HDFS的BlockReportsAvgTime应500msLevel 3故障注入测试使用chaosblade工具模拟blade create network delay --interface eth0 --time 3000 --offset 1000网络延迟blade create disk fill --path /data/nn --size 90磁盘写满验证HDFS自动恢复时间5分钟Flink Job在3次Checkpoint失败后自动从最近成功点恢复某次压测发现当Yarn队列资源使用率达95%时Flink JobManager向RM申请Container的平均耗时从200ms飙升至8秒。根因是RM的yarn.resourcemanager.scheduler.monitor.policies未启用ProportionalCapacityPreemptionPolicy资源抢占策略。启用后高优先级队列可强制回收低优先级Container将延迟压回500ms内。5. 架构选型避坑指南没有银弹只有最适合的组合5.1 “HDFS vs 对象存储”不是技术优劣而是成本与场景的博弈HDFS仍是批处理首选但对象存储如S3、OSS在云原生场景崛起。关键差异维度HDFSS3/OSS一致性模型强一致性写后立即可读最终一致性GET可能读到旧版本元数据性能NameNode内存索引百万文件list毫秒级ListObjects API延迟高10万文件需数秒成本结构服务器磁盘折旧CAPEX按GB/月付费请求次数OPEX适用场景高频随机读写、低延迟元数据操作如Hive Metastore归档冷数据、跨云迁移、无需强一致性的日志存储我们某客户从IDC迁移到公有云时将HDFS用于实时计算层Flink Checkpoint、Spark ShuffleS3用于原始日志归档和机器学习样本库。通过flink-s3-fs-hadoop插件无缝对接但必须配置fs.s3a.implorg.apache.hadoop.fs.s3a.S3AFileSystem和s3a.block.size134217728128MB匹配HDFS块大小避免小文件读放大。5.2 “Flink vs Spark Streaming”流处理的十字路口选错代价巨大Spark Streaming微批和Flink原生流的本质区别在于时间语义Spark Streaming的batchDuration1s实际是每秒启动一个微批事件时间窗口如window(10 minutes)在批内计算无法处理跨批次的乱序事件。某次活动大屏统计“近10分钟下单量”因网络抖动导致第9分钟的数据晚于第10分钟到达Spark将其分到两个批次结果漏计。Flink的TumblingEventTimeWindows.of(Time.minutes(10))基于事件时间戳排序配合Watermark确保即使数据延迟5分钟只要在Watermark之后到达仍能正确归入对应窗口。但Flink也有短板复杂ETL场景下Spark SQL的优化器Catalyst和Tungsten执行引擎对多表Join、聚合的优化更成熟。我们最终采用混合方案Flink做实时清洗和轻量聚合如UV统计结果写入KafkaSpark Structured Streaming消费该Kafka Topic做深度关联如用户画像订单物流并写入Hive。这样既发挥Flink实时性又利用Spark SQL的SQL生态优势。5.3 “Zookeeper vs etcd”协调服务的选型铁律Zookeeper和etcd都是CP系统但设计哲学迥异Zookeeper面向Java生态提供Watch机制事件通知、临时节点ephemeral node、顺序节点sequential node完美匹配HDFS HA、Kafka Broker注册等场景。但REST API弱运维工具链zkCli命令晦涩。etcd面向云原生gRPC接口、HTTP/JSON API友好与Kubernetes深度集成。但缺少ZK的Watch语义需客户端轮询或使用watch命令长连接。我们的选型铁律存量Hadoop生态必须用ZK。强行替换etcd会导致HDFS NameNode无法选主、Yarn ResourceManager无法HA。新项目如K8s上部署Flink Native Kubernetes则直接用etcd通过flink-conf.yaml配置kubernetes.rest-service.exposed-type: LoadBalancer和high-availability.storageDir: s3://flink-ha/完全绕过ZK依赖。5.4 “Lambda vs Kappa”架构决策的终极拷问——你的业务能承受多大程度的“不一致”Lambda架构的“不一致”是结果不一致离线报表和实时大屏数字不同需人工核对。Kappa架构的“不一致”是过程不一致Flink重放历史数据时因UDF逻辑变更如税率计算规则更新导致重算结果与原始离线结果偏差。我们某税务分析系统选择Lambda因为监管要求所有报表必须经离线MapReduce校验实时数据仅作预警参考。而某推荐系统采用Kappa因业务容忍“昨天的推荐结果和今天的略有不同”且省下的20人/年运维成本远超数据微小偏差带来的商业损失。真正的架构师不做非此即彼的选择而是画出数据一致性容忍度曲线横轴是时间T0到T24h纵轴是业务可接受的误差率0.1%~5%。曲线越陡峭越倾向Lambda越平缓越倾向Kappa。6. 运维监控体系让集群“会说话”而非“等它崩溃”6.1 必须监控的12个黄金指标附Prometheus配置脱离监控的集群如同盲人开车。我们提炼出12个不可妥协的核心指标指标Prometheus Query告警阈值业务含义hadoop_namenode_capacity_used_percenthadoop_namenode_capacity_used / hadoop_namenode_capacity_total * 10085%HDFS存储超载影响新文件写入hadoop_datanode_remaining_percenthadoop_datanode_remaining / hadoop_datanode_capacity_total * 10010%DataNode磁盘将满触发副本删除yarn_cluster_metrics_apps_pendingyarn_cluster_metrics_apps_pending50Yarn资源严重不足新任务排队flink_jobmanager_num_registered_taskmanagersflink_jobmanager_num_registered_taskmanagers0.8×总TM数TaskManager失联计算能力下降zookeeper_server_zxid_proposedzookeeper_server_zxid_proposed1小时内无增长ZK Leader停止提案集群僵死kafka_broker_topic_partition_under_replicated_countsum by (topic) (kafka_broker_topic_partition_under_replicated_count)0Kafka副本同步异常数据丢失风险jvm_memory_pool_used_bytes{poolMetaspace}jvm_memory_pool_used_bytes{poolMetaspace}90% of maxJVM元空间泄漏常见于动态类加载process_open_fdsprocess_open_fds80% offs.file-max文件句柄泄漏进程可能被OS killnetwork_receive_bytes_total{deviceeth0}rate(network_receive_bytes_total{deviceeth0}[5m])10MB/s千兆网卡网络中断或交换机故障disk_io_time_seconds_total{devicesda}rate(disk_io_time_seconds_total{devicesda}[5m])0.8磁盘IO饱和影响HDFS读写flink_taskmanager_job_task_operator_current_input_watermarkmin(flink_taskmanager_job_task_operator_current_input_watermark)滞后当前时间5minFlink Watermark停滞实时性失效hadoop_namenode_corrupt_blockshadoop_namenode_corrupt_blocks0数据块损坏需立即修复6.2 日志分析的“三板斧”grep、awk、jq的极限用法生产环境日志是故障第一现场。我们总结出高效分析法定位异常堆栈zcat yarn--resourcemanager-.log.gz | grep -A 5 -B 5
