从衣柜整理到列式存储：大数据时代的“数据收纳术”

关键词

列式存储、大数据、OLAP、数据压缩、查询优化、Parquet、ORC

摘要

你有没有过这样的经历：早上急着出门，想找一件红色上衣，却不得不翻遍衣柜里的所有盒子——因为每套衣服（上衣+裤子+鞋子）都被塞进同一个盒子里？等你终于找到红色上衣时，已经迟到了10分钟。

在大数据时代，传统的“行式存储”就像这样的“按套放衣柜”：每一条数据（比如用户行为、交易记录）的所有字段都被存在一起。当你需要分析其中几个字段（比如“过去7天的点击量”）时，必须扫描所有数据的所有字段，效率极低。而“列式存储”则是一种“按类别放衣柜”的智慧：把同一个字段的所有数据存在一起（比如所有“上衣”放一个盒子，所有“裤子”放另一个盒子），找红色上衣时直接打开“上衣盒子”，效率提升数倍。

本文将用“衣柜整理”的类比，一步步拆解列式存储的核心概念：为什么列式存储比行式快？ 压缩效率为什么更高？ Parquet、ORC这些格式到底怎么工作？ 最后，我们会用电商、金融的真实案例，说明列式存储在大数据分析中的应用，并展望其未来趋势。

一、背景介绍：大数据时代的“衣柜危机”

1.1 为什么需要列式存储？

随着互联网、物联网的发展，全球数据量正以每年20%以上的速度增长（IDC，2023）。比如：

  • 电商平台每天产生数十亿条用户行为数据（点击、浏览、购买）；
  • 金融机构每天处理数千万条交易记录（转账、消费、理财）；
  • 医疗系统每天积累数百万条病历数据（诊断、化验、用药）。

这些数据的共同特点是：字段多（几十到几百个）、分析需求集中在少数字段（比如“统计每个商品的点击量”只需要“商品ID”和“行为类型”）。

传统的“行式存储”（比如CSV、MySQL的InnoDB）是按“行”存储的：每一行的所有字段连续存在磁盘上（如图1左）。当你需要查询“商品ID”和“行为类型”时，必须读取每一行的所有字段（包括不需要的“用户ID”“时间”“地点”等），导致大量不必要的IO开销。

比如，假设一条数据有100个字段，每个字段占10字节，那么一行就是1000字节。如果要查询其中2个字段，行式存储需要读取1000字节/行，而列式存储只需要读取20字节/行——IO量减少98%！

这就是列式存储诞生的原因：为大数据分析场景（OLAP）解决“查询慢、存储贵”的问题。

1.2 目标读者

本文适合以下人群：

  • 大数据初学者：想理解“列式存储”到底是什么，为什么它是大数据分析的基础；
  • 数据分析师：想知道为什么用Parquet格式的查询比CSV快10倍；
  • 开发人员：想学习如何在Spark、Hive中使用列式存储优化分析任务。

1.3 核心挑战

行式存储在OLAP场景下的三大瓶颈：

  1. 查询效率低：需要扫描所有行的所有字段，IO开销大；
  2. 压缩效率低：行内字段类型多样（比如字符串、整数、日期），无法用高效的压缩算法；
  3. 无法优化聚合查询：比如“统计每个商品的点击量”，行式存储需要逐行读取“商品ID”和“行为类型”，再进行分组统计，而列式存储可以直接对“商品ID”列进行分组，效率更高。

二、核心概念解析：用“衣柜整理”理解列式存储

2.1 行式存储 vs 列式存储：按套放 vs 按类别放

我们用“衣柜整理”来类比两种存储方式：

行式存储（按套放）列式存储（按类别放）
每一套衣服（上衣+裤子+鞋子）放在一个盒子里所有上衣放在一个盒子，所有裤子放在另一个盒子，所有鞋子放在第三个盒子
找红色上衣需要打开所有盒子，看每一套的上衣找红色上衣直接打开“上衣盒子”，只看上衣
盒子里的物品类型多样（上衣、裤子、鞋子），无法用统一方式压缩（比如上衣用真空袋，裤子用折叠）同一个盒子里的物品类型一致（都是上衣），可以用高效压缩方式（比如真空袋）

