Không có cái hồ dữ liệu nào thật sự yên

Giả sử công ty mình có 1.000 cửa hàng.

Mỗi ngày, từ 1.000 cửa hàng ấy chảy về trung tâm hàng triệu hóa đơn, phiếu nhập kho, phiếu trả hàng, lượt bấm trên website, lịch sử tìm kiếm sản phẩm, log máy chủ, hình ảnh, âm thanh tổng đài và những file Excel mà không ai dám xóa vì sợ một ngày đẹp trời kế toán trưởng hỏi tới.

Ban đầu, dữ liệu còn ít.

Người ta dựng một data warehouse, thiết kế bảng ngay ngắn, đặt tên cột rõ ràng, xây báo cáo doanh thu rồi sống những ngày tương đối yên bình.

Nhưng dữ liệu lớn dần.

Hình ảnh không vừa trong những chiếc bảng quan hệ. Log máy chủ đổ xuống như mưa. Data scientist cần dữ liệu chi tiết để huấn luyện mô hình. Hệ thống recommendation muốn giữ từng cú bấm chuột. Voice bot lại sinh ra âm thanh và transcript mỗi ngày.

Người ta bèn xây một cái hồ thật lớn để ném mọi thứ vào.

Cái hồ ấy được gọi là data lake.

Tên nghe rất thơ.

Tưởng tượng có nước trong, có cá bơi, có một ông già ngồi câu bên bờ.

Nhưng dưới mặt hồ thường là những thư mục như thế này:

1sales/
2├── final/
3├── final_v2/
4├── final_v2_fix/
5├── final_v2_fix_new/
6└── final_v2_fix_new_latest/

Và vì một quy luật thần bí nào đó của ngành dữ liệu, thư mục latest thường không phải là bản mới nhất.

Data lake rộng, rẻ và chứa được gần như mọi thứ.

Nhưng chứa được không có nghĩa là quản lý được.

Một đống file Parquet nằm cạnh nhau vẫn chỉ là một đống file Parquet. Chúng chưa tự nhiên biến thành một bảng dữ liệu có transaction, schema, lịch sử phiên bản và khả năng chịu được việc nhiều tiến trình cùng đọc ghi.

Từ mâu thuẫn đó, Lakehouse bắt đầu xuất hiện.

Trước Lakehouse, dữ liệu phải sống hai cuộc đời

Data warehouse và data lake đều được sinh ra để giải quyết những bài toán hợp lý.

Data warehouse phù hợp với:

• Báo cáo doanh thu.
• Dashboard quản trị.
• Truy vấn SQL.
• Dữ liệu có schema rõ ràng.
• Các bảng tổng hợp ổn định.

Data lake phù hợp với:

• Dữ liệu rất lớn.
• Dữ liệu thô.
• Log, JSON, hình ảnh và âm thanh.
• Xử lý bằng Spark hoặc Python.
• Machine Learning và Data Science.

Nghe thì rất đẹp.

Data lake làm việc của data lake.

Data warehouse làm việc của data warehouse.

Hai người một người rửa chén, một người nấu cơm, gia đình hạnh phúc.

Nhưng ngoài đời, dữ liệu không chịu đứng yên trong phần việc được phân công.

Dữ liệu bán hàng đi vào data lake trước.

Sau đó, một pipeline đọc dữ liệu từ lake, làm sạch rồi chép sang data warehouse.

Data scientist lại tạo thêm một bản riêng để huấn luyện mô hình.

Nhóm báo cáo tài chính có thể tạo thêm bảng tổng hợp.

Nhóm recommendation lại xuất một bộ dữ liệu khác để xây feature.

Một chiếc tủ lạnh ngoài cửa hàng chỉ được bán đúng một lần.

Nhưng bên trong hệ thống dữ liệu, chiếc tủ lạnh ấy có thể sống năm cuộc đời:

 1Dữ liệu nguồn
 2    |
 3    v
 4Bản thô trong data lake
 5    |
 6    v
 7Bản staging
 8    |
 9    v
10Bản trong data warehouse
11    |
12    v
13Bản dùng cho Machine Learning
14    |
15    v
16File CSV "tạm thời" tồn tại ba năm

Mỗi lần dữ liệu được sao chép là thêm một pipeline.

Mỗi pipeline là thêm một nơi có thể thất bại.

Mỗi lần thất bại là thêm một kỹ sư bị gọi lúc hai giờ sáng để trả lời câu hỏi:

Vì sao báo cáo hôm nay chỉ có 998 cửa hàng, trong khi hôm qua vẫn còn đủ 1.000?

Bài toán mà Lakehouse 1.0 muốn giải quyết không phải là xóa bỏ data warehouse hay data lake.

Nó muốn giảm khoảng cách giữa hai thế giới ấy, để nhiều workload có thể làm việc trên một lớp dữ liệu chung thay vì liên tục sao chép dữ liệu qua lại.

