Hive生产环境安装配置全攻略:从元数据库选型到避坑实践

发布时间:2026/10/13 5:07:49
Hive生产环境安装配置全攻略:从元数据库选型到避坑实践 大数据生态圈里Hive 几乎是离线数仓绕不开的一环。但要说安装配置网上的教程要么只覆盖皮毛要么版本老得能进博物馆。我自己在多个生产环境里装过 Hive踩过不少坑也总结出一套相对稳妥的流程。这篇东西不打算写成官方文档的复述版就是基于我实际操作的记录把这个过程中的关键决策和常见问题一次性讲明白。先说清楚这篇博文能帮你解决什么问题从零开始在已经具备 Hadoop 环境的服务器上完整安装并配置一套 Hive并让它在生产可用状态下跑起来。适合正在搭建数仓平台的开发工程师也适合想深入了解 Hive 运行机制的学习者。整个安装过程说难不难但有几个弯弯绕绕的点比如元数据库的选型、字符集的设置、和 Hadoop 版本的兼容性处理不好会浪费大量时间。1. 安装前的核心思路搞清楚 Hive 在整条链路里的角色1.1 Hive 的本质SQL 翻译官Hive 本身不是数据库它不存数据。它做的事情是把你写的 SQL 解析成一系列计算任务扔给底层的执行引擎默认是 MapReduce也可以配 Tez 或 Spark去处理。数据到底存在哪儿呢存在 HDFS 上。那表的字段定义、分区信息、存储路径这些元数据放哪儿这就要引入元数据库Metastore的概念了。这里必须掰扯清楚一个常见误区很多人以为装了 Hive 就用上了 MySQL这是不对的。Hive 自带的默认元数据库是内嵌的 Derby一个单机版 Java 数据库。它的特点是零配置、开箱即用适合你第一次接触 Hive 时在本地跑几条 SQL 玩玩。但它的缺陷致命Derby 只支持单客户端连接你要是多开几个会话马上就会报锁异常。生产环境如果敢用 Derby 存元数据那基本属于自找麻烦。所以安装 Hive 的重点不是 Hive 服务本身而是把元数据库从 Derby 切换成一个真正建在 MySQL或者 PostgreSQL上的独立库。这一步做完Hive 才具备多人协作、多服务并发访问的基础。1.2 版本选型和兼容性这是一切坑的根源选版本这事经验不足的人最容易踩雷。Hive 有 1.x、2.x、3.x 三个大版本线每个大版本对 Hadoop 版本的要求都不一样。我目前用的搭配是 Hadoop 3.x 配 Hive 3.x这套组合在实际生产里比较稳。关于版本的硬性匹配我给出一个普遍适用的观察结论Hive 2.x 起步要求 Hadoop 2.6 以上Hive 3.x 则要求 Hadoop 3.0 及以上。如果你用的是 Hadoop 2.7却硬塞一个 Hive 3.1.2编译元数据的时候会报各种找不到类、版本冲突的问题。还有一个容易忽略的点是 JDK 版本Hive 3.x 对 JDK 8 支持最好到了 JDK 11 反而会出现一些模块化访问限制的问题。所以保守一点JDK 1.8 加 Hadoop 3.x 加 Hive 3.1.x是当前最不容易出幺蛾子的组合。2. 安装前的环境准备不急着装 Hive先把地基打牢2.1 确认 Hadoop 集群状态在动 Hive 之前Hadoop 集群必须处于健康状态。这里的健康不是说进程在跑就行而是要确认几个关键目录。Hive 在运行时会用到/tmp和/user/hive/warehouse这两个 HDFS 路径。特别是/tmp目录很多教程把这个细节忽略了结果 Hive 启动时拼命报权限错误。安装之前我建议你按顺序执行这几步用jps检查 NameNode、DataNode 进程是否正常。用hdfs dfs -ls /确认 HDFS 根目录可读。手动创建 Hive 的仓库目录并授予相应的权限hdfs dfs -mkdir -p /user/hive/warehouse hdfs dfs -mkdir -p /tmp hdfs dfs -chmod gw /tmp hdfs dfs -chmod gw /user/hive/warehouse这几条命令里的chmod gw非常关键。Hive 在运行时会有一些临时文件要往/tmp里写有时候执行 SQL 的 Session 用户对/tmp没有写权限就会抛Permission denied异常。如果你和我一样习惯用hdfs超级用户来起服务可能体会不到这个问题但一旦切换到普通用户跑 Hive这个权限配置就是第一个拦路虎。2.2 MySQL 的初始化准备MySQL 的角色是元数据库它的准备比 Hive 本身还繁琐一些主要体现在用户授权和字符集上。我先创建独立的数据库用户避免直接用 root 去连CREATE DATABASE hive_metastore; CREATE USER hive% IDENTIFIED BY YourPassword; GRANT ALL PRIVILEGES ON hive_metastore.* TO hive%; FLUSH PRIVILEGES;这里有两个细节我强调一下。第一hive%里我用的是%而不是localhost因为 Hive 服务可能在集群的某个节点上而 MySQL 在另外的机器上如果用localhost远程连接会直接拒绝。第二数据库名我建议用hive_metastore清晰明了后续排查问题时不会混淆。字符集的问题在初始化阶段就要处理好。Hive 元数据里会存很多表名、列名、分区键以及 HiveQL 层面的字符串对象如果 MySQL 端字符集是默认的latin1一旦字段里有中文字符就会出现乱码或者Incorrect string value的报错。所以在建库语句里建议直接写成DEFAULT CHARACTER SET utf8mb4我在生产环境里统一用这个方案无论是中文表注释还是分区值都没再出过编码问题。2.3 JDBC 驱动要提前备好Hive Metastore 要和 MySQL 通信靠的是 JDBC 驱动。这个驱动文件并不在 Hive 的安装包里需要你单独下载。装了 MySQL 之后有些人会去 MySQL 的 lib 目录里找通常是没有的得自己去网上下mysql-connector-java.jar。版本匹配上MySQL 5.x 用 5.1.49 的 connector 比较稳MySQL 8.x 则要用 8.0.x 版本。下载完成后把这个 jar 包放进 Hive 安装目录的 lib 下cp mysql-connector-java-8.0.28.jar /opt/hive/lib/如果不放这个 jar 包后续初始化元数据库时报错信息会是ClassNotFoundException: com.mysql.cj.jdbc.Driver这类错误在日志里非常显眼不过也容易排查。3. Hive 安装与配置的完整实操3.1 解压安装与环境变量配置下载 Hive 安装包时优先选择源码编译好的apache-hive-x.y.z-bin包很多初学的人会不小心下载src源码包那种包还需要自己编译徒增成本。解压到统一目录并建立软链方便将来升级tar -zxvf apache-hive-3.1.3-bin.tar.gz -C /opt/ ln -s /opt/apache-hive-3.1.3-bin /opt/hive接下来配置环境变量。编辑/etc/profile加入以下内容export HIVE_HOME/opt/hive export PATH$HIVE_HOME/bin:$PATHsource /etc/profile让配置生效后用hive --version验证一下如果能正常打印版本信息说明环境变量配置没问题。3.2 核心配置文件 hive-site.xmlHive 安装目录下最初没有hive-site.xml只有一个模板hive-site.xml.template需要我们复制并修改cp /opt/hive/conf/hive-site.xml.template /opt/hive/conf/hive-site.xml在hive-site.xml里有几项配置是必须写的。这里我给出一个比较精简但够用的模板configuration !-- 连接 MySQL 元数据库 -- property namejavax.jdo.option.ConnectionURL/name valuejdbc:mysql://192.168.1.100:3306/hive_metastore?useSSLfalseamp;serverTimezoneAsia/Shanghai/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 valueYourPassword/value /property !-- Hive 数据仓库在 HDFS 的存储路径 -- property namehive.metastore.warehouse.dir/name value/user/hive/warehouse/value /property !-- Hive 服务端运行时的线程池大小在并发度高的查询场景下需要调大 -- property namehive.server2.thrift.max.worker.threads/name value500/value /property /configuration这里插一句ConnectionURL里的serverTimezoneAsia/Shanghai很多人容易漏。MySQL 8.x 默认时区设置如果不对连接时会报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized这类乱码一样的错误。处理方式有两个一是在 URL 里明确指定时区二是在 MySQL 里执行set global time_zone 8:00我习惯两者都做省心。对于初学者可能不太清楚这些配置项的实际作用。简单来说javax.jdo.option.ConnectionURL这一系列是 JDO 框架连接数据库的关键配置Hive 的 Metastore 组件底层就是用 JDO 来持久化元数据的。而hive.metastore.warehouse.dir决定了你之后建表数据文件在 HDFS 上落在哪个目录。这两块是 Hive 存储与元数据分离架构的具体落地。3.3 解决 Guava 版本冲突这个坑是每个安装 Hive 的人都会遇到的而且属于那种不提前处理、启动必报错的类型。Hive 和 Hadoop 都依赖 Google 的 Guava 库但各自依赖的版本不一样。Hadoop 3.x 对应 Guava 27.0Hive 3.x 内置的可能是 Guava 19.0如果你不做处理启动时会出现类似NoSuchMethodError或com.google.common.base.Preconditions.checkArgument的错误。解决办法很简单把 Hive lib 目录下的旧 Guava 删掉用 Hadoop 目录里的新版覆盖rm /opt/hive/lib/guava-19.0.jar cp /opt/hadoop/share/hadoop/common/lib/guava-27.0-jre.jar /opt/hive/lib/建议在启动前就检查好这一项省得启动失败了再来排查绕了一圈发现是版本冲突问题。3.4 Hive 环境变量脚本 hive-env.shHadoop 安装路径需要在 hive-env.sh 里告知 Hive不然它不知道去哪找 HDFS 配置。复制模板并编辑cp /opt/hive/conf/hive-env.sh.template /opt/hive/conf/hive-env.sh在文件里加入 HADOOP_HOME 变量export HADOOP_HOME/opt/hadoop这里需要说明一下Hive 启动时很多内部脚本会通过HADOOP_HOME去定位 Hadoop 的配置文件core-site.xml、hdfs-site.xml从而获取 NameNode 的地址。如果不配置即使你设置了系统环境变量Hive 自己在子进程里也未必能继承到所以显式写在这里最保险。3.5 初始化元数据库 Schema配置文件准备完毕后就要执行 schema 初始化。这个步骤的本质是在 MySQL 的hive_metastore库里创建一系列 Hive 内部使用的表包含DBS、TBLS、SDS、PARTITIONS等用于记录数据库、表、分区的元信息。执行命令/opt/hive/bin/schematool -initSchema -dbType mysql -userName hive -passWord YourPassword -url jdbc:mysql://192.168.1.100:3306/hive_metastore?useSSLfalseserverTimezoneAsia/Shanghai看到Initialization script completed并且返回码为 0就说明成功了。此时去 MySQL 里查看会发现hive_metastore库下面多了一堆表其中VERSION表里会有一条版本记录这是 Hive 用来标记 Schema 版本用的。这个初始化步骤有个隐含的前提MySQL 连接用户必须有建表权限。如果使用了权限受限的账号会看到各种Access denied for user的报错。所以最稳妥的做法是初始化时用前面创建的拥有全部权限的hive用户不要为了图省事用临时账号。4. 启动 Hive 服务从 CLI 到 ThriftServer4.1 用 hive CLI 快速验证一切配置就绪先用 CLI 模式做冒烟测试。直接在终端输入hive进入交互界面后执行show databases如果能看到default库说明 Hive 到 MySQL 元数据库的连接是通的。这里有一点容易导致误判CLI 模式可以正常启动不代表服务端模式没有问题。CLI 模式是直接在本地进程里完成所有操作而服务端模式HiveServer2会额外启动一个 Thrift 服务监听在 10000 端口客户端通过该端口远程提交 SQL。两者共用一套元数据配置但启动机制和资源消耗完全不同。4.2 启动 HiveServer2 与 Metastore 服务生产环境里没人会天天跑到服务器上敲 CLI。标准用法是把 Metatore 服务和 HiveServer2 服务以后台进程的方式拉起来。先启动 Metastorenohup /opt/hive/bin/hive --service metastore /opt/hive/logs/metastore.log 21 再启动 HiveServer2nohup /opt/hive/bin/hive --service hiveserver2 /opt/hive/logs/hiveserver2.log 21 日志文件路径建议固定在某个目录别让 nohup 输出乱飞否则等你想排查问题的时候发现日志散落在各个目录心态会崩。启动完成后用lsof -i:10000确认 HiveServer2 端口处于监听状态。然后用 beeline 客户端连接/opt/hive/bin/beeline -u jdbc:hive2://localhost:10000 -n hiveuser连接成功后执行show databases如果返回default说明整个服务链路健康。4.3 解释启动过程中的几个关键机制这里要给新手解释一个很多人会困惑的地方Metastore 服务和 HiveServer2 到底是什么关系Metastore 是负责和 MySQL 打交道的核心服务它屏蔽了底层元数据库的细节对外提供 Thrift 接口。HiveServer2 则是接受客户端 SQL 的服务入口它会把 SQL 转成执行计划再交给执行引擎。客户端比如 beeline只和 HiveServer2 通信HiveServer2 需要获取表结构等元信息时再回头找 Metastore。有些精简部署模式会把 Metastore 内嵌到 HiveServer2 进程里配置方式是hive.metastore.uris不设置让 Hive 在本地启动一个内嵌 Metastore。这种方式在早期学习阶段可行但集群规模上来之后多个客户端并发访问内嵌模式会出现性能瓶颈。生产环境我建议显式指定property namehive.metastore.uris/name valuethrift://node01:9083/value /property这样 Metastore 独立进程也可以被 HiveServer2 和其他工具比如 Spark 的 Hive 集成共享访问。4.4 Shell 脚本一键启停手工敲nohup启动进程虽然能跑但每次重启服务器或者调整配置之后手工操作容易遗漏也不方便管理。我习惯写一个简单的启停脚本内容不复杂但能省去很多重复劳动#!/bin/bash HIVE_HOME/opt/hive case $1 in start) nohup $HIVE_HOME/bin/hive --service metastore $HIVE_HOME/logs/metastore.log 21 echo Metastore started nohup $HIVE_HOME/bin/hive --service hiveserver2 $HIVE_HOME/logs/hiveserver2.log 21 echo HiveServer2 started ;; stop) PID$(ps -ef | grep HiveServer2 | grep -v grep | awk {print $2}) kill -9 $PID PID$(ps -ef | grep metastore | grep -v grep | awk {print $2}) kill -9 $PID echo services stopped ;; *) echo Usage: $0 {start|stop} ;; esac使用jps或者ps -ef确认进程退出。这里提个醒kill -9在生产环境里适当慎用如果进程正在处理元数据事务强杀可能导致 MySQL 连接未正常释放长时间积累后可能出现连接数打满的情况。我一般在维护窗口用这个脚本平时重启服务会用更温和的kill先尝试。5. 验证配置成果建表与数据映射实操5.1 在 beeline 中创建测试表服务跑起来不建一张表验证一下总觉得不踏实。我在 beeline 里执行一段标准的建表语句在 HDFS 上看到对应的目录才认为整条链路合格。CREATE DATABASE test_db; USE test_db; CREATE TABLE employee ( id INT, name STRING, salary FLOAT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY \t STORED AS TEXTFILE;建表成功后去 HDFS 上看一眼hdfs dfs -ls /user/hive/warehouse/test_db.db/employee能看到一个空的目录说明表和 HDFS 路径已经正确映射。这一步能验证三个环节的正常性HiveServer2 连接正常、Metastore 能在 MySQL 里写元数据、HDFS 的写权限没问题。如果这三者中任意一个有问题在这里都会暴露。5.2 加载本地数据测试把一段文本数据放到本地文件然后用LOAD DATA导入vi /tmp/employee.txt内容模拟几行数据比如1 张三 15000 2 李四 12000 3 王五 18000回到 beeline 执行LOAD DATA LOCAL INPATH /tmp/employee.txt INTO TABLE employee;然后执行SELECT * FROM employee;能查询出三行记录说明从 SQL 解析、元数据访问到 HDFS 数据读取整条链路完全跑通。这里多说一句LOAD DATA LOCAL和LOAD DATA的区别。带LOCAL表示数据文件在客户端所在机器上不带LOCAL表示数据文件在 HDFS 上。新手经常在这块疑惑而且容易误以为数据是导入了表里但 Hive 的 load 操作本质上只是把文件从原路径移动到表对应的 HDFS 目录下并不做数据格式层面的转换。理解这个步骤后续在排查数据为什么查不到时才不会走弯路。6. 常见问题与排查技巧实录6.1 问题速查表一眼定位常见故障我在多次安装和排障过程中整理了一个高频问题的速查表基本覆盖了 90% 的安装期故障。报错信息或现象根因分析解决思路ClassNotFoundException: com.mysql.cj.jdbc.DriverMySQL JDBC 驱动未放入 Hive lib 目录下载对应版本 jar 包并复制到/opt/hive/lib/Access denied for user hivelocalhostMySQL 授权账号的主机范围不对授权时使用hive%并执行FLUSH PRIVILEGESFailed to initialize metastore或版本不匹配信息Schematool 初始化未执行或执行失败执行schematool -initSchema检查返回码Column ID is not null或 Schema 相关报错元数据库字符集不是 utf8 导致乱码建库时显式指定utf8mb4字符集启动 Hive 时NoSuchMethodErrorGuava 版本冲突删除 Hive lib 内旧版 Guava替换为 Hadoop 对应版本beeline 连接时Connection refusedHiveServer2 未启动或端口未监听用lsof -i:10000检查端口查看 hiveserver2 日志Permission denied在写入仓库目录时出现HDFS 目录权限不足hdfs dfs -chmod gw /user/hive/warehouse这张表里的问题我在帮同事处理环境时几乎都遇到过。有一个典型的场景是用户自报beeline 连接被拒绝我上去一看进程确实在但是端口监听在 127.0.0.1 而不是 0.0.0.0客户端从远程机器过来当然连不上。这个问题的根因在于 HiveServer2 默认监听地址配置在hive-site.xml里增加property namehive.server2.thrift.bind.host/name value0.0.0.0/value /property同时确保没有防火墙拦截 10000 端口。6.2 Schema 初始化失败的深度排查schematool执行失败是概率最高的问题。根据我的经验失败情况分两种一种是纯环境问题比如前面的认证失败、驱动没放对这类错误通过日志能快速定位另一种是报错信息含糊比如Specified key was too long; max key length is 3072 bytes这其实是 MySQL 版本和 Hive Schema 语句之间对于索引长度的限制不一致造成的。遇到这种问题不用急着去改 MySQL 参数先确认 MySQL 版本5.7 和 8.0 对 InnoDB 索引长度的限制不同。稳妥的做法是初始化前把 MySQL 的innodb_large_prefix和innodb_file_format调整为支持大前缀的模式或者直接使用 MySQL 8.0 版本默认就支持 3072 字节索引。另外schema 初始化脚本在运行过程中会执行大量建表语句如果中途失败第二次重新初始化前务必要清空元数据库中的残留表否则会报Table already exists之类的问题。我建议初始化前直接重建一个干净的数据库DROP DATABASE IF EXISTS hive_metastore; CREATE DATABASE hive_metastore DEFAULT CHARACTER SET utf8mb4;这套操作看起来暴力但能规避残留表的影响尤其在反复调试的情况下尤为高效。6.3 字符串乱码源头上防住乱码问题看起来不致命但非常影响使用体验。有次我在表里导入中文数据查询返回的结果是问号排查一圈下来问题出在 HiveServer2 和 beeline 会话之间的字符集传输上。处理思路分两层第一层是元数据库连接我们已经在 JDBC URL 里加了characterEncodingUTF-8这样 MySQL 会话的字符集会跟着连接串走。第二层是 beeline 客户端的字符集设置可以修改 hive-env.sh 加入export HADOOP_OPTS$HADOOP_OPTS -Dfile.encodingUTF-8这种做法能保证 HiveServer2 启动时Java 文件编码和 JVM 内部字符集都被设定为 UTF-8。之后再查询中文基本不会再遇到乱码。稍微注意一下如果你的数据本身不是 UTF-8 编码的比如从 Windows 上传的 GBK 文件那还需要做编码转换或指定表的编码方式这属于数据清洗层面的问题了。6.4 调优建议安装完成后值得做的小事安装完成只是第一步要让 Hive 在产出环境里跑得更顺有几个参数我建议顺手就改了。首先是执行引擎。Hive 3.x 默认执行引擎是 Tez而不是传统的 MapReduce。Tez 在复杂 DAG 任务上的性能优势明显但它的容器调度和资源管理配置相对敏感。如果你觉得作业调度不太稳定可以在 hive-site.xml 里临时切回 MapReduceproperty namehive.execution.engine/name valuemr/value /property不过我不建议长期用 MapReduce它在这个时代太慢了。如果你的集群内存资源充足直接上 Spark 引擎会更好配置方式是property namehive.execution.engine/name valuespark/value /property其次是 JVM 堆内存。HiveServer2 在默认配置下JVM 堆内存可能不够支撑大量并发查询。修改$HIVE_HOME/conf/hive-env.sh中的HADOOP_OPTS或HIVE_OPTSexport HIVE_OPTS-Xmx4096m如果是资源受限的测试机至少给到 2G不然大一点的查询就会把服务压垮。最后是关于本地模式。在小数据集测试阶段可以通过设置set hive.exec.mode.local.autotrue;让 Hive 在数据量小的情况下自动切换为本地执行能大幅减少任务调度延迟。不过这个参数生产环境不建议开因为一旦数据量波动本地模式会造成内存瓶颈。6.5 服务启动后如何确保稳定性Hive 服务跑起来不代表万事大吉运维层面的检查需要形成习惯。个人经验是每天关注两个指标一是 HiveServer2 的日志里是否有大量异常堆栈二是 MySQL 里的连接数是否持续走高。后者尤其容易被忽视。Hive 在元数据并发访问高时可能会建立大量 JDBC 连接而 MySQL 的max_connections一旦不够就会出现间歇性连接超时。查看连接数的方式SHOW STATUS LIKE Threads_connected;如果连接数长期贴近上限可以在 hive-site.xml 里调小 Metastore 的连接池上限property namedatanucleus.connectionPool.maxPoolSize/name value20/value /property另外Metastore 和 HiveServer2 的日志要开启定期切割不然跑久了日志文件膨胀到几个 GB 都是常见的。可以使用 Linux 的logrotate来做简单切割省得磁盘被日志写满。7. 基于这套安装环境的日常使用体会安装配置 Hive 这事熟练的人半小时能搞定不熟悉的人可能要折腾一整天。差别不在于命令背得熟不熟而在于是否理解每一步配置背后的原因。比如知道为什么要换元数据库为什么要处理 Guava 版本为什么建库时指定 utf8mb4这些细节组合在一起就是一条完整的知识链。遇到报错时具备这种链条式的理解能力排障速度会快很多。再分享一个我个人的操作习惯每次安装完成后我会专门建一个记录文档把安装包的版本、MySQL 连接串、各项关键配置的最终值、启动命令和常见报错截图全部放进去。这个文档最初是为了自己复查方便后来团队里别人遇到相同问题时直接扔给他们就能自取所需省了我大量重复回答问题的时间。如果后续你还要做更多的事情比如把 Hive 接入调度系统、做数据权限控制、或者用 Spark 来跑 Hive SQL这套安装配置就是一切的地基。地基打得稳不稳直接决定上面能建多高的楼。希望这篇东西能让你少踩几个坑一次把 Hive 装明白。

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询