1. 学习环境准备云主机选型与软件栈1.1 为什么我坚持用云主机而不是本地虚拟机Day6这个时间节点很多人的学习进度会在这里出现一次明显的分化。有人前三五天已经装完环境、跑通了HDFS和YARN的基础命令有人则还在跟虚拟机抢内存、跟网络重名冲突较劲。我自己带过不少新手发现一个共通的规律凡是本地虚拟机方案坚持到第六天还顺畅的几乎都有两个前提一是电脑配置确实扛得住二是对Linux操作已经有肌肉记忆。如果你不满足这两个前提我强烈建议把学习环境直接放到云平台上这也是目前“基于云平台大数据应用开发”最主流的做法。用云主机做大数据开发学习环境最直观的好处是隔离性和一致性。大数据组件动辄占用好几个GB内存Hadoop生态的进程又多NameNode、DataNode、ResourceManager、NodeManager再加上后续要装的Hive、Spark、Flume这套组合拳下来8GB内存的电脑基本只能干看着风扇狂转。云主机则可以把内存规格开到16GB甚至32GB本地电脑只承担一个SSH终端连接的工作压力瞬间转移到云端。更重要的是云平台上的环境是固定的你在这台机器上踩过的坑、配好的参数、积累的脚本可以原样保留不会因为本地软件更新、系统重装、网络环境切换而把辛苦搭好的环境弄坏。另一个被很多人忽略的点是云主机天然具备“公网可达”的属性。大数据开发到了中后期一定会涉及多节点协同、外部系统对接、接口联调这些场景数据源不可能永远只在本机生成。举个实际例子我在Day6设计学习任务时需要模拟一台“远端服务器”持续产生业务日志这个场景如果放在本地虚拟机里要么把数据生成脚本挂在本机后台要么用容器模拟绕来绕去总觉得缺了点真实感。而云主机本身就有公网IP训练数据服务的部署位置和模拟方式都更接近企业里的真实形态这对建立工程直觉非常有帮助。如果你之前完全没有接触过云平台不要被“云主机”三个字吓到。国内主流的云平台都提供按量计费或者轻量应用服务器套餐新用户往往还有免费试用额度。对于学习用途一台2核4GB或者4核8GB内存的云主机足够支撑到学习周期结束关键是操作系统选CentOS 7.9或者Ubuntu 20.04这两套系统在Hadoop生态下的兼容性资料最多碰到问题随便一搜都有解法。1.2 软件栈版本组合与配置参数参考软件版本搭配是新手最容易忽略、却又最容易导致后期返工的问题。很多教程在安装Hadoop时直接写了最新版本号但其实大数据生态各组件之间存在很强的版本绑定关系盲目追新会给自己埋雷。我在第一天定学习计划时就按“稳定优先、生态匹配”的原则固定了一套版本组合到Day6依然沿用它目前跑下来没有任何兼容性问题。推荐版本组合参考如下JDK1.8对应Java 8这是Hadoop 2.x/3.x系列兼容性最好的Java版本Hadoop3.3.4配套的HDFS、YARN、MapReduce框架相对成熟且社区资料充足Spark3.2.4对应Scala 2.12与Hadoop 3.3.x搭配使用很稳妥Flume1.9.0用于日志采集配置文件简单适合学习阶段理解数据接入流程Hive3.1.3元数据存储使用内置Derby即可学习阶段不需要单独部署MySQL注意安装JDK时优先使用官方提供的tar.gz包手动解压配置不要直接用系统自带的OpenJDK版本。部分系统自带的JDK路径不标准容易导致Hadoop脚本找不到JAVA_HOME排查起来很麻烦。云主机内存配置上我建议给Hadoop相关进程预留足够空间。在/etc/hadoop/hadoop-env.sh中设置HADOOP_HEAPSIZE为1024MB或2048MB如果机器内存只有4GB可以调低到512MB防止OOM。YARN的NodeManager内存参数yarn.nodemanager.resource.memory-mb可以根据总内存按比例分配我实际使用的配置是总内存8GB时分配给YARN 6GB留给系统和其他进程2GB余量。这套资源规划思路比单纯抄配置有价值得多因为在实际项目里资源分配不均导致的性能问题会比代码逻辑问题更隐蔽。2. 实战内容拆解第一条端到端数据链路2.1 Day6实战任务的完整设计到今天为止HDFS的常用命令、YARN的任务调度机制、MapReduce的基本流程这些知识点都已经过了。我发现很多人在前五天会陷入一个误区知识点学了不少但零散的厉害每个命令都会敲可一旦要把它们串成一个有业务含义的完整流程反而不知道从哪下手。Day6的核心任务就是打破这种“知识孤岛”的状态完整走一遍从数据生产、采集、存储到计算、输出的全链路。这条链路的具体设计是这样的。第一步用Shell脚本或者Python脚本生成一份模拟的Web服务器访问日志内容包含时间戳、访问IP、请求路径、状态码、响应耗时等字段。第二步使用Flume采集这份日志文件中的数据实时写入HDFS的指定目录。第三步通过MapReduce或Spark读取HDFS上的日志数据统计出访问量最高的TOP 10请求路径。最后将统计结果写入HDFS的统计表目录中查看输出文件。整个任务看起来不难但它实际上串联了大数据开发中最核心的一条主线“数据从哪来—怎么进—存在哪—怎么算—结果放哪”。每个环节都会用到此前几天学的知识同时又强制你重新思考这些知识之间的关系。例如Flume采集日志时你会发现自己需要理解Flume的source、channel、sink三段结构而不是只会用现成命令。MapReduce统计任务会让你把Mapper、Reducer、Partitioner、Combiner这些概念真正落实到代码里而不只是背概念。2.2 计算引擎选型从MapReduce到Spark的理由任务设计时我在“用MapReduce还是用Spark”这个问题上纠结了一阵。在Day6这个时间点MapReduce是刚学过的内容Spark则属于还没系统接触的“新东西”。按学习闭环的规律新知识应当优先巩固旧知识所以我建议Day6先以MapReduce为主要的计算实现方案Spark作为扩展挑战。在实际项目中Spark的实时性和开发效率确实优于MapReduce但如果没有MapReduce打底直接上手Spark很多优化手段会让你陷入“知其然不知其所以然”的困惑。MapReduce任务的特点是稳定、逻辑清晰但代码量偏多。以统计日志中的TOP 10请求路径为例需要自己编写Mapper类、Reducer类还需要考虑作业配置、输入输出路径等参数。这个过程虽然繁琐却能让你真切理解数据是怎样被分片、排序、合并、归约的。当你亲手把一条日志从文本变成键值对再从键值对聚合成统计结果Hadoop底层的“分而治之”思想会有非常直观的体感这种体验是直接用Spark一行reduceByKey替代不来的。当然不能厚此薄彼。我建议有基础的同学在完成MapReduce版本后额外用Spark RDD重写同一个统计逻辑。对比两次实现你会看到两种引擎在代码表达、任务调度、中间结果落盘方式上的差异这也是后续深入学习Spark的良好切入点。我在第四天搭建环境时特意装好了Spark就是为Day6这个扩展任务做的准备事实证明这样安排很顺。3. 核心实操流程与关键细节3.1 用脚本构造一份像样的仿真日志真实业务里的Web访问日志字段组成是有规律的不像很多人练习时随意造几个单词就完事。为了让Day6的数据处理效果更接近实际情况我在设计日志生成脚本时加入了时间戳、用户IP、请求方法、请求路径、协议版本、状态码、响应时长、来源页、User-Agent共九类字段。关键实现思路是用随机函数模拟真实分布而不是完全均匀地随机。例如某些热门接口如/api/user/login、/api/order/list被访问的频率应当明显高于普通路径这样最终统计出的TOP 10才有区分度。状态码也不能只生成200还要按一定比例混入404、500、302这样后续做质量分析才有素材。我写的是一个Python脚本通过random.choices配合权重列表控制各类字段的出现概率每秒钟生成约50条日志写入一个不断追加的本地文件。脚本运行后可以用tail -f命令实时观察日志内容生成情况。这一步看起来很简单但它是检验后续Flume采集链路是否正常的“数据源头”如果源头数据格式不对后面所有统计都会受影响。我当时就吃过亏脚本里时间戳用的默认格式和后续统计时想提取的日期字段格式对不上导致解析环节白白浪费了半小时。日志生成时有一个容易被忽视的细节要保证文件按天或按小时滚动。真实场景中日志文件不会无限增长而是会按时间周期切割。模拟这种滚动机制可以在脚本里根据系统时间自动切换输出文件文件名带上日期后缀。这个细节直接关系到Flume的spooldir采集方式能否正确感知新文件也影响HDFS上数据按时间分目录存储的设计。3.2 Flume采集链路配置与运行时细节Flume在这条链路里扮演的是“搬运工”角色它的三段结构Source、Channel、Sink需要有一个清晰的认知框架。Source负责从数据源读取数据Channel作为中间缓冲队列暂存数据Sink负责把数据推送到目标存储。Day6使用exec source监听日志文件新增内容使用file channel做本地落盘缓冲使用hdfs sink写入HDFS。# flume-day6.conf agent1.sources logsource agent1.channels filechannel agent1.sinks hdfssink agent1.sources.logsource.type exec agent1.sources.logsource.command tail -F /data/weblog/access.log agent1.sources.logsource.shell /bin/bash -c agent1.sources.logsource.interceptors i1 agent1.sources.logsource.interceptors.i1.type regex_filter agent1.sources.logsource.interceptors.i1.regex ^\\d{4}-\\d{2}-\\d{2} agent1.sources.logsource.interceptors.i1.excludeEvents false agent1.channels.filechannel.type file agent1.channels.filechannel.checkpointDir /data/flume/checkpoint agent1.channels.filechannel.dataDirs /data/flume/data agent1.channels.filechannel.capacity 10000 agent1.channels.filechannel.transactionCapacity 1000 agent1.sinks.hdfssink.type hdfs agent1.sinks.hdfssink.hdfs.path hdfs://localhost:9000/flume/weblog/dt%Y%m%d agent1.sinks.hdfssink.hdfs.filePrefix access_log agent1.sinks.hdfssink.hdfs.rollInterval 60 agent1.sinks.hdfssink.hdfs.rollSize 134217728 agent1.sinks.hdfssink.hdfs.rollCount 0 agent1.sinks.hdfssink.hdfs.fileType DataStream agent1.sources.logsource.channels filechannel agent1.sinks.hdfssink.channel filechannel配置文件里hdfs.path中使用了%Y%m%d时间格式Flume会自动将当前时间转换成对应的日期目录这样HDFS上的文件天然就按天归档了。rollInterval设置为60秒作用是让HDFS上的文件不长期处于“正在写入”状态而是每隔一段时间生成一个可读取的小文件这在学习阶段更方便用HDFS命令直接查看。如果rollCount和rollSize不设置文件可能会持续增长在真实生产环境里会影响下游读取效率这也是一个值得记住的调优点。启动Flume后要观察日志输出重点看有没有报错、以及Event数量是否持续增加。我习惯用另外一个终端窗口同时执行hdfs dfs -ls /flume/weblog/查看HDFS目录下的文件生成情况。如果你看到文件大小在增长说明整条采集链路已经通了下一步就可以放心去做统计计算。3.3 统计任务的实现思路与代码级要点接下来是Day6的核心计算环节。我用MapReduce实现“统计访问路径TOP 10”完整代码结构并不复杂但每一个类背后的职责都值得细品。Mapper阶段读取的每一行是对应一条访问日志按空格切分后请求路径是第7个字段这是由日志格式决定的需要你在代码中确认字段下标。Mapper输出的key是请求路径value是固定值1。Reducer阶段把相同key的value累加得到每个路径的访问总量。为了让最终只输出TOP 10可以在Reducer端维护一个TreeMap遍历时保留前10个最大键值对。这时TreeMap的自然排序效果就体现出来了不用额外引入复杂的排序逻辑。public class TopNReducer extends ReducerText, IntWritable, Text, IntWritable { private TreeMapInteger, String topMap new TreeMap(); Override protected void reduce(Text key, IterableIntWritable values, Context context) { int sum 0; for (IntWritable val : values) { sum val.get(); } topMap.put(sum, key.toString()); if (topMap.size() 10) { topMap.remove(topMap.firstKey()); } } Override protected void cleanup(Context context) throws IOException, InterruptedException { for (Map.EntryInteger, String entry : topMap.entrySet()) { context.write(new Text(entry.getValue()), new IntWritable(entry.getKey())); } } }这里有一个容易踩的坑如果直接使用TreeMapInteger, String当两个路径的访问量相同时后面的key会覆盖前面的key导致丢失统计结果。解决方式是把TreeMap的value改成存储路径的List或者在记录条目时使用组合key。我在Day6的代码里用了List方案既保留了全部统计结果又没有增加多少代码量。Reduce阶段还需要注意一个MapReduce的基础概念Partitioner。默认情况下相同的key会被分发到同一个Reducer这个过程由默认的HashPartitioner完成。TOP 10这种场景数据量不大使用一个Reducer就足够了把mapreduce.job.reduces设为1即可。如果你尝试设置为多个Reducer最终会得到多个输出文件每个文件部分有序但合并成全局TOP 10还需要额外步骤这会增加复杂度学习阶段不建议这样搞。写完代码后用hadoop jar命令提交作业观察YARN的Application日志。作业运行期间可以用yarn application -status查看进度也可以到ResourceManager的Web界面上看详细的任务执行情况。Day6跑完作业你会看到一个真实存在的、自己亲手走通的数据处理流程这种成就感比刷100道选择题来得实在。4. 常见问题与排查技巧实录4.1 新手最容易踩的几个坑Day6这种多组件联动的场景问题通常会出现在组件之间的匹配、配置项的遗漏、路径不对这些“低级但致命”的地方。我这里把实际演练中遇到过的高频问题以及对应的排查思路整理成表格方便你对号入座。现象可能原因排查思路Flume启动成功但日志不采集exec source中trackerDir未配置Flume重启后从文件开头重新读取配置trackerDir为独立目录并检查日志文件是否有新内容写入写入HDFS的日志文件为空hdfs Sink与namenode通信失败或HDFS处于SafeMode检查HDFS集群状态执行hdfs dfsadmin -safemode get必要时等待自动退出MapReduce作业一直在调度但无进度YARN的NodeManager资源不足或容器频繁被kill查看YARN日志和系统内存使用情况调大容器内存或减少并发容器数统计结果缺字段HDFS上的日志文件格式与代码切分逻辑不一致先用head查看原始日志内容确认分隔符和字段下标Spark提交任务报ClassNotFound依赖的jar没有打进提交命令使用--jars参数指定依赖包或者打包成fat jar这些坑有一个共同特征报错信息并不直接告诉你“哪错了”需要你回到数据原点逐层排查。我在排查Flume问题时总结出一个原则先确认源端有没有数据再看通道里有没有事件最后检查目标端有没有落盘。这套“源—管道—目标”三步排查法在后续学习Kafka、Flink、DataWorks等各类数据组件时同样通用。4.2 线上排查时的通用思路排查问题如果一上来就瞎试往往会越搞越乱。我在Day6学到的教训是必须先建立一条“因果链”从输出端倒推逐步缩小范围。以“HDFS上没有生成Flume写入的文件”为例可以倒推检查HDFS目录是否存在、权限是否正确、namenode是否活跃、Flume的sink配置是否正确、channel中是否有积压事件、source是否真的读到了数据。沿着这条链查下去大约五分之一的概率就能定位到问题所在。查看日志文件也是一个重要的习惯。Flume的日志默认在logs/flume.logMapReduce的日志在YARN的聚合日志中。发现异常后第一件事不是去改配置而是先看日志分析报错堆栈到底指向哪个模块。很多人在群里提问时只截一句话“报错了”却不肯把堆栈贴全这其实是在浪费彼此的时间。学会看完整日志、能抓住堆栈中的关键异常类是开发者从新手走向熟练的重要分水岭。另一个实用原则是“隔离变量”。如果一次链路中有多个组件协同工作排查问题时只改动一个变量然后观察效果。比如Flume不写HDFS你可能同时怀疑source配置和sink配置这时先单独测sink是否能向HDFS写一个测试文件如果sink没问题再往前查source。一次动多处最后连哪个改动生效了都说不清楚这种调试习惯在真实项目里是致命的。结尾关于Day6的一点个人体会跑完Day6的完整流程我最大的感受是大数据开发的学习到了第六天真正开始了“从知识到能力”的过渡。前五天你学的是零件今天你把这些零件装成了一台能跑的机器。虽然这台机器还很粗糙但它能完成从日志采集到统计输出的完整闭环这就说明你已经拥有了“独立串起一条数据链路”的基础能力。如果非要给今天的学习提个建议我会说把每一步的验证动作做扎实。日志生成后先看文件是否在持续增长Flume启动后先看HDFS上有没有文件出现作业提交后先等它跑完再仔细看输出结果。这种“每一步都有反馈”的节奏能让你在报错发生时迅速定位到具体环节而不是在整条链路上迷茫地猜。从“基于云平台大数据应用开发”的角度来看今天是第一次真正体会到“云端数据工程”的完整样貌。后面随着Hive数仓、Spark SQL、实时计算框架的加入你会在今天搭建的这条主线上不断延伸和扩展逐步逼近大型数据平台的真实架构。但对现在的你来说能让一元钱的云主机跑出一条全链路的日志统计就已经足够为接下来的学习积蓄信心了。
1. 学习环境准备云主机选型与软件栈1.1 为什么我坚持用云主机而不是本地虚拟机Day6这个时间节点很多人的学习进度会在这里出现一次明显的分化。有人前三五天已经装完环境、跑通了HDFS和YARN的基础命令有人则还在跟虚拟机抢内存、跟网络重名冲突较劲。我自己带过不少新手发现一个共通的规律凡是本地虚拟机方案坚持到第六天还顺畅的几乎都有两个前提一是电脑配置确实扛得住二是对Linux操作已经有肌肉记忆。如果你不满足这两个前提我强烈建议把学习环境直接放到云平台上这也是目前“基于云平台大数据应用开发”最主流的做法。用云主机做大数据开发学习环境最直观的好处是隔离性和一致性。大数据组件动辄占用好几个GB内存Hadoop生态的进程又多NameNode、DataNode、ResourceManager、NodeManager再加上后续要装的Hive、Spark、Flume这套组合拳下来8GB内存的电脑基本只能干看着风扇狂转。云主机则可以把内存规格开到16GB甚至32GB本地电脑只承担一个SSH终端连接的工作压力瞬间转移到云端。更重要的是云平台上的环境是固定的你在这台机器上踩过的坑、配好的参数、积累的脚本可以原样保留不会因为本地软件更新、系统重装、网络环境切换而把辛苦搭好的环境弄坏。另一个被很多人忽略的点是云主机天然具备“公网可达”的属性。大数据开发到了中后期一定会涉及多节点协同、外部系统对接、接口联调这些场景数据源不可能永远只在本机生成。举个实际例子我在Day6设计学习任务时需要模拟一台“远端服务器”持续产生业务日志这个场景如果放在本地虚拟机里要么把数据生成脚本挂在本机后台要么用容器模拟绕来绕去总觉得缺了点真实感。而云主机本身就有公网IP训练数据服务的部署位置和模拟方式都更接近企业里的真实形态这对建立工程直觉非常有帮助。如果你之前完全没有接触过云平台不要被“云主机”三个字吓到。国内主流的云平台都提供按量计费或者轻量应用服务器套餐新用户往往还有免费试用额度。对于学习用途一台2核4GB或者4核8GB内存的云主机足够支撑到学习周期结束关键是操作系统选CentOS 7.9或者Ubuntu 20.04这两套系统在Hadoop生态下的兼容性资料最多碰到问题随便一搜都有解法。1.2 软件栈版本组合与配置参数参考软件版本搭配是新手最容易忽略、却又最容易导致后期返工的问题。很多教程在安装Hadoop时直接写了最新版本号但其实大数据生态各组件之间存在很强的版本绑定关系盲目追新会给自己埋雷。我在第一天定学习计划时就按“稳定优先、生态匹配”的原则固定了一套版本组合到Day6依然沿用它目前跑下来没有任何兼容性问题。推荐版本组合参考如下JDK1.8对应Java 8这是Hadoop 2.x/3.x系列兼容性最好的Java版本Hadoop3.3.4配套的HDFS、YARN、MapReduce框架相对成熟且社区资料充足Spark3.2.4对应Scala 2.12与Hadoop 3.3.x搭配使用很稳妥Flume1.9.0用于日志采集配置文件简单适合学习阶段理解数据接入流程Hive3.1.3元数据存储使用内置Derby即可学习阶段不需要单独部署MySQL注意安装JDK时优先使用官方提供的tar.gz包手动解压配置不要直接用系统自带的OpenJDK版本。部分系统自带的JDK路径不标准容易导致Hadoop脚本找不到JAVA_HOME排查起来很麻烦。云主机内存配置上我建议给Hadoop相关进程预留足够空间。在/etc/hadoop/hadoop-env.sh中设置HADOOP_HEAPSIZE为1024MB或2048MB如果机器内存只有4GB可以调低到512MB防止OOM。YARN的NodeManager内存参数yarn.nodemanager.resource.memory-mb可以根据总内存按比例分配我实际使用的配置是总内存8GB时分配给YARN 6GB留给系统和其他进程2GB余量。这套资源规划思路比单纯抄配置有价值得多因为在实际项目里资源分配不均导致的性能问题会比代码逻辑问题更隐蔽。2. 实战内容拆解第一条端到端数据链路2.1 Day6实战任务的完整设计到今天为止HDFS的常用命令、YARN的任务调度机制、MapReduce的基本流程这些知识点都已经过了。我发现很多人在前五天会陷入一个误区知识点学了不少但零散的厉害每个命令都会敲可一旦要把它们串成一个有业务含义的完整流程反而不知道从哪下手。Day6的核心任务就是打破这种“知识孤岛”的状态完整走一遍从数据生产、采集、存储到计算、输出的全链路。这条链路的具体设计是这样的。第一步用Shell脚本或者Python脚本生成一份模拟的Web服务器访问日志内容包含时间戳、访问IP、请求路径、状态码、响应耗时等字段。第二步使用Flume采集这份日志文件中的数据实时写入HDFS的指定目录。第三步通过MapReduce或Spark读取HDFS上的日志数据统计出访问量最高的TOP 10请求路径。最后将统计结果写入HDFS的统计表目录中查看输出文件。整个任务看起来不难但它实际上串联了大数据开发中最核心的一条主线“数据从哪来—怎么进—存在哪—怎么算—结果放哪”。每个环节都会用到此前几天学的知识同时又强制你重新思考这些知识之间的关系。例如Flume采集日志时你会发现自己需要理解Flume的source、channel、sink三段结构而不是只会用现成命令。MapReduce统计任务会让你把Mapper、Reducer、Partitioner、Combiner这些概念真正落实到代码里而不只是背概念。2.2 计算引擎选型从MapReduce到Spark的理由任务设计时我在“用MapReduce还是用Spark”这个问题上纠结了一阵。在Day6这个时间点MapReduce是刚学过的内容Spark则属于还没系统接触的“新东西”。按学习闭环的规律新知识应当优先巩固旧知识所以我建议Day6先以MapReduce为主要的计算实现方案Spark作为扩展挑战。在实际项目中Spark的实时性和开发效率确实优于MapReduce但如果没有MapReduce打底直接上手Spark很多优化手段会让你陷入“知其然不知其所以然”的困惑。MapReduce任务的特点是稳定、逻辑清晰但代码量偏多。以统计日志中的TOP 10请求路径为例需要自己编写Mapper类、Reducer类还需要考虑作业配置、输入输出路径等参数。这个过程虽然繁琐却能让你真切理解数据是怎样被分片、排序、合并、归约的。当你亲手把一条日志从文本变成键值对再从键值对聚合成统计结果Hadoop底层的“分而治之”思想会有非常直观的体感这种体验是直接用Spark一行reduceByKey替代不来的。当然不能厚此薄彼。我建议有基础的同学在完成MapReduce版本后额外用Spark RDD重写同一个统计逻辑。对比两次实现你会看到两种引擎在代码表达、任务调度、中间结果落盘方式上的差异这也是后续深入学习Spark的良好切入点。我在第四天搭建环境时特意装好了Spark就是为Day6这个扩展任务做的准备事实证明这样安排很顺。3. 核心实操流程与关键细节3.1 用脚本构造一份像样的仿真日志真实业务里的Web访问日志字段组成是有规律的不像很多人练习时随意造几个单词就完事。为了让Day6的数据处理效果更接近实际情况我在设计日志生成脚本时加入了时间戳、用户IP、请求方法、请求路径、协议版本、状态码、响应时长、来源页、User-Agent共九类字段。关键实现思路是用随机函数模拟真实分布而不是完全均匀地随机。例如某些热门接口如/api/user/login、/api/order/list被访问的频率应当明显高于普通路径这样最终统计出的TOP 10才有区分度。状态码也不能只生成200还要按一定比例混入404、500、302这样后续做质量分析才有素材。我写的是一个Python脚本通过random.choices配合权重列表控制各类字段的出现概率每秒钟生成约50条日志写入一个不断追加的本地文件。脚本运行后可以用tail -f命令实时观察日志内容生成情况。这一步看起来很简单但它是检验后续Flume采集链路是否正常的“数据源头”如果源头数据格式不对后面所有统计都会受影响。我当时就吃过亏脚本里时间戳用的默认格式和后续统计时想提取的日期字段格式对不上导致解析环节白白浪费了半小时。日志生成时有一个容易被忽视的细节要保证文件按天或按小时滚动。真实场景中日志文件不会无限增长而是会按时间周期切割。模拟这种滚动机制可以在脚本里根据系统时间自动切换输出文件文件名带上日期后缀。这个细节直接关系到Flume的spooldir采集方式能否正确感知新文件也影响HDFS上数据按时间分目录存储的设计。3.2 Flume采集链路配置与运行时细节Flume在这条链路里扮演的是“搬运工”角色它的三段结构Source、Channel、Sink需要有一个清晰的认知框架。Source负责从数据源读取数据Channel作为中间缓冲队列暂存数据Sink负责把数据推送到目标存储。Day6使用exec source监听日志文件新增内容使用file channel做本地落盘缓冲使用hdfs sink写入HDFS。# flume-day6.conf agent1.sources logsource agent1.channels filechannel agent1.sinks hdfssink agent1.sources.logsource.type exec agent1.sources.logsource.command tail -F /data/weblog/access.log agent1.sources.logsource.shell /bin/bash -c agent1.sources.logsource.interceptors i1 agent1.sources.logsource.interceptors.i1.type regex_filter agent1.sources.logsource.interceptors.i1.regex ^\\d{4}-\\d{2}-\\d{2} agent1.sources.logsource.interceptors.i1.excludeEvents false agent1.channels.filechannel.type file agent1.channels.filechannel.checkpointDir /data/flume/checkpoint agent1.channels.filechannel.dataDirs /data/flume/data agent1.channels.filechannel.capacity 10000 agent1.channels.filechannel.transactionCapacity 1000 agent1.sinks.hdfssink.type hdfs agent1.sinks.hdfssink.hdfs.path hdfs://localhost:9000/flume/weblog/dt%Y%m%d agent1.sinks.hdfssink.hdfs.filePrefix access_log agent1.sinks.hdfssink.hdfs.rollInterval 60 agent1.sinks.hdfssink.hdfs.rollSize 134217728 agent1.sinks.hdfssink.hdfs.rollCount 0 agent1.sinks.hdfssink.hdfs.fileType DataStream agent1.sources.logsource.channels filechannel agent1.sinks.hdfssink.channel filechannel配置文件里hdfs.path中使用了%Y%m%d时间格式Flume会自动将当前时间转换成对应的日期目录这样HDFS上的文件天然就按天归档了。rollInterval设置为60秒作用是让HDFS上的文件不长期处于“正在写入”状态而是每隔一段时间生成一个可读取的小文件这在学习阶段更方便用HDFS命令直接查看。如果rollCount和rollSize不设置文件可能会持续增长在真实生产环境里会影响下游读取效率这也是一个值得记住的调优点。启动Flume后要观察日志输出重点看有没有报错、以及Event数量是否持续增加。我习惯用另外一个终端窗口同时执行hdfs dfs -ls /flume/weblog/查看HDFS目录下的文件生成情况。如果你看到文件大小在增长说明整条采集链路已经通了下一步就可以放心去做统计计算。3.3 统计任务的实现思路与代码级要点接下来是Day6的核心计算环节。我用MapReduce实现“统计访问路径TOP 10”完整代码结构并不复杂但每一个类背后的职责都值得细品。Mapper阶段读取的每一行是对应一条访问日志按空格切分后请求路径是第7个字段这是由日志格式决定的需要你在代码中确认字段下标。Mapper输出的key是请求路径value是固定值1。Reducer阶段把相同key的value累加得到每个路径的访问总量。为了让最终只输出TOP 10可以在Reducer端维护一个TreeMap遍历时保留前10个最大键值对。这时TreeMap的自然排序效果就体现出来了不用额外引入复杂的排序逻辑。public class TopNReducer extends ReducerText, IntWritable, Text, IntWritable { private TreeMapInteger, String topMap new TreeMap(); Override protected void reduce(Text key, IterableIntWritable values, Context context) { int sum 0; for (IntWritable val : values) { sum val.get(); } topMap.put(sum, key.toString()); if (topMap.size() 10) { topMap.remove(topMap.firstKey()); } } Override protected void cleanup(Context context) throws IOException, InterruptedException { for (Map.EntryInteger, String entry : topMap.entrySet()) { context.write(new Text(entry.getValue()), new IntWritable(entry.getKey())); } } }这里有一个容易踩的坑如果直接使用TreeMapInteger, String当两个路径的访问量相同时后面的key会覆盖前面的key导致丢失统计结果。解决方式是把TreeMap的value改成存储路径的List或者在记录条目时使用组合key。我在Day6的代码里用了List方案既保留了全部统计结果又没有增加多少代码量。Reduce阶段还需要注意一个MapReduce的基础概念Partitioner。默认情况下相同的key会被分发到同一个Reducer这个过程由默认的HashPartitioner完成。TOP 10这种场景数据量不大使用一个Reducer就足够了把mapreduce.job.reduces设为1即可。如果你尝试设置为多个Reducer最终会得到多个输出文件每个文件部分有序但合并成全局TOP 10还需要额外步骤这会增加复杂度学习阶段不建议这样搞。写完代码后用hadoop jar命令提交作业观察YARN的Application日志。作业运行期间可以用yarn application -status查看进度也可以到ResourceManager的Web界面上看详细的任务执行情况。Day6跑完作业你会看到一个真实存在的、自己亲手走通的数据处理流程这种成就感比刷100道选择题来得实在。4. 常见问题与排查技巧实录4.1 新手最容易踩的几个坑Day6这种多组件联动的场景问题通常会出现在组件之间的匹配、配置项的遗漏、路径不对这些“低级但致命”的地方。我这里把实际演练中遇到过的高频问题以及对应的排查思路整理成表格方便你对号入座。现象可能原因排查思路Flume启动成功但日志不采集exec source中trackerDir未配置Flume重启后从文件开头重新读取配置trackerDir为独立目录并检查日志文件是否有新内容写入写入HDFS的日志文件为空hdfs Sink与namenode通信失败或HDFS处于SafeMode检查HDFS集群状态执行hdfs dfsadmin -safemode get必要时等待自动退出MapReduce作业一直在调度但无进度YARN的NodeManager资源不足或容器频繁被kill查看YARN日志和系统内存使用情况调大容器内存或减少并发容器数统计结果缺字段HDFS上的日志文件格式与代码切分逻辑不一致先用head查看原始日志内容确认分隔符和字段下标Spark提交任务报ClassNotFound依赖的jar没有打进提交命令使用--jars参数指定依赖包或者打包成fat jar这些坑有一个共同特征报错信息并不直接告诉你“哪错了”需要你回到数据原点逐层排查。我在排查Flume问题时总结出一个原则先确认源端有没有数据再看通道里有没有事件最后检查目标端有没有落盘。这套“源—管道—目标”三步排查法在后续学习Kafka、Flink、DataWorks等各类数据组件时同样通用。4.2 线上排查时的通用思路排查问题如果一上来就瞎试往往会越搞越乱。我在Day6学到的教训是必须先建立一条“因果链”从输出端倒推逐步缩小范围。以“HDFS上没有生成Flume写入的文件”为例可以倒推检查HDFS目录是否存在、权限是否正确、namenode是否活跃、Flume的sink配置是否正确、channel中是否有积压事件、source是否真的读到了数据。沿着这条链查下去大约五分之一的概率就能定位到问题所在。查看日志文件也是一个重要的习惯。Flume的日志默认在logs/flume.logMapReduce的日志在YARN的聚合日志中。发现异常后第一件事不是去改配置而是先看日志分析报错堆栈到底指向哪个模块。很多人在群里提问时只截一句话“报错了”却不肯把堆栈贴全这其实是在浪费彼此的时间。学会看完整日志、能抓住堆栈中的关键异常类是开发者从新手走向熟练的重要分水岭。另一个实用原则是“隔离变量”。如果一次链路中有多个组件协同工作排查问题时只改动一个变量然后观察效果。比如Flume不写HDFS你可能同时怀疑source配置和sink配置这时先单独测sink是否能向HDFS写一个测试文件如果sink没问题再往前查source。一次动多处最后连哪个改动生效了都说不清楚这种调试习惯在真实项目里是致命的。结尾关于Day6的一点个人体会跑完Day6的完整流程我最大的感受是大数据开发的学习到了第六天真正开始了“从知识到能力”的过渡。前五天你学的是零件今天你把这些零件装成了一台能跑的机器。虽然这台机器还很粗糙但它能完成从日志采集到统计输出的完整闭环这就说明你已经拥有了“独立串起一条数据链路”的基础能力。如果非要给今天的学习提个建议我会说把每一步的验证动作做扎实。日志生成后先看文件是否在持续增长Flume启动后先看HDFS上有没有文件出现作业提交后先等它跑完再仔细看输出结果。这种“每一步都有反馈”的节奏能让你在报错发生时迅速定位到具体环节而不是在整条链路上迷茫地猜。从“基于云平台大数据应用开发”的角度来看今天是第一次真正体会到“云端数据工程”的完整样貌。后面随着Hive数仓、Spark SQL、实时计算框架的加入你会在今天搭建的这条主线上不断延伸和扩展逐步逼近大型数据平台的真实架构。但对现在的你来说能让一元钱的云主机跑出一条全链路的日志统计就已经足够为接下来的学习积蓄信心了。
