Kiến trúc Medallion trong Lakehouse: Khám phá Batch Processing, Real-time Processing, Spark Structured Streaming

Trong các nền tảng dữ liệu hiện đại, việc lưu trữ dữ liệu chỉ là bước khởi đầu. Điều quan trọng hơn là làm thế nào để biến dữ liệu thô thành dữ liệu có chất lượng cao, đáng tin cậy và sẵn sàng phục vụ báo cáo, phân tích cũng như các ứng dụng AI tạo sinh. Nếu mọi loại dữ liệu đều được lưu trữ trong cùng một khu vực mà không có quy trình xử lý rõ ràng, hệ thống sẽ nhanh chóng trở nên khó quản lý, dữ liệu dễ mất tính nhất quán và việc khai thác giá trị từ dữ liệu sẽ ngày càng phức tạp.

Đó là lý do kiến trúc Medallion ra đời. Đây là một mô hình tổ chức dữ liệu được sử dụng rộng rãi trong các nền tảng Lakehouse, giúp dữ liệu được cải thiện chất lượng theo từng giai đoạn thông qua ba lớp Bronze, Silver và Gold. Mỗi lớp đảm nhận một vai trò riêng, từ lưu trữ dữ liệu gốc, làm sạch và chuẩn hóa cho đến xây dựng các tập dữ liệu phục vụ trực tiếp cho hoạt động kinh doanh.

Trong bài viết này, chúng ta sẽ tìm hiểu toàn diện về kiến trúc Medallion, bao gồm nguồn gốc của Lakehouse, ý nghĩa của từng lớp dữ liệu, vai trò của Landing Zone, sự khác biệt giữa Batch Processing và Real-time Processing, cách Spark Structured Streaming hỗ trợ xử lý dữ liệu thời gian thực cũng như các công cụ ETL và Orchestration thường được sử dụng để xây dựng các Data Pipeline hiện đại.

Lakehouse Architecture: Kiến trúc dữ liệu hợp nhất cho BI, AI và Big Data

1. Kiến trúc Lakehouse

Bối cảnh: Khi "Hồ" và "Kho" không còn đủ

Trước đây, các doanh nghiệp thường phải duy trì hai hệ thống song song: Một cái "Kho" (Warehouse) để lưu dữ liệu sạch phục vụ báo cáo, và một cái "Hồ" (Lake) để chứa dữ liệu thô khổng lồ cho AI/Machine Learning. Việc phải sao chép dữ liệu qua lại giữa hai nơi gây tốn kém, chậm trễ và dễ sai lệch.

Bước ngoặt từ Spark và Databricks (2013)

• Sự trỗi dậy của Spark: Năm 2013, dự án Apache Spark trở nên phổ biến và được mở rộng để xử lý dữ liệu quy mô lớn một cách nhanh chóng.

• Sự ra đời của Databricks: Các nhà sáng lập Spark đã lập ra Databricks để thương mại hóa công nghệ này. Thay vì tập trung vào cài đặt tại chỗ (on-premises) như các đối thủ thời đó, họ chọn con đường chỉ tập trung vào đám mây (cloud-only). Chính bước đi chiến lược này đã giúp Spark trở nên linh hoạt, tách rời lưu trữ khỏi sức mạnh tính toán.

Sự xuất hiện của "Các định dạng bảng mở" - Chìa khóa vàng

Đây là phần quan trọng nhất để tạo nên Lakehouse. Để dữ liệu trong "Hồ" (vốn là các tệp tin rời rạc) có thể hoạt động ổn định như trong "Kho", cần có các định dạng bảng mới:

• Hudi (2017) và Iceberg (2018): Bắt đầu đặt nền móng cho việc quản lý dữ liệu lớn một cách tin cậy hơn.

• Delta Lake (2019): Do Databricks ra mắt, mang lại các tính năng quan trọng như giao dịch ACID (đảm bảo dữ liệu không bị lỗi khi ghi/đọc đồng thời) và khả năng "du hành thời gian" (xem lại trạng thái dữ liệu cũ).

