很多刚接触大数据平台的人第一次看到的就是这样一个组合Apache Hadoop、Hive、Hue、Spark、HBase。名字一个比一个熟感觉自己都会但真开始动手把五个组件装到同一个集群里让它们跑起来、共享数据、互相协作你会发现这事远不止“五个软件装了就行”。这篇文章没有废话就是把我在实际环境中把这五件套整合在一起的完整过程写下来每一个连接点怎么配、每个连接点容易怎么坏、坏了怎么查。适合正在搭离线数仓、准备做SparkSQL分析、又需要HBase承接实时读写的团队和开发者参考也适合一个人一台虚拟机把整个链路先跑通的初学者。1. 整体方案设计与架构定位1.1 从“五件套”想清楚各自干什么很多人上来就装Hive装完之后发现Hive其实不会自己存数据。Hive只是在HDFS之上做了一层“翻译”把SQL翻译成分布式作业把表结构和文件目录对应起来。所以准确地说Hive依赖Hadoop的HDFS来存数据真正执行的默认计算可以走Hadoop的MapReduce也可以走Spark。理解了这一点整套架构的关系就开始清晰了。把这五个组件放到一张图上各干各的组件核心职责类比HadoopHDFSYARN分布式存储 资源调度仓库和物业调度中心HiveSQL语义层 统一元数据翻译官和账本Spark内存计算引擎高效的运输队HBase分布式列族数据库快递柜支持随机存取HueWeb界面统一入口监控室和操作台为什么要强调各干各的因为整合的本质就是让它们各司其职而不是越位。举个例子HBase虽然挂在HDFS上但它管理着自己目录下的文件如果让Hive直接去扫描HBase的数据目录完全读不出有效内容反过来SparkSQL去看Hive表很顺利是因为它走了Hive Metastore这条“账本”通道。1.2 整合的真正难点是4个连接点安装单个组件基本是一路下一步整合的真正工作量在于把“连接点”打通Hive 和 HDFS 的连接Hive 数据仓库的默认目录要落在HDFS上Hive表本质是HDFS上的一串目录和文件。Spark 和 Hive 的连接SparkSQL 需要通过 Hive Metastore 获取库表元数据这样Spark里建的表Hive能查Hive里建的表Spark能查。Hive 和 HBase 的连接通过Hive的HBaseStorageHandler让Hive可以读HBase的实时表HBase也可以反过来通过Hive做复杂聚合。Hue 和所有组件的连接Hue 本质是一个聚合网关它要分别拿到各组件的地址、端口、认证方式才能把文件浏览、SQL编辑、调度监控统一到一个浏览器页面。这四个连接点中第1点是底层做不好后面全白搭第2点是使用体验的分水岭做不好SparkSQL就是个孤立工具第3点是数仓接实时数据的关键第4点是团队效率的加分项但前面三条不通它就完全没意义。1.3 为什么采用“共享资源池”而不是各起炉灶有一种错误做法是Hadoop归Hadoop跑Spark单独开一个独立集群HBase又用另外一组进程。结果就是内存互相挤运维要盯三套监控数据还要来回拷贝。我推荐的做法是让 Spark on YARN也就是说 Spark 本身不常驻资源只有提交任务时才向YARN申请容器。这样整个集群只有HDFS、YARN、Hive Metastore、HBase、Hue这几个常驻服务在跑资源调度统一归YARN管Spark任务即使写出几百个并发容器跑完就释放不会和HBase抢资源。说得更直白一点Hive和Spark都跑在YARN容器里HBase的RegionServer独立常驻但也在同一批机器上。这样集成后的架构既满足离线批处理Hive/Spark、又满足实时随机读写HBase还只有一个运维入口Hue是最稳妥的中小型平台方案。2. 环境准备与版本选型2.1 版本选型是第一步也是最大的坑如果我在文章里只说一句“注意版本兼容”你大概不会当回事但实际工作中80%的整合失败都来自版本冲突尤其是Spark和Hive之间、HBase和Hue之间。我的习惯是不追新追求通过社区验证的组合。给一套我用过的、稳定运行过的参照组合组件参照版本选型理由Hadoop3.3.6Hadoop 3.x 生态成熟YARN 能力比 2.x 好用Hive3.1.3与 Spark 3.x 兼容性好官方文档有明确支持Spark3.3.4SparkSQL 原生集成 Hive提交到 YARN 稳定HBase2.4.17支持 Hadoop 3 命名空间RegionServer 稳定Hue4.11.0集成 Hive、Spark、HBase 都有成熟模块这里有一个关键认知Hive 2.x 和 Spark 2.x、3.x 混搭很容易出问题Hive 3.1.x 与 Spark 3.x 在元数据对接上比较顺。如果你们团队要用Spark 3.4或更高请再去翻对应版本的兼容文档不要拍脑袋。其他依赖JDK建议1.8HBase 2.4和Hive 3.1对JDK8的支持最成熟主节点额外准备一台MySQL/MariaDBHive Metastore的元数据要落到关系库里。2.2 节点规划与资源估算我习惯按三台虚拟机来规划主机名就叫node01、node02、node03node01HDFS NameNode、YARN ResourceManager、Hive Metastore/HiveServer2、Huenode02HDFS DataNode、YARN NodeManager、HBase RegionServer、Spark客户端node03HDFS DataNode、YARN NodeManager、HBase RegionServer、Spark客户端如果只有一台开发机把所有服务堆到一台也不是不行但内存至少16GB否则HBase和YARN同时起来后很容易陷入OOM循环。资源估算也简单每个DataNode/NodeManager节点至少8GB内存其中HBase RegionServer默认最大堆很大要主动调小否则留给容器内存就少了。一般我这样分16GB的机器NodeManager最大可用8GBRegionServer给4GB剩4GB给操作系统和HDFS进程。2.3 基础依赖hosts、SSH、JDK、MySQL在动手装五件套之前先把底层铺好hosts三台机器都要写 node01/node02/node03 的IP映射不只写自己这台。很多连接失败问题最后查出来是主机名解析不过去。SSH免密至少保证node01能免密登录所有节点启动脚本和后续启停Hadoop都要用。JDK 1.8建议按官方要求配置JAVA_HOME三台一致。MySQL在node01上装好给Hive建一个独立的库比如库名hive_meta账号hive。授权时不要只授权localhostMetastore跑了thrift服务后是走网络连接的。这里提醒一句MySQL连接串里的字符编码建议显式加上useUnicodetruecharacterEncodingUTF-8不然后面Hive表注释里的中文容易乱码。3. 核心集成配置逐个击破五个组件的连接点3.1 先把Hadoop装稳YARN是后面所有计算的钥匙先用两段能直接抄的配置说明核心。core-site.xmlproperty namefs.defaultFS/name valuehdfs://node01:9000/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /propertyyarn-site.xmlproperty nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.resourcemanager.hostname/name valuenode01/value /property property nameyarn.nodemanager.resource.memory-mb/name value8192/value /property property nameyarn.scheduler.maximum-allocation-mb/name value4096/value /property property nameyarn.scheduler.minimum-allocation-mb/name value1024/value /property这里要讲清楚两个参数的含义minimum-allocation是单个容器最少申请内存maximum是单个容器最多申请nodemanager.resource是整台机器愿意给YARN的总内存。如果你的机器只有16GBRegionServer又占了4GB那NodeManager写10GB已经不保险写8GB比较稳。如果这个值写太大YARN在申请内存时不会管其他常驻服务最后整机OOM表现为HBase RegionServer突然消失、DataNode心跳中断。启动HDFS和YARN后先不要着急装下一个组件用jps检查进程再用 hdfs dfsadmin -report 看存储是否正常。这里补一个建议把格式化NameNode之前的配置文件反复检查一遍因为格式化之后如果要改fs.defaultFS还得再格式化一次代价很大。打通这一步后面才有意义。3.2 Hive把Metastore做成独立服务Hive整合里最关键的认知是Metastore 不是一个只能给Hive自己用的内部模块而是整个平台的元数据中枢。把hive-site.xml里的javax.jdo相关配置指向MySQL并把metastore地址公布出来。hive-site.xml关键项property namejavax.jdo.option.ConnectionURL/name valuejdbc:mysql://node01:3306/hive_meta?createDatabaseIfNotExisttrueamp;useUnicodetrueamp;characterEncodingUTF-8/value /property property namejavax.jdo.option.ConnectionDriverName/name valuecom.mysql.cj.jdbc.Driver/value /property property namejavax.jdo.option.ConnectionUserName/name valuehive/value /property property namejavax.jdo.option.ConnectionPassword/name value你的密码/value /property property namehive.metastore.uris/name valuethrift://node01:9083/value /property property namehive.server2.thrift.bind.host/name valuenode01/value /property property namehive.server2.thrift.port/name value10000/value /property property namehive.metastore.warehouse.dir/name valuehdfs://node01:9000/user/hive/warehouse/value /property需要做的操作按顺序来把MySQL JDBC驱动放进 Hive 的 lib 目录。我自己经常漏这一步然后初始化时报错找不到Driver。执行初始化bin/schematool -dbType mysql -initSchema启动顺序先启动metastore确认9083端口起来再启动hiveserver2。因为hiveserver2启动时也会尝试连接metastore顺序反了会报一堆连接失败。测试bin/beeline -u jdbc:hive2://node01:10000跑show databases看结果。这里有个非常重要的经验hive.metastore.uris一定要配置而且不能用默认的本地模式。很多人在单机测试时习惯不配它Hive会在本地起一个内嵌Metastore。可一旦Spark或Hue要连接Hive它们不会自动走“本地内嵌”这条路都要通过网络访问9083端口。不配就会导致Spark能看到一套空的默认库Hive里却有自己的表——两者完全对不上。3.3 Spark on YARN接上Hive元数据Spark安装不需要常驻进程只需要在所有能提交任务的节点放一份解压好的客户端。我建议node01、node02、node03各放一份或者至少node01和node02有一份不然任务提交时的HDFS本地化会多走一跳。Spark要做的三件事。第一spark-env.sh 里设置Hadoop配置目录和Java路径export JAVA_HOME/opt/jdk1.8 export HADOOP_HOME/opt/hadoop export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop export SPARK_HOME/opt/spark第二把Hive的hive-site.xml放到Spark的conf目录。这一步不配置SparkSQL根本不知道Hive Metastore在哪。也可以直接在spark-defaults.conf里写spark.masteryarn spark.sql.catalogImplementationhive spark.hadoop.hive.metastore.uristhrift://node01:9083其实如果把hive-site.xml都已经复制过来了后面两行可以靠hive-site.xml自动生效但spark.sql.catalogImplementationhive最直观建议还是写清楚。这套配置做完之后SparkSQL里show databases看到的就是Hive里的库两者才算真正共享元数据。第三提交测试。不要一上来就跑大SQL先跑一个简单的bin/spark-sql --master yarn --deploy-mode client -e show databases;看到结果后再试建表CREATE TABLE spark_hive_test(id int, name string); INSERT INTO spark_hive_test VALUES (1, a);之后回到Hive beeline里select这个表如果能查到说明Spark和Hive元数据链路已经通了。我在这步踩过的最隐蔽的坑Spark运行时找不到Hive表的原始文件。原因是HDFS目录权限和默认目录归属不一致。比如Spark以某个用户身份运行建的表目录owner是它而HiveServer2用另一个身份登录就读不到了。我的规避办法是在跑测试时统一用户身份最简单就是用hdfs用户或者一个统一的平台用户能避免这种花好几个小时才能定位的权限冲突。3.4 HBase建列族再让Hive能读写它HBase的配置要点在hbase-site.xmlproperty namehbase.rootdir/name valuehdfs://node01:9000/hbase/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.zookeeper.quorum/name valuenode01,node02,node03/value /property property namehbase.zookeeper.property.clientPort/name value2181/value /propertyHBase启动后用 hbase shell 建一张测试表hbase shell create user_behavior, info put user_behavior, row1, info:name, zhangsan再让Hive能查询这张表。做法是在Hive中创建一张“外联表”本质是Hive不自己复制数据而是通过HBaseStorageHandler去读写HBaseCREATE EXTERNAL TABLE hbase_hive_user_behavior( id string, name string ) STORED BY org.apache.hadoop.hive.hbase.HBaseStorageHandler WITH SERDEPROPERTIES (hbase.columns.mapping :key, info:name) TBLPROPERTIES (hbase.table.name user_behavior);其中 hbase.columns.mapping 的规则是第一列对应HBase的RowKey用:key后面每一列对应一个列族下的一个限定词。这里有个易错点Hive表字段顺序必须和mapping对齐否则数据错位查出来全是乱的。要做这一步前提是把HBase的客户端jar复制到Hive的lib目录。和Hive整合HBase相关的常见jar包括hbase-client、hbase-server、hbase-common、hbase-protocol、htrace-core4等。注意版本要和HBase安装版本一致不能顺手拿别的版本替代否则类冲突的概率极高。这一步做完你会在Hive里看到真实数据HBase里有实时写入的数据Hive通过一张外部表就能做聚合分析反过来也可以往Hive外部表里insert数据会落到HBase的底层表中。生产环境里很多实时报表场景就是这么组合的流式作业写HBase离线数仓用Hive跑SparkSQL分析HBase里沉淀的数据。3.5 Hue把所有入口统一到浏览器Hue配置文件的重点是 desktops/conf/hue.ini按段来改。hive段[beeswax] hive_server_hostnode01 hive_server_port10000或者新版里用解释器段的方式配置Hive。关键是hive_server_host要写node01而不是localhost因为Hue虽然运行在同一台node01上直接写localhost也能通但写成主机名可以避免以后迁移机器时再改配置。hdfs段[filebrowser] fs.defaultFShdfs://node01:9000对应的NameNode Web端口看版本可以是9870或9820自己在UI里看到实际值再填。hbase段[hbase] hbase_conf_dir/opt/hbase/conf thrift_transportbuffered hbase_clusters(default|node01:9090)Hue通过HBase的Thrift或REST接口访问重点是把集群地址和配置目录写对否则HBase浏览器打不开显示白板。spark段Hue 4.x以后支持Spark解释器需要配置Livy或者直接接Spark Thrift Server。如果不想额外维护一套常驻服务也可以只让SQL解释器走HiveServer2因为HiveServer2可以配合Hive配置里的Spark引擎来执行SparkSQL。所以我一般会让Hue的Spark入口指向同一套HiveServer2减少一个常驻服务和一大截配置量。Hue初始化和启动cd /opt/hue ./build/env/bin/hue migrate ./build/env/bin/supervisor -d第一次启动会要求设置管理员账号。随后打开 http://node01:8888登录后左侧菜单里能看到文件浏览、Hive查询、HBase浏览器等入口。这里有个普遍困扰新手的问题Hue启动报错总在最后一步才暴露前端页面显示启动失败但后端进程还在。排查方式永远是先看Hue的日志而不是反复重启。日志在logs目录下它会明确告诉你缺哪个Python依赖或者连不上哪个端口。4. 真实环境里最常踩的坑与排查速查4.1 元数据对不上Spark和Hive各看各的表这是出现频率最高的一个现象——Hive里建了一张表SparkSQL里show tables查不到或者在Spark里建的表Hive那边看不到。排查顺序检查Spark的conf里有没有hive-site.xml或者spark-defaults.conf里有没有spark.sql.catalogImplementationhive。没有就补上。检查Metastore端口nc -zv node01 9083能通再接。检查两边连的是不是同一套MySQL不要Hive连库ASpark连库B。我自己曾经在复制配置文件时不小心把旧的hive-site.xml带了过去结果Spark连到了另一台机器的元数据库排查了两天。这种“看起来配置没问题但就是各看各的”的故障最好的排除法就是把“同一份hive-site.xml”直接复制到所有需要访问元数据服务的组件目录再从这份唯一配置文件里看ConnectionURL到底指向哪里。只要全平台共用一份源配置元数据不对齐的问题基本断根。4.2 资源分配不当HBase退场、容器被kill通常不是计算问题而是资源分配问题。常见状态是HBase起来后默认占用很大堆内存YARN那边又把NodeManager总内存设得很大两个服务叠加直接压垮整台机器。解决办法是主动调小hbase-env.sh里HBASE_HEAPSIZE给4GB左右yarn-site.xml里nodemanager.resource.memory-mb按“机器物理内存 - HBase堆 - 系统预留”来算Hive和Spark的executor内存不要开太大单容器建议先1GB~2GB测试后面看监控再往上调。经验公式其实很简单把常驻服务该占的内存先预留出来剩下的才是YARN容器的池子。如果一台机器的物理内存是16GB那NodeManager设8GB、RegionServer设4GB、系统和其他HDFS进程占4GB是比较稳妥的划分。你去看官网默认值它们大多按“整机都给YARN”的思路来这在多框架共存时是会打架的。4.3 包冲突NoSuchMethodError与ClassNotFoundExceptionHive的lib目录里如果同时存在多个版本的guava、jackson或者HBase的jar版本和Hadoop shaded jar冲突运行时会报很奇怪的类错误。排查手段用find在对应lib目录下看是否存在多个同名不同版本的jar出现NoSuchMethodError或ClassNotFoundException时先确定是哪个jar没加载对再通过软链接屏蔽多余版本而不是直接删jar。直接删很可能连带破坏其他依赖比如guava删了Hadoop又要用它处理HBase整合到Hive时优先选择官方文档列出的最小jar集合不要整个lib目录拷过来。整个目录拷过来只会把冲突批发式地全部带进来。4.4 常见故障速查表现象大概率原因快速处理beeline连不上10000HiveServer2没启动或端口被占用netstat检查端口确保先启动metastore再启动HS2SparkSQL看不到Hive表未连Metastore补spark.sql.catalogImplementationhive复制hive-site.xmlHue页面能打开但Hive查询失败Hue里Hive解释器地址指向错改hue.ini的hive_server_host和port并重启HueHBase浏览器白屏Hue的hbase配置地址或端口不对检查hbase_conf_dir、thrift端口9090或REST端口20550HDFS报副本数不足DataNode不够或起晚了hdfs dfsadmin -report看节点活跃DataNode达到2个以上时重新校验任务跑着跑着容器被kill单个容器内存超限调低executor内存或调大yarn.scheduler.maximum-allocation-mb但不能超过NodeManager总量4.5 验收前先过一遍连接点清单最后分享我实际执行的检查顺序相当于“五件套系统上线前的体检表”HDFS和YARN进程都在node01有NameNode和ResourceManagernode02/node03有DataNode和NodeManagerHive Metastore 9083监听正常MySQL里能看到hive_meta库且元数据表已初始化SparkSQL能看到Hive库表HBase里建的表Hive外部表能读到Hue登录后文件浏览、SQL查询、HBase浏览器三个入口都能正常打开。每次搭建我都会按顺序过一遍能省下大量返工时间。这个清单看起来简单但任何一个环节断了后续在上层写业务都会产生连锁问题。聊到最后说点实在的。这套整合做完之后我最大的体会是五个组件越复杂越要先把连接点理清楚再动手装。哪怕是版本选型这种看起来最不起眼的一步都决定了后面三天是顺利收工还是反复找错。如果你正在做类似的事我建议你把每台机器的内存规划写进一个简单表格把每个组件需要开放的端口记下来然后再开始配置整个链路会顺畅得多。最后再分享一个小技巧所有配置文件改完以后尽量保留当时的备份并顺手记录改动原因。我吃过亏后来排查一个诡异问题时就是靠当时的备份记录十分钟定位到了是某一行配置被误改。希望这套思路对你有用。
转义缺陷到命令注入绕过与加固)
