Kiến trúc Lambda và kiến trúc Kappa
1. Tổng quan
A. Định nghĩa
Kiến trúc Lambda (Lambda Architecture) là kiến trúc xử lý dữ liệu lớn vận hành song song tầng batch (Batch Layer) xử lý dữ liệu khối lượng lớn một cách chính xác, đầy đủ và tầng tốc độ (Speed Layer) xử lý với độ trễ thấp, rồi hợp nhất hai kết quả ở tầng phục vụ (Serving Layer) để đồng thời bảo đảm độ trễ truy vấn thấp và tính chính xác của kết quả.
Kiến trúc Kappa (Kappa Architecture) là kiến trúc loại bỏ tầng batch, thống nhất toàn bộ dữ liệu thành luồng sự kiện của log bất biến (Immutable Log) có bảo đảm thứ tự, và chỉ dùng một pipeline xử lý luồng duy nhất để thực hiện cả xử lý thời gian thực lẫn tái xử lý (Reprocessing) dữ liệu quá khứ.
Cả hai kiến trúc đều là những câu trả lời khác nhau cho cùng một vấn đề: "xử lý khối lượng dữ liệu lớn như thế nào trong sự đánh đổi giữa độ trễ (latency) và độ chính xác (accuracy)". Lambda đặt hai đường dẫn sự thật là batch và stream để tận dụng ưu điểm của từng bên (tính đầy đủ của batch, tính tức thời của stream), còn Kappa hợp nhất đường dẫn thành một log để loại bỏ sự phức tạp của việc duy trì hai codebase. Dưới góc nhìn Kỹ sư chuyên nghiệp Quản lý Thông tin, chủ đề này không chỉ là việc chọn công cụ, mà phải được hiểu là bài toán quản trị pipeline dữ liệu, thiết kế đồng thời mô hình bảo đảm nhất quán dữ liệu, chiến lược tái xử lý, độ phức tạp vận hành và chi phí.
B. Bối cảnh ra đời và sự cần thiết
Thứ nhất, nhu cầu xử lý dữ liệu lớn đã phân hóa thành "tổng hợp chính xác" và "tính tức thời". Xử lý batch truyền thống (ví dụ ETL ban đêm) tạo ra thống kê chính xác theo ngày, nhưng các sự kiện phát sinh trong khoảng đó chỉ được phản ánh vào ngày hôm sau. Ngược lại, xử lý thời gian thực thuần túy có tính tức thời tốt nhưng khó hiệu chỉnh hoàn toàn dữ liệu đến muộn (late-arriving data) hoặc thiếu sót, trùng lặp khi sự cố. Kiến trúc Lambda (Nathan Marz, khoảng năm 2011) được định hình từ kinh nghiệm kết hợp batch dựa trên Hadoop thời kỳ đầu với stream dựa trên Storm.
Thứ hai, có ràng buộc về CAP và khả năng tái hiện. Trong môi trường phân tán, khi node xử lý chết hoặc mạng bị trễ, kết quả xử lý luồng dễ trở thành giá trị xấp xỉ. Lambda lấy nhất quán cuối cùng dựa trên tính toán lại (recompute) làm nguyên lý cốt lõi: "kết quả của tầng tốc độ là giá trị tạm thời, và tầng batch sớm muộn sẽ ghi đè bằng giá trị chính xác". Tức là cấu trúc tự hiệu chỉnh trong đó batch định kỳ chữa lành sai số của stream.
Thứ ba, sự trưởng thành của các bộ máy xử lý luồng đã cho phép loại bỏ batch. Khi chức năng lưu giữ (retention) và phát lại (replay) log của Apache Kafka, xử lý trạng thái chính xác một lần (exactly-once) của Apache Flink, cửa sổ dựa trên thời gian sự kiện (event-time) và watermark trở nên trưởng thành, quan điểm "batch thực chất là một luồng hữu hạn" (Jay Kreps, đề xuất Kappa năm 2014) trở nên khả thi. Từ đó hình thành xu hướng giảm gánh nặng của Lambda vốn phải duy trì hai codebase.
C. Mục tiêu chung và đặc điểm
Điều mà cả hai kiến trúc cùng theo đuổi là lưu giữ bất biến dữ liệu nguồn và khả năng tái xử lý. Nếu lưu sự kiện gốc dạng append-only không thay đổi, thì dù phát hiện lỗi logic cũng có thể sửa mã và cho dữ liệu quá khứ chảy lại để tạo lại kết quả. Đây là nguyên tắc "lưu trữ là bản gốc, view là dẫn xuất", có lợi cho cả dòng dõi dữ liệu (lineage) và kiểm toán (audit). Khác biệt nằm ở chỗ việc tái xử lý đó được thực hiện bằng job batch riêng (Lambda) hay bằng phát lại trên cùng bộ máy xử lý luồng (Kappa).
Ngoài ra, cả hai kiến trúc đều thiết kế kho phục vụ trên tiền đề có thể tạo lại view dẫn xuất. View phục vụ không phải bản gốc mà gần với cache có thể tạo lại bất cứ lúc nào, nên dù thay đổi lược đồ, chỉ mục, trục tổng hợp thì cũng chỉ cần xây dựng lại view mà không đụng tới bản gốc. Tư duy này kết nối tự nhiên với CQRS và event sourcing — "tính trước và lưu tại thời điểm ghi (precompute), tại thời điểm đọc chỉ truy vấn" — và cung cấp sự linh hoạt để đặt nhiều hình thức tiêu thụ như dashboard, tìm kiếm, gợi ý trên cùng một nguồn.
2. Cấu trúc và hoạt động của kiến trúc Lambda
A. Cấu thành 3 tầng
Lambda gồm ba tầng: batch, tốc độ, phục vụ. Tập dữ liệu chủ (bản gốc bất biến) đồng thời đi vào tầng batch và tầng tốc độ, và tầng phục vụ hợp nhất các view do từng tầng tạo ra để trả lời truy vấn.
flowchart LR
SRC["Nguồn dữ liệu (log·IoT·giao dịch)"] --> ING["Thu thập (message broker)"]
ING --> BL["Tầng batch (tập dữ liệu chủ)"]
ING --> SL["Tầng tốc độ (xử lý thời gian thực)"]
BL --> BV["Batch view (chính xác·đầy đủ)"]
SL --> RTV["Real-time view (xấp xỉ·mới nhất)"]
BV --> SV["Tầng phục vụ (truy vấn hợp nhất)"]
RTV --> SV
SV --> Q["Truy vấn/dashboard/API"]
Tầng batch định kỳ (ví dụ mỗi giờ, mỗi ngày) tính toán lại toàn bộ tập dữ liệu chủ để tạo batch view chính xác. Vì đọc lại toàn bộ dữ liệu, một số lỗi logic hay dữ liệu đến muộn cũng được hiệu chỉnh tự nhiên ở lần batch tiếp theo. Hadoop MapReduce và Spark là các bộ máy tiêu biểu. Nhược điểm là độ trễ cho đến khi hoàn tất: sự kiện vừa đến sẽ không được phản ánh cho tới lần batch tiếp theo.
Tầng tốc độ chỉ xử lý thời gian thực đoạn gần đây mà batch chưa xử lý để tạo real-time view. Storm, Flink, Spark Streaming được sử dụng. Đây là xử lý tăng dần (incremental) nên nhanh, nhưng vì duy trì trạng thái một cách xấp xỉ nên sai số có thể tích lũy. Điểm cốt lõi là view này mang tính tạm thời.
Tầng phục vụ hợp nhất batch view và real-time view để trả lời truy vấn. Đến thời điểm batch bao phủ thì dùng batch view, còn đoạn mới nhất sau đó dùng real-time view để cộng dồn. Khi batch view được cập nhật, phần cũ tương ứng của real-time view bị loại bỏ (hết hạn). Kho phục vụ thường dùng kho key-value hoặc cột mạnh về đọc ngẫu nhiên và truy vấn nhanh (ví dụ HBase, Cassandra, Redis) hoặc công cụ tìm kiếm, và batch view được thay thế nguyên tử (swap) để ngăn bất nhất trong khi truy vấn.
B. Nguyên lý nhất quán dữ liệu (tính lại vs tăng dần)
Tính chính xác của Lambda đến từ nguyên tắc tính lại: "sớm muộn batch sẽ tính lại toàn bộ để xác lập sự thật". Chẳng hạn, dù việc tổng hợp số lượt truy cập thời gian thực bỏ sót một phần sự kiện trong 5 phút do sự cố node, lần batch tiếp theo sẽ đếm lại toàn bộ log gốc và ghi đè view phục vụ bằng giá trị chính xác. Biểu diễn bằng công thức là ket_qua_truy_van = merge(batch_view(toan_bo_du_lieu - gan_day), realtime_view(gan_day)), và khi thời gian trôi qua, đoạn "gần đây" được hấp thụ vào batch thì sai số thời gian thực biến mất.
Ví dụ cụ thể, xét trường hợp xử lý log nhấp chuột quảng cáo 2 tỷ bản ghi mỗi ngày (trung bình khoảng 23,000 TPS, đỉnh 50 nghìn TPS). Dashboard của nhà quảng cáo phải hiển thị "tổng số nhấp đến hiện tại", trong khi quyết toán phải chính xác và dashboard phải thời gian thực. Nếu tầng batch tổng hợp chính xác số nhấp lũy kế mỗi giờ và tầng tốc độ chỉ tổng hợp tăng dần phần 1 giờ vừa qua, nhà quảng cáo có được cả tính tức thời lẫn tính chính xác. Quyết toán chỉ tin cậy batch view, nên sai số xấp xỉ của stream không ảnh hưởng tới việc tính phí.
C. Ưu điểm và giới hạn
Ưu điểm lớn nhất của Lambda là cô lập lỗi và tự hiệu chỉnh. Dù tầng tốc độ hoạt động sai, ảnh hưởng chỉ giới hạn ở "sai số tạm thời của đoạn gần đây", và lần batch tiếp theo ghi đè bằng bản chuẩn nên sai số không bị vĩnh viễn hóa. Ngoài ra, batch view có thể được tạo lại từ bản gốc bất cứ lúc nào, nên cũng linh hoạt trong việc áp dụng hồi tố chỉ số mới hoặc thay đổi trục phân tích quá khứ. Đặc tính này đặc biệt có giá trị trong tài chính, viễn thông, thống kê công nơi niềm tin dữ liệu là cốt lõi.
Ngược lại, giới hạn là gánh nặng vận hành do nhân đôi logic. Cùng một quy tắc tổng hợp phải được viết và duy trì hai bản cho batch (ví dụ Spark) và cho stream (ví dụ Flink), và khi quy tắc thay đổi mà hai mã lệch nhau thì batch view và real-time view bất nhất, gây ra giá trị nhảy vọt khi hợp nhất ở tầng phục vụ. Để giảm điều này cần có kỷ luật như trích xuất logic tổng hợp thành thư viện chung hoặc buộc hai bộ máy chia sẻ cùng UDF và lược đồ. Bản thân logic hợp nhất và hết hạn của tầng phục vụ cũng phải xử lý chính xác các điều kiện biên (trùng lặp, thiếu sót tại ranh giới thời điểm batch bao phủ).
3. Cấu trúc và hoạt động của kiến trúc Kappa
A. Pipeline luồng duy nhất
Kappa loại bỏ tầng batch, append mọi thứ vào log (Kafka topic, v.v.) và tạo view bằng một job xử lý luồng duy nhất. Khi cần tái xử lý, khởi chạy job mới tiêu thụ lại log từ đầu (hoặc từ offset cụ thể) để tạo view mới, và khi sẵn sàng thì chuyển lưu lượng.
flowchart LR
SRC["Nguồn dữ liệu (log·IoT·giao dịch)"] --> LOG["Log bất biến (Kafka topic, thứ tự·lưu giữ)"]
LOG --> J1["Job xử lý luồng v1"]
J1 --> V1["View phục vụ v1 (đang vận hành)"]
LOG -. "Tái xử lý: phát lại từ offset 0" .-> J2["Job xử lý luồng v2"]
J2 --> V2["View phục vụ v2 (mới)"]
V2 -. "Chuyển đổi khi sẵn sàng" .-> APP["Truy vấn/dashboard/API"]
V1 --> APP
Cốt lõi là quan điểm "batch là trường hợp đặc biệt của luồng hữu hạn". Việc tính lại toàn bộ quá khứ (= vai trò của batch) được thay thế bằng job luồng phát lại (replay) log từ offset 0. Do đó chỉ tồn tại một bản logic xử lý, và gánh nặng đồng bộ hai codebase cho batch và stream biến mất.
B. Chiến lược tái xử lý (Reprocessing) và quản lý trạng thái
Trong Kappa, khi thay đổi logic hoặc sửa lỗi, dùng "tái xử lý blue-green". Trong khi job hiện tại (v1) đang phục vụ, chạy job đã sửa (v2) từ đầu log để lấp đầy bảng đầu ra mới. Khi v2 đuổi kịp (catch-up) thời điểm hiện tại (head), chuyển consumer sang v2 và loại bỏ v1 cùng bảng cũ. Tiền đề của phương thức này là thời gian lưu giữ log phải đủ để chứa toàn bộ lịch sử cần cho tái xử lý. Nếu lưu giữ vô hạn quá tốn kém, phân tầng sự kiện cũ sang object storage (tiered storage) hoặc kết hợp với snapshot định kỳ.
Tính chính xác phụ thuộc vào chức năng xử lý trạng thái và thời gian của bộ máy xử lý luồng. Exactly-once dựa trên checkpoint của Flink, cửa sổ và watermark dựa trên thời gian sự kiện, độ trễ cho phép (allowed lateness) cho dữ liệu đến muộn thay thế phần lớn tính đầy đủ của batch. Ví dụ, trong phát hiện bất thường thanh toán, giao dịch đến muộn 3 phút do trễ mạng cũng được tổng hợp vào đúng cửa sổ nếu watermark cho phép trễ 30 phút. Tuy nhiên, dữ liệu rất muộn hoặc backfill quy mô lớn vẫn phải xử lý bằng job tái xử lý, và điểm này quyết định độ khó vận hành của Kappa.
Thành bại của tái xử lý trong Kappa phụ thuộc vào việc thiết kế trước các yếu tố dưới đây. Mỗi mục không phải tùy chọn độc lập mà là biến liên động cùng quyết định thời gian lưu giữ, chi phí, thời gian khôi phục (RTO), nên phải cân bằng dựa trên SLA.
| Yếu tố | Vai trò | Lưu ý khi thiết kế |
|---|---|---|
| Thời gian lưu giữ log | Quyết định phạm vi quá khứ có thể tái xử lý | Càng dài khả năng tái hiện↑, chi phí lưu trữ·gánh nặng dữ liệu cá nhân↑ |
| Partition·mức song song | Quyết định thông lượng tái xử lý | Cân bằng tốc độ catch-up và chi phí tài nguyên |
| State backend | Lưu trạng thái cửa sổ·tổng hợp | Tinh chỉnh kích thước RocksDB v.v.·chu kỳ checkpoint |
| Snapshot/time travel | Phát lại từ thời điểm cụ thể | Kết hợp Lakehouse để giảm chi phí lưu giữ vô hạn |
| Sink lũy đẳng | Ngăn đầu ra trùng lặp | Hoàn thiện exactly-once bằng khóa lũy đẳng·giao dịch |
C. Ưu điểm và giới hạn
Ưu điểm của Kappa là sự đơn giản và nhất quán nhờ một mã, một hệ thống. Vì logic chỉ có một bản nên về căn bản không phát sinh bất nhất quy tắc giữa batch và stream, và thời gian thực cùng tái xử lý quá khứ đi qua cùng một đường mã nên lỗi tinh vi "cách tính giá trị thời gian thực và giá trị quá khứ khác nhau" biến mất. Tốc độ phát triển và triển khai nhanh, kết hợp tự nhiên với microservice hướng sự kiện và nền tảng streaming.
Giới hạn là gánh nặng chính xác và tái xử lý tập trung vào bộ máy luồng và thiết kế log. Bảo đảm chính xác một lần, thời gian sự kiện và watermark, vận hành state backend khó hiểu và khó vận hành hơn batch, còn backfill quy mô lớn gây tải tức thời cho cụm vận hành. Khi lưu giữ lịch sử gần như vô hạn quá tốn kém hoặc bị cấm theo quy định, chỉ Kappa thuần túy khó gánh "tính lại toàn bộ dữ liệu rất cũ", rốt cuộc cần bổ sung mang tính batch như Lakehouse hay snapshot.
4. So sánh và trường hợp (nguyên nhân khác biệt và hàm ý thực tiễn)
Sự khác biệt giữa hai kiến trúc không chỉ ở số tầng mà bắt nguồn từ sự đánh đổi giữa "bảo đảm tính chính xác ở đâu" và "đơn giản hóa mã và vận hành đến mức nào". Lambda đặt đường dẫn sự thật độc lập là batch để chữa lành căn bản sai số của stream, nhưng phải duy trì hai bản logic. Kappa gộp logic thành một để đơn giản hóa bảo trì, nhưng phải gánh tính chính xác và gánh nặng tái xử lý quy mô lớn bằng bộ máy luồng và thiết kế lưu giữ log.
| Phân loại | Kiến trúc Lambda | Kiến trúc Kappa |
|---|---|---|
| Đường xử lý | Batch + tốc độ (2 đường) | Luồng duy nhất (1 đường) |
| Codebase | 2 bản batch·stream (nhân đôi logic) | 1 bản |
| Cách tái xử lý | Tính lại toàn bộ bằng job batch | Phát lại luồng từ offset log |
| Bảo đảm chính xác | Batch tính lại toàn bộ định kỳ | Exactly-once·thời gian sự kiện·watermark của stream |
| Độ trễ (latency) | Batch từ phút~giờ, tốc độ theo giây | Đơn vị giây (tải tăng khi tái xử lý) |
| Độ phức tạp vận hành | Đồng bộ hai hệ thống·logic hợp nhất phức tạp | Gánh nặng lưu giữ log·quản lý trạng thái luồng |
| Tình huống phù hợp | Chính xác tới hạn như quyết toán + song hành thời gian thực | Streaming hướng sự kiện·logic thay đổi thường xuyên |
Hàm ý thực tiễn như sau. Thứ nhất, trong lĩnh vực mà sai số dẫn tới trách nhiệm tài chính, pháp lý như quyết toán, báo cáo quy định, đường batch của Lambda cung cấp "bản chuẩn có thể kiểm toán" nên an toàn. Ví dụ, quyết toán cước viễn thông lấy batch view làm bản chuẩn và chỉ hiển thị real-time view để tham khảo. Thứ hai, trong lĩnh vực logic thay đổi thường xuyên và sự kiện thực chất là luồng vô hạn (gợi ý, phát hiện bất thường, telemetry IoT), Kappa có lợi về tốc độ phát triển và triển khai. Netflix, LinkedIn v.v. đã công bố trường hợp xử lý hàng trăm nghìn TPS bằng pipeline kiểu Kappa lấy log Kafka làm trung tâm.
Thứ ba, đa số hệ thống thực tế là dạng lai. Tạo real-time view bằng bộ máy luồng, nhưng nạp log vào Data Lakehouse (ví dụ Delta, Iceberg, Hudi) để khi cần thì thực hiện backfill quy mô lớn và kiểm chứng nhất quán bằng batch. Tức là "Kappa lý thuyết + batch lưới an toàn", có rủi ro vận hành thấp hơn dạng thuần túy.
Ví dụ so sánh cụ thể, hãy xét telemetry cảm biến thiết bị trong nhà máy thông minh (hàng trăm nghìn điểm mỗi giây). Nếu đi theo Lambda thuần túy, cảnh báo bất thường thời gian thực do tầng tốc độ đảm nhận, báo cáo hiệu suất thiết bị tổng thể (OEE) hằng ngày do tầng batch đảm nhận, nhưng mỗi khi công thức OEE được sửa đổi phải sửa mã của cả hai tầng. Nếu đi theo Kappa, khi sửa công thức có thể phát lại job luồng đã sửa từ đầu log để tính lại nhất quán cả OEE quá khứ, nên bảo trì đơn giản hơn, nhưng phải chịu chi phí lưu giữ log nguồn nhiều tháng và tải cụm tăng vọt khi tái xử lý. Bên nào đúng được quyết định bởi tích các biến nghiệp vụ "tần suất thay đổi công thức × yêu cầu tái hiện lịch sử × hạn mức chi phí lưu giữ", và việc trình bày logic phán đoán này là điểm khác biệt cốt lõi của bài thi Kỹ sư chuyên nghiệp.
5. Chuyên sâu: xu hướng chuẩn hóa streaming và động thái mới nhất
Xu hướng gần đây đang hội tụ về "hợp nhất batch và stream (Unified Batch/Stream)". Apache Flink cung cấp thực thi hợp nhất xử lý dữ liệu có biên (bounded) và không biên (unbounded) bằng cùng một API, còn Apache Beam trừu tượng hóa batch và stream thành một mô hình lập trình duy nhất, chỉ cần thay runner. Điều này hỗ trợ ý tưởng của Kappa (một logic) ở mức ngôn ngữ và bộ máy.
Xu hướng thứ hai là kết hợp với định dạng bảng Lakehouse. Khi Iceberg, Delta Lake, Hudi cung cấp ACID, time travel và đọc tăng dần, log (Kafka) – xử lý luồng (Flink/Spark) – bảng (Lakehouse) được nối thành một pipeline. Chức năng time travel đơn giản hóa tái xử lý của Kappa thành "phát lại từ snapshot cụ thể" và giảm bớt vấn đề chi phí lưu giữ log vô hạn. Vì vậy ranh giới giữa Lambda/Kappa thuần túy mờ dần, và hình thái "streaming lakehouse" đang nổi lên.
Xu hướng thứ ba là chuẩn hóa ngữ nghĩa chính xác một lần (exactly-once) và xử lý thời gian sự kiện. Khi giao dịch Kafka, sink commit hai pha của Flink, xử lý dữ liệu trễ dựa trên watermark trở nên trưởng thành, tiền đề trước đây "chỉ batch mới chính xác" đã yếu đi. Tuy nhiên, "chính xác một lần" chỉ thành lập trên tiền đề lưu trạng thái và tính lũy đẳng (idempotency) của sink, nên khi liên kết hệ thống bên ngoài, thiết kế khóa lũy đẳng vẫn là bắt buộc.
Các hướng ra đề dự kiến có khả năng cao gồm: ▲Trình bày sơ đồ cấu trúc và khác biệt giữa Lambda và Kappa ▲Vai trò của tầng batch/tốc độ/phục vụ và nguyên lý nhất quán ▲Chiến lược tái xử lý của Kappa và vấn đề lưu giữ log ▲Liên kết với Lakehouse, Flink ▲Nêu căn cứ chọn kiến trúc phù hợp nghiệp vụ cụ thể (quyết toán vs phát hiện bất thường). Chiến lược cấu trúc bài làm là triển khai theo thứ tự "sơ đồ khái niệm → vai trò từng tầng → nguyên lý nhất quán → bảng so sánh → logic lựa chọn dựa trên đặc tính nghiệp vụ → xu hướng hợp nhất mới nhất" để đáp ứng yêu cầu chuyên sâu và tự luận.
6. Lưu ý và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)
- Gắn yêu cầu chính xác với lựa chọn kiến trúc: Lĩnh vực quyết toán, công bố thông tin nơi sai số dẫn tới trách nhiệm tài chính, quy định thì Lambda có bản chuẩn batch (hoặc dạng lai có batch lưới an toàn) là phù hợp, còn gợi ý, phát hiện bất thường ưu tiên tính tức thời và sự linh hoạt logic thì Kappa có lợi. Phải phân biệt rõ khi thiết kế rằng "thời gian thực không đồng nghĩa với chính xác".
- Thiết kế trước chiến lược tái xử lý và backfill: Thay đổi logic và sửa lỗi là tất yếu, nên phải định nghĩa ngay từ đầu kiến trúc việc lưu giữ bất biến log nguồn, thời gian lưu giữ, quy trình phát lại (replay), chuyển đổi blue-green. Chi phí lưu giữ log được tối ưu bằng lưu trữ phân tầng, snapshot, time travel của Lakehouse.
- Đánh đổi giữa độ phức tạp vận hành và năng lực tổ chức: Với Lambda, chi phí là đồng bộ hai codebase, logic hợp nhất, kiểm chứng trùng lặp; với Kappa, độ khó là vận hành trạng thái luồng, watermark, bảo đảm chính xác một lần. Cần cân nhắc mức trưởng thành streaming, năng lực SRE, hệ thống giám sát của đội để chọn hình thái thực tế (thuần túy vs lai).
- Liên kết với quản trị dữ liệu và dòng dõi: Cấu trúc bản gốc bất biến – view dẫn xuất gắn trực tiếp với dòng dõi, kiểm toán và ứng phó yêu cầu xóa dữ liệu cá nhân (GDPR, Luật Bảo vệ Thông tin Cá nhân của Hàn Quốc). Nếu dữ liệu cá nhân được lưu vô hạn trong log sẽ xung đột với nghĩa vụ xóa, nên cần thiết kế đồng thời chiến lược bí danh hóa, token hóa, thời gian lưu giữ, crypto-shredding (hủy khóa).
- Quản lý định lượng chi phí và hiệu năng: Cần tinh chỉnh định lượng chu kỳ tính lại batch, mức song song của luồng, partition và lưu giữ log, kích thước state backend (RocksDB v.v.) phù hợp với SLA (độ trễ, độ chính xác) và ngân sách. Lưu giữ vô hạn tùy tiện và chu kỳ batch quá dày làm chi phí tăng vọt.
- Triển vọng: Với sự kết hợp giữa xử lý hợp nhất của Flink, Beam và định dạng bảng Lakehouse, sự phân biệt Lambda/Kappa thuần túy sẽ dần bị hấp thụ vào hình thái hợp nhất "streaming lakehouse". Tuy nhiên, trong nghiệp vụ chính xác tới hạn, lưới an toàn kiểm chứng batch sẽ còn tồn tại lâu, vì vậy Kỹ sư chuyên nghiệp cần năng lực thiết kế sự dung hòa thực dụng phù hợp đặc tính nghiệp vụ thay vì cấy nguyên kiến trúc lý tưởng.
Tài liệu tham khảo
- Nathan Marz, "How to beat the CAP theorem" / Big Data (Lambda Architecture), http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
- Jay Kreps, "Questioning the Lambda Architecture" (Kappa), https://www.oreilly.com/radar/questioning-the-lambda-architecture/
- Apache Flink, Unified Batch and Stream Processing, https://flink.apache.org/
- Apache Beam Programming Model, https://beam.apache.org/documentation/basics/
- Apache Iceberg / Delta Lake table format, https://iceberg.apache.org/ , https://delta.io/
Tóm tắt một câu: Lambda là kiến trúc hợp nhất hai đường batch (chính xác) và tốc độ (tức thời) tại tầng phục vụ để đồng thời đạt tính chính xác và tính thời gian thực, còn Kappa là kiến trúc hợp nhất xử lý thời gian thực và tái xử lý bằng một pipeline luồng duy nhất trên log bất biến để đơn giản hóa mã và vận hành; gần đây cả hai đang hội tụ về 'streaming lakehouse' kết hợp Flink và Lakehouse.