1. 项目概述：为什么Hadoop调优是数据工程师的必修课？

干了这么多年大数据，我越来越觉得，Hadoop集群就像一辆重型卡车。你买回来，装上货（数据），它确实能跑。但如果你不根据路况（业务负载）、货物重量（数据规模）和发动机状态（集群硬件）去精细地调整变速箱、悬挂和油门，那结果要么是“小牛拉大车”跑得吭哧瘪肚，资源空转；要么就是“大炮打蚊子”，一点小作业把整个集群搞得鸡飞狗跳，成本飙升。Hadoop调优，本质上就是让这辆“数据卡车”在稳定性、速度和油耗（资源成本）之间找到最佳平衡点的过程。

很多刚接触Hadoop的朋友容易陷入一个误区：认为集群性能不行，加机器就行了。这当然是一种办法，但也是最昂贵、最不优雅的办法。真正的价值在于，通过对现有资源的精细化管理和参数优化，用同样的硬件榨出更高的性能。这不仅能直接降低企业的云资源或硬件采购成本，更能提升数据产出的时效性，让业务决策更快一步。今天，我就结合自己踩过的无数个坑，从集群规划、核心组件参数、到JVM和操作系统层面，系统地拆解一遍Hadoop调优的完整思路和实操细节。无论你是在维护一个几台机器的小集群，还是管理着上百个节点的大平台，这里面的原理和方法都是相通的。

2. 调优核心思路：从“能用”到“好用”的思维转变

调优不是漫无目的地修改配置文件，而是有目标、有层次地系统性工程。我的经验是，一定要遵循“自上而下，由外而内”的原则。

2.1 确立调优目标与评估基准

在动手改任何一个参数之前，你必须先回答三个问题：

  1. 当前的主要矛盾是什么？ 是作业跑得慢（性能瓶颈），还是集群动不动就挂（稳定性差），或者是资源利用率长期低于50%（成本浪费）？不同的问题，调优的侧重点截然不同。
  2. 你的量化目标是什么？ “变快”是一个模糊的概念。你需要一个可衡量的基准。例如：“将夜间核心ETL作业的总耗时从4小时降低到2.5小时以内”，或者“将集群整体CPU平均利用率从40%提升至65%”。
  3. 如何测量？ 依赖Hadoop自带的监控（如ResourceManager UI, NameNode UI）和作业历史（JobHistory Server）是基础。更推荐接入像Prometheus + Grafana这样的专业监控栈，对集群、队列、作业级别的CPU、内存、IO、网络进行全方位、历史化的度量。没有监控的调优就是盲人摸象。

实操心得 ：调优前，务必用 teragen 和 terasort 这类基准测试工具，在集群上跑一个标准测试，记录下耗时、吞吐量等关键指标。这个数据将成为你后续对比优化效果的“基线”。任何参数的调整，都要能在这个基准测试或你的真实业务作业上体现出可复现的改进。

2.2 分层调优策略

我把Hadoop调优分为四个层次，像剥洋葱一样，从外到内：

  1. 集群规划与硬件层 ：这是调优的基石。如果硬件配置不合理，软件层面的优化事倍功半。包括磁盘选型（SSD vs HDD， RAID配置）、网络架构（万兆？ bonding？）、内存与CPU配比。
  2. 操作系统层 ：Linux内核参数对Hadoop这种高并发、高IO的应用影响巨大。包括文件描述符数量、网络参数、内存交换策略、磁盘调度算法等。
  3. Hadoop组件配置层 ：这是最核心的部分，涉及HDFS, YARN, MapReduce等核心组件的上百个参数。我们需要理解它们之间的关联和制约。
  4. 应用/作业层 ：针对具体的MapReduce、Spark或Hive作业进行代码和参数优化。比如数据倾斜处理、小文件合并、UDF优化等。

今天，我们主要聚焦在2、3、4层，因为硬件规划通常在集群搭建初期就确定了。但我会穿插讲清楚，底层硬件如何影响上层参数的配置选择。