对应到数据存储：

  • 行式存储：每一行数据的所有字段（比如user_id、product_id、behavior_type、timestamp）连续存储在磁盘上；
  • 列式存储：同一个字段的所有行数据（比如所有product_id）连续存储在磁盘上。

用Mermaid图表示两者的结构：

列式存储
行式存储
user_id: 1, 2, 3
product_id: A, B, A
behavior_type: click, view, click
timestamp: 2024-01-01, 2024-01-01, 2024-01-02
Row 1: user_id=1, product_id=A, behavior_type=click, timestamp=2024-01-01
Row 2: user_id=2, product_id=B, behavior_type=view, timestamp=2024-01-01
Row 3: user_id=3, product_id=A, behavior_type=click, timestamp=2024-01-02

2.2 列式存储的三大核心优势

（1）查询效率：只取需要的“列”，减少IO

比如要查询“过去7天的点击量”，需要product_id、behavior_type、timestamp三个字段。

  • 行式存储：必须读取每一行的所有字段（比如user_id、product_id、behavior_type、timestamp），然后过滤出behavior_type=click且timestamp在过去7天的数据，再统计product_id的数量；
  • 列式存储：直接读取product_id、behavior_type、timestamp三个列的数据，过滤和统计都在这三个列上进行，IO量减少到行式的1/10甚至1/100。
（2）压缩效率：同列数据类型一致，压缩比更高

行式存储中，每一行的字段类型多样（比如user_id是整数，product_id是字符串，timestamp是日期），无法用高效的压缩算法。而列式存储中，同一个列的所有数据类型一致（比如product_id都是字符串），可以用以下压缩方式：

  • 字典编码（Dictionary Encoding）：把重复的字符串换成数字，比如product_id列的A→1、B→2，这样存储数字比字符串省空间；
  • 行程编码（RLE）：把连续重复的数据换成“值+次数”，比如behavior_type列的click, click, view→(click,2), (view,1)；
  • Delta编码：存储相邻数据的差值，比如timestamp列的2024-01-01, 2024-01-02, 2024-01-03→2024-01-01, +1, +1。

比如，一个product_id列有100万条数据，其中A出现50万次，B出现30万次，C出现20万次：

  • 行式存储：每个字符串占10字节，总大小是100万×10=10MB；
  • 列式存储：字典编码后A→1、B→2、C→3（占3×10=30字节），然后用RLE编码存储(1,50万), (2,30万), (3,20万)（占3×(4+8)=36字节，其中4字节是值，8字节是次数），总大小约30+36=66字节，压缩比高达15万:1！
（3）适合OLAP：优化聚合、统计查询

OLAP（在线分析处理）的核心需求是聚合、统计、多维分析（比如“每个商品的月点击量”“每个地区的季度销售额”）。列式存储的结构天然适合这些操作：

  • 聚合操作：比如count(product_id)，只需要扫描product_id列的所有数据，统计非空值的数量；
  • 分组操作：比如group by product_id，只需要对product_id列进行排序或哈希分组，不需要处理其他列；
  • 谓词下推：比如where behavior_type=click，可以在读取behavior_type列时直接过滤掉非click的数据，减少后续处理的数据量。

2.3 核心概念间的关系

列式存储的三大优势是相互依赖的：

  • 按列存储是基础：只有按列存储，才能实现“只取需要的列”和“同列数据类型一致”；
  • 压缩效率依赖于按列存储：同列数据类型一致，才能用高效的压缩算法；
  • 查询效率依赖于按列存储和压缩：减少IO量（按列存储）和数据量（压缩），才能提高查询速度。

三、技术原理与实现：列式存储的“收纳细节”

3.1 列式存储的核心结构：Row Group与Page

为了平衡查询效率和存储效率，列式存储通常将数据划分为Row Group（行组）和Page（页）两个层级（以Parquet为例）：

（1）Row Group：衣柜里的“抽屉”

Row Group是列式存储的基本存储单元，相当于衣柜里的一个“抽屉”。每个Row Group包含多列数据（比如product_id、behavior_type、timestamp），且每列的数据量相同（比如128MB）。

