1. Hadoop核心组件初探从存储到计算的基石第一次接触Hadoop时我被它庞大的生态系统吓到了。但后来发现只要掌握HDFS、YARN和MapReduce这三个核心组件就能解决80%的实际问题。这就像学做菜先掌握煎炒烹炸这几种基本技法就能应付大多数家常菜。HDFSHadoop Distributed File System是Hadoop的存储基石。我常把它比作一个巨型文件柜数据被切成固定大小的块默认128MB然后分散存放在不同服务器上。有趣的是每个数据块会自动复制3份可配置存放在不同机器上。这种设计让系统即使丢失一两台服务器也不会影响数据安全。记得有次机房空调故障导致三台服务器宕机但我们的数据依然完好无损——这就是HDFS副本机制的威力。YARNYet Another Resource Negotiator是Hadoop 2.0引入的资源调度系统。它就像公司的HR部门负责给各个项目分配人力在这里是计算资源。ResourceManager是总调度NodeManager负责单台服务器的资源管理。最妙的是ApplicationMaster机制每个任务都有自己的项目经理向ResourceManager申请资源并管理任务生命周期。这种架构让Hadoop从单纯的批处理系统进化成了多功能计算平台。MapReduce可能是有史以来影响最深远的编程模型之一。它的核心思想很简单把大问题拆分成小问题Map汇总小问题的结果Reduce。但第一次写MapReduce程序时我被各种Writable类搞得头大。后来发现只要记住IntWritable对应intText对应String就能应付大部分场景。比如统计词频的经典例子Map阶段把文档拆成(单词,1)的键值对Reduce阶段把相同单词的计数相加短短几十行代码就能处理TB级数据。2. 集群部署实战从零搭建生产环境去年给公司部署Hadoop集群时踩了不少坑这里分享下血泪经验。硬件配置上NameNode需要大内存建议64G因为要缓存所有文件元数据DataNode则更需要磁盘空间和网络带宽。我们最初给NameNode配了32G内存结果处理千万级文件时频繁Full GC后来升级到128G才稳定。配置文件是另一个大坑。core-site.xml中fs.defaultFS指定集群地址时千万别用localhosthdfs-site.xml中dfs.replication设置副本数要根据DataNode数量调整我们设成3但初期只有两台DataNode导致一直报警告。最坑的是mapred-site.xml和yarn-site.xml的配置记得一定要把yarn.nodemanager.resource.memory-mb和yarn.scheduler.maximum-allocation-mb设成物理内存的80%左右否则容易引发OOM。高可用(HA)配置更是个技术活。JournalNode至少要3个节点我们用了5个ZooKeeper最好也是3节点以上。第一次配置自动故障转移时zkfc总是报错后来发现是防火墙没开8485和2181端口。这里有个小技巧先用hdfs haadmin -getServiceState nn1手动检查状态再测试kill -9强制终止进程观察是否自动切换。监控环节同样重要。我们组合使用Ganglia系统指标Prometheus应用指标ELK日志的方案。特别要关注NameNode堆内存、DataNode磁盘使用率、YARN容器排队时间这些关键指标。有次发现某个DataNode的磁盘使用率明显偏高检查发现是其他节点磁盘故障导致数据重新均衡不及时。3. 数据处理全流程电商订单分析实战最近用Hadoop处理了一个电商订单分析项目完整流程值得分享。数据源是MySQL的订单表每天约50GB增量。我们先用Sqoop把数据导入HDFS命令类似这样sqoop import \ --connect jdbc:mysql://mysql-server:3306/ecommerce \ --username user --password pass \ --table orders \ --target-dir /data/orders/dt${current_date} \ --m 8这里用了动态分区${current_date}方便后续按日期查询。遇到的问题是某些大字段包含特殊字符导致解析失败最后加了--hive-drop-import-delims参数解决。Hive表设计也有讲究。订单主表用ORC格式Snappy压缩分区按日期订单商品这类嵌套数据用复杂类型array存储。建表语句示例CREATE TABLE orders_analyze ( order_id BIGINT, customer_id BIGINT, order_items ARRAYSTRUCT item_id:BIGINT, item_name:STRING, quantity:INT, price:DOUBLE, payment_info MAPSTRING,STRING ) PARTITIONED BY (dt STRING) STORED AS ORC TBLPROPERTIES (orc.compressSNAPPY);分析阶段最耗资源的是用户行为路径分析。我们先用LATERAL VIEW explode展开数组再用窗口函数计算购买间隔SELECT customer_id, item1.item_name AS prev_item, item2.item_name AS next_item, DATEDIFF(next_order_date, order_date) AS days_diff FROM ( SELECT customer_id, order_date, LEAD(order_date) OVER (PARTITION BY customer_id ORDER BY order_date) AS next_order_date, item AS item1, LEAD(item) OVER (PARTITION BY customer_id ORDER BY order_date) AS item2 FROM orders LATERAL VIEW explode(order_items) t AS item ) t WHERE next_order_date IS NOT NULL;这个查询最初要跑2小时后来通过调整ORC的stripe大小256MB和建合适的Bloom Filter优化到25分钟。4. 性能调优从慢如蜗牛到快若闪电Hadoop集群跑得慢我整理了一份实用调优清单。首先是HDFS层面块大小从默认128MB调到256MB后我们的Map任务数减少40%小文件问题用HAR归档解决。命令很简单hadoop archive -archiveName data.har -p /input /outputYARN调优关键是资源分配。计算每个节点的可用资源内存物理内存0.8vcores物理核心0.8。比如48核128G的机器在yarn-site.xml中配置property nameyarn.nodemanager.resource.memory-mb/name value102400/value !-- 100GB -- /property property nameyarn.nodemanager.resource.cpu-vcores/name value38/value /propertyMapReduce作业调优更是门艺术。设置mapreduce.job.maps时我通常按输入数据量除以256MB来计算reduce任务数则根据最终输出大小调整一般设成0.95节点数每个节点最大容器数。有些特殊场景要用到Combiner比如统计UV时public static class UVCombiner extends ReducerText, IntWritable, Text, IntWritable { public void reduce(Text key, IterableIntWritable values, Context context) throws IOException, InterruptedException { int sum 0; for (IntWritable val : values) { sum val.get(); } context.write(key, new IntWritable(sum 0 ? 1 : 0)); } }内存调优也不容忽视。遇到Container killed by YARN for exceeding memory limits错误时需要调整mapreduce.map.memory.mb和mapreduce.reduce.memory.mb通常设为容器内存的80%。对于OOM问题我习惯在jvm参数中添加-XX:HeapDumpOnOutOfMemoryError方便事后分析。