Databricks 1 — Tổng quan nền tảng Lakehouse

Databricks là gì

Databricks là một nền tảng dữ liệu và AI thống nhất (unified data and AI platform) chạy trên đám mây. Công ty được lập bởi chính nhóm tác giả tạo ra Apache Spark tại UC Berkeley (AMPLab) — cùng những dự án nguồn mở đình đám khác như Delta Lake, MLflow và Unity Catalog. Điểm mấu chốt cần khắc sâu ngay: Databricks không phải là "một cụm Spark được dựng sẵn". Đó là cách hiểu của mười năm trước. Ngày nay, Databricks là nơi bạn làm toàn bộ vòng đời dữ liệu trên một nền tảng duy nhất — từ ingest dữ liệu thô, biến đổi (ETL/ELT), xây kho phân tích, chạy dashboard BI, cho tới huấn luyện và triển khai mô hình machine learning.

Giá trị cốt lõi mà Databricks bán là sự thống nhất (unification). Trong kiến trúc truyền thống, một tổ chức thường phải ghép nối rất nhiều mảnh rời rạc: một data lake để chứa dữ liệu thô (S3/ADLS), một data warehouse riêng cho BI (Snowflake/Redshift), một cụm Spark riêng cho data engineering, một nền tảng ML riêng, và một công cụ governance riêng ở trên cùng. Mỗi mảnh là một hợp đồng, một đội vận hành, một bản sao dữ liệu và một điểm gãy. Databricks định vị mình là một nền tảng gộp tất cả — cùng một bản sao dữ liệu, cùng một lớp quản trị, cùng một engine tính toán phục vụ cả kỹ thuật dữ liệu, phân tích và ML. Nền tảng công nghệ khiến điều này khả thi chính là kiến trúc lakehouse — thứ Databricks tiên phong và thương mại hoá.

Kiến trúc Lakehouse

Trước khi có lakehouse, tổ chức phải chọn giữa hai thái cực. Data lake (hồ dữ liệu — thường là file Parquet/JSON trên object storage) thì rẻ, mở, chứa được mọi loại dữ liệu, nhưng thiếu quản trị: không có transaction, không đảm bảo schema, dễ biến thành "đầm lầy dữ liệu" (data swamp) mà không ai tin tưởng nổi. Data warehouse (kho dữ liệu) thì ngược lại — quản trị chặt, hiệu năng SQL cao, đảm bảo ACID, nhưng đắt, đóng (dữ liệu bị khoá trong định dạng độc quyền của nhà cung cấp) và kém linh hoạt với dữ liệu phi cấu trúc hay ML.

Lakehouse là kiến trúc lai: giữ độ mở và chi phí thấp của data lake (dữ liệu vẫn là file mở trên object storage của chính bạn) nhưng bổ sung lớp quản trị và hiệu năng của warehouse (transaction ACID, schema enforcement, chỉ mục, hiệu năng truy vấn SQL cao). Chi tiết về ba mô hình này và cách phân biệt được trình bày sâu trong bài Data Lake, Warehouse & Lakehouse. Với Databricks, mảnh ghép công nghệ làm nên lakehouse là Delta Lake — một open table format thêm một lớp metadata (transaction log) lên trên các file Parquet, biến một đống file rời rạc thành một "bảng" thực thụ có ACID, time travel và schema. Delta Lake là chủ đề của bài 2.

Hệ quả thực tế rất lớn: dữ liệu của bạn không bị nhốt trong một hệ độc quyền. Nó vẫn nằm trong bucket S3/ADLS/GCS của chính bạn, ở định dạng mở, các engine khác (Spark, Trino, thậm chí công cụ ngoài Databricks) đọc được. Đây là lập luận "chống vendor lock-in" mạnh nhất của Databricks.

Control plane vs Data plane

Đây là kiến trúc quan trọng nhất cần hiểu để dùng Databricks đúng, đặc biệt trong ngân hàng nơi data residency (dữ liệu phải nằm ở đâu) là vấn đề tuân thủ sống còn. Databricks tách hạ tầng thành hai mặt phẳng.

Control plane là phần Databricks quản lý trong tài khoản đám mây của Databricks. Nó chứa: giao diện web (workspace UI), job scheduler (bộ lập lịch), quản lý cluster, metadata về notebook/job/cấu hình, và các dịch vụ điều phối. Đây là "bộ não điều khiển" — nhưng dữ liệu nghiệp vụ của bạn không nằm ở đây.

Data plane (còn gọi compute plane) là nơi compute thực sự chạy và dữ liệu thực sự nằm. Với mô hình classic (cổ điển), data plane nằm ngay trong tài khoản đám mây / VPC của chính khách hàng: cluster Spark khởi tạo trên máy ảo trong subscription của bạn, đọc/ghi dữ liệu trên object storage của bạn. Databricks chỉ ra lệnh; dữ liệu không rời khỏi ranh giới của tổ chức bạn. Với mô hình serverless, compute chạy trên hạ tầng do Databricks quản lý (nhanh khởi động, không cần bạn tự dựng máy) — đổi lại bạn nhượng một phần quyền kiểm soát về vị trí compute, nên với dữ liệu cực nhạy cần cân nhắc kỹ về ranh giới và tuân thủ.