Row Group的大小通常设置为128MB-256MB（接近HDFS的块大小），这样可以：

  • 减少HDFS的元数据开销（每个Row Group对应一个HDFS块）；
  • 提高查询的并行度（每个Row Group可以由一个Spark任务处理）。
（2）Page：抽屉里的“叠衣页”

每个列的数据在Row Group中被划分为Page（页），相当于抽屉里的“叠衣页”。每个Page包含连续的行数据（比如8KB-16KB），且每个Page有自己的元数据（比如压缩类型、数据类型、索引）。

Page的类型主要有三种：

  • 数据页（Data Page）：存储实际的数据（比如product_id列的A、B、A）；
  • 字典页（Dictionary Page）：存储字典编码的映射表（比如A→1、B→2）；
  • 索引页（Index Page）：存储数据页的索引（比如数据页的起始位置、最大值、最小值），用于快速定位数据（比如找product_id=A的数据，不需要扫描所有数据页）。

用比喻总结：

  • Row Group = 衣柜里的一个抽屉（放一类衣服，比如上衣）；
  • Page = 抽屉里的一叠衣服（比如红色上衣叠成一页，蓝色上衣叠成另一页）；
  • 字典页 = 衣服的标签（比如红色→1、蓝色→2）；
  • 索引页 = 抽屉里的目录（比如红色上衣在第3页，蓝色上衣在第5页）。

3.2 列式存储的压缩原理：用“标签”和“叠衣”省空间

我们用一个具体的例子，说明列式存储的压缩过程（以behavior_type列为例）：

（1）原始数据

假设behavior_type列有10条数据：
[click, click, view, click, purchase, purchase, view, click, purchase, click]

（2）字典编码（给衣服贴标签）

首先，提取所有不同的值：click、view、purchase，然后给每个值分配一个数字标签：
click→1、view→2、purchase→3

编码后的数据为：
[1, 1, 2, 1, 3, 3, 2, 1, 3, 1]

（3）行程编码（把相同的衣服叠起来）

行程编码（RLE）将连续重复的数据换成“值+次数”：
(1,2), (2,1), (1,1), (3,2), (2,1), (1,1), (3,1), (1,1)

（4）压缩结果

原始数据每个字符串占10字节，总大小是10×10=100字节；
压缩后的数据（标签+次数）每个数字占4字节，总大小是8×(4+4)=64字节（8个行程，每个行程占8字节）；
如果再用Snappy或Zstandard压缩，总大小可以降到20字节以下，压缩比超过5:1！

3.3 列式存储的查询流程：从“找衣服”到“查数据”

我们用“查询过去7天的点击量”为例，说明列式存储的查询流程（以Parquet+Spark为例）：

（1）步骤1：读取元数据（看衣柜目录）

Spark首先读取Parquet文件的元数据（比如Row Group的位置、每个列的Page索引），找到包含product_id、behavior_type、timestamp列的Row Group。

（2）步骤2：过滤Row Group（选对抽屉）

根据timestamp列的索引页（比如每个Row Group的timestamp最小值和最大值），过滤掉timestamp不在过去7天的Row Group（比如Row Group 1的timestamp是2023-12-01，直接跳过）。

（3）步骤3：读取列数据（打开抽屉取衣服）

读取剩下的Row Group中的product_id、behavior_type、timestamp列的数据页。

（4）步骤4：过滤数据页（挑对衣服）

根据behavior_type列的字典页（比如click→1），过滤掉behavior_type≠1的数据页（比如数据页2的behavior_type是view，直接跳过）。

（5）步骤5：聚合统计（数衣服数量）

对过滤后的product_id列进行分组统计，计算每个product_id的点击量。

整个流程中，只有需要的列和数据页被读取，IO量和计算量都大大减少。

3.4 代码示例：用Python模拟列式存储的查询

我们用Python模拟行式存储和列式存储的查询过程，对比两者的效率：

（1）行式存储的查询

行式存储是一个列表的字典，每个字典代表一行数据：