3. HDFS调优：守护好你的数据仓库

HDFS是数据的家，它的稳定与性能直接决定了上层计算的速度。调优HDFS，核心目标是： 高吞吐量数据读写 和 元数据服务高可用 。

3.1 核心参数解析与配置

1. dfs.datanode.data.dir - 数据存储目录 这不是一个简单的路径设置。它的最佳实践是： 使用多块独立的物理磁盘，并配置为逗号分隔的多个目录 。 

<property>
  <name>dfs.datanode.data.dir</name>
  <value>/data1/dfs/dn,/data2/dfs/dn,/data3/dfs/dn</value>
</property>
  • 为什么？ HDFS会将数据块（block）轮询写入这些目录。多块磁盘可以并行进行IO操作，显著提升写入和读取吞吐量。这比用RAID 0（条带化）更常见，因为单块磁盘故障只会影响一部分数据块，而不是整个阵列，恢复起来更快、更经济。
  • 注意事项 ：确保每个目录挂载在不同的物理磁盘上，而不是同一块盘的不同分区。用 df -h 命令仔细检查。

2. dfs.blocksize - HDFS块大小 默认是128MB。这个参数需要根据你的数据规模和计算引擎来调整。

  • 调大（如256MB或512MB）的场景 ：适用于存储和处理 超大文件 （TB级以上）。优点是可以减少元数据（NameNode内存占用），减少MapReduce作业的Map Task数量（因为一个块通常对应一个Map），减少任务调度开销。缺点是，如果文件较小，会导致块内浪费空间，且单个Map任务处理数据量过大可能拖慢整体进度。
  • 调小（如64MB）的场景 ：适用于 小文件众多 的场景。可以增加并行度，但会加重NameNode内存压力。
  • 经验值 ：对于TB级数据仓库，256MB是一个不错的起点。对于PB级数据湖，可以考虑512MB甚至1GB。调整后，需要用 hadoop distcp 或重新写入数据来生效。

3. dfs.namenode.handler.count - NameNode RPC服务线程数 这个参数控制NameNode处理客户端RPC请求（如打开文件、创建文件）的线程数量。 

<property>
  <name>dfs.namenode.handler.count</name>
  <value>40</value>
</property>
  • 计算公式 ：一个经验公式是 20 * log2(Cluster Size) 。例如，对于一个50个节点的集群， 20 * log2(50) ≈ 20 * 5.64 = 112 。你可以从40开始，通过监控NameNode的RPC队列长度（在NameNode UI的 RpcDetailedActivityForPort8020 图表中查看）来调整。如果队列经常不为空，说明线程不足，需要增加。
  • 踩过的坑 ：这个值不是越大越好。设置过大，会导致线程上下文切换频繁，反而降低性能。同时，需要同步调整Linux系统的 nproc 限制，确保有足够的进程数支持这些线程。

3.2 高可用与故障恢复优化

对于生产集群，NameNode高可用（HA）是必须的。除了搭建ZKFC和JournalNode，这些参数关乎故障切换速度：

  • dfs.ha.automatic-failover.enabled : 必须设为 true ，启用自动故障转移。
  • dfs.client.failover.proxy.provider.[nameservice] : 配置正确的代理提供者。
  • dfs.ha.fencing.methods : 配置可靠的隔离方法（如SSH），防止“脑裂”。

针对DataNode的调优 ：

  • dfs.datanode.failed.volumes.tolerated : 默认是0，即一块磁盘失败，整个DataNode就下线。在生产环境中，可以设置为1或2，允许DataNode在损失一两块磁盘的情况下继续工作，给你时间窗口去更换磁盘，避免节点频繁退役影响数据块副本数。

4. YARN资源管理调优：当好集群的“调度总管”

YARN负责管理集群所有计算资源。它的调优目标是： 最大化资源利用率 ，同时 保证多租户间的公平性 。

4.1 资源量化：理解 vcore 和内存

