简介pentaho-kettle-8.2.zip 是面向数据集成与企业级数仓建设的ETL工具包内含 Pentaho Data IntegrationKettle8.2版本完整安装文件及运行组件适合数据分析师、开发人员和DBA在本地或服务器上搭建抽取、清洗、转换、加载流程。压缩包为zip格式体积约87.11MB涵盖Spoon图形化设计界面、Pan与Kitchen执行引擎等核心模块可配合教程完成环境配置与工作流设计。已有666人学习下载具备较好的入门参考价值。读者可通过实际安装操作体验拖拽式步骤配置、多数据源接入、任务调度及日志监控理解ETL的关键环节为后续数据处理项目奠定基础。1. 这个 ETL 工具包解决的是「数据搬运」问题做数据集成的人对 Pentaho Kettle 8.2 不会陌生它是一款图形化 ETL 工具核心价值是把数据从 A 点移动到 B 点中间完成清洗、转换、校验。我拆过别人给的 pentaho-kettle-8.2.zip也自己下载部署过多次结论是它开箱即用但坑点集中在环境、驱动和路径三处。这份资源适合两类人一类是刚接触 ETL、不想写代码就想把 Excel 导进数据库的新手另一类是需要定时从多个业务库抽数、做轻度清洗的老手。Kettle 的逻辑不是写程序而是用「步骤 跳」搭出数据流鼠标拖拽替代编码但对数据模型和 SQL 基本功还是有要求的。它能解决的是企业中 80% 的常规数据搬运场景——文件导入、库表同步、字段拆分合并、增量抽取这些都覆盖到了。先给结论8.2 版本稳定、社区资料多、踩坑帖多到能绕地球一圈值得下载。2. 安装与启动解压就能跑但三个前置条件先确认2.1 JDK 版本与位数校验Kettle 8.2 对 Java 的依赖非常死。官方要求 JDK 8必须是 64 位版本实测在更高版本 JDK 上会直接起不来或运行到一半抛 UnsupportedClassVersionError。很多用户把 Kettle 启动失败归咎于软件本身其实十有八九是 Java 环境问题。java -version # 正确输出示例 # java version 1.8.0_291 # Java(TM) SE Runtime Environment (build 1.8.0_291-b10) # Java HotSpot(TM) 64-Bit Server VM (build 25.291-b10, mixed mode)这里有个小坑部分 JDK 安装包是 32 位和 64 位共存的命令行输出只要出现 32-Bit 就需要重装。Kettle 启动脚本 spoon.bat 会自动检测 JAVA_HOME如果检测不到就采用注册表里的 Java 路径。所以排查的第一件事不是改脚本而是看 java -version 输出。JAVA_HOME环境变量指向的路径不要带空格比如C:\Program Files\Java\jdk1.8.0_291会引发潜在问题最稳妥是装在D:\Java\jdk1.8.0_291这类无空目录下。另外注意 8.2 版本不支持 JDK 11 或 17这是社区里反复验证过的。2.2 解压路径与权限陷阱Windows 下解压 pentaho-kettle-8.2.zip 后直接双击 Spoon.bat 是最常见的启动方式。但路径不能带中文也不能带空格D:\数据分析工具\kettle这种路径会导致某些插件加载失败表现是启动后左侧组件树部分为空。从 ZIP 包里解压时如果遇到文件被占用或杀毒软件报警通常是lib\下某些 jar 被误杀了这时候从原压缩包重新提取对应文件即可。macOS 和 Linux 环境下执行启动脚本前需要给文件加执行权限。最常见的报错是Permission denied原因是 zip 包解压后没保留可执行位。cd pentaho-kettle-8.2 chmod x spoon.sh ./spoon.shLinux 服务器通常没有图形界面Kettle 8.2 的 Spoon 界面依赖 X Window纯命令行环境要用 Pan转换执行和 Kitchen作业执行这个区别后面会讲。另外解压后建议检查libswt\目录下是否有对应操作系统的 swt.jar 文件——Windows 版 zip 里会带上 win32 相关 jarmacOS 版需要额外下载拿错平台的包会导致启动时闪退或报 No more handles 错误。2.3 启动参数与内存调整Kettle 默认启动内存不大处理大文件时经常报Java heap space。这个问题的解决入口在 Spoon.bat 里的PENTAHO_DI_JAVA_OPTIONS参数。我一般会改到至少 2Gset PENTAHO_DI_JAVA_OPTIONS-Xmx2048m -Xms256m -XX:MaxPermSize256m在 64 位 JDK 8 下Xmx调大效果非常明显。一个常见误区是只调Xms不调Xmx导致堆内存到达上限后频繁 Full GC。此外如果同时跑多个转换任务每个 Spoon 实例会申请独立内存改完参数记得重启 Spoon 才生效。Kettle 的运行机制可以理解为「数据流管道」每个步骤Step是一个节点步骤间通过跳Hop连接数据从第一个步骤灌入顺流而下经过各节点处理——了解这个模型后面所有配置都会变得容易理解。3. 核心概念拆解转换Transformation和作业Job的分工逻辑3.1 转换面向行的数据流处理Kettle 8.2 里最基础的文件是转换文件后缀.ktr。转换描述的是一条数据流输入步骤 → 处理步骤 → 输出步骤。典型场景是把 Excel 内容读进内存做字段类型转换再写入数据库表。Kettle 把每一行数据当作流式单元处理所以几百 MB 的 Excel 不会一次性加载进内存这是它优于直接用 Pandas 脚本的地方。创建转换的入口文件 → 新建 → 转换。核心操作区是画布左侧有步骤面板按类目分组输入、输出、转换、应用、流程、脚本等。一个最简单的「读取文本文件并输出到控制台」由两个步骤构成文本文件输入和自定义常量用于在日志里打印把两个步骤用鼠标拖一条 Hop 连起来运行后就能预览数据。这里的逻辑关系和 SQL 的 SELECT 有点像——每个步骤相当于 SELECT 子句里的一层计算。参数调优的一个关键点在「行集大小」Rows in RowSet。Kettle 的数据流步骤间默认用行集做缓冲行集太小会造成频繁阻塞和上下文切换。常见做法是把行集大小调整到 5000 以上# 文件 → 转换设置 → 行集大小 # 默认是 10000对大多数场景够用 # 但步骤间有大数据量传递时比如一亿行调整为 50000 可以明显降低等待时间这个值是怎么发挥作用的每个步骤的输入输出都通过行集队列连接上游产出快、下游消化慢时队列堆积到上限就会阻塞上游。调高行集大小就是给上下游之间加缓冲池代价是内存占用上升。这个参数实践里最容易被忽略却是 Kettle 调优性价比最高的旋钮之一。3.2 作业面向任务顺序的调度器作业的后缀是.kjb它不处理单行数据而是把「转换」「SQL 脚本」「文件传输」「邮件通知」按顺序或按条件组织起来是 Kettle 的调度中枢。作业可以嵌套一个作业里能调用多个转换也能调用其他作业——这就是 ETL 项目的总控入口。作业和转换在概念上容易混淆用一个场景区分需要「每天凌晨把订单库增量数据同步到数仓完成后触发报表刷新」——「订单增量同步」是转换「按顺序执行同步、判断是否成功、触发报表」是作业。作业从START组件开始组件之间用跳连接跳上可以设置条件属性支持成功时执行、失败时执行等逻辑。这是 Kettle 8.2 里做复杂调度的基础能力。一个常见设计原则ETL 任务只要涉及两个以上步骤且对执行顺序有要求就套作业而不是把一堆步骤堆在转换里。很多新手习惯在一个转换里堆二十个步骤结果出现「上一步没跑完下一步就启动」的想当然场景逻辑错乱后调试极其痛苦——作业里可以显式控制执行顺序转换里步骤间没有顺序依赖只有数据依赖这是两者的本质区别。3.3 命名参数与变量避免魔法值一个健壮的 Kettle 项目不会把数据库连接串、文件路径直接写死。Kettle 8.2 支持变量Variable和命名参数Named Parameter两种机制。变量作用于全局通常在kettle.properties文件里声明命名参数作用于当前转换或作业可以设置默认值执行时从命令行或作业传递进来。// 在转换里使用变量 // 步骤参数写法示例 // JDBC 连接参数 // Host: ${DB_HOST} // Port: ${DB_PORT} // Database: ${DB_NAME} // 用户名: ${DB_USER} // 密码: ${DB_PASSWORD}这种做法的价值在于环境迁移。开发环境、测试环境、生产环境的数据库多半不同把连接参数抽成变量后部署时只需要改kettle.properties一个文件不需要打开每个转换修改数据库步骤。执行时还能用命令行覆盖pan.sh -file /path/etl.ktr -param:DB_HOST10.20.30.40 -param:DB_PORT3307变量使用要遵循的一个边界是Kettle 变量是启动时解析的运行途中改了参数文件不会立即生效。另外变量名区分大小写${db_host}和${DB_HOST}是两个不同变量这类问题排查起来比较隐蔽日志里不会直接提示变量不存在而是给你一个奇怪的连接错误——看到数据库连不上的报错第一反应检查变量名是否拼写一致。4. 手把手做一个 Excel 转数据库的转换从空画布到跑通4.1 输入侧Excel 输入步骤的配置细节以最常见的「把销售明细 Excel 导入 MySQL 表」为例完整走一遍配置流程。打开 Spoon新建转换左侧面板拖出Excel 输入步骤。第一步是选择文件。点击「浏览」选中 .xls 或 .xlsx 文件。注意 8.2 版本对 Excel 格式有隐性要求——.xlsx 文件需要额外的 POI 依赖默认发行包已经包含但如果是从精简版 zip 解压的可能缺少poi-ooxml-schemas.jar此时导入 .xlsx 会报 Unable to load class 错误民间解决方案是把对应文件从lib目录补全。更稳的做法是转存一份 .xls 作为测试。第二步是工作表配置。Sheet 名称留空表示读取第一个工作表起始行默认 0对应第一行数据头部行区域里勾选「头部行」选项Kettle 会把第一行作为列名读取这一步影响后面所有字段名的引用。第三步是字段映射。点「获取字段」按钮Kettle 自动按 Excel 列生成字段列表。这一步需要人工核对类型映射文本 → String数字 → Integer/Long日期 → Date。不能直接信任默认映射——Excel 里的数字往往被读成 BigDecimal写入数据库时目标列是 INT 就会报错。我一般会在这里把不需要的字段删掉避免数据流里带着冗余列跑。# 字段列表示例获取后手工调整 # 字段名: 订单号 类型: String 长度: 50 # 字段名: 商品ID 类型: Long 长度: - # 字段名: 销售数量 类型: Long 长度: - # 字段名: 销售日期 类型: Date 长度: - # 字段名: 销售额 类型: BigDecimal 长度: -这一步的检测技巧是点击「预览」按钮看 100 行数据读出来是否与 Excel 一致。预览是 Kettle 8.2 的「后悔药」所有输入步骤都支持预览数据务必在搭后续步骤前确认类型解析正确。否则类型错误会被传递到输出侧导致整条数据流在最后一步炸掉排查范围被迫扩大。4.2 输出侧表输出步骤的选型判断Kettle 8.2 提供两种写数据库的步骤表输出和插入/更新。两者适用场景不同表输出是把数据直接 INSERT不做查询判断适合一次性全量导入插入/更新是逐行做主键匹配存在则更新、不存在则插入适合增量同步。导入场景下选表输出就够了。连接配置窗口里填主机名、数据库名、端口、用户名密码。实际工作中有一个几乎必踩的坑MySQL 驱动问题。Kettle 8.2 自带的是旧版 MySQL 驱动对 MySQL 8.0 的连接协议不支持表现为连接测试成功但运行时抛Communications link failure或Public Key Retrieval is not allowed。解决办法是把mysql-connector-java-5.1.49.jar放进 Kettle 的lib目录覆盖旧的驱动另外建立连接时 URL 后面要拼接useSSLfalseallowPublicKeyRetrievaltrue参数。表输出步骤里「提交记录数量」参数是性能核心。它表示每攒够多少行提交一次事务。默认值是 1000对大数据量写入来说太小——每 1000 行就开一次事务磁盘刷写频率高总耗时按指数增长。生产环境我一般调到 5000 到 10000具体要看数据库负载能力。# 表输出参数 # 提交记录数量Commit Size: 5000 # 目标表: sales_detail # 数据库连接: MySQL / sales_ods # 勾选“指定数据库字段”后点击“获取字段”指定数据库字段这个按钮值得单独说明。它会读取目标表的元数据把源字段和目标字段做名称匹配。如果两边字段名不一致要手工在列表中拖拽对应关系。很多使用者在字段名不一致时直接忽略运行后报 Unknown column xxx in field list——这就是没做字段映射的后果。4.3 执行与验证从日志判断数据是否真正落库配置完成后点击运行按钮Kettle 会弹出一个执行窗口下方显示实时日志。判断是否成功的标准不是「没有报错」而是看日志尾部写着Finished processing.同时已处理行数与 Excel 行数一致。如果中间出现了红色 ERROR 行点击日志里的错误行会跳转到对应步骤。日志级别默认是「基本」排查问题时可以改为「详细」或「调试」这样能看到每个步骤传输的行数和耗时。一个技巧是运行窗口有个「日志」标签页修改级别后重新运行对比每个步骤处理行数的差异瓶颈一眼可见。# 日志中关键输出 # 2025/01/10 10:23:15 - Excel输入.0 - 完成读取了 100000 行 # 2025/01/10 10:23:15 - 表输出.0 - 完成写入 100000 行 # 2025/01/10 10:23:15 - Spoon - 转换完成!还有一个验证方式是直接到数据库里查行数。如果 Excel 有 100000 行数据而库里只落了 99999 行优先检查源数据是不是有重复的标题行或空行——这是 Excel 输入步骤里最常见的脏数据问题配置时把「起始行」跳过标题、勾选「忽略空行」可以解决大半。4.4 避坑清单Excel 导入场景的四个高频问题现象一预览时字段名乱码或中文变问号。原因是 Excel 文件编码不是 UTF-8。解决把文件另存为 CSV 或统一转为 UTF-8 编码的 Excel。现象二日期字段读出来是数字如 43831。这是 Excel 日期序列值Kettle 读取时没识别列类型。解决在 Excel 输入字段列表里手工把类型改成 Date同时指定格式yyyy/MM/dd。现象三目标表没有创建表输出报Table doesnt exist。Kettle 的表输出默认不会自动建表。解决在数据库连接窗口的「选项」里勾选自动建表或者在表输出目标表属性里选择「创建表」按钮手动生成 DDL。现象四BigDecimal 写入 DECIMAL 目标字段丢精度。Kettle 的默认精度是 10 位小数读取 Excel 数字时可能产生1.2300000000000002这类浮点尾差。解决在字段映射的「格式」列设置#.##或者在 Excel 输入步骤中把类型指定为 BigDecimal 并设置 scale。这些坑都是我在实际项目里砸过时间的每一条都有具体的报错形态和解决办法值得收藏备份。5. 数据库连接与驱动治理连不上、时区错、驱动冲突的根治方案5.1 MySQL 8 连接的驱动对策Kettle 8.2 发布时 MySQL 5.x 是主流自带的驱动是mysql-connector-java-5.1.x。时代变了现在多数业务库已经是 MySQL 8.x直接连就会遇到驱动兼容性报错。典型错误有三种形态Access denied for user用户名密码错也可能是驱动用旧协议连接新版本用户认证插件caching_sha2_password——自带驱动不认这个插件。解决把认证插件改回mysql_native_password或者换驱动。Communications link failure底层连接建立后协议握手失败跟网络无关。解决替换驱动到mysql-connector-java-8.0.22及以上。The server time zone value йʱ is unrecognized时区问题MySQL 8 默认时区配置在驱动侧不识别。解决JDBC URL 后缀加serverTimezoneAsia/ShanghaiuseSSLfalse。# Kettle 数据库连接 JDBC URL 写法示例 # jdbc:mysql://192.168.1.100:3306/sales_db?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue注意 URL 里的useSSLfalse不是安全妥协而是规避内网环境自签名证书导致的 SSL 握手失败。allowPublicKeyRetrievaltrue是 MySQL 8 在非 SSL 模式下获取 RSA 公钥必须的参数不加会报Public Key Retrieval is not allowed。5.2 Oracle 与 SQL Server 连接经验Oracle 的坑主要在驱动 jar 版本上。Kettle 8.2 对 Oracle 11g/12c 的驱动兼容性良好但 12c 以上版本需要使用ojdbc8.jar。很多读者搜索kettle ojdbc6.jar 11.2.0.4说明线上还是大量使用 Oracle 11g。这个版本对应驱动文件名是ojdbc6.jar但有一个隐藏要求Kettle 的lib目录不能同时存在多个 ojdbc 版本否则类加载器随机使用连接时报奇怪的ORA-01017或ORA-28040协议版本不匹配。# Oracle 连接配置 # 连接类型: Oracle # Host: 10.0.0.5 # Port: 1521 # Database: ORCL (SID 方式) # 或使用 Service Name: ORCL.WORLD # URL格式: jdbc:oracle:thin:10.0.0.5:1521/ORCL.WORLDOracle 驱动替换有个习惯性操作确认lib目录下只有一个ojdbc*.jar最好把多余版本移到备份目录而不是删除防止后续要回退。Kettle 对 Oracle 连接类型的「使用 SID 还是 Service Name」有区分——SID 用:host:port:sidService Name 用:host:port/servicename冒号后是斜杠还是冒号决定连接是否成功这个细节试错成本极高。5.3 资源库文件版还是数据库版Kettle 8.2 支持两种资源库文件资源库基于 XML和数据库资源库基于表结构。新手推荐文件资源库简单、可版本控制。数据库资源库适合团队多人协作把转换存在共享库里避免各自本地文件冲突。数据库资源库的坑在于首次初始化选择数据库类型后Kettle 会自动创建 20 多张表。如果用 MySQL 5.7 以下版本且字符集不是 utf8mb4初始化可能失败报错信息里出现Specified key was too long——因为表结构里索引字段长度超过旧版 MySQL 的 767 字节限制。解决创建数据库时指定utf8mb4和ROW_FORMATDYNAMIC或者在初始化之前先执行CREATE DATABASE kettle_repo DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; ALTER DATABASE kettle_repo CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;团队协作时资源库的版本冲突问题也存在。两个人在同一个数据库资源库上同时编辑同一个转换后保存的人会覆盖先保存的人。这是产品设计限制8.2 没有分锁机制。习惯做法是一人负责一个模块或者导出成 XML 文件再合并——但要小心Kettle XML 文件是单行紧凑格式Git 对比时的 diff 不友好kettle-xml格式化工具也不够成熟建议用 Kettle 自带插件Version Control做集成社区版支持有限生产环境我用文件资源库 人工评审居多。5.4 连接问题的定位路径数据库连不上时别急着改 Kettle 配置先在命令行用 JDBC 驱动直接测一下网络层和认证层。Kettle 里测试连接虽然方便但它给出的错误信息有时经过一层封装掩盖了原始原因。常见定位路径是先确认服务器端口可达telnet 192.168.1.100 3306 # 或 nc -vz 192.168.1.100 3306确认端口能通之后再用 Java 命令行模拟 Kettle 的连接方式看原始报错。我习惯在 Kettle 安装目录下运行一个临时 Java 类或者直接用写数据库的转换里加的执行 SQL 脚本步骤打出一条SELECT 1。这样能区分开「网络问题、认证问题、驱动问题、SQL 语法问题」四个层面避免在错误层面上做无用功。Kettle 8.2 里「数据库连接」对话框页签多「高级」标签页里的参数不要乱勾有些选项比如Use streaming在不同驱动下行为差异大默认值保持不动是稳妥策略。6. 里增量同步与变量化改造给 ETL 上「后悔药」和生产可维护性6.1 增量同步的三种实现策略批量全量导入是入门操作生产环境需要响应「每天只同步新增和变更数据」的场景。Kettle 8.2 里常见的增量策略有三种各有适用边界。第一种是时间戳增量。源表里有update_time字段作业里先取上次同步的最大时间再作为 SQL 查询条件抽取数据。实现方式是作业里用获取变量拿到上次时间拼到 SQL 里。这里有一个细节时间比较最好在 SQL 里做而不是在 Kettle 步骤里过滤——减少数据传输量。第二种是主键对比。适合源表没有时间字段的场景把目标表主键集合加载到内存用合并记录步骤做比对输出 new/update/delete 三类结果。这个方案对内存要求高表行数超过百万后性能急剧下降需要分区分批处理。Kettle 的合并记录步骤会全量加载两侧数据做排序不是流式处理这一点要心里有数。第三种是数据库 CDC。MySQL 的 binlog 解析、Oracle 的 GoldenGateKettle 本身不直接消费 binlog而是通过中间表配合实现。常见做法是源库通过触发器或定时任务把变更记录写入一张日志表Kettle 作业读取日志表并同步日志数据。这也是很多生产环境采用的方式因为对源库侵入小、实现稳定。三种策略选型没有银弹。数据量小百万行以下用时间戳最省事无时间字段但主键稳定的用主键对比数据量大且变更频繁的建议走日志表方案。分布式环境下 Kettle 的同步不是实时管道偏移量管理很弱不适合做真正的实时同步。6.2 增量的参数传递变量在作业与转换间的桥接增量同步离不开变量传递。作业里每次执行完同步任务后要把最新时间戳写回参数或配置文件供下一次作业启动时读取。Kettle 8.2 的做法是在作业里加一个SQL 脚本步骤执行UPDATE kettle_sync_status SET last_sync_timeNOW()或者用写日志步骤配合设置变量步骤把时间存成全局变量。设置变量步骤的坑在作用域变量可以设置成「JVM」「当前作业」「父作业」「祖父作业」四种范围。选错范围会出现「这个作业里明明设置了变量下一个转换里就是读不到」的诡异问题。最常见的错误是选成JVM导致在同一个 Spoon 实例里运行多个作业时变量互相污染。生产环境我一般把跨作业共享的变量范围设为当前作业并明确把变量名和用途写在一张注释表里防止后续接手的人猜谜。# 增量状态表结构示例MySQL CREATE TABLE kettle_sync_status ( sync_name VARCHAR(100) PRIMARY KEY, last_sync_time DATETIME, sync_start_time DATETIME, sync_end_time DATETIME, row_count INT, status VARCHAR(20) );这张表是增量同步的「后悔药」——所有同步任务的断点续跑都依赖它。一旦中间过程出错可以手动调整last_sync_time来回退数据不需要重跑全量。这是我在生产项目里一定会做的事。6.3 失败重试与通知作业里的可靠性设计作业跑挂了最怕的不是报错本身而是没人知道。Kettle 8.2 的作业支持邮件组件可以在失败分支上接一个发邮件的步骤把错误日志一并发出。这里有一个参数值得留意邮件连接配置里「SSL」选项默认关闭很多公司邮箱强制 SSL不打开就发不出去。重试机制方面Kettle 原生不支持「步骤级重试」但支持作业级重试——在作业跳上设置「失败时重新执行」并指定重试次数。这个功能藏得比较深在跳的属性面板里选项叫Number of retries。同时要配合Sleep between retries设置间隔防止失败时立即重试导致数据库连接风暴。# 作业跳参数 # 错误处理: 失败时重试 # 重试次数: 3 # 重试间隔: 30 秒 # 如果仍失败: 发送邮件给 oncall 组重试次数不是越大越好。如果失败原因是 SQL 语法错误重试 100 次结果都一样如果原因是数据库连接池耗尽间隔太短每次重试都会加剧问题。经验值是重试 2-3 次、间隔 30-60 秒能覆盖大部分抖动场景。6.4 日志回溯的标准化Kettle 的默认日志是控制台输出任务跑完就没了。生产环境要做日志持久化Kettle 8.2 提供日志表机制可以在转换或作业设置里勾选日志记录把执行信息写入数据库表。日志表包括作业日志、步骤日志、性能日志、渠道日志。我在项目里的最小配置方案是启用作业日志和步骤日志作业日志记录整体执行结果步骤日志记录每个步骤的行数、耗时。这样出问题时能追溯到是哪个步骤消耗了 90% 的时间还是在哪个步骤开始没有数据流入。另外日志表字段里的LOG_FIELD可以存完整日志文本但这个字段类型在 MySQL 下是TEXT只保留最近几次执行的问题日志防止表膨胀。从那以后我每次部署 Kettle 任务都强制走一遍「数据库连接测试 → 转换单跑 → 作业连跑 → 日志入库」四步验证。这个流程能挡掉 95% 的线上事故剩下的 5% 靠日志回溯。希望这份 Kettle 8.2 实战拆解帮到你——工具是死的流程是活的祝你的数据管道跑得顺畅。本文还有配套的精品资源点击获取