File Formats

How analytics file formats encode records, columns, metadata, statistics, compression, and schema for data-platform workloads.

File format: không chỉ là đuôi file

Trong data platform, file format là contract giữa storage và query engine:

raw bytes trên HDFS/S3/GCS/ADLS

file format: schema + layout + encoding + compression + metadata

engine: Spark / Trino / Flink / DuckDB đọc để scan/filter/project

Một file format không chỉ quyết định “file tên gì”, mà quyết định engine phải làm gì để trả lời các câu hỏi rất thực tế:

  • Muốn đọc 3 cột trong 200 cột thì có phải đọc cả record không?
  • Muốn filter event_date = '2026-06-27' thì có metadata nào giúp skip bớt data không?
  • Data có được compress/encode theo kiểu phù hợp với analytics scan không?
  • Schema nằm ở đâu, engine discover kiểu dữ liệu như thế nào?
  • File có tối ưu cho append/log, row lookup, hay analytical scan?

Row-based vs column-based

Mental model đầu tiên cần clear là: một dataset dạng bảng có thể được ghi xuống file theo nhiều physical layout khác nhau.

Giả sử logical table:

user_idcountryevent_dateamount
1VN2026-06-01100
2US2026-06-01200
3VN2026-06-02300

Row-based layout

Row-based format đặt các field của cùng một record gần nhau:

row 1: user_id=1, country=VN, event_date=2026-06-01, amount=100
row 2: user_id=2, country=US, event_date=2026-06-01, amount=200
row 3: user_id=3, country=VN, event_date=2026-06-02, amount=300

Kiểu này hợp với workload cần xử lý từng record nguyên vẹn, ghi append/log nhanh, hoặc truyền message/event:

  • CSV/JSON: dễ đọc, dễ debug, nhưng schema/typing/metadata yếu.
  • Avro: row-oriented binary format, có schema rõ hơn, hay dùng cho streaming/log/event payload.

Nhưng với analytical query kiểu:

SELECT sum(amount)
FROM events
WHERE country = 'VN';

engine thường chỉ cần countryamount, nhưng row-based layout dễ kéo theo nhiều field không cần thiết.

Column-based layout

Column-based format đặt values của cùng một column gần nhau:

column user_id:    1, 2, 3
column country:    VN, US, VN
column event_date: 2026-06-01, 2026-06-01, 2026-06-02
column amount:     100, 200, 300

Kiểu này hợp với analytics vì query thường:

  • scan nhiều rows;
  • chỉ đọc một phần columns;
  • aggregate/filter/project theo cột;
  • hưởng lợi từ compression/encoding vì values cùng loại nằm cạnh nhau.
Columnar không tự động đồng nghĩa với nhanh

Columnar giúp engine đọc ít cột hơn. Nhưng để đọc ít vùng dữ liệu hơn trong cùng một cột, engine còn cần metadata như statistics, row group/page index, partition/table metadata, và layout đủ tốt để các stats đó hữu ích.

File format vs table format

Một nhầm lẫn rất dễ gặp trong lakehouse là trộn file formattable format.

ConceptNó quản lý cái gì?Ví dụ
File formatBên trong một file đơn lẻ: schema, column/row layout, encoding, compression, footer metadataParquet, ORC, Avro
Table formatMột table/dataset gồm nhiều file: snapshots, manifest/log, transaction, schema evolution, partition evolutionIceberg, Delta Lake, Hudi

Ví dụ: một Delta table thường vẫn lưu data chính bằng nhiều file Parquet. Delta thêm transaction log và table metadata ở ngoài; Parquet vẫn chịu trách nhiệm cho physical bytes/layout bên trong từng data file.

Parquet series

Later / open thread

On this page