这是最容易出错的地方。YARN管理的是“虚拟”资源。

  • yarn.nodemanager.resource.memory-mb ：一个NodeManager节点上，YARN可以管理的 总物理内存 。比如机器有64G内存，留给操作系统和其他进程（如DataNode）10G，那么这里可以设为 54 * 1024 = 55296 MB。

    重要提示 ：这个值必须小于等于物理内存，且要为操作系统和HDFS预留足够空间（通常15-20%）。否则会引发OOM Killer杀掉YARN进程。

  • yarn.nodemanager.resource.cpu-vcores ：一个NodeManager节点上，YARN可以管理的 虚拟CPU核心数 。它可以大于物理核心数，目的是为了支持那些IO密集型（非CPU密集型）的任务。例如，一台32物理核心的机器，可以设置为40或48个vcore，以提升资源封装率和集群吞吐量。
  • yarn.scheduler.minimum-allocation-mb / yarn.scheduler.maximum-allocation-mb ：单个容器（Container）可申请的最小和最大内存。默认是1024MB和集群总内存。根据你的任务类型调整。如果有很多小任务，可以适当调小最小值（如512MB）以减少资源碎片。
  • yarn.scheduler.minimum-allocation-vcores / yarn.scheduler.maximum-allocation-vcores ：单个容器可申请的最小和最大vcore数。

4.2 调度器选择与队列配置

默认的FIFO调度器不适合多用户/多团队共享集群。 Capacity Scheduler （容量调度器）是更主流的选择。

配置示例 ( capacity-scheduler.xml ) ： 

<property>
  <name>yarn.scheduler.capacity.root.queues</name>
  <value>prod,dev,default</value>
</property>
<property>
 <name>yarn.scheduler.capacity.root.prod.capacity</name>
 <value>60</value>
</property>
<property>
 <name>yarn.scheduler.capacity.root.dev.capacity</name>
 <value>30</value>
</property>
<property>
 <name>yarn.scheduler.capacity.root.default.capacity</name>
 <value>10</value>
</property>
<property>
 <name>yarn.scheduler.capacity.root.prod.maximum-capacity</name>
 <value>80</value>
</property>
  • capacity ：队列的 最低保证资源容量 。即使其他队列空闲，这个队列也能获得这部分资源。
  • maximum-capacity ：队列的 资源使用上限 。即使其他队列空闲，这个队列也不能超过这个比例。这防止了一个队列独占所有资源。
  • user-limit-factor ：设置单个用户在一个队列内可使用的资源倍数，防止单个用户占满整个队列。

实操心得 ：队列规划是门艺术。通常，我会划分出： prod （生产核心任务，高保障）、 etl （日常ETL，中等优先级）、 ad-hoc （即席查询，可抢占）和 default （兜底）。为 prod 队列设置较高的 capacity 和 user-limit-factor ，确保核心任务稳定；为 ad-hoc 队列设置较低的 capacity 但较高的 maximum-capacity ，允许它在集群空闲时充分利用资源。

4.3 容器与内存超售控制

  • yarn.nodemanager.pmem-check-enabled / yarn.nodemanager.vmem-check-enabled ：是否启用物理内存和虚拟内存检查。建议在生产环境将 vmem-check-enabled 设为 false ，因为Linux的虚拟内存计算方式（ pmem * 2.1 ）常常过于严格，导致任务因“超用虚拟内存”被误杀。更可靠的是依赖 pmem-check 和下面的参数。
  • yarn.nodemanager.vmem-pmem-ratio ：虚拟内存与物理内存的比率。如果启用vmem检查，可以适当调大此比例（如设为4.0）。
  • yarn.nodemanager.container-monitor.interval-ms ：容器监控间隔。调小（如3000ms）可以更快地检测到超用内存的容器并终止它，但会增加ResourceManager负担。

5. MapReduce应用层调优：让作业飞起来

YARN把资源管好了，接下来就是让MapReduce作业本身更高效。很多性能问题其实出在作业逻辑和参数上。

5.1 Map与Reduce任务数优化

