Encoding & serialization — text vs binary

TL;DR: Dữ liệu trong bộ nhớ là object — con trỏ, cấu trúc, tham chiếu — chỉ có nghĩa trong tiến trình đang chạy. Để lưu xuống đĩa hay gửi qua mạng, nó phải thành một chuỗi byte tự chứa: đó là encoding (hay serialization). Đọc ngược lại thành object là decoding (deserialization). Có hai họ định dạng: text (JSON, XML, CSV) — người đọc được, phổ biến, nhưng tốn chỗ và schema lỏng lẻo; và binary (Avro, Protocol Buffers, Thrift) — gọn, nhanh parse, có schema chặt, đổi lại không đọc bằng mắt được. Chọn loại nào tuỳ bạn cần con người đọc hay máy xử lý khối lượng lớn. Đây là quyết định nền cho cả storage lẫn truyền dữ liệu.

Một service gọi API trả về một User object: có id, name, một list roles, và một con trỏ tới manager (cũng là User). Bạn muốn gửi nó cho service khác qua mạng. Nhưng "con trỏ tới manager" là một địa chỉ bộ nhớ — vô nghĩa với tiến trình khác, trên máy khác. Bạn không thể memcpy object qua mạng và mong nó hoạt động.

Đây là vấn đề nền tảng: biểu diễn trong bộ nhớ và biểu diễn để lưu/truyền là hai thứ khác nhau. Bài này giải thích vì sao cần encode, hai họ định dạng để encode, và cách chọn — kiến thức áp dụng cho mọi lúc dữ liệu rời khỏi RAM: ghi file, gọi API, đẩy vào message queue, lưu database.

1. Analogy — Đóng gói đồ chuyển nhà

Đồ đạc trong nhà bạn được sắp xếp tiện cho sống: tủ lạnh cắm điện, sách trên kệ theo chủ đề, dây nối chằng chịt. Nhưng để chuyển sang nhà khác, bạn không bê nguyên cả căn phòng lên xe — bạn đóng gói: tháo rời, gói vào thùng có nhãn, xếp gọn. Đến nơi, bạn mở gói và lắp lại.

• Đóng gói (serialize): chuyển trạng thái "đang sống, có liên kết" thành dạng "phẳng, tự chứa, vận chuyển được".
• Nhãn thùng (schema): cho biết bên trong là gì để lắp lại đúng.
• Mở gói (deserialize): dựng lại trạng thái sống ở đầu bên kia.

Object trong RAM giống căn phòng đang sống (có con trỏ, liên kết). Chuỗi byte để lưu/truyền giống thùng đồ đã đóng gói. Bạn không thể "chuyển nhà" mà bỏ qua bước đóng gói.

flowchart LR
  OBJ["Object trong RAM<br/>(con tro, lien ket)"] -->|"encode<br/>(serialize)"| BYTES["Chuoi byte<br/>phang, tu chua"]
  BYTES -->|"luu / truyen"| MED[("Dia hoac mang")]
  MED --> BYTES2["Chuoi byte"]
  BYTES2 -->|"decode<br/>(deserialize)"| OBJ2["Object dung lai<br/>o tien trinh khac"]

2. Vì sao object không thể lưu/truyền trực tiếp

Trong bộ nhớ, một object là một mạng lưới: các trường nằm rải rác, nối nhau bằng con trỏ (địa chỉ bộ nhớ). Hai lý do con trỏ không vượt ra ngoài tiến trình:

1. Địa chỉ chỉ có nghĩa cục bộ. Con trỏ 0x7ffe... trỏ tới một ô nhớ trong tiến trình này. Tiến trình khác (hay máy khác) có bố cục bộ nhớ hoàn toàn khác — địa chỉ đó trỏ vào hư không.
2. Bố cục phụ thuộc runtime. Cách một ngôn ngữ/runtime sắp object trong RAM (padding, thứ tự field, header) là chi tiết nội bộ, không ổn định giữa phiên bản, máy, hay ngôn ngữ.

Trong RAM (tien trinh A):
  user --> [id|0x40][name|0x88][roles|0x12c]
            0x88 --> "Mai"          (con tro -> chuoi)
            0x12c --> [list node...] (con tro -> list)

Gui 0x88 sang tien trinh B?  -> B doc 0x88 cua chinh no -> rac

Encoding giải bài này bằng cách thay con trỏ bằng nội dung thực, sắp mọi thứ thành một chuỗi byte tuyến tính, tự chứa — đọc đâu cũng đủ, không cần tra địa chỉ ở nơi khác. Đó là điều kiện để byte đó sống độc lập trên đĩa hay đường truyền.

3. Text formats — JSON, XML, CSV

Họ thứ nhất encode dữ liệu thành văn bản con người đọc được. Bạn mở file bằng editor là thấy nội dung.

{
  "id": 42,
  "name": "Mai",
  "roles": ["admin", "editor"],
  "manager_id": 7
}

Đặc điểm:

• Ưu — đọc được & gỡ lỗi dễ: mở ra xem ngay, debug bằng mắt, mọi ngôn ngữ đều có thư viện parse. JSON gần như là lingua franca của API web.
• Ưu — không cần schema để đọc: byte tự mô tả tên field ngay trong dữ liệu ("name": ...).
• Nhược — tốn chỗ: tên field lặp lại trong mọi bản ghi. Một triệu user thì chữ "name" xuất hiện một triệu lần. Số cũng lưu dạng chuỗi ký tự, không nén.
• Nhược — kiểu lỏng lẻo: JSON không phân biệt số nguyên với số thực, không có kiểu ngày tháng, dễ mơ hồ. CSV còn tệ hơn: mọi thứ là chuỗi, không có kiểu, ranh giới cột dễ vỡ khi giá trị chứa dấu phẩy.