Vì sao giai đoạn 2019–2023 trở thành cột mốc quan trọng?

Lakehouse không được phát minh trong một ngày.

Nó là kết quả của nhiều mảnh ghép đã phát triển trước đó:

• Object storage có chi phí thấp.
• Định dạng cột như Parquet.
• Hệ thống xử lý phân tán như Spark.
• Kiến trúc tách compute khỏi storage.
• Các SQL engine có thể truy vấn trực tiếp trên file.
• Lớp metadata giúp quản lý một tập hợp file như một bảng.

Năm 2019 là một cột mốc dễ quan sát khi phiên bản mã nguồn mở đầu tiên của Delta Lake được công bố. Các phiên bản tiếp theo trong năm đó bổ sung hỗ trợ cloud storage và cải thiện khả năng xử lý đồng thời. Những thay đổi này cho thấy người ta có thể đặt một lớp giao dịch phía trên data lake thay vì xem hồ dữ liệu chỉ là nơi chứa file. (Delta)

Đến tháng 1 năm 2021, bài nghiên cứu Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics được trình bày tại CIDR 2021. Công trình này mô tả Lakehouse là một hệ thống quản lý dữ liệu xây dựng trên lớp lưu trữ chi phí thấp, có thể truy cập trực tiếp, nhưng bổ sung những khả năng quản lý quen thuộc của hệ thống phân tích như transaction, versioning và tối ưu truy vấn. (CIDRDB)

Từ năm 2021 đến khoảng năm 2023, khái niệm Lakehouse dần không còn chỉ là tên của một ý tưởng. Nó trở thành một cách thiết kế kiến trúc dữ liệu với các lớp tương đối rõ ràng:

 1Object Storage
 2    |
 3File Format
 4    |
 5Table Format và Metadata
 6    |
 7Compute Engine
 8    |
 9Bronze → Silver → Gold
10    |
11BI, Analytics, Data Science

Trong bài viết này, mình dùng cụm từ Lakehouse 1.0 để nói về nền móng của giai đoạn đầu đó.

Đây không phải tên phiên bản chính thức của một sản phẩm.

Nó là cách gọi để phân biệt phần kiến trúc cốt lõi: dữ liệu mở trên object storage, lớp quản lý bảng, transaction, schema, versioning và quy trình tổ chức dữ liệu từ Bronze đến Gold.

Lakehouse 1.0 là gì?

Có thể hiểu Lakehouse 1.0 bằng một câu:

Giữ sự rộng rãi và rẻ tiền của data lake, nhưng đặt lên trên nó một lớp quản lý để dữ liệu có thể được sử dụng gần giống những bảng phân tích đáng tin cậy trong data warehouse.

Nếu data lake là một cái hồ, Lakehouse không hút cạn nước rồi đổ vào một nhà kho khác.

Nó xây sàn, dựng cột, đặt luật và xây căn nhà ngay trên mặt hồ.

Nghe hơi ngáo.

Nhưng việc xây hai thành phố dữ liệu riêng biệt rồi dùng xe tải chở dữ liệu qua lại mỗi đêm cũng không tỉnh táo hơn bao nhiêu.

Kiến trúc Lakehouse 1.0 có thể nhìn theo hai hướng.

Hướng thứ nhất là các lớp kỹ thuật:

1Object Storage
2    ↓
3File Format
4    ↓
5Table Format và Transaction Log
6    ↓
7Compute Engine

Hướng thứ hai là vòng đời dữ liệu:

1Bronze
2    ↓
3Silver
4    ↓
5Gold

Hai hướng này thường bị trộn lẫn với nhau.

Object storage, Parquet và table format trả lời câu hỏi:

Dữ liệu được lưu và quản lý bằng cách nào?

Bronze, Silver và Gold trả lời một câu hỏi khác:

Dữ liệu đang sạch tới đâu và đã sẵn sàng phục vụ ai?

Các lớp kỹ thuật của Lakehouse 1.0

Object storage: mảnh đất rộng nhưng không biết làm kế toán

Ở đáy kiến trúc là object storage như Amazon S3, Azure Data Lake Storage hoặc Google Cloud Storage. Với hệ thống tự vận hành, vai trò tương tự có thể được đảm nhiệm bởi HDFS hoặc các nền tảng lưu trữ tương thích.

Đây là nơi những byte dữ liệu thật sự nằm xuống.

Một bảng doanh thu có thể được chia thành hàng nghìn file:

1sales/
2├── year=2026/
3│   ├── month=07/
4│   │   ├── day=23/
5│   │   │   ├── part-00001.parquet
6│   │   │   ├── part-00002.parquet
7│   │   │   └── part-00003.parquet

Object storage biết file nào tồn tại.

Nó biết file nặng bao nhiêu byte.

Nó biết file nằm ở đường dẫn nào.

Nhưng nó không hiểu:

• File nào thuộc phiên bản hiện tại của bảng.
• Một lần ghi đã hoàn thành hay chưa.
• File nào bị thay thế.
• Hai tiến trình có đang ghi đè lên nhau không.
• Bản ghi nào là đơn hàng thật, bản ghi nào là dữ liệu lỗi.

Object storage giống nền xi măng của nhà kho.

Nền nhà có thể chịu được một triệu thùng hàng.

Nhưng không thể yêu cầu nền nhà tự đếm hàng tồn kho.

File format: cách dữ liệu được xếp vào thùng

Lakehouse thường lưu dữ liệu phân tích bằng định dạng cột như Parquet hoặc ORC.

Giả sử một bảng bán hàng có 100 cột.

Nhưng câu SQL chỉ cần ba cột:

1SELECT
2    sale_date,
3    store_id,
4    revenue
5FROM sales;

Với định dạng cột, hệ thống có thể tập trung đọc những phần dữ liệu cần thiết thay vì kéo toàn bộ 100 cột lên khỏi ổ đĩa.

Điều này rất phù hợp với các workload phân tích.

Nhưng cần nhớ:

Parquet là định dạng file, không phải hệ quản trị cơ sở dữ liệu.

Một file Parquet có schema.

Nhưng một triệu file Parquet chưa tự động có transaction.

Một file có thể ghi dở.

Một job có thể chết giữa đường.

Hai job có thể cùng thêm dữ liệu.

Nếu không có lớp quản lý phía trên, người đọc có thể nhìn thấy một trạng thái nửa sống nửa chết, giống một con gà đã bước được một chân vào nồi nhưng chân còn lại vẫn chạy ngoài sân.

Table format: cuốn sổ nói file nào thuộc về bảng

Table format là một trong những mảnh ghép quan trọng nhất của Lakehouse 1.0.

Nó đặt một lớp metadata phía trên các file dữ liệu để quản lý:

• Schema của bảng.
• Danh sách file hợp lệ.
• Phiên bản hiện tại.
• Lịch sử thay đổi.
• Partition.
• Trạng thái của một lần commit.

Ví dụ, trên object storage có năm file:

1part-001.parquet
2part-002.parquet
3part-003.parquet
4part-004.parquet
5part-005.parquet

Nhưng metadata của phiên bản hiện tại có thể nói:

1Snapshot hiện tại: 108
2
3Các file đang thuộc bảng:
4- part-001.parquet
5- part-004.parquet
6- part-005.parquet

Hai file còn lại vẫn tồn tại về mặt vật lý.

Nhưng về mặt logic, chúng không còn nằm trong phiên bản hiện tại của bảng.

Apache Iceberg, chẳng hạn, dùng metadata, snapshot, manifest list và manifest để theo dõi trạng thái bảng cùng tập hợp data file thuộc từng snapshot. Một snapshot đại diện cho trạng thái của bảng tại một thời điểm. (Apache Iceberg)

Đây là điểm rất quan trọng.

Thay vì mở một file khổng lồ rồi sửa từng dòng, hệ thống có thể:

1. Ghi file dữ liệu mới.
2. Tạo metadata mới.
3. Commit metadata.
4. Chuyển con trỏ từ phiên bản cũ sang phiên bản mới.

Người đọc hoặc thấy phiên bản cũ.

Hoặc thấy phiên bản mới.

Họ không thấy một sinh vật ba đầu, trong đó doanh thu buổi sáng thuộc phiên bản cũ còn doanh thu buổi chiều thuộc phiên bản mới.

Compute engine: đội công nhân được thuê theo ca

Phía trên storage và metadata là các compute engine.

Ví dụ:

• Spark xử lý ETL.
• SQL engine phục vụ truy vấn.
• Python đọc dữ liệu cho Data Science.
• Một pipeline khác tạo bảng tổng hợp.

Storage và compute được tách rời.

Dữ liệu nằm cố định trong kho.

Còn các đội công nhân có thể được gọi đến tùy công việc.

Khi cần xử lý một lượng dữ liệu lớn, ta tăng compute.

Khi công việc kết thúc, compute có thể được thu nhỏ.

Không cần nhân bản toàn bộ nhà kho chỉ vì hôm nay cần thêm người đếm hàng.

Kiến trúc Lakehouse ban đầu xem việc tách storage khỏi compute là một đặc điểm phù hợp với môi trường cloud, nơi nhiều cụm tính toán có thể truy cập cùng lớp dữ liệu nền. (CIDRDB)

Bronze, Silver và Gold: ba lần dữ liệu được tắm rửa

Nếu chỉ có object storage, Parquet và transaction log, ta mới xây được một nhà kho biết giữ trật tự.

Nhưng hàng hóa đi vào vẫn có thể lấm lem bùn đất.

Một hệ thống gửi mã thành phố là:

1TP.HCM