# 行式存储：每个元素是一行数据（字典）
row_store = [
    {"user_id": 1, "product_id": "A", "behavior_type": "click", "timestamp": "2024-01-01"},
    {"user_id": 2, "product_id": "B", "behavior_type": "view", "timestamp": "2024-01-01"},
    {"user_id": 3, "product_id": "A", "behavior_type": "click", "timestamp": "2024-01-02"},
    {"user_id": 4, "product_id": "C", "behavior_type": "purchase", "timestamp": "2024-01-03"},
    {"user_id": 5, "product_id": "A", "behavior_type": "click", "timestamp": "2024-01-04"},
]

# 查询：过去7天（2024-01-01至2024-01-07）的点击量（behavior_type=click）
def query_row_store(store, start_date, end_date, target_behavior):
    result = {}
    for row in store:
        # 检查时间范围（需要读取所有行的timestamp字段）
        if not (start_date <= row["timestamp"] <= end_date):
            continue
        # 检查行为类型（需要读取所有行的behavior_type字段）
        if row["behavior_type"] != target_behavior:
            continue
        # 统计product_id的数量（需要读取所有行的product_id字段）
        product_id = row["product_id"]
        if product_id in result:
            result[product_id] += 1
        else:
            result[product_id] = 1
    return result

# 测试查询
start_date = "2024-01-01"
end_date = "2024-01-07"
target_behavior = "click"
print("行式存储查询结果：", query_row_store(row_store, start_date, end_date, target_behavior))
# 输出：{'A': 3}
（2）列式存储的查询

列式存储是一个字典的列表，每个字典代表一列数据：

# 列式存储：每个键是列名，对应的值是该列的所有行数据（列表）
column_store = {
    "user_id": [1, 2, 3, 4, 5],
    "product_id": ["A", "B", "A", "C", "A"],
    "behavior_type": ["click", "view", "click", "purchase", "click"],
    "timestamp": ["2024-01-01", "2024-01-01", "2024-01-02", "2024-01-03", "2024-01-04"],
}

# 查询：过去7天的点击量
def query_column_store(store, start_date, end_date, target_behavior):
    # 1. 取需要的列（product_id、behavior_type、timestamp）
    product_ids = store["product_id"]
    behavior_types = store["behavior_type"]
    timestamps = store["timestamp"]
    
    # 2. 过滤时间范围（只处理timestamp列）
    valid_indices = [i for i, ts in enumerate(timestamps) if start_date <= ts <= end_date]
    
    # 3. 过滤行为类型（只处理behavior_type列）
    valid_indices = [i for i in valid_indices if behavior_types[i] == target_behavior]
    
    # 4. 统计product_id的数量（只处理product_id列）
    result = {}
    for i in valid_indices:
        product_id = product_ids[i]
        if product_id in result:
            result[product_id] += 1
        else:
            result[product_id] = 1
    return result

# 测试查询
print("列式存储查询结果：", query_column_store(column_store, start_date, end_date, target_behavior))
# 输出：{'A': 3}
（3）效率对比
  • 行式存储：需要遍历每一行的所有字段（user_id、product_id、behavior_type、timestamp），即使这些字段不需要；
  • 列式存储：只需要遍历需要的列（product_id、behavior_type、timestamp），且过滤操作只在这些列上进行。

当数据量达到100万行时，列式存储的查询时间通常是行式的1/10到1/100（取决于列的数量）。

3.5 数学模型：列式存储的效率提升公式

（1）查询时间复杂度

假设数据有N行，M列，查询需要k列（k ≪ M）：

  • 行式存储：查询时间T_row = O(N*M)（需要扫描所有行的所有列）；
  • 列式存储：查询时间T_col = O(N*k)（只需要扫描所有行的k列）。

因为k ≪ M，所以T_col ≪ T_row。

（2）压缩比

压缩比CR定义为原始数据大小与压缩后数据大小的比值：
CR=原始数据大小压缩后数据大小 CR = \frac{原始数据大小}{压缩后数据大小} CR=压缩后数据大小原始数据大小​

列式存储的压缩比通常是行式的3-10倍（取决于数据的重复性）。比如，原始数据大小是100GB，压缩后是10GB，压缩比是10:1。

四、实际应用：列式存储在大数据分析中的“用武之地”

4.1 案例1：电商用户行为分析

（1）需求背景

某电商平台每天产生10亿条用户行为数据（点击、浏览、购买），每条数据有20个字段（user_id、product_id、behavior_type、timestamp、device_type、city等）。需要分析“过去7天每个商品的点击量”，用于商品推荐和库存管理。

（2）行式存储的问题

如果用CSV格式（行式存储）存储数据，每个文件大小是100GB（10亿行×100字节/行）。查询时需要扫描所有100GB数据，提取product_id、behavior_type、timestamp三个字段，然后统计——查询时间需要2小时以上。

（3）列式存储的解决方案

改用Parquet格式（列式存储）存储数据，压缩比为10:1（100GB→10GB）。查询时：

  • 只需要读取product_id、behavior_type、timestamp三个列的数据（约3GB）；
  • 用Spark的filter函数过滤timestamp在过去7天且behavior_type=click的数据；
  • 用groupBy和count函数统计每个product_id的点击量。

查询时间缩短到10分钟以内，满足了实时分析的需求。

（4）实现代码（Spark）
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, count

# 初始化SparkSession
spark = SparkSession.builder.appName("UserBehaviorAnalysis").getOrCreate()

# 加载Parquet文件（列式存储）
df = spark.read.parquet("s3://your-bucket/user-behavior.parquet")

# 查询过去7天的点击量
result = df.filter(
    (col("behavior_type") == "click") & 
    (col("timestamp") >= "2024-01-01") & 
    (col("timestamp") <= "2024-01-07")
).groupBy("product_id").agg(count("*").alias("click_count"))

# 显示结果
result.show()

# 保存结果到Parquet（供后续分析使用）
result.write.parquet("s3://your-bucket/product-click-count.parquet")

4.2 案例2：金融风险分析

（1）需求背景

某银行每天处理500万条交易记录（转账、消费、理财），每条数据有30个字段（transaction_id、user_id、amount、timestamp、from_account、to_account等）。需要分析“过去24小时内转账金额超过10万元的用户”，用于反洗钱监控。

（2）行式存储的问题

如果用MySQL的InnoDB（行式存储）存储数据，查询“转账金额超过10万元且时间在过去24小时内的用户”需要扫描所有500万行数据，查询时间需要30分钟以上。

（3）列式存储的解决方案

改用ORC格式（列式存储）存储数据，压缩比为8:1（50GB→6.25GB）。查询时：

  • 只需要读取user_id、amount、timestamp三个列的数据（约1.875GB）；
  • 用Hive的where clause过滤amount>100000且timestamp在过去24小时内的数据；
  • 用distinct函数提取唯一的user_id。

查询时间缩短到5分钟以内，满足了实时风险监控的需求。

4.3 常见问题及解决方案

（1）问题1：列式存储不适合OLTP场景

OLTP（在线事务处理）的核心需求是频繁的插入、更新、删除（比如用户下单、修改密码）。列式存储的结构（按列存储）导致插入一行数据需要修改所有列的存储（比如插入一条用户数据，需要把user_id、name、age等列都添加一条记录），插入效率比行式存储低10-100倍。

解决方案：采用“混合存储架构”（比如Lambda架构）：

  • OLTP场景用行式存储（比如MySQL、PostgreSQL），处理频繁的事务；
  • OLAP场景用列式存储（比如Parquet、ORC），处理大规模分析；
  • 用数据管道（比如Kafka、Flink）将行式存储的数据同步到列式存储，实现“实时分析”。
（2）问题2：列式存储的更新困难

列式存储通常是append-only（只追加）的，修改或删除数据需要重写整个Row Group（比如修改一条数据的product_id，需要重写该数据所在的Row Group的所有列），更新效率低。

解决方案：

  • 用支持ACID事务的列式存储（比如ORC with Hive ACID），可以实现原子性的更新和删除；
  • 用湖仓一体工具（比如Delta Lake、Apache Iceberg），在列式存储之上添加事务层，支持增量更新和时间旅行（查询历史版本的数据）。

五、未来展望：列式存储的“进化方向”

5.1 技术发展趋势

（1）更高效的压缩算法

当前列式存储主要用Snappy（压缩速度快）和Zstandard（压缩比高），未来会出现更智能的压缩算法（比如基于AI的压缩），可以根据数据的特征自动选择压缩方式（比如文本数据用字典编码，数值数据用Delta编码），进一步提高压缩比。

（2）实时列式存储

传统列式存储（比如Parquet、ORC）适合批量数据处理，而实时分析（比如实时监控用户行为）需要实时摄入和实时查询。未来会出现更多支持实时的列式存储（比如Apache Druid、ClickHouse），可以在秒级内处理百万条实时数据。

（3）智能查询优化

未来的列式存储会集成机器学习模型，预测查询模式（比如用户经常查询“过去7天的点击量”），提前对数据进行预聚合（比如预计算每个商品的日点击量），或者调整列的存储顺序（比如把经常一起查询的列放在同一个Row Group中），进一步提高查询效率。

（4）云原生列式存储

随着云计算的普及，未来的列式存储会更紧密地集成云服务（比如AWS的Redshift Spectrum、Google的BigQuery），支持按需查询（只支付查询的数据量费用）和弹性扩展（根据数据量自动调整存储和计算资源）。

5.2 潜在挑战

（1）平衡OLTP和OLAP的需求

实时分析需要列式存储支持快速插入，而传统列式存储的插入效率低。如何平衡OLTP（插入）和OLAP（查询）的需求，是未来的重要挑战。

（2）数据湖中的列式存储管理

数据湖（比如AWS S3、HDFS）中的列式存储面临元数据管理（比如跟踪每个Row Group的位置和状态）和数据分区优化（比如按时间分区，减少查询的数据量）的挑战。

（3）隐私和安全

列式存储中的数据通常是敏感的（比如用户交易记录、病历数据），如何在压缩和查询的同时保护数据隐私（比如加密列数据、匿名化处理），是未来的重要课题。

5.3 行业影响

列式存储的普及会推动数据驱动决策的普及：

  • 电商：可以更快地分析用户行为，优化商品推荐和库存管理；
  • 金融：可以实时监控风险，预防 fraud 和洗钱；
  • 医疗：可以分析病历数据，找出疾病模式，提高诊断效率；
  • 制造业：可以分析传感器数据，预测设备故障，减少停机时间。

六、总结与思考

6.1 总结要点

  • 列式存储是什么？ 按列存储数据的方式，适合大数据分析场景（OLAP）；
  • 核心优势：查询效率高（只取需要的列）、压缩效率高（同列数据类型一致）、适合聚合统计；
  • 核心结构：Row Group（行组）和Page（页），平衡查询和存储效率；
  • 常见格式：Parquet（通用）、ORC（适合Hadoop）；
  • 应用场景：电商用户行为分析、金融风险监控、医疗病历分析等。

6.2 思考问题

  1. 如果你的项目需要同时支持实时交易（OLTP）和实时分析（OLAP），如何设计数据存储架构？
  2. 列式存储的压缩比受哪些因素影响？如何优化压缩比？
  3. 湖仓一体工具（比如Delta Lake）如何解决列式存储的更新问题？

6.3 参考资源

  1. 《大数据时代的列式存储技术》（作者：李航，机械工业出版社）；
  2. Apache Parquet官方文档：https://parquet.apache.org/；
  3. Apache ORC官方文档：https://orc.apache.org/；
  4. 《Spark编程指南》（作者：Matei Zaharia，人民邮电出版社）；
  5. IDC大数据报告：https://www.idc.com/promo/big-data/executive-summary。

结语
列式存储不是“银弹”，但它是大数据分析的“基石”。就像衣柜整理一样，正确的存储方式能让你更快找到需要的“衣服”（数据），提高效率。希望本文能帮助你理解列式存储的关键概念，并用它解决实际问题。

如果你有任何问题或想法，欢迎在评论区留言，我们一起讨论！

作者：AI技术专家与教育者
日期：2024年XX月XX日
版权：本文受Creative Commons Attribution 4.0 International License保护，转载请注明作者和出处。

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 亚马逊云科技技术品牌专区