寫作背景

近期看了幾篇關於日誌解決方案的文章, 發現它們都在使用 Apache Parquet 作為存儲文件格式. 如下:

• Yelp 發佈大規模管理 S3 服務器訪問日誌的方案_架構_InfoQ精選文章
• Cloudflare Log Explorer is now GA, providing native observability and forensics
• 逆勢降本：雲上數據平台年復削減30%的治理實踐_雲計算_吳建陽_InfoQ精選文章
• AWS Debuts a Distributed SQL Database, Amazon S3 Tables for Iceberg - The New Stack
• Grafana Tempo 2.5 release: vParquet4, streaming endpoints, and more metrics | Grafana Labs
• 對象存儲應用：雲原生最新架構 - The New Stack --- Object Store Apps: Cloud Native's Freshest Architecture - The New Stack

這勾起了我的好奇心:

• Apache Parquet 是什麼?
• 有什麼優勢?
• 什麼軟件可以處理 Apache Parquet?
• 近期發現很多日誌解決方案會將日誌轉換為 Apache Parquet, 為什麼要這樣處理, 有什麼優勢?

Apache Parquet 簡介

Apache Parquet 是一種開源的列式存儲文件格式，專門為大數據處理框架設計，最初由 Twitter 和 Cloudera 聯合開發，現為 Apache 頂級項目。

核心優勢

1. 列式存儲結構

• 與傳統行式存儲不同，Parquet 按列存儲數據
• 查詢時只需讀取相關列，大幅減少 I/O
• 示例對比：

行式存儲：Row1[col1,col2,col3], Row2[col1,col2,col3], ...
列式存儲：Column1[所有行的值], Column2[所有行的值], ...

2. 高效的壓縮和編碼

• 同列數據類型一致，壓縮效率更高（可達行式存儲的 1/10）
• 支持多種編碼：RLE、字典編碼、Delta 編碼等
• 支持多種壓縮：Snappy、Gzip、LZO、Zstd

3. Schema 演化支持

• 支持向後/向前兼容的 schema 變更
• 可以添加新列、刪除列、修改列類型

4. 謂詞下推（Predicate Pushdown）

• 查詢引擎可以在讀取數據前過濾不相關的數據塊
• 利用列統計信息（min/max 值）跳過無關數據塊

5. 嵌套數據結構支持

• 原生支持複雜嵌套數據類型（數組、映射、結構體）
• 使用 Dremel 記錄 shredding 算法高效存儲嵌套數據

能處理 Parquet 的軟件/框架

大數據處理框架

• Apache Spark（主要使用場景）
• Apache Hive
• Apache Impala
• Presto/Trino
• Apache Flink
• Apache Arrow（內存格式轉換）

查詢引擎

• AWS Athena
• Google BigQuery
• Azure Synapse
• DuckDB
• Polars

編程語言支持

• Python（PyArrow、pandas）
• Java
• R
• Go
• .NET

日誌解決方案

• Cloudflare Log Explorer
• OpenObserve
• Grafana Tempo
• Yelp
• AWS 官方參考架構: Extracting key insights from Amazon S3 access logs with AWS Glue for Ray | AWS Big Data Blog

日誌解決方案轉用 Parquet 的原因

1. 成本效益

# 示例：日誌存儲成本對比

原始 JSON 日誌：1TB → 存儲成本 $$$$
Parquet 壓縮後：~100GB → 存儲成本 $

• 存儲成本降低 70-90%
• 網絡傳輸成本顯著降低

2. 查詢性能提升

-- 典型日誌查詢場景
SELECT COUNT(*), error_code 
FROM logs 
WHERE date >= '2024-01-01' 
  AND status = 'ERROR' 
GROUP BY error_code;

-- Parquet 優勢：
-- 1. 只讀取 date, status, error_code 三列
-- 2. 利用列統計快速跳過無關日期分區
-- 3. 壓縮數據減少磁盤 I/O

3. 適合時序數據分析

• 日誌數據天然具有時間屬性
• Parquet 支持按時間分區，優化時間範圍查詢
• 結合分區剪枝（Partition Pruning）大幅提升性能

4. 兼容現代數據棧

# 典型日誌處理管道
原始日誌 → Fluentd/Logstash → Kafka → 
Spark Streaming → Parquet (S3/ADLS) → 
Trino/Athena 查詢 → BI 工具

5. 長期存儲和分析

• Parquet 是分析型工作負載的理想格式
• 支持數據湖架構（Delta Lake、Iceberg、Hudi）
• 便於歷史日誌的趨勢分析和機器學習

具體應用場景示例

案例：ELT 日誌分析管道

原始日誌 (JSON/文本)
       ↓
實時處理層 (Kafka)
       ↓
批處理層 (Spark) → 轉換為 Parquet
       ↓
雲存儲 (S3/GCS) → 分區: dt=2024-01-01/
       ↓
查詢層 (Athena/Presto)
       ↓
可視化 (Grafana/Tableau)

性能對比數據

• 存儲空間：較 JSON 減少 75-90%
• 查詢速度：提升 10-100 倍（取決於查詢模式）
• 掃描數據量：減少 60-95%（列裁剪效果）

注意事項

1. 不適合場景：

   • 高頻單行讀寫（OLTP）
   • 需要流式逐行處理的場景
   • 小文件過多會影響性能

2. 最佳實踐：

   • 合理設置文件大小（128MB-1GB）
   • 按時間分區組織數據
   • 選擇適當的壓縮算法（平衡速度/比率）

Parquet 已成為現代數據湖和日誌分析的事實標準格式，特別適合需要長期存儲、批量分析和成本優化的日誌管理場景。