Hệ thống khác gửi:

1Ho Chi Minh

Hệ thống khác nữa gửi:

1SG

Ba cái tên cùng chỉ một nơi, giống ba người cùng nhìn một con voi nhưng nhất quyết khai nó thành ba loài động vật khác nhau.

Để tổ chức vòng đời dữ liệu, Lakehouse thường sử dụng mô hình Medallion Architecture:

 1Nguồn dữ liệu
 2    |
 3    v
 4Bronze: dữ liệu thô
 5    |
 6    v
 7Silver: dữ liệu đã làm sạch và chuẩn hóa
 8    |
 9    v
10Gold: dữ liệu phục vụ nghiệp vụ

Tên nghe giống giải đấu thể thao.

Nhưng thực chất đây là hành trình một dòng dữ liệu đi từ lúc vừa bước xuống xe tải, tóc tai rối bù, cho đến khi mặc áo sơ mi và bước vào phòng họp với ban giám đốc.

Medallion Architecture tổ chức dữ liệu theo các lớp Bronze, Silver và Gold nhằm tăng dần chất lượng và mức độ sẵn sàng của dữ liệu khi nó đi qua pipeline. (Databricks Documentation)

Bronze: cứ đem dữ liệu về trước đã

Bronze là tầng gần hệ thống nguồn nhất.

Dữ liệu được đưa vào đây với mức biến đổi tối thiểu.

Ví dụ một giao dịch từ hệ thống bán hàng có thể được nhận dưới dạng:

1{
2  "store": "Q9_001",
3  "product": "sony-tv-55-inch",
4  "price": "15.990.000 VNĐ",
5  "created_at": "23/07/2026 10:31",
6  "status": "SUCCESS"
7}

Ở tầng Bronze, ta thường quan tâm đến:

• Giữ lại dữ liệu gần với nguồn.
• Lưu thời điểm dữ liệu được tiếp nhận.
• Ghi nhận hệ thống nguồn.
• Hạn chế làm mất thông tin.
• Cho phép chạy lại pipeline.
• Hỗ trợ điều tra khi dữ liệu phía sau bị sai.

Bronze giống khu nhận hàng phía sau siêu thị.

Xe tải vừa tới, người ta đưa hàng xuống trước.

Thùng có thể méo.

Nhãn có thể sai.

Rau còn dính đất.

Một vài kiện hàng còn chưa biết thuộc quầy nào.

Nhưng chưa ai vội ném đi, vì dữ liệu thô là dấu vết gần nhất với những gì thật sự xảy ra ở hệ thống nguồn.

Nếu ta làm sạch quá sớm rồi ghi đè mất bản gốc, việc điều tra lỗi sau này giống như cố tìm dấu chân sau khi ai đó đã lau sạch sàn.

Bronze không cần đẹp.

Bronze cần trung thực.

Bronze nên lưu thêm metadata gì?

Ngoài dữ liệu gốc, mỗi bản ghi Bronze nên có thêm một số thông tin kỹ thuật:

 1{
 2  "source_system": "pos",
 3  "source_file": "sales_20260723_1030.json",
 4  "ingested_at": "2026-07-23T10:32:14+07:00",
 5  "batch_id": "batch_20260723_1032",
 6  "raw_payload": {
 7    "store": "Q9_001",
 8    "product": "sony-tv-55-inch",
 9    "price": "15.990.000 VNĐ"
10  }
11}

Nhờ đó, khi một giao dịch có vấn đề, ta có thể lần ngược lại:

• Nó đến từ hệ thống nào?
• Được nhận lúc nào?
• Thuộc batch nào?
• Dữ liệu ban đầu là gì?

Bronze là nơi hệ thống lưu lại trí nhớ.

Không có trí nhớ, mỗi lần pipeline lỗi là cả đội lại đứng quanh một con số sai và tranh luận bằng niềm tin.

Silver: cùng một con voi chỉ nên có một cái tên

Silver là tầng dữ liệu đã được kiểm tra, làm sạch, chuẩn hóa và kết hợp.

Đây thường là nơi xử lý:

• Kiểu dữ liệu.
• Dữ liệu trùng.
• Giá trị thiếu.
• Mã sản phẩm.
• Mã cửa hàng.
• Đơn vị đo.
• Múi giờ.
• Dữ liệu đến muộn.
• Quan hệ giữa các bảng.
• Bản ghi lỗi hoặc không hợp lệ.

Bản ghi Bronze:

1{
2  "store": "Q9_001",
3  "product": "sony-tv-55-inch",
4  "price": "15.990.000 VNĐ",
5  "created_at": "23/07/2026 10:31"
6}

Sau khi đi qua Silver có thể trở thành:

1{
2  "store_id": 1001,
3  "product_id": 583920,
4  "selling_price": 15990000,
5  "currency": "VND",
6  "created_at": "2026-07-23T10:31:00+07:00"
7}