Định nghĩa "Lakehouse" ra đời

Với sức mạnh của Spark và tính tin cậy của Delta Lake, thuật ngữ "Lakehouse" được Databricks tiên phong đặt tên. Nó kết hợp:

• Chi phí thấp và tính linh hoạt của Hồ dữ liệu (Data Lake).

• Hiệu suất và tính chính xác của Kho dữ liệu (Data Warehouse).

Sự bùng nổ của thị trường hiện nay

Đến năm 2025, kiến trúc Lakehouse đã trở thành một tiêu chuẩn ngành. Tất cả các ông lớn công nghệ như Microsoft (với Azure Synapse, Microsoft Fabric), Google, Amazon và Snowflake đều đã tích hợp hoặc hỗ trợ khái niệm này.

Tóm lại: Lakehouse không chỉ là một công nghệ mới, mà là một tầm nhìn hợp nhất. Để vận hành hiệu quả bên trong "ngôi nhà chung" này, các chuyên gia đã đề xuất Kiến trúc Medallion (Đồng - Bạc - Vàng) như một quy chuẩn vàng để tổ chức dữ liệu một cách khoa học.

2. Kiến trúc Medallion là gì

Kiến trúc Medallion là một mẫu thiết kế dữ liệu dùng để tổ chức dữ liệu một cách logic trong một "lakehouse".

Ý tưởng là: "Càng đi sâu, càng giá trị".

Mục tiêu của kiến trúc này là cải thiện dần dần và liên tục cấu trúc cũng như chất lượng của dữ liệu. Dữ liệu giống như một dòng chảy đi qua ba "trạm lọc" chính: Đồng ⇒ Bạc ⇒ Vàng. Càng chuyển qua lớp sau, dữ liệu càng sạch, chuẩn hóa và sẵn sàng để sử dụng cho mục đích kinh doanh.

Ý nghĩa của ba lớp "Huy chương"

Sử dụng các kim loại quý để đặt tên cho các lớp dữ liệu nhằm giúp người dùng (ngay cả những người không chuyên về kỹ thuật) dễ dàng hình dung về chất lượng của chúng:

• Lớp Đồng (Bronze Layer) – Dữ liệu thô: Đây là "điểm dừng chân" đầu tiên của dữ liệu khi được lấy từ nguồn về. Đặc điểm của nó là giữ nguyên cấu trúc gốc, không thay đổi bất cứ thứ gì. Nó đóng vai trò như một kho lưu trữ lịch sử đáng tin cậy nhất.

• Lớp Bạc (Silver Layer) – Dữ liệu tinh chế: Ở lớp này, dữ liệu thô bắt đầu được "gọt giũa". Các kỹ sư sẽ thực hiện kiểm tra chất lượng, chuẩn hóa các định dạng, loại bỏ dữ liệu trùng lặp và làm cho dữ liệu trở nên nhất quán hơn. Đây là bước đệm quan trọng để dữ liệu có thể dùng chung cho toàn bộ tổ chức.

• Lớp Vàng (Gold Layer) – Dữ liệu tối ưu: Đây là lớp dữ liệu "thành phẩm". Dữ liệu ở đây đã được tính toán, tổng hợp và tổ chức lại theo cách mà các báo cáo kinh doanh hoặc các nhà phân tích có thể lấy ra dùng ngay lập tức. Nó ưu tiên tốc độ truy cập và độ chính xác của các chỉ số kinh doanh.

Tại sao lại dùng kiến trúc này?

Kiến trúc Medallion mang lại những lợi ích quan trọng sau:

• Thân thiện với kinh doanh: Các nhãn "Đồng", "Bạc", "Vàng" giúp các bộ phận kinh doanh hiểu ngay được trạng thái của dữ liệu mà họ đang xem.