Ý nghĩa cho ngân hàng: control plane chỉ giữ metadata (tên bảng, lịch job, cấu hình) chứ không giữ số dư tài khoản hay thông tin khách hàng. Dữ liệu nghiệp vụ nằm trong storage và VPC do ngân hàng kiểm soát, đúng vùng địa lý yêu cầu (ví dụ vùng cloud tại Việt Nam/Singapore theo quy định). Đây là lý do kỹ thuật khiến Databricks có thể được duyệt qua vòng đánh giá tuân thủ.

Workspace và các thành phần

Workspace là môi trường làm việc bạn đăng nhập vào — một không gian tổ chức chứa toàn bộ tài sản. Các thành phần chính:

Thành phần	Vai trò
Notebook	Sổ tay tương tác, chạy hỗn hợp Python / SQL / Scala / R theo từng cell; nơi viết và thử nghiệm code
Cluster	Cụm máy tính chạy Spark; nơi thực thi thật sự của các phép biến đổi lớn
Job / Workflow	Pipeline được lập lịch và điều phối (chạy tự động theo cron/trigger)
SQL Warehouse	Compute chuyên tối ưu cho truy vấn SQL/BI (trước đây gọi SQL Endpoint)
Repos	Tích hợp Git — đưa version control vào notebook và code
Unity Catalog	Lớp quản trị & metastore thống nhất: catalog → schema → table, quyền, lineage

Điểm cần phân biệt: cluster (dạng all-purpose hoặc job cluster) thiên về data engineering và ML — chạy code Spark tổng quát; còn SQL Warehouse được tinh chỉnh riêng cho tải BI, độ trễ thấp, tự co giãn theo số truy vấn. Cùng đọc một bảng Delta nhưng phục vụ hai loại người dùng khác nhau.

Các trụ cột nền tảng

Databricks là tập hợp nhiều lớp công nghệ ăn khớp. Series này đi qua từng trụ cột:

• Delta Lake — table format nền tảng cho lakehouse (ACID, time travel, schema evolution). Xem bài 2 và tổng quan Delta ở spark-07.
• Spark & Photon — engine tính toán phân tán. Photon là engine vector hoá viết bằng C++, thay thế phần thực thi của Spark cho SQL/DataFrame để tăng tốc đáng kể. Xem bài 3 và nền tảng Spark ở spark-01.
• Workflows & DLT — điều phối pipeline; Delta Live Tables (DLT) là framework khai báo để xây pipeline ETL với chất lượng dữ liệu tích hợp. Xem bài 4.
• Unity Catalog — governance thống nhất: quyền truy cập, lineage, audit trên toàn workspace. Xem bài 5.
• Databricks SQL — lớp warehouse/BI trên lakehouse (SQL Warehouse + dashboard). Xem bài 6.
• ML & MLflow — vòng đời machine learning end-to-end với theo dõi thí nghiệm và triển khai mô hình. Xem bài 7.

Nền tảng chạy được trên cả ba đám mây lớn: AWS, Azure (bản "Azure Databricks" tích hợp sâu, là dịch vụ hạng nhất của Microsoft) và GCP. Cùng một trải nghiệm, khác nhà cung cấp hạ tầng bên dưới.

Medallion architecture

Cách tổ chức dữ liệu chuẩn mực trên Databricks là medallion architecture (kiến trúc huy chương) — chia dữ liệu thành ba tầng chất lượng tăng dần:

• Bronze — dữ liệu thô nạp thẳng từ nguồn, giữ nguyên như gốc (để truy vết và tái xử lý).
• Silver — đã làm sạch, khử trùng lặp, chuẩn hoá schema, join các nguồn — bảng "sự thật" đáng tin.
• Gold — bảng tổng hợp theo nghiệp vụ, tối ưu cho báo cáo và mô hình.

Mỗi tầng là bảng Delta; pipeline đẩy dữ liệu chảy từ bronze lên gold. Đây là khung tổ chức mặc định mà DLT và Workflows hướng tới.

Định vị: chọn Databricks khi nào

Tiêu chí	Databricks	Snowflake	Spark tự quản (OSS)
Xuất phát điểm	Lakehouse (lake-first)	Warehouse-first	Engine tính toán thuần
ML / Data science	Rất mạnh (MLflow tích hợp)	Yếu hơn, đang bổ sung	Tự ghép công cụ
Data engineering / Spark	Bản địa, tối ưu (Photon)	Không phải thế mạnh	Đầy đủ nhưng phải tự vận hành
SQL/BI thuần	Tốt (Databricks SQL)	Xuất sắc, đơn giản nhất	Cần thêm engine (Trino…)
Vận hành	Managed	Managed (ít vận hành nhất)	Tự lo mọi thứ, tốn công nhất
Khoá nhà cung cấp	Thấp (định dạng mở)	Cao hơn (định dạng độc quyền)	Không có (nhưng nặng công)

Nguyên tắc chọn thực dụng:

• Chọn Databricks khi tổ chức cần một nền tảng thống nhất cho cả data engineering nặng, phân tích và ML/AI — đặc biệt khi có khối lượng dữ liệu lớn, phi cấu trúc, và tham vọng ML rõ ràng.
• Chọn Snowflake khi trọng tâm là kho phân tích SQL/BI cho analyst, muốn vận hành đơn giản nhất, ít nhu cầu Spark/ML sâu.
• Chọn Spark tự quản khi có đội nền tảng mạnh, muốn kiểm soát chi phí và hạ tầng tuyệt đối, chấp nhận gánh nặng vận hành (tự dựng cluster, tự lo governance) — xem spark-01 để cân nhắc.

Nói ngắn gọn: Databricks mạnh nhất khi biên giới giữa "data engineering" và "machine learning" mờ đi và bạn muốn xoá bỏ các bản sao dữ liệu rời rạc.

Use case thực tế

Bối cảnh: Khối Dữ liệu NCB muốn xây một nền tảng thống nhất phục vụ đồng thời báo cáo giám sát rủi ro (cho khối tuân thủ) và mô hình phát hiện gian lận (cho khối vận hành thẻ). Trước đây, dữ liệu giao dịch được sao chép ba lần: một bản trong lake cho data engineer, một bản đẩy sang warehouse cho analyst, một bản trích xuất riêng cho đội ML — ba bản lệch nhau, tốn kho, và mỗi lần đối soát mất 2-3 ngày.

Triển khai trên Databricks (minh hoạ):

1. Data residency: Dựng workspace theo mô hình classic, data plane đặt trong VPC của ngân hàng tại vùng cloud Singapore; control plane chỉ giữ metadata. Đội tuân thủ xác nhận số dư và thông tin định danh khách hàng (PII) không rời khỏi VPC — vượt qua vòng đánh giá.
2. Bronze: Ingest ~40 triệu bản ghi giao dịch/ngày từ core banking và log ATM vào bảng Delta thô, giữ nguyên gốc để truy vết.
3. Silver: Pipeline Spark khử trùng lặp, chuẩn hoá mã tiền tệ, join với danh mục khách hàng — một bảng "sự thật" duy nhất.
4. Gold: Từ silver dựng bảng tổng hợp rủi ro theo ngày cho dashboard Databricks SQL (khối tuân thủ), đồng thời đội ML đọc chính bảng silver đó làm feature huấn luyện mô hình gian lận qua MLflow — không tạo bản sao thứ tư.
5. Governance: Unity Catalog cấp quyền theo vai trò — analyst chỉ thấy bảng gold đã ẩn PII, kỹ sư ML thấy silver, mọi truy cập được audit và có lineage.

Kết quả (minh hoạ): một bản sao dữ liệu duy nhất phục vụ cả ba nhóm; thời gian đối soát giảm từ vài ngày xuống gần như tức thời vì mọi người dùng chung một nguồn sự thật.

Ghi nhớ

• Databricks là nền tảng dữ liệu & AI thống nhất do nhóm tạo Apache Spark lập, thương mại hoá kiến trúc lakehouse — không chỉ là "Spark dựng sẵn".
• Lakehouse = độ mở + chi phí thấp của data lake cộng quản trị + hiệu năng của warehouse; nền tảng kỹ thuật là Delta Lake (file mở + transaction log).
• Control plane (Databricks quản: UI, scheduler, metadata) tách khỏi data plane (compute và dữ liệu chạy trong VPC của khách với classic) — điểm mấu chốt cho data residency và tuân thủ ngân hàng.
• Classic = compute trong tài khoản khách; serverless = compute do Databricks quản, nhanh nhưng nhượng bớt kiểm soát vị trí.
• Workspace gồm: notebook, cluster, job/workflow, SQL Warehouse (tối ưu BI), repos, Unity Catalog (governance).
• Trụ cột nền tảng: Delta Lake, Spark/Photon, Workflows/DLT, Unity Catalog, Databricks SQL, ML/MLflow — chạy trên AWS/Azure/GCP.
• Medallion: bronze (thô) → silver (sạch) → gold (nghiệp vụ) là khung tổ chức dữ liệu mặc định.
• Định vị: Databricks (lakehouse, mạnh ML + data engineering) vs Snowflake (warehouse-first, đơn giản) vs Spark tự quản (kiểm soát tối đa, nặng vận hành).
• Ưu thế chống vendor lock-in: dữ liệu vẫn là định dạng mở trong storage của chính bạn.