Sự thay đổi nhìn có vẻ nhỏ.

Nhưng nó rất quan trọng.

Ở Bronze, 15.990.000 VNĐ chỉ là một chuỗi ký tự.

Ở Silver, 15990000 là một con số có thể cộng, trừ, so sánh và tổng hợp.

Ở Bronze, sony-tv-55-inch là tên do một hệ thống tự đặt.

Ở Silver, product_id=583920 là định danh đã được đối chiếu với catalog sản phẩm chung.

Silver là nơi nhiều hệ thống bắt đầu nói cùng một ngôn ngữ.

Nếu công ty có mười hệ thống cùng nhắc đến một cái máy lạnh, Silver cố gắng làm cho chúng hiểu rằng đó là cùng một cái máy lạnh, chứ không phải mười sinh vật sống trong mười vũ trụ song song.

Silver có phải dữ liệu tổng hợp không?

Không nhất thiết.

Silver thường vẫn giữ dữ liệu ở mức tương đối chi tiết.

Ví dụ, mỗi dòng vẫn có thể đại diện cho:

• Một đơn hàng.
• Một sản phẩm trong đơn hàng.
• Một lần thay đổi tồn kho.
• Một sự kiện khách hàng bấm vào sản phẩm.
• Một cuộc gọi.

Điểm khác biệt là dữ liệu đã đủ sạch và nhất quán để các nhóm khác sử dụng lại.

Có thể xem Silver là lớp dữ liệu dùng chung của doanh nghiệp.

Nó không còn quá thô như Bronze.

Nhưng cũng chưa bị nấu thành một món ăn cụ thể như Gold.

Gold: dữ liệu bước vào phòng họp

Gold là tầng được tổ chức theo nhu cầu nghiệp vụ cụ thể.

Thay vì bắt người dùng tự đọc hàng tỷ giao dịch, Gold chuẩn bị sẵn những bảng như:

• Doanh thu theo ngày và cửa hàng.
• Lợi nhuận theo ngành hàng.
• Tồn kho hiện tại.
• Tỷ lệ hết hàng.
• Hiệu quả khuyến mãi.
• Hiệu suất giao hàng.
• Giá trị vòng đời khách hàng.

Ví dụ:

1gold_daily_store_revenue

Dashboard không cần mở hàng triệu hóa đơn rồi cộng lại mỗi khi giám đốc tải trang.

Nó đọc bảng Gold đã được chuẩn bị sẵn cho câu hỏi:

Hôm qua cửa hàng này bán được bao nhiêu?

Gold giống quầy thức ăn trong nhà hàng.

Khách không cần xuống kho, mở bao gạo, rửa rau, bắt gà rồi tự nấu.

Khách chỉ muốn gọi cơm gà.

Và hệ thống cần đưa ra một đĩa cơm gà, không phải một con gà còn sống kèm đường dẫn đến nhà kho.

Gold không phải một bảng duy nhất

Mỗi nhu cầu có thể cần một nhóm bảng Gold khác nhau.

Ví dụ:

1gold_finance_daily_revenue
2gold_operation_store_inventory
3gold_marketing_campaign_performance
4gold_product_category_margin

Bảng Gold dành cho tài chính có thể khác bảng Gold dành cho vận hành.

Bảng phục vụ dashboard doanh thu có thể không phù hợp cho việc phân tích hành vi khách hàng.

Gold đã được chế biến cho một mục đích cụ thể.

Vì vậy nó dễ sử dụng hơn, nhưng cũng ít linh hoạt hơn Silver.

Một giao dịch đi qua Bronze, Silver và Gold như thế nào?

Giả sử lúc 10 giờ 31 phút, một khách hàng mua chiếc TV Sony với giá 15.990.000 đồng.

Ngoài cửa hàng, hành động ấy chỉ mất vài giây.

Nhân viên quét mã.

Khách thanh toán.

Máy in nhả hóa đơn.

Mọi người tưởng câu chuyện đã kết thúc.

Nhưng bên dưới hệ thống, một chuỗi phản ứng vật chất vừa bắt đầu.

Thông tin được biến thành tín hiệu điện.

Tín hiệu chạy qua dây mạng.

Một service ghi message vào hàng đợi.

Một máy chủ khác đọc message.

CPU kiểm tra từng byte.

Dữ liệu được nén thành file.

Object storage ghi nó xuống những thiết bị vật lý đang ăn điện và tỏa nhiệt.

Sau đó, bản ghi bắt đầu chuyến đi qua ba tầng.

Ở Bronze

Dữ liệu gần giống với nguồn:

1{
2  "store": "Q9_001",
3  "sku": "SONY55X80L",
4  "price": "15.990.000",
5  "transaction_time": "23/07/2026 10:31"
6}

Ở Silver

Dữ liệu được chuẩn hóa:

1{
2  "store_id": 1001,
3  "product_id": 583920,
4  "selling_price": 15990000,
5  "currency": "VND",
6  "transaction_time": "2026-07-23T10:31:00+07:00"
7}

Ở Gold

Giao dịch được cộng vào chỉ số kinh doanh:

1Doanh thu cửa hàng 1001 ngày 2026-07-23
2tăng thêm 15.990.000 đồng.

Trên dashboard, kết quả cuối cùng chỉ là một ô nhỏ:

1Doanh thu hôm nay: 1.250.000.000 đồng

Ô số ấy trông rất yên tĩnh.

Nhưng phía sau nó là hàng tỷ electron vừa chạy qua chip, dây mạng, ổ lưu trữ và nhiều tầng xử lý.

Không có gì là hoàn toàn ảo.

Một con số trên dashboard luôn có trọng lượng vật lý của nó: điện năng, máy chủ, thiết bị lưu trữ, hệ thống làm mát và thời gian của những người xây pipeline.

Ví dụ với một triệu đơn hàng mỗi ngày

Giả sử hệ thống bán lẻ xử lý một triệu đơn hàng mỗi ngày.

Mỗi đơn hàng trung bình có ba sản phẩm.

Như vậy bảng chi tiết có khoảng:

$$ 1.000.000 \times 3 = 3.000.000 $$

dòng mỗi ngày.

Sau một năm:

$$ 3.000.000 \times 365 = 1.095.000.000 $$

Tức hơn một tỷ dòng chi tiết đơn hàng.

Ta có thể tổ chức như sau.

Tầng Bronze

1bronze_orders
2bronze_order_details
3bronze_payments
4bronze_returns
5bronze_shipments

Các bảng này giữ dữ liệu gần nguồn và có metadata ingestion.

Tầng Silver

1silver_orders
2silver_order_items
3silver_products
4silver_stores
5silver_customers
6silver_inventory_movements

Tại đây, dữ liệu được:

• Chuẩn hóa mã sản phẩm.
• Xử lý đơn trùng.
• Đối chiếu cửa hàng.
• Chuẩn hóa thời gian.
• Liên kết đơn bán và đơn trả.
• Kiểm tra trạng thái thanh toán.

Tầng Gold

1gold_daily_store_sales
2gold_product_margin
3gold_inventory_status
4gold_return_rate
5gold_delivery_performance

Gold không nhất thiết giữ toàn bộ một tỷ dòng.

Ví dụ bảng doanh thu theo ngày, cửa hàng và ngành hàng có thể nhỏ hơn rất nhiều:

1365 ngày
2× 1.000 cửa hàng
3× 20 ngành hàng
4= 7.300.000 dòng

Bảy triệu dòng vẫn lớn.

Nhưng nhẹ hơn rất nhiều so với việc dashboard phải quét hơn một tỷ dòng mỗi lần người dùng chọn lại bộ lọc.

ACID trên một đống file hoạt động như thế nào?

Một câu hỏi tự nhiên là:

Dữ liệu chỉ là file trên object storage thì làm sao có transaction?

Ý tưởng đơn giản là không công bố trạng thái mới cho đến khi toàn bộ thay đổi đã sẵn sàng.

Giả sử bảng Silver đang ở phiên bản 100.

Một job bắt đầu xử lý batch mới.

Nó thực hiện:

1. Đọc dữ liệu Bronze.
2. Làm sạch và chuẩn hóa.
3. Ghi các file dữ liệu mới.
4. Tạo metadata cho phiên bản 101.
5. Commit phiên bản 101.
6. Chuyển trạng thái hiện tại từ 100 sang 101.

Nếu job chết trước bước commit, người đọc vẫn thấy phiên bản 100.

Nếu commit thành công, người đọc thấy phiên bản 101.

Họ không thấy một trạng thái mà nửa bảng thuộc hôm qua, nửa bảng thuộc hôm nay, còn ba file ở giữa đang suy nghĩ về ý nghĩa cuộc đời.

Trong Apache Iceberg, việc thay nguyên tử metadata file của bảng là nền tảng cho cơ chế cô lập khi commit. (Apache Iceberg)

Đây là lý do table format quan trọng.

Nó biến việc quản lý bảng từ:

Hãy quét toàn bộ thư mục rồi đoán xem file nào đang dùng.

thành:

Hãy đọc metadata để biết chính xác snapshot hiện tại gồm những file nào.

Bronze, Silver và Gold không phải ba loại ổ cứng

Một hiểu nhầm khá phổ biến là nghĩ Bronze, Silver và Gold phải nằm trên ba hệ thống vật lý khác nhau.

Không nhất thiết.

Cả ba tầng có thể cùng nằm trên một object storage:

1lakehouse/
2├── bronze/
3├── silver/
4└── gold/

Hoặc được tổ chức thành các schema:

1bronze.orders
2silver.orders
3gold.daily_sales