CSV hợp cho bảng phẳng đơn giản (xuất ra Excel); XML dài dòng hơn JSON, nay ít dùng cho dữ liệu mới. Điểm chung của cả họ: người đọc được, nhưng trả giá bằng kích thước và sự thiếu chặt chẽ về kiểu.

4. Binary formats — Avro, Protocol Buffers, Thrift

Họ thứ hai encode thành byte máy đọc, không phải văn bản. Mở bằng editor chỉ thấy ký tự lạ. Đổi lại: gọn hơn nhiều và có schema chặt.

Ý tưởng cốt lõi: thay vì nhúng tên field vào mỗi bản ghi (như JSON), binary format tách schema (mô tả cấu trúc một lần) khỏi dữ liệu (chỉ chứa giá trị). Một số format dùng field tag — mỗi field gắn một số nguyên nhỏ thay cho tên chuỗi:

Schema (dinh nghia 1 lan, agnostic):
  message User {
    int32         id    = 1;   -- field tag 1
    string        name  = 2;   -- field tag 2
    repeated role roles = 3;   -- field tag 3
  }

Du lieu tren day (khai niem): khong co ten field, chi co
  tag=1 -> 42, tag=2 -> "Mai", tag=3 -> [admin, editor]

Vì không lặp tên field và mã hoá số ở dạng nhị phân, bản ghi gọn hơn JSON đáng kể. Parse cũng nhanh hơn vì máy nhảy theo tag thay vì quét chuỗi tìm "name".

Một khác biệt đáng nhớ giữa các format: schema để ở đâu:

• Protocol Buffers / Thrift: field tag được nhúng trong dữ liệu; bên đọc cần file schema (.proto) để biết tag nào nghĩa gì.
• Avro: dữ liệu không chứa tag, chỉ là giá trị theo thứ tự — nên bên đọc cần cả schema ghi lẫn schema đọc để khớp. Đổi lại Avro rất gọn và linh hoạt với schema thay đổi (chủ đề bài 03).

5. So sánh & khi nào dùng cái nào

Quy tắc chọn:

• Chọn text khi con người là một bên đọc: API công khai, file cấu hình, log để mắt người xem, dữ liệu trao đổi với đối tác cần dễ kiểm. Sự tiện gỡ lỗi đáng giá hơn vài byte.
• Chọn binary khi máy xử lý khối lượng lớn: giao tiếp giữa các service nội bộ (RPC), event đẩy hàng triệu/giây vào message queue, hay lưu trữ dài hạn nơi mỗi byte nhân lên hàng tỉ lần. Gọn + nhanh + schema chặt thắng thế.

Quyet dinh nhanh:
  Nguoi se doc byte nay?            -> TEXT (JSON)
  May xu ly khoi lon, can gon/nhanh? -> BINARY (Avro/Protobuf)

6. Pitfall — nhầm "đọc được" với "đúng"

WRONG (tin tuong text la du):
  doc CSV -> gia su cot 3 luon la so -> mot hang co dau phay -> lech cot -> sai

RIGHT (ep kiem):
  - dung binary co schema (parse fail neu sai kieu/thieu field), HOAC
  - validate JSON theo schema (vd JSON Schema) ngay luc nhap

7. 📚 Deep Dive

8. Liên hệ các bài khác

• Bài 01 — Vòng đời dữ liệu: encode là việc xảy ra ở mọi tầng storage và serving — quyết định text/binary ảnh hưởng chi phí lưu ở tầng cold và tốc độ truyền ở serving.
• Bài 03 — Schema evolution: field tag và schema của binary format chính là nền cho khả năng đổi schema mà không vỡ dữ liệu/client cũ.
• Module 10 — OLTP vs OLAP: kho phân tích thường lưu dữ liệu dạng binary cột (column-oriented) — đẩy ý "gọn + nhanh quét" của binary tới cực hạn.

9. Tóm tắt

• Biểu diễn dữ liệu trong RAM (object, con trỏ) khác biểu diễn để lưu/truyền (chuỗi byte tự chứa) — con trỏ chỉ có nghĩa cục bộ nên không vượt ra ngoài tiến trình.
• Encoding/serialization chuyển object thành byte tuyến tính tự chứa; decoding dựng lại object.
• Text (JSON/XML/CSV): người đọc được, phổ biến, không cần schema để đọc — nhưng tốn chỗ (lặp tên field) và kiểu lỏng lẻo.
• Binary (Avro/Protobuf/Thrift): gọn, parse nhanh, có schema chặt với field tag số — đổi lại không đọc bằng mắt, cần file schema.
• Khác biệt schema-ở-đâu: Protobuf/Thrift nhúng tag trong dữ liệu; Avro dựa hoàn toàn vào schema khi đọc.
• Chọn text khi con người là một bên đọc (API public, config); chọn binary khi máy xử lý khối lớn (RPC, message queue, lưu trữ dài hạn).
• Pitfall: "đọc được" không bằng "đúng cấu trúc" — schema lỏng của text âm thầm hỏng dữ liệu; dùng binary hoặc validate text khi dữ liệu sống lâu/đi xa.

10. Tự kiểm tra

Bài tiếp theo: Schema evolution — đổi schema không downtime