这是调优的重中之重。任务数不是拍脑袋定的。

1. 如何确定Map数量？ Map数量主要由输入数据量和 InputSplit 大小决定。对于HDFS上的文件， InputSplit 大小约等于HDFS块大小（ dfs.blocksize ）。你可以通过 FileInputFormat.setMaxInputSplitSize() 和 setMinInputSplitSize() 来间接控制。

  • 原则 ：让每个Map任务处理的数据量在128MB到512MB之间是一个较好的范围。太小则任务启动开销占比大；太大则可能导致任务执行时间过长，且失败重试成本高。
  • 对于小文件 ：务必使用 CombineFileInputFormat 或其衍生类（如Hive中的 HiveInputFormat ），它可以将多个小文件“打包”成一个 InputSplit ，从而减少Map任务数，减轻调度压力。

2. 如何确定Reduce数量？ Reduce数量的设定更灵活，也更容易出错。

  • 经验公式 ： 0.95 或 1.75 乘以节点数乘以 yarn.nodemanager.resource.cpu-vcores 。
    • 0.95 倍时，所有Reduce任务可以在一波中启动，并立即开始从Map端拉取数据。
    • 1.75 倍时，第一波快的Reduce任务完成后，可以立即启动第二波，更好地负载均衡。
  • 更科学的做法 ：基于数据量估算。一个Reduce任务处理的数据量建议在1GB以内。你可以通过采样作业，估算出Shuffle阶段的总数据量，然后除以目标每个Reduce处理的数据量来设定。
  • 在代码中设置 ： job.setNumReduceTasks(100);
  • 踩过的坑 ： 永远不要将Reduce数设为0或1 ，除非你确定不需要Reduce阶段。设为1是常见的性能瓶颈，会导致所有数据汇聚到一个节点，极易产生数据倾斜和单点压力。如果不需要Reduce，请将Reduce数设为0，并确保输出格式是 NullOutputFormat 。

5.2 Shuffle阶段性能调优

Shuffle（洗牌）是MapReduce的心脏，也是最耗时的阶段，涉及大量的磁盘IO和网络传输。

Map端调优 ( mapred-site.xml ) ：

  • mapreduce.task.io.sort.mb ：Map端环形缓冲区（sort buffer）大小，默认100MB。如果Map输出较大，可以增加到200-400MB。这减少了溢写（spill）到磁盘的次数。
  • mapreduce.map.sort.spill.percent ：缓冲区溢写阈值，默认0.8（80%）。可以适当提高到0.9，让缓冲区容纳更多数据再溢写。
  • mapreduce.map.output.compress / mapreduce.map.output.compress.codec ： 强烈建议开启Map输出压缩 ！这能显著减少Shuffle阶段的网络传输量和磁盘IO。使用 snappy 或 lz4 编解码器，它们压缩解压速度快，CPU开销低。 
    <property>
  <name>mapreduce.map.output.compress</name>
  <value>true</value>
</property>
<property>
  <name>mapreduce.map.output.compress.codec</name>
  <value>org.apache.hadoop.io.compress.SnappyCodec</value>
</property>

Reduce端调优 ：

  • mapreduce.reduce.shuffle.parallelcopies ：Reduce同时从Map端拉取数据的并行拷贝数，默认5。在节点较多或网络较好的集群，可以增加到10-20，加快数据拉取速度。
  • mapreduce.reduce.shuffle.input.buffer.percent ：Shuffle阶段，Reduce任务内存中用于存放拉取数据的缓冲区比例（占整个Reduce堆内存的百分比），默认0.7。如果Reduce内存足够大，可以保持或微调。
  • mapreduce.reduce.shuffle.merge.percent ：内存中数据达到多少比例时开始合并溢写到磁盘，默认0.66。可以适当调高，减少磁盘合并次数。

5.3 压缩与序列化优化