• Tính linh hoạt và khả năng mở rộng: Nó cho phép tổ chức xử lý được cả dữ liệu có cấu trúc và phi cấu trúc trên một nền tảng thống nhất.

• Đảm bảo tính chính xác: Bằng cách chia nhỏ quá trình xử lý thành các bước, bạn có thể dễ dàng kiểm soát lỗi và đảm bảo dữ liệu cuối cùng (lớp Vàng) luôn đạt tiêu chuẩn cao nhất.

Thông điệp: Dù các tên gọi nghe có vẻ đơn giản, nhưng việc triển khai thực tế đòi hỏi sự cẩn trọng trong việc mô hình hóa dữ liệu. Kiến trúc Medallion không chỉ là một thủ thuật đặt tên, mà là một chiến lược để biến dữ liệu thô thành những thông tin chi tiết có giá trị cho doanh nghiệp.

3. Vùng hạ cánh (Landing Zone)

Đây là các khu vực đệm trung gian cần thiết trước khi dữ liệu chính thức bước vào kiến trúc Medallion.

Vùng hạ cánh là gì?

Một "vùng hạ cánh" (landing zone) là một khu vực sơ bộ, nơi dữ liệu thô được nạp vào lần đầu tiên từ các hệ thống nguồn trước khi nó thực sự "hạ cánh" xuống lớp Đồng (Bronze) của kiến trúc Medallion.

Tại sao cần thêm các vùng hạ cánh "phụ"?

Mặc dù lớp Bronze thường được coi là điểm dừng chân đầu tiên, nhưng thực tế đôi khi bạn cần một bước đệm trước đó vì các lý do sau:

• Yêu cầu bảo mật: Khi làm việc với các dịch vụ bên ngoài hoặc nhà cung cấp phần mềm dạng dịch vụ (SaaS), bạn có thể cần một vùng hạ cánh an toàn để lưu trữ tạm thời trước khi chuyển vào hệ thống chính.

• Yêu cầu của từng đội nhóm: Một số đội ngũ ứng dụng có quy trình kiểm soát cực kỳ nghiêm ngặt. Họ muốn quản lý quá trình trích xuất dữ liệu riêng để đảm bảo không có lỗi hoặc sự không nhất quán nào xảy ra trước khi đưa vào kho dữ liệu chung.

• Công cụ đặc thù: Đôi khi việc nạp dữ liệu đòi hỏi các công cụ ETL (trích xuất, biến đổi, nạp) cụ thể hoặc các thiết lập mạng riêng biệt mà chỉ có vùng hạ cánh này mới đáp ứng được.

Sự linh hoạt trong cách gọi và thiết kế

Cấu trúc này rất linh hoạt. Tùy thuộc vào tổ chức, vùng hạ cánh bổ sung này có thể được gọi bằng nhiều tên khác nhau như:

• Lớp Thiếc (Tin layer)

• Tiền-Đồng (Pre-Bronze)

• Khu vực dàn dựng (Staging area)

Dữ liệu có thể được nạp trực tiếp vào lớp Bronze nếu hệ thống nguồn đủ ổn định và bảo mật, nhưng trong các môi trường lớn và phức tạp, việc có nhiều vùng hạ cánh trung gian là điều rất phổ biến.

Tóm lại: Không có một công thức duy nhất cho tất cả mọi người. Số lượng các lớp hay vùng hạ cánh tùy thuộc hoàn toàn vào nhu cầu thực tế, yêu cầu chức năng và quản trị của tổ chức bạn. Quan trọng là bạn phải nạp và lưu trữ dữ liệu sao cho phù hợp nhất với sự an toàn và hiệu quả của hệ thống.

4. Batch Processing" (Xử lý theo lô)

Batch Processing (Xử lý theo lô) là một phương thức truyền thống nhưng vẫn cực kỳ quan trọng trong kiến trúc dữ liệu hiện đại.

Xử lý theo lô là gì?