Tên gọi cũng không bắt buộc phải là Bronze, Silver và Gold.

Một số hệ thống dùng:

1raw → curated → serving

Hoặc:

1landing → standardized → business

Doanh nghiệp cũng có thể thêm các lớp:

1Landing
2    ↓
3Bronze
4    ↓
5Quarantine
6    ↓
7Silver
8    ↓
9Gold

Tầng Quarantine có thể giữ những bản ghi lỗi:

• Thiếu mã sản phẩm.
• Giá bán âm.
• Không xác định được cửa hàng.
• Sai định dạng ngày.
• Không thể liên kết với đơn gốc.

Điểm quan trọng không nằm ở màu huy chương.

Điểm quan trọng là phải phân biệt được ba trạng thái:

• Dữ liệu vừa được tiếp nhận.
• Dữ liệu đã đủ sạch để dùng chung.
• Dữ liệu đã được chuẩn bị cho nghiệp vụ cụ thể.

Nếu trộn cả ba vào một chỗ, người dùng có thể lấy nhầm dữ liệu Bronze để làm báo cáo tài chính, rồi phát hiện doanh thu có cả đơn trùng, đơn lỗi và những giao dịch mà hệ thống nguồn đã hủy từ ba ngày trước.

Lakehouse 1.0 giải quyết được gì?

Giảm việc sao chép giữa lake và warehouse

Thay vì bắt dữ liệu đi qua nhiều hệ thống chỉ để phục vụ những workload khác nhau, Lakehouse cho phép nhiều engine làm việc trên cùng lớp dữ liệu được quản lý.

Điều này không loại bỏ hoàn toàn việc nhân bản dữ liệu.

Bronze, Silver và Gold vẫn là các phiên bản dữ liệu khác nhau.

Bảng tổng hợp vẫn cần tồn tại.

Feature dataset vẫn có thể cần được tạo riêng.

Nhưng đây là những bản sao có mục đích nghiệp vụ hoặc hiệu năng rõ ràng, thay vì các bản sao chỉ sinh ra vì data lake và data warehouse không thể dùng chung một lớp lưu trữ.

Giữ được dữ liệu thô để xử lý lại

Khi logic làm sạch thay đổi, dữ liệu Bronze có thể được dùng để tái tạo Silver.

Ví dụ hôm nay công ty phát hiện:

1Q9_001

và:

1HCM_Q9_01

thực ra là cùng một cửa hàng.

Ta có thể sửa quy tắc ánh xạ rồi chạy lại từ Bronze.

Nếu chỉ giữ Gold, thông tin chi tiết có thể đã bị tổng hợp mất.

Một khi trứng đã thành bánh, rất khó yêu cầu cái bánh trả lại đúng từng quả trứng ban đầu.

Tạo một lớp dữ liệu dùng chung

Silver có thể trở thành nơi nhiều nhóm cùng sử dụng:

• BI.
• Data Science.
• Vận hành.
• Tài chính.
• Recommendation.
• Forecasting.

Mỗi nhóm không cần tự làm sạch lại mã sản phẩm, mã cửa hàng và thời gian theo một cách riêng.

Nếu mỗi đội tự định nghĩa “đơn hàng thành công”, công ty sẽ có bảy con số doanh thu, và cả bảy đều đúng trong vũ trụ của người tạo ra chúng.

Tách dữ liệu khỏi compute

Storage có thể tồn tại lâu dài.

Compute được lựa chọn theo workload.

Spark có thể xử lý Silver.

SQL engine có thể đọc Gold.

Python có thể phân tích dữ liệu chi tiết.

Các workload khác nhau không nhất thiết phải sao chép toàn bộ dữ liệu vào hệ thống lưu trữ riêng.

Lakehouse 1.0 không giải quyết được gì?

Lakehouse là kiến trúc.

Nó không phải nước thánh.

Đổ dữ liệu bẩn vào Lakehouse không làm dữ liệu sạch hơn.

Nó chỉ giúp ta quản lý đống bẩn ấy có cấu trúc và lịch sử rõ ràng hơn.

Nó không tự định nghĩa nghiệp vụ

Lakehouse không tự biết:

• Doanh thu có trừ đơn trả hay chưa.
• Đơn giao thất bại có được tính là đơn bán không.
• Một sản phẩm nhiều màu là một product hay nhiều SKU.
• Khách đổi sản phẩm có được tính là hai giao dịch không.

Đây là các quyết định nghiệp vụ.

Không có transaction log nào đủ can đảm bước vào phòng họp giữa tài chính và vận hành để tự quyết định thay con người.

Nó không tự làm truy vấn nhanh

Dữ liệu vẫn có thể bị tổ chức tệ.

Ví dụ:

• Quá nhiều file nhỏ.
• Partition sai.
• Một partition quá lớn.
• Quét nhiều cột không cần thiết.
• Bảng Gold thiết kế không phù hợp.
• Join khối lượng lớn giữa nhiều bảng.