除了中间输出，最终输出也建议压缩，以节省存储空间。选择压缩编解码器需要权衡压缩比和速度：

  • 高压缩比，可切片 ： bzip2 ，但速度慢。适用于冷数据存储。
  • 平衡之选 ： snappy 或 lz4 ，速度快，压缩比适中。适用于热数据和处理中间数据。
  • Hive表常用 ： ORC 或 Parquet 列式存储格式，它们自带高效的压缩（如 zlib , snappy ），并且支持谓词下推，能极大提升查询性能。 将文本文件转换为ORC/Parquet格式，本身就是最有效的“调优”之一。

序列化方面，使用 Writable 接口是Hadoop原生的，但效率不是最高。可以考虑使用更高效的序列化框架，如 Avro 、 Protocol Buffers ，特别是在跨语言或需要Schema演化的场景。

6. JVM与操作系统层调优：夯实基础

6.1 JVM垃圾回收调优

Map和Reduce任务都是在独立的JVM中运行的。不合理的GC设置会导致任务长时间停顿甚至失败。

  • 堆内存设置 ：通过 mapreduce.map.memory.mb 和 mapreduce.reduce.memory.mb 设置的是容器物理内存。JVM堆内存（ -Xmx ）应略小于这个值，以留给堆外内存（如Native库、线程栈）空间。通常设为容器内存的80%-90%。
    • 在 mapred-site.xml 中配置： 
    <property>
  <name>mapreduce.map.java.opts</name>
  <value>-Xmx2048m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=35</value>
</property>
<property>
  <name>mapreduce.reduce.java.opts</name>
  <value>-Xmx4096m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=35</value>
</property>
  • GC算法选择 ：对于大数据应用， G1垃圾回收器（ -XX:+UseG1GC ） 通常比传统的Parallel GC表现更好，因为它能更好地处理大内存堆，并具有可预测的停顿时间目标（通过 -XX:MaxGCPauseMillis 设置）。
  • 监控GC ：在 java.opts 中添加 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/tmp/gc.log ，将GC日志输出到文件。用工具（如GCViewer）分析，如果发现Full GC频繁或停顿时间过长，需要调整堆大小或GC参数。

6.2 Linux操作系统调优

这些设置通常需要root权限，在集群初始化时完成。

  1. 文件描述符与进程数 ：Hadoop会打开大量文件和网络连接。
    • ulimit -n (文件描述符) 和 ulimit -u (用户进程数) 应设置为一个较大的值（如65535或更高）。在 /etc/security/limits.conf 中永久设置。
  2. 网络参数 ：在 /etc/sysctl.conf 中调整。 
    net.core.somaxconn = 2048 # 提高连接队列长度
net.ipv4.tcp_tw_reuse = 1 # 允许重用TIME-WAIT sockets
net.ipv4.tcp_fin_timeout = 30 # 缩短FIN超时时间
net.ipv4.ip_local_port_range = 1024 65000 # 扩大本地端口范围
    执行 sysctl -p 生效。
  3. 磁盘调度算法 ：对于机械硬盘（HDD），将调度器设置为 deadline 或 noop 通常比默认的 cfq 性能更好，尤其对于大数据顺序读写。 
    echo deadline > /sys/block/sda/queue/scheduler
    对于SSD，使用 noop 或 deadline 。
  4. 关闭透明大页（Transparent Huge Pages） ：Hadoop工作负载，特别是Java应用，已知与THP存在交互问题，可能导致CPU使用率异常升高。建议关闭。 
    echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
    将此命令加入 /etc/rc.local 使其开机生效。

7. 监控、问题排查与实战案例

调优不是一劳永逸的，需要持续的监控和迭代。

