如何在AWS S3与Athena中优化产品-数量键值对的存储与查询？

1. 扁平化列式存储（Parquet/ORC）—— 首选方案 #

将每个客户-产品-数量组合作为单独一行，存储为Parquet或ORC格式（Athena对这两种列式存储的支持最优），结构如下：

核心优势： #

• 查询逻辑极简：直接用标准SQL完成需求，比如筛选数量≥3的产品：

  SELECT Customer_ID, Product, Quantity
  FROM your_table
  WHERE Quantity >= 3
  

• 性能与成本最优：列式存储仅扫描查询所需的列（比如只扫Quantity和Customer_ID），压缩率远高于CSV，大幅降低Athena的扫描数据量和查询成本，数百万级客户+数千万级行的规模完全适配。
• 扩展性强：可根据查询场景按Customer_ID（前缀分区）或Product分区，进一步提升特定查询的速度。

2. 嵌套结构列式存储（Parquet/ORC封装）—— 保留客户单行场景 #

如果需要保留每个客户为一行的结构，可采用嵌套数组格式，用Parquet或ORC存储，示例结构（JSON表示）：

{
  "Customer_ID": "C1",
  "products": [
    {"product": "P1", "quantity": 3},
    {"product": "P2", "quantity": 1},
    {"product": "P3", "quantity": 5}
  ]
}

查询示例： #

通过UNNEST展开嵌套数组实现筛选：

SELECT Customer_ID, p.product, p.quantity
FROM your_table
CROSS JOIN UNNEST(products) AS p(product, quantity)
WHERE p.quantity >= 3

核心优势： #

• 保留客户维度的整体记录，适合需要批量获取客户全量产品信息的场景。
• 同样享受列式存储的压缩和查询性能优势，避免原CSV格式的字符串解析开销。

为什么原格式不可取？ #

原计划的Product:Quantity(csv)格式需要通过字符串拆分、正则匹配等操作提取数据，在数百万级数据下：

• 查询逻辑复杂，容易出错。
• 全表扫描所有字符串字段，扫描数据量极大，查询速度慢且成本高。
• 无法利用Athena的索引和分区优化能力，扩展性极差。

内容的提问来源于stack exchange，提问作者Swapna K E