Lakehouse cung cấp nền móng.

Nhưng nền móng tốt không tự biến thành ngôi nhà đẹp.

Vẫn cần người biết đặt bếp ở đâu, đặt cửa ở đâu và không xây nhà vệ sinh giữa phòng khách.

Nó không thay thế data modeling

Gold vẫn cần star schema, bảng fact, dimension hoặc một cách tổ chức phù hợp với nghiệp vụ.

Silver vẫn cần khóa định danh rõ ràng.

Bronze vẫn cần chiến lược lưu trữ và retention.

Gắn nhãn Bronze, Silver, Gold lên ba thư mục không tự động tạo ra kiến trúc.

Một con vịt đeo bảng “đại bàng” vẫn chưa biết bay.

Nó có thể làm hệ thống nhiều mảnh hơn

Lakehouse thường gồm nhiều thành phần:

• Object storage.
• File format.
• Table format.
• Catalog.
• Compute engine.
• Công cụ ingestion.
• Công cụ orchestration.
• Pipeline Bronze–Silver–Gold.

Tách rời giúp hệ thống linh hoạt.

Nhưng linh hoạt cũng có nghĩa là có nhiều thứ phải hiểu, cấu hình, theo dõi và sửa chữa.

Tự do kỹ thuật luôn đi kèm hóa đơn vận hành.

Khi nào chưa cần Lakehouse?

Không phải hệ thống nào cũng cần Lakehouse.

Giả sử công ty có:

• Vài chục GB dữ liệu.
• Dữ liệu chủ yếu có cấu trúc.
• Một nhóm nhỏ chạy báo cáo.
• PostgreSQL vẫn xử lý tốt.
• Chưa có workload Machine Learning lớn.
• Chưa phải sao chép dữ liệu qua nhiều nền tảng.

Trong trường hợp đó, dựng đầy đủ Lakehouse có thể giống mua xe tải 18 bánh để chở một bịch rau muống.

Chở được.

Nhìn rất mạnh.

Nhưng đậu xe hơi cực.

Lakehouse bắt đầu đáng cân nhắc khi:

• Object storage đã trở thành nơi giữ dữ liệu chính.
• Khối lượng dữ liệu tăng nhanh.
• BI và Data Science cần dùng chung dữ liệu.
• Data lake cần transaction và versioning.
• Có quá nhiều pipeline đồng bộ giữa lake và warehouse.
• Doanh nghiệp muốn tổ chức dữ liệu rõ ràng từ raw đến business.
• Việc chạy lại dữ liệu từ nguồn đang quá khó khăn.

Câu hỏi đúng không phải là:

Lakehouse có hiện đại không?

Câu hỏi đúng là:

Nỗi đau của mình có đúng là nỗi đau mà Lakehouse được sinh ra để giải quyết không?

Tổng kết

Lakehouse 1.0 xuất hiện từ một ý tưởng khá giản dị:

Đừng bắt dữ liệu phải sống hai cuộc đời chỉ vì data lake rộng nhưng bừa bộn, còn data warehouse ngăn nắp nhưng đóng kín.

Ở tầng kỹ thuật, Lakehouse đặt lớp quản lý bảng và transaction lên trên object storage cùng các định dạng file mở.

Ở tầng xử lý, dữ liệu đi qua ba trạng thái:

1Bronze → Silver → Gold

Bronze giữ ký ức gần nhất với hệ thống nguồn.

Silver biến nhiều cách gọi khác nhau thành một ngôn ngữ chung.

Gold biến dữ liệu thành những bảng có thể trả lời trực tiếp câu hỏi nghiệp vụ.

Một giao dịch ngoài cửa hàng chỉ mất vài giây.

Nhưng khi bước vào hệ thống, nó phải chạy qua mạng, hàng đợi, CPU, object storage, transaction log, Bronze, Silver rồi Gold, trước khi biến thành một ô doanh thu nhỏ bé trên dashboard.

Ô số ấy nhìn có vẻ nhẹ như không khí.

Nhưng không có gì là hoàn toàn ảo.

Phía sau nó là máy chủ thật, điện năng thật, dữ liệu thật và hàng trăm quyết định kỹ thuật của con người.

Lakehouse không làm cái hồ biến mất.

Nó chỉ giúp chúng ta xây được một căn nhà trên hồ mà không phải mỗi đêm thức dậy kiểm tra xem phòng khách đã trôi sang tỉnh khác hay chưa.

Cảm ơn các bạn đã quan tâm và theo dõi bài viết, hẹn gặp lại ở các bài viết tiếp theo.

Tham khảo

• Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics
• Delta Lake 0.1.0 Released
• Delta Lake 0.2.0 Released
• Delta Lake 0.5.0 Released
• Apache Iceberg Specification
• Medallion Lakehouse Architecture