7.1 监控指标看什么？

  • HDFS ：
    • Capacity Used% ：集群容量使用率。
    • Files and Blocks ：文件数和块数。块数增长过快需关注小文件问题。
    • Missing/Corrupt/Under Replicated Blocks ：缺失、损坏、副本不足的块数，应为0。
    • DataNodes ：活跃/死亡/退役的DataNode数量。
  • YARN ：
    • Resources ：集群总/已用/预留的内存和vcore。
    • Applications ：运行中/已提交/已完成/失败的应用数。
    • Nodes ：活跃/不健康的节点数。
  • MapReduce作业（通过JobHistory或Spark History） ：
    • 任务执行时间分布 ：是否有个别Map或Reduce任务执行时间远长于其他（数据倾斜）。
    • Shuffle数据量 ：Map输出和Reduce输入数据量是否异常大。
    • GC时间 ：任务花费在垃圾回收上的时间比例。

7.2 常见问题排查清单

问题现象 可能原因 排查方向与解决方案
作业运行极慢，Map阶段卡在100% 1. Reduce数太少（如=1）。
2. 个别Map任务输出巨大（数据倾斜）。
3. 网络或磁盘IO瓶颈。 		1. 检查 NumReduceTasks 设置，增加Reduce数。
2. 查看作业Counter，比较每个Map的 Bytes Written ，定位倾斜的Key。
3. 检查集群节点IOwait和网络流量。
任务频繁失败，报 Container killed 1. 物理内存超限（ pmem-check ）。
2. 虚拟内存超限（ vmem-check ）。
3. JVM GC overhead过高。 		1. 增加 mapreduce.map.memory.mb 或 reduce.map.memory.mb 。
2. 关闭 vmem-check 或增大 vmem-pmem-ratio 。
3. 分析GC日志，调整JVM堆大小和GC参数。
NameNode响应慢，RPC队列长 1. dfs.namenode.handler.count 设置过小。
2. 小文件过多，元数据压力大。
3. 内存不足，频繁Full GC。 		1. 增加handler线程数。
2. 合并小文件（使用Har或Spark/Impala合并）。
3. 检查NameNode堆内存，升级硬件或调整JVM。
集群整体资源利用率低 1. 任务资源申请不合理（如每个Map申请4G，但只用了500M）。
2. 调度队列配置不合理，资源被预留但未使用。
3. 数据本地性差，任务需跨网络拉数据。 		1. 通过监控调整 map/reduce memory.mb 和 java.opts 。
2. 检查Capacity Scheduler队列的 capacity 和 maximum-capacity 。
3. 观察作业的 Data-local maps 比例，优化数据分布。

7.3 一个实战调优案例：解决“数据倾斜”导致的作业长尾

我曾遇到一个夜间ETL作业，原本2小时完成，后来逐渐拖到6小时。分析发现，99%的Map任务在10分钟内完成，但有3个Map任务跑了近2小时。

  • 排查 ：检查作业Counter，发现这三个慢Map的 Bytes Written （输出）是其他Map的数百倍。这是典型的Map端数据倾斜。
  • 原因 ：输入数据中某个 key 异常多（比如日志中的 null 或默认值），导致处理这个 key 的Map任务负载过重。
  • 解决方案 ：
    1. 预处理 ：在数据清洗阶段，将这些异常 key 过滤掉或打散。
    2. 修改分区器 ：如果倾斜的 key 是业务必需的，可以自定义 Partitioner ，将这些热点 key 分散到多个Reduce任务中去处理。例如，对热点 key 附加一个随机后缀（ key_suffix ）后再进行分区。
    3. 增加Reduce资源 ：对于Reduce端倾斜，可以单独为处理热点 key 的Reduce任务申请更多内存（通过设置特定Job的Reduce内存参数），但这治标不治本。
  • 结果 ：采用方案1过滤无效键后，作业恢复至2小时左右完成。

调优是一个持续的过程，没有放之四海而皆准的“银弹”参数。最好的方法是： 建立监控基线 -> 定位瓶颈 -> 假设调整 -> 测试验证 -> 对比效果 -> 固化配置 。每次只调整一个或少数几个关键参数，观察其影响，才能稳步地将你的Hadoop集群性能提升到新的高度。记住，理解原理比记住参数更重要。当你明白了每个参数背后的“为什么”，你就能在面对千变万化的业务场景时，做出最合理的调优决策。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区