Hãy tưởng tượng thay vì bạn đi chợ mỗi khi cần một cọng hành, bạn sẽ đợi đến cuối tuần để đi siêu thị một lần và mua thực phẩm cho cả tuần. Xử lý theo lô cũng vậy: dữ liệu được thu thập qua một khoảng thời gian, sau đó toàn bộ "lô" dữ liệu đó sẽ được xử lý cùng một lúc vào các thời điểm đã định sẵn.

Tại sao phương pháp này vẫn rất phổ biến?

Có 3 lý do chính khiến xử lý theo lô vẫn giữ vững vị thế:

• Tiết kiệm chi phí: Thay vì hệ thống phải chạy liên tục 24/7 (gây tốn tài nguyên), nó chỉ hoạt động vào những khung giờ nhất định để xử lý khối lượng lớn dữ liệu trong một lần duy nhất.

• Hỗ trợ rộng rãi: Hầu hết các hệ thống và hạ tầng cũ đều hỗ trợ tốt phương thức này.

• Tốt cho dữ liệu lịch sử: Rất phù hợp khi bạn muốn xây dựng cái nhìn toàn cảnh về quá khứ bằng cách xử lý tất cả dữ liệu tích lũy được.

Những lưu ý "sống còn" khi xây dựng lớp Bronze

Có 4 điểm cần chuẩn bị kỹ khi thiết lập nạp dữ liệu theo lô vào lớp Đồng (Bronze layer):

• Đảm bảo tính toàn vẹn: Bạn phải dùng các phương pháp kiểm tra như đếm số dòng (row counts) hoặc kiểm tra mã băm (checksum) để chắc chắn dữ liệu không bị mất mát hay sai lệch trong quá trình chuyển dời.

• Lên lịch trình thông minh: Cần chọn khoảng thời gian nạp dữ liệu hợp lý, dựa trên việc nguồn dữ liệu có sẵn khi nào và doanh nghiệp cần báo cáo nhanh đến mức nào.

• Cơ chế xử lý lỗi mạnh mẽ: Luôn phải có phương án dự phòng khi quá trình nạp dữ liệu thất bại. Nên tạo một "vùng cách ly dữ liệu lỗi" (data orphanage) để theo dõi và xử lý các lô dữ liệu gặp sự cố, đảm bảo hệ thống vận hành trơn tru.

• Chọn công cụ phù hợp: Việc chọn đúng công cụ (như Azure Data Factory) sẽ giúp việc điều phối và quản lý các đường ống dữ liệu trở nên hiệu quả hơn.

Tóm lại: Đừng coi thường sự đơn giản của xử lý theo lô. Dù nghe có vẻ dễ, nhưng trong thực tế doanh nghiệp, nó vẫn là một thách thức lớn vì mỗi nguồn dữ liệu thường có những đặc thù riêng và đòi hỏi một "công thức" xử lý khác biệt.

5. Real-Time Data Processing" (Xử lý dữ liệu thời gian thực)

Real-Time Data Processing (Xử lý dữ liệu thời gian thực) là cách hệ thống xử lý thông tin ngay khi nó vừa được tạo ra, thay vì chờ đợi gom đủ một "lô" dữ liệu như phương pháp truyền thống.

Mục tiêu cốt lõi: Phản ứng tức thì

Tinh thần ở đây là sự nhạy bén. Trong thế giới kinh doanh hiện đại, việc xử lý dữ liệu ngay lập tức cho phép bạn đưa ra quyết định nhanh chóng trong các tình huống như: phát hiện gian lận tài chính, tương tác cá nhân hóa với khách hàng ngay trên web, hoặc điều chỉnh hệ thống máy móc tự động.

Ba công cụ "vàng" trong hệ sinh thái xử lý luồng

Có 3 phương thức phổ biến để xử lý dữ liệu đang chảy:

• Spark Structured Streaming: Công cụ mạnh mẽ nhất, cho phép bạn đọc và biến đổi dữ liệu liên tục khi nó vẫn đang chuyển động.

