暑假生活周报4

这周总算把计划里的Hadoop技术框架给啃下来了，虽然还没实战到集群部署那么深入，但整个基础体系的逻辑算是跑通了。最大的收获是拆解清楚了三大核心组件各自扮演的角色：HDFS负责当那个“不会丢数据的硬盘管家”，它用三副本的冗余策略硬扛硬件故障的设计确实聪明，试了下用hdfs dfs -put传文件然后故意kill掉一个DataNode，文件照样能读出来；MapReduce编程模型理解了它分而治之的套路，写了个单词统计的Demo跑在本地伪分布式环境，看着split-》map-》shuffle-》reduce的数据流有种拼乐高的爽感；YARN作为资源调度总管的作用也摸清了，监控页面上能看到它把CPU和内存像切蛋糕一样分给MapReduce作业或者其他计算框架（比如后面想试的Spark），资源利用率肉眼可见比传统单体应用高不少。还顺手搞定了关键环境——照着文档在Linux上搭了个伪分布式集群，start-dfs.sh启动时那一串日志冒出来的时候居然有点小激动。

踩坑的地方也很“经典”，尤其伪分布式环境的配置复杂度超乎预期。光是core-site.xml、hdfs-site.xml、yarn-site.xml这几个文件里上百个参数就够晕的，改个fs.defaultFS的地址配错协议前缀（比如写成hdfs://漏了端口），整个HDFS直接罢工；设内存参数更头大，YARN的yarn.nodemanager.resource.memory-mb和MapReduce的mapreduce.map.memory.mb必须严格匹配，否则要么报容器超限要么资源浪费，调这几个值搞到凌晨两点。还有第一次跑MapReduce作业时没设HADOOP_CLASSPATH，疯狂报ClassNotFound，查了半小时才知道要把依赖的jar包路径导进去。另外调试信息太散也是痛点，一个作业失败得同时翻YARN的Web UI看日志聚合、查DataNode的syslog、甚至还得瞅瞅NameNode的状态，排查效率被拉低不少。至于MapReduce开发效率低的问题也有体会，写个简单统计居然要拆成Mapper/Reducer两个类加一坨样板代码，远不如写SQL或者pandas来得快。

不过整体没白折腾，至少对大数据生态的“地基”有了手感——理解了为什么说Hadoop是离线批处理的骨架，也看明白了后来Spark/Flink这些框架要解决它的哪些瓶颈（比如内存计算替代磁盘洗牌）。接下来就等实战环节了：准备找个小点的真实数据集试试hive的SQL化查询，再跑跑看用YARN调度Spark的任务对比原生MapReduce能提速多少。对了，还有生产里那些让人头大的参数调优坑，估计还得专门再啃一轮文档才能少掉点头发。