• Change Data Feed (CDF): Một tính năng của Delta Lake giúp theo dõi những thay đổi nhỏ nhất trong bảng dữ liệu theo thời gian thực.

• Change Data Capture (CDC): Kỹ thuật theo dõi nhật ký giao dịch của cơ sở dữ liệu nguồn để sao chép các thay đổi (thêm, sửa, xóa) ngay lập tức.

Triết lý kiến trúc: Dữ liệu này nằm ở đâu?

Đây là phần cần "cẩn trọng". Khi dữ liệu thời gian thực đổ vào Lakehouse, bạn cần quyết định nó thuộc về lớp nào:

• Nếu bạn muốn lưu bản sao thô để đối chiếu lịch sử: Hãy xếp nó vào lớp Đồng (Bronze).

• Nếu bạn chỉ muốn truy vấn nhanh trạng thái mới nhất: Nó có thể chỉ được coi là một vùng đệm trung gian trước khi vào lớp Bạc hoặc Vàng.

Cập nhật song song (Parallel Updates)

Một điểm thú vị là với dữ liệu thời gian thực, các lớp có thể được cập nhật cùng một lúc. Bạn có thể vừa lưu dữ liệu thô vào lớp Đồng để lưu trữ, vừa đồng thời làm sạch và đẩy thẳng vào lớp Bạc hoặc Vàng để phục vụ báo cáo ngay lập tức. Lúc này, lớp Đồng đóng vai trò giống như một khu vực lưu trữ vĩnh viễn (archive) hơn là một nơi để đọc dữ liệu.

Tóm lại: Xử lý thời gian thực rất mạnh mẽ nhưng cũng phức tạp và tốn kém hơn xử lý theo lô (vì máy tính phải chạy liên tục). Cần dựa trên nhu cầu thực tế của doanh nghiệp để quyết định có thực sự cần tốc độ "tức thì" hay không.

6. Spark Structured Streaming

Spark Structured Streaming là một engine xử lý luồng dữ liệu (stream processing engine) mạnh mẽ, tích hợp sẵn trong nhân Apache Spark để xử lý dữ liệu theo thời gian thực.

Xử lý dữ liệu khi đang "chảy"

Thay vì đợi thu thập đủ một lượng dữ liệu lớn rồi mới xử lý (như phương pháp Batch), Spark Structured Streaming cho phép hệ thống đọc và biến đổi dữ liệu liên tục ngay khi nó vừa được tạo ra. Đây là một phần không thể thiếu của Spark, giúp việc xây dựng các đường ống dữ liệu thời gian thực trở nên đơn giản và thống nhất hơn.

Khả năng kết nối đa dạng

Công cụ này có thể "ăn" dữ liệu từ nhiều nguồn khác nhau, bao gồm:

• Các hệ thống tin nhắn: Như Apache Kafka (phổ biến nhất cho dữ liệu luồng).

• Thiết bị IoT: Dữ liệu cảm biến từ các máy móc gửi về liên tục.

• Tệp tin nhật ký (Log files): Các tệp ghi lại hoạt động của hệ thống.

Đích đến cuối cùng: Delta Lake

Sau khi đã được làm sạch và biến đổi, dữ liệu sẽ được ghi vào các hệ thống lưu trữ bền vững. Trong kiến trúc Medallion, đích đến ưu tiên thường là Delta Lake vì nó hỗ trợ tính nhất quán (ACID) và cho phép quản lý các phiên bản dữ liệu khác nhau. Ngoài ra, nó cũng có thể đẩy dữ liệu vào các cơ sở dữ liệu NoSQL hoặc gửi ngược lại các hàng đợi tin nhắn để phục vụ các ứng dụng khác.

Lưu ý quan trọng về Chi phí và Hiệu suất

• Chi phí: Xử lý thời gian thực thường yêu cầu cụm máy tính phải "luôn bật" (always on), dẫn đến chi phí duy trì cao hơn so với xử lý theo lô.

• Giải pháp tối ưu: Nếu doanh nghiệp của bạn không thực sự cần tốc độ nhanh đến từng giây, bạn có thể thiết lập cơ chế Trigger (ví dụ: cứ mỗi 5 phút chạy một lần). Cách này giúp giảm đáng kể chi phí mà vẫn đảm bảo tính cập nhật của dữ liệu.

Tóm lại: Spark Structured Streaming là một công cụ giúp tổ chức phản ứng tức thì với các cơ hội hoặc rủi ro kinh doanh (như phát hiện gian lận hay điều chỉnh hệ thống tự động) bằng cách tận dụng sức mạnh xử lý dữ liệu quy mô lớn của Spark.

7. ETL and Orchestration Tools (Công cụ ETL và Điều phối)

Vai trò: "Người nhạc trưởng" của dữ liệu

Việc chọn đúng công cụ ETL (Extract - Trích xuất, Transform - Biến đổi, Load - Nạp) và Orchestration (Điều phối) là cực kỳ quan trọng vì nó ảnh hưởng trực tiếp đến cách bạn thiết kế đường ống dữ liệu.

• ETL: Giúp lấy dữ liệu từ nguồn, thay đổi hình dạng cho phù hợp và nạp vào các tầng Medallion.

• Orchestration (Điều phối): Giống như một người nhạc trưởng, công cụ này đảm bảo các công việc diễn ra đúng thứ tự, đúng thời gian và tự động xử lý khi có lỗi xảy ra.

Các công cụ phổ biến

• Apache Airflow: Một nền tảng mã nguồn mở mạnh mẽ cho phép bạn lập trình (viết code) để lập lịch và giám sát các luồng công việc phức tạp. Nó rất giỏi trong việc quản lý các nhiệm vụ có sự phụ thuộc lẫn nhau.

• Azure Data Factory (ADF): Rất phổ biến trong hệ sinh thái Microsoft (Azure Databricks, Fabric). Điểm mạnh của nó là có hơn 200 "đầu nối" (connectors) giúp lấy dữ liệu từ vô số nguồn khác nhau một cách dễ dàng.

• Databricks Auto Loader: Công cụ đặc thù của Databricks, cực kỳ hiệu quả trong việc tự động nạp các tệp tin mới khi chúng vừa xuất hiện trong kho lưu trữ đám mây và tự động xử lý khi cấu trúc dữ liệu thay đổi.

• Các công cụ bên thứ ba khác: Fivetran, Qlik, Informatica... dành cho những tổ chức cần sự đa dạng tối đa về kết nối và khả năng điều phối chuyên sâu.

8. Kết luận

Kiến trúc Medallion không chỉ là cách chia dữ liệu thành ba lớp Bronze, Silver và Gold mà còn là một phương pháp tổ chức dữ liệu có hệ thống, giúp nâng cao chất lượng dữ liệu theo từng giai đoạn xử lý. Khi được triển khai trên nền tảng Lakehouse, mô hình này giúp doanh nghiệp cân bằng giữa khả năng lưu trữ dữ liệu quy mô lớn, hiệu năng xử lý và tính tin cậy của dữ liệu phục vụ phân tích.

Bên cạnh đó, các thành phần như Landing Zone, Batch Processing, Real-time Processing, Spark Structured Streaming và các công cụ ETL, Orchestration đóng vai trò quan trọng trong việc xây dựng những Data Pipeline ổn định, có khả năng mở rộng và dễ quản trị. Hiểu rõ cách các thành phần này phối hợp với nhau sẽ giúp bạn thiết kế các hệ thống dữ liệu hiện đại đáp ứng tốt nhu cầu phân tích, trí tuệ nhân tạo và ra quyết định dựa trên dữ liệu.

Ở các bài viết tiếp theo, chúng ta sẽ đi sâu hơn vào từng thành phần của kiến trúc Medallion cũng như các kỹ thuật triển khai thực tế trên những nền tảng dữ liệu phổ biến hiện nay.