Một pipeline xử lý tài liệu là chuỗi các công đoạn tự động biến tài liệu thành thông tin dùng được. Tùy loại tài liệu, chuỗi đó có thể gồm phát hiện tệp, xử lý PDF, tiền xử lý ảnh, nhận dạng ký tự quang học (OCR), trích xuất văn bản, phân loại, lưu trữ và lập chỉ mục. Hệ thống production còn cần các thành phần phụ trợ như truyền thông điệp, giám sát và ghi log để pipeline luôn ổn định.

Không có ứng dụng đơn lẻ nào làm tốt mọi công đoạn. Một hệ thống xử lý tài liệu sẵn sàng cho production kết hợp nhiều công cụ mã nguồn mở chuyên biệt, mỗi công cụ giải quyết một vấn đề riêng. Cách tiếp cận mô-đun này giúp pipeline dễ bảo trì, dễ mở rộng và dễ thích ứng khi yêu cầu thay đổi.

Bài viết điểm qua các công cụ mã nguồn mở phổ biến để xử lý tài liệu trên Linux. Với từng nhóm, bạn sẽ biết công cụ làm gì, nằm ở đâu trong luồng xử lý, điểm mạnh và đánh đổi, cùng những điều cần cân nhắc trước khi chọn. Bài cũng có thêm một số lựa chọn thương mại tùy chọn cho ai muốn dùng giải pháp trả phí hoặc so sánh các hướng khác nhau.

Các nhóm công cụ mã nguồn mở trên Linux

Một pipeline xử lý tài liệu được ghép từ nhiều thành phần, mỗi thành phần đảm nhận một nhiệm vụ cụ thể. Có công cụ phát hiện tệp mới, có công cụ xử lý PDF, trích xuất văn bản, lưu trữ tài liệu hoặc theo dõi sức khỏe hệ thống. Ghép lại, chúng tạo thành một giải pháp xử lý tài liệu hoàn chỉnh.

Các nhóm công cụ dưới đây ánh xạ những trách nhiệm thường gặp sang công cụ mã nguồn mở được dùng rộng rãi. Hãy xem đây là bản đồ cho phần còn lại của bài; từng nhóm sẽ được xem xét ở các mục sau.

Các nhóm này chỉ là ví dụ, không phải yêu cầu bắt buộc. Phần lớn hệ thống xử lý tài liệu chỉ dùng những thành phần mình cần, và nhiều hệ thống có các lựa chọn thay thế tương đương. Điều quan trọng là hiểu trách nhiệm của từng nhóm trước khi chọn công cụ hiện thực nó.

Các lựa chọn thương mại cho xử lý tài liệu (tùy chọn)

Công cụ mã nguồn mở đủ dùng cho nhiều pipeline xử lý tài liệu. Tuy vậy, một số tổ chức có thể thích dịch vụ được quản lý hoặc nền tảng thương mại hơn, tùy yêu cầu vận hành, tuân thủ hoặc kinh doanh.

Tư vấn AI và triển khai tùy chỉnh

AI tài liệu trên đám mây

Xử lý tài liệu thông minh cấp doanh nghiệp

Tự động hóa quy trình

Các nền tảng này thường kết hợp OCR với những khả năng như phân loại tài liệu, nhận dạng chữ viết tay, trích xuất bảng, trích xuất cặp khóa–giá trị và tự động hóa quy trình.

Chúng tôi khuyến nghị bạn đánh giá chúng dựa trên độ chính xác, loại tài liệu được hỗ trợ, mô hình triển khai, khả năng tích hợp, giá, bảo mật và yêu cầu về nơi lưu trữ dữ liệu.

Nếu bạn thích công cụ miễn phí và mã nguồn mở thì có rất nhiều lựa chọn.

Giờ ta bắt đầu với phát hiện tệp, công đoạn tài liệu lần đầu bước vào pipeline.

1. Phát hiện tệp mới

Mọi pipeline xử lý tài liệu đều bắt đầu bằng việc phát hiện công việc mới. Trước khi một tài liệu có thể được kiểm tra, xử lý hay lập chỉ mục, hệ thống phải biết nó tồn tại.

Trên Linux, việc này thường được làm bằng cách theo dõi tệp hoặc thư mục để bắt sự kiện của hệ thống tệp. Khi tài liệu đến hoặc thay đổi, pipeline có thể bắt đầu xử lý ngay thay vì dựa vào việc thăm dò định kỳ.

Phát hiện tệp chỉ có một trách nhiệm: phát hiện công việc mới và chuyển sang bước kế tiếp. Giữ công đoạn này tập trung giúp pipeline dễ bảo trì, dễ kiểm thử và dễ mở rộng.

Các công cụ mã nguồn mở phổ biến gồm inotify, systemd.path và Watchdog. Chúng giải quyết cùng một vấn đề nhưng phù hợp với những luồng công việc khác nhau.

1.1. inotify

Tóm tắt

inotify (inotify) là một hệ thống con của nhân Linux dùng để theo dõi sự kiện của hệ thống tệp. Nó nhẹ, hiệu quả và thường là cách đơn giản nhất để kích hoạt pipeline xử lý tài liệu khi tệp được tạo hoặc sửa đổi.

Điểm chính

  • Tích hợp sẵn trong nhân Linux.
  • Theo dõi từng tệp và thư mục.
  • Phát hiện các sự kiện như tạo, sửa, xóa và đổi tên tệp.
  • Hoạt động theo hướng sự kiện, tránh chi phí của việc thăm dò định kỳ.
  • Được nhiều ngôn ngữ lập trình và công cụ dòng lệnh hỗ trợ.

Cần biết

inotify (inotify) là một API của nhân, không phải tiện ích dòng lệnh. Phần lớn người dùng tương tác với nó qua các công cụ như inotifywait thuộc dự án inotify-tools, hoặc qua thư viện ngôn ngữ phơi ra cùng giao diện đó.

Tài nguyên:

1.2. systemd.path

Tóm tắt

systemd.path (systemd.path) là một unit đường dẫn của systemd, theo dõi tệp và thư mục rồi khởi động dịch vụ tương ứng khi các điều kiện đã cấu hình được thỏa. Nó phù hợp với pipeline xử lý tài liệu vốn đã dùng systemd để quản lý dịch vụ.

Điểm chính

  • Thuộc hệ thống khởi tạo systemd (systemd).
  • Theo dõi tệp và thư mục bằng các unit đường dẫn.
  • Khởi động unit systemd.service (systemd.service) tương ứng khi các điều kiện đã cấu hình được thỏa.
  • Bên trong dùng API inotify của Linux để theo dõi thay đổi hệ thống tệp.
  • Rất phù hợp cho tự động hóa nhẹ, hướng sự kiện trên Linux.

Cần biết

Một unit systemd.path không bao giờ tự xử lý tài liệu. Trách nhiệm duy nhất của nó là theo dõi hệ thống tệp và kích hoạt một dịch vụ. Tách phát hiện khỏi xử lý giúp pipeline dễ bảo trì và dễ gỡ lỗi hơn.

Tài nguyên:

1.3. Watchdog

Tóm tắt

Watchdog là thư viện Python để theo dõi sự kiện của hệ thống tệp. API đa nền tảng của nó khiến nó thành lựa chọn tốt cho pipeline xử lý tài liệu viết bằng Python cần phản ứng với thay đổi tệp.

Điểm chính

  • Được thiết kế cho ứng dụng Python.
  • Theo dõi tệp và thư mục để bắt sự kiện của hệ thống tệp.
  • Dùng API theo dõi tệp gốc của hệ điều hành khi có sẵn.
  • Quay về cơ chế thăm dò trên nền tảng không có theo dõi gốc.
  • Hỗ trợ Linux, Windows, macOS và BSD.

Điều thú vị

Trên Linux, Watchdog mặc định dùng API inotify. Nhờ vậy ứng dụng Python có thể theo dõi sự kiện hệ thống tệp mà không phải tương tác trực tiếp với API của nhân.

Tài nguyên:

2. Chuẩn bị và xử lý PDF

Phần lớn pipeline xử lý tài liệu nhận tệp PDF, nhưng không phải PDF nào cũng cần cách xử lý giống nhau. Có tệp đã chứa văn bản tìm kiếm được. Có tệp hoàn toàn là ảnh quét. Có tệp bị mã hóa, hỏng, hoặc chứa nhiều tài liệu cần tách ra trước khi xử lý.

Xử lý PDF chuẩn bị tài liệu cho bước kế tiếp. Tùy khối lượng công việc, bước này có thể gồm kiểm tra thuộc tính tài liệu, xác thực tính toàn vẹn của tệp, tách hoặc gộp trang, sửa PDF hỏng, hoặc chuyển trang thành ảnh để OCR.

Các công cụ mã nguồn mở phổ biến gồm Poppler, qpdf và PDFtk Server. Mỗi công cụ giải quyết một vấn đề khác nhau và thường bổ trợ chứ không thay thế nhau.

2.1. Poppler

Tóm tắt

Poppler là thư viện kết xuất PDF mã nguồn mở, đồng thời cung cấp tiện ích dòng lệnh để kiểm tra, chuyển đổi và trích xuất thông tin từ tài liệu PDF. Nó được dùng rộng rãi trong pipeline xử lý tài liệu trên Linux.

Điểm chính

  • Dựa trên bộ kết xuất Xpdf.
  • Cung cấp các tiện ích như pdfinfo (pdfinfo), pdftotext (pdftotext), pdftoppm (pdftoppm) và pdftocairo (pdftocairo).
  • Trích xuất siêu dữ liệu và văn bản nhúng trong tài liệu.
  • Chuyển trang PDF thành ảnh cho các bước xử lý sau, kể cả OCR.
  • Có sẵn trên hầu hết bản phân phối Linux qua gói poppler-utils (poppler-utils).

Cần biết

Nếu PDF đã có lớp văn bản tìm kiếm được, pdftotext thường trích xuất được văn bản mà không cần OCR. Chạy OCR trên những tài liệu này tốn thêm xử lý không cần thiết và có thể làm giảm độ chính xác của văn bản.

Tài nguyên:

2.2. qpdf

Tóm tắt

qpdf là công cụ dòng lệnh và thư viện mã nguồn mở để kiểm tra và biến đổi tệp PDF. Nó làm việc với cấu trúc bên trong của PDF, nên rất phù hợp để tách, gộp, mã hóa, giải mã, tuyến tính hóa và phục hồi tài liệu PDF trước khi xử lý tiếp.

Điểm chính

  • Làm việc với cấu trúc bên trong của tệp PDF thay vì nội dung hiển thị.
  • Tách, gộp và xoay trang PDF.
  • Có thể phục hồi nhiều lỗi cấu trúc trong tệp PDF hỏng.
  • Hỗ trợ mã hóa và giải mã khi có mật khẩu hoặc quyền cần thiết.
  • Có thể tuyến tính hóa PDF để tải nhanh hơn trên web.

Điều thú vị

Poppler và qpdf bổ trợ nhau. Poppler tập trung kết xuất trang và trích xuất thông tin, còn qpdf tập trung thao tác cấu trúc PDF mà không kết xuất nội dung trang.

Tài nguyên:

2.3. PDFtk Server

Tóm tắt

PDFtk Server là công cụ dòng lệnh mã nguồn mở để thao tác tài liệu PDF. Nó phù hợp cho việc lắp ghép tài liệu, thao tác trang, xử lý biểu mẫu PDF và các luồng tự động hóa.

Điểm chính

  • Gộp, tách và sắp xếp lại các trang PDF.
  • Xoay, trộn và trích xuất trang.
  • Điền biểu mẫu PDF bằng dữ liệu FDF hoặc XFDF.
  • Áp nền và con dấu.
  • Mã hóa và giải mã tài liệu PDF khi quyền cho phép.

Cần biết

PDFtk Server và qpdf trùng nhau ở vài điểm, nhưng PDFtk Server vẫn là lựa chọn phổ biến cho xử lý biểu mẫu PDF và những luồng tự động hóa lâu đời. Nhiều hệ thống Linux hiện hữu vẫn dựa vào giao diện dòng lệnh ổn định của nó.

Tài nguyên:

3. Tiền xử lý ảnh

Không phải tài liệu quét nào cũng sẵn sàng cho OCR. Trang bị nghiêng, nhiễu nền, độ tương phản kém và chất lượng ảnh thấp đều có thể làm giảm độ chính xác nhận dạng văn bản.

Tiền xử lý ảnh cải thiện chất lượng ảnh trước OCR khi cần. Tùy tài liệu, bước này có thể làm thẳng trang, giảm nhiễu, cắt viền thừa, chỉnh độ tương phản hoặc chuyển ảnh sang đen trắng. Đầu vào tốt hơn thường cho kết quả OCR tốt hơn.

Các công cụ mã nguồn mở phổ biến gồm OpenCV và ImageMagick. Cả hai đều xử lý ảnh nhưng giải quyết vấn đề khác nhau và thường bổ trợ nhau.

3.1. OpenCV

Tóm tắt

OpenCV là thư viện thị giác máy tính và xử lý ảnh mã nguồn mở. Trong pipeline xử lý tài liệu, nó thường được dùng để cải thiện tài liệu quét trước OCR.

Điểm chính

  • Được thiết kế cho thị giác máy tính và xử lý ảnh.
  • Cung cấp các thành phần cơ bản cho thao tác như làm thẳng, khử nhiễu, phân ngưỡng, phát hiện biên và biến đổi hình học.
  • Có thể cải thiện độ chính xác OCR bằng cách nâng chất lượng ảnh trước khi nhận dạng văn bản.
  • Hỗ trợ nhiều ngôn ngữ lập trình, gồm C++, Python và Java.
  • Phù hợp cho cả ứng dụng thời gian thực lẫn xử lý tài liệu theo lô.

Cần biết

OpenCV là thư viện thị giác máy tính đa dụng, không phải engine OCR. Nó chuẩn bị ảnh cho OCR nhưng không trích xuất văn bản từ ảnh.

Tài nguyên:

3.2. ImageMagick

Tóm tắt

ImageMagick là bộ công cụ và thư viện mã nguồn mở để tạo, chỉnh sửa, chuyển đổi và xử lý ảnh. Trong pipeline xử lý tài liệu, nó thường được dùng để chuẩn bị những lô lớn ảnh quét trước OCR.

Điểm chính

  • Hỗ trợ hàng trăm định dạng ảnh.
  • Xử lý ảnh hiệu quả từ dòng lệnh.
  • Thay đổi kích thước, cắt, xoay, cắt viền và chuyển đổi ảnh.
  • Chỉnh độ sáng, độ tương phản và áp phân ngưỡng.
  • Dễ tích hợp vào script shell và luồng tự động hóa.

Điều thú vị

ImageMagick và OpenCV giải quyết vấn đề khác nhau. ImageMagick tập trung thao tác ảnh, còn OpenCV tập trung thị giác máy tính. Nhiều pipeline xử lý tài liệu dùng cả hai công cụ cùng lúc.

Tài nguyên:

4. Nhận dạng ký tự quang học (OCR)

Không phải tài liệu nào cũng cần OCR. Nếu PDF đã có lớp văn bản tìm kiếm được, thường có thể trích xuất văn bản trực tiếp. OCR chủ yếu dùng cho tài liệu quét và PDF dạng ảnh, nơi văn bản tồn tại dưới dạng hình ảnh chứ không phải ký tự máy đọc được.

OCR nhận dạng văn bản trong ảnh và chuyển thành văn bản máy đọc được. Chất lượng kết quả phụ thuộc phần lớn vào chất lượng đầu vào, nên tiền xử lý ảnh thường được làm trước.

Các công cụ mã nguồn mở phổ biến gồm Tesseract OCR và OCRmyPDF. Dù liên quan chặt chẽ, chúng giải quyết vấn đề khác nhau. Tesseract thực hiện nhận dạng văn bản, còn OCRmyPDF tự động hóa OCR cho tài liệu PDF bằng cách thêm lớp văn bản tìm kiếm được mà vẫn giữ nguyên hình thức gốc của PDF.

4.1. Tesseract OCR

Tóm tắt

Tesseract OCR là engine OCR mã nguồn mở nhận dạng văn bản trong tài liệu quét và ảnh. Đây là một trong những engine OCR được dùng rộng rãi nhất và là nền tảng của nhiều pipeline xử lý tài liệu.

Điểm chính

  • Thực hiện nhận dạng ký tự quang học trên tệp ảnh.
  • Mặc định dùng mô hình mạng nơ-ron dựa trên LSTM từ Tesseract 4.
  • Hỗ trợ hơn 100 ngôn ngữ và hệ chữ qua các tệp dữ liệu huấn luyện.
  • Có sẵn dưới dạng công cụ dòng lệnh và thư viện C++.
  • Thường được tích hợp vào các luồng xử lý tài liệu lớn hơn.

Bạn có biết?

Tesseract nhận dạng văn bản nhưng không tự động hóa toàn bộ luồng PDF. Các công cụ như OCRmyPDF mặc định dùng Tesseract để thực hiện OCR, giữ nguyên hình thức gốc của trang PDF và thêm lớp văn bản tìm kiếm được.

Tài nguyên:

4.2. OCRmyPDF

Tóm tắt

OCRmyPDF là công cụ dòng lệnh mã nguồn mở thêm lớp văn bản tìm kiếm được, không nhìn thấy, vào tài liệu PDF quét mà vẫn giữ nguyên hình thức trang gốc. Nó tự động hóa OCR cho các luồng dựa trên PDF.

Điểm chính

  • Thêm lớp văn bản tìm kiếm được vào PDF quét.
  • Mặc định dùng Tesseract OCR để nhận dạng văn bản.
  • Giữ nguyên hình thức trang gốc.
  • Có thể bỏ qua những trang đã chứa văn bản tìm kiếm được.
  • Hỗ trợ xoay trang, tối ưu ảnh và tùy chọn xuất PDF/A.

Cần biết

OCRmyPDF không phải engine OCR. Nó tự động hóa OCR cho tài liệu PDF bằng cách phối hợp Tesseract với xử lý PDF và tối ưu ảnh. Nhờ vậy bạn có thể tìm kiếm và sao chép văn bản mà không thay đổi hình thức hiển thị của tài liệu gốc.

Tài nguyên:

5. Phân loại tài liệu

Trích xuất văn bản chỉ là một phần công việc. Pipeline xử lý tài liệu còn cần hiểu tài liệu là gì để quyết định bước tiếp theo.

Phân loại tài liệu gán tài liệu vào các nhóm định trước như hóa đơn, biên lai, hợp đồng, đơn mua hàng hoặc sơ yếu lý lịch. Kết quả quyết định cách tài liệu đi qua phần còn lại của pipeline, gồm trích xuất dữ liệu, kiểm tra, lưu trữ và các luồng phê duyệt.

Các công cụ mã nguồn mở phổ biến gồm spaCy và Hugging Face Transformers. Cả hai đều cung cấp khả năng phân loại văn bản có thể dùng để phân loại tài liệu sau khi đã trích xuất văn bản.

spaCy là thư viện NLP mạnh mẽ cấp công nghiệp, thiết kế cho ứng dụng production, còn Hugging Face Transformers cung cấp quyền truy cập các mô hình transformer đã huấn luyện trước cho những tác vụ hiểu ngôn ngữ và phân loại nâng cao.

5.1. spaCy

Tóm tắt

spaCy là thư viện xử lý ngôn ngữ tự nhiên (NLP) mã nguồn mở, mạnh mẽ cấp công nghiệp. Trong pipeline xử lý tài liệu, nó thường được dùng để phân loại văn bản, trích xuất thực thể và xử lý văn bản sau OCR.

Điểm chính

  • Được thiết kế cho ứng dụng NLP cấp production.
  • Hỗ trợ phân loại văn bản, nhận dạng thực thể có tên, tách từ và phân tích phụ thuộc.
  • Hỗ trợ huấn luyện pipeline NLP tùy chỉnh.
  • Được tối ưu cho hiệu năng và xử lý hiệu quả.
  • Có thể tích hợp mô hình transformer qua tiện ích mở rộng spacy-transformers (spacy-transformers).

Bạn có biết?

spaCy và Hugging Face Transformers thường được dùng cùng nhau thay vì riêng rẽ. Tiện ích mở rộng spacy-transformers (spacy-transformers) cho phép pipeline spaCy dùng mô hình transformer, kết hợp pipeline NLP hướng production của spaCy với các mô hình ngôn ngữ hiện đại.

Tài nguyên:

5.2. Hugging Face Transformers

Tóm tắt

Hugging Face Transformers là thư viện mã nguồn mở cung cấp quyền truy cập các mô hình transformer đã huấn luyện trước. Trong pipeline xử lý tài liệu, nó thường được dùng cho các tác vụ NLP nâng cao như phân loại văn bản, nhận dạng thực thể có tên, tóm tắt và trả lời câu hỏi.

Điểm chính

  • Cung cấp quyền truy cập các mô hình transformer đã huấn luyện trước cho NLP và các tác vụ AI khác.
  • Hỗ trợ phân loại văn bản, nhận dạng thực thể có tên, tóm tắt, trả lời câu hỏi và nhiều tác vụ NLP khác.
  • Làm việc với PyTorch, TensorFlow và JAX.
  • Hỗ trợ tinh chỉnh mô hình cho các tác vụ xử lý tài liệu chuyên ngành.
  • Có thể tích hợp vào pipeline spaCy qua tiện ích mở rộng spacy-transformers (spacy-transformers).

Điều thú vị

Nhiều hệ thống NLP production kết hợp spaCy và Hugging Face Transformers. spaCy cung cấp pipeline NLP hiệu quả, còn mô hình transformer được dùng cho những tác vụ cần hiểu ngôn ngữ sâu hơn.

Tài nguyên:

6. Xử lý tác vụ phân tán

Xử lý từng tài liệu một phù hợp với khối lượng nhỏ, nhưng hệ thống production thường phải xử lý hàng trăm hoặc hàng nghìn tài liệu đồng thời. Chạy tuần tự mọi bước có thể nhanh chóng thành nút thắt cổ chai.

Xử lý tác vụ phân tán chia khối lượng công việc thành các tác vụ độc lập để worker thực thi đồng thời. Thay vì chờ một tài liệu xong mới bắt đầu tài liệu kế tiếp, pipeline có thể xử lý nhiều tài liệu cùng lúc, tăng thông lượng và khả năng mở rộng.

Công cụ mã nguồn mở phổ biến cho bước này là Celery. Nó phân phối công việc bằng cách gửi tác vụ qua một message broker, cho phép nhiều worker xử lý tài liệu khi nhu cầu tăng.

6.1. Celery

Tóm tắt

Celery là framework hàng đợi tác vụ phân tán mã nguồn mở, phân phối và thực thi tác vụ bất đồng bộ trên một hoặc nhiều tiến trình worker. Trong pipeline xử lý tài liệu, nó giúp mở rộng xử lý khi lượng tài liệu tăng.

Điểm chính

  • Phân phối và thực thi tác vụ bất đồng bộ.
  • Dùng message broker như RabbitMQ hoặc Redis để chuyển tác vụ tới worker.
  • Hỗ trợ tự động thử lại tác vụ thất bại.
  • Hỗ trợ lập lịch tác vụ, định tuyến và backend kết quả tùy chọn.
  • Mở rộng từ một worker lên nhiều máy.

Bạn có biết?

Celery không tự xử lý tài liệu. Nhiệm vụ của nó là điều phối công việc. Ví dụ, một worker có thể làm OCR, worker khác phân loại tài liệu, worker thứ ba lưu kết quả. Cách tách biệt này giúp pipeline dễ mở rộng và dễ bảo trì hơn.

Tài nguyên:

7. Điều phối luồng công việc

Khi pipeline xử lý tài liệu lớn dần, việc điều phối từng tác vụ riêng lẻ không còn đủ. Có công việc phụ thuộc vào các bước trước hoàn tất, có công việc cần chạy theo lịch hoặc theo một trình tự định trước.

Điều phối luồng công việc quản lý các phụ thuộc này bằng cách lập lịch, điều phối và giám sát luồng nhiều bước. Nó quyết định khi nào tác vụ chạy, theo thứ tự nào và xử lý thất bại ra sao, giúp pipeline xử lý tài liệu phức tạp dễ vận hành và bảo trì hơn.

Công cụ mã nguồn mở phổ biến cho bước này là Apache Airflow. Nó điều phối luồng công việc bằng cách quản lý phụ thuộc giữa các tác vụ, lập lịch thực thi và giám sát tiến độ.

7.1. Apache Airflow

Tóm tắt

Apache Airflow là nền tảng điều phối luồng công việc mã nguồn mở. Trong pipeline xử lý tài liệu, nó lập lịch, điều phối và giám sát các luồng nhiều bước.

Điểm chính

  • Viết luồng công việc bằng Python dưới dạng đồ thị có hướng không chu trình (DAG).
  • Lập lịch và điều phối tác vụ với phụ thuộc đã định.
  • Cung cấp giao diện web để giám sát thực thi luồng công việc, trạng thái tác vụ và log.
  • Hỗ trợ lập lịch, thử lại và quản lý phụ thuộc.
  • Hỗ trợ nhiều executor, gồm CeleryExecutor cho thực thi tác vụ phân tán.

Điều thú vị

Apache Airflow và Celery thường được dùng cùng nhau. Airflow điều phối luồng công việc bằng cách quyết định khi nào tác vụ chạy và theo thứ tự nào, còn Celery thực thi các tác vụ đó trên các tiến trình worker.

Tài nguyên:

8. Truyền thông điệp

Khi pipeline xử lý tài liệu lớn dần, các thành phần cần một cách đáng tin cậy để trao đổi công việc. Để một dịch vụ gọi trực tiếp dịch vụ khác tạo ra sự gắn kết chặt và khiến hệ thống khó mở rộng hơn.

Hệ thống truyền thông điệp giải quyết vấn đề này bằng cách chuyển tác vụ qua message broker hoặc công nghệ nhắn tin tương tự. Thay vì gửi công việc trực tiếp tới dịch vụ khác, một thành phần đặt thông điệp vào hàng đợi hoặc luồng, nơi một hoặc nhiều worker có thể xử lý độc lập.

Các công cụ mã nguồn mở phổ biến gồm RabbitMQ và Redis. RabbitMQ là message broker chuyên dụng, còn Redis là kho dữ liệu trong bộ nhớ cũng cung cấp khả năng nhắn tin. Cả hai đều được dùng rộng rãi với các framework xử lý tác vụ phân tán như Celery.

8.1. RabbitMQ

Tóm tắt

RabbitMQ là message broker mã nguồn mở cho phép ứng dụng trao đổi thông điệp bất đồng bộ. Trong pipeline xử lý tài liệu, nó thường chuyển tác vụ từ producer tới tiến trình worker.

Điểm chính

  • Định tuyến thông điệp từ producer tới hàng đợi để consumer xử lý.
  • Hỗ trợ hàng đợi bền vững, xác nhận, định tuyến và dead-lettering.
  • Tích hợp với các framework xử lý tác vụ phân tán như Celery.
  • Hỗ trợ nhiều giao thức nhắn tin qua plugin.
  • Được dùng rộng rãi trong hệ thống production cho nhắn tin bất đồng bộ.

Bạn có biết?

RabbitMQ không thực thi tác vụ. Nó chuyển thông điệp tới hàng đợi, nơi các tiến trình worker như Celery nhận và thực thi. Tách việc chuyển thông điệp khỏi việc thực thi tác vụ giúp pipeline dễ mở rộng và dễ bảo trì.

Tài nguyên:

8.2. Redis

Tóm tắt

Redis là kho dữ liệu trong bộ nhớ mã nguồn mở. Trong pipeline xử lý tài liệu, nó thường được dùng làm message broker cho Celery, backend kết quả tùy chọn và bộ nhớ đệm hiệu năng cao.

Điểm chính

  • Lưu dữ liệu trong bộ nhớ để truy cập nhanh.
  • Hỗ trợ các cấu trúc dữ liệu như chuỗi, hash, danh sách, tập hợp, tập hợp có thứ tự và stream.
  • Có thể làm message broker và backend kết quả tùy chọn cho Celery.
  • Thường được dùng để cache, nhắn tin và lưu dữ liệu tạm thời.
  • Cung cấp tính năng nhắn tin như Pub/Sub và Streams.

Cần biết

Redis không chỉ là cache. Việc hỗ trợ nhiều cấu trúc dữ liệu khiến nó hữu ích cho nhắn tin, điều phối phân tán, cache và lưu dữ liệu tạm thời, nên nó xuất hiện trong nhiều kiến trúc production ngoài phạm vi xử lý tài liệu.

Tài nguyên:

9. Cơ sở dữ liệu

Pipeline xử lý tài liệu tạo ra nhiều thứ hơn là văn bản trích xuất. Nó còn tạo siêu dữ liệu mà hệ thống cần ghi nhớ: tài liệu đến từ đâu, đã qua những bước xử lý nào, có bước nào thất bại không và thông tin gì đã được trích xuất.

Cơ sở dữ liệu cung cấp nơi lưu trữ có cấu trúc cho thông tin này. Nó cho phép pipeline theo dõi sự kiện vòng đời tài liệu, truy vấn lịch sử xử lý và duy trì tính nhất quán khi khối lượng công việc tăng.

Cơ sở dữ liệu mã nguồn mở phổ biến cho bước này là PostgreSQL. Nó thường được dùng để lưu siêu dữ liệu tài liệu, trạng thái xử lý, trường đã trích xuất và dữ liệu ứng dụng, trong khi tệp lớn được lưu riêng khi kiến trúc yêu cầu.

9.1. PostgreSQL

Tóm tắt

PostgreSQL là hệ quản trị cơ sở dữ liệu quan hệ đối tượng mã nguồn mở, thường được dùng trong pipeline xử lý tài liệu để lưu siêu dữ liệu, trạng thái luồng công việc, thông tin trích xuất và dữ liệu ứng dụng.

Điểm chính

  • Lưu thông tin có cấu trúc về tài liệu và luồng xử lý.
  • Hỗ trợ truy vấn SQL, giao dịch, ràng buộc và lập chỉ mục.
  • Cung cấp hỗ trợ JSON và JSONB cho siêu dữ liệu tài liệu linh hoạt hoặc bán cấu trúc.
  • Giúp theo dõi sự kiện vòng đời tài liệu như tải lên, các bước xử lý, thất bại và trạng thái hoàn tất.
  • Làm việc tốt cùng hệ thống lưu trữ đối tượng như MinIO, nơi tệp lớn có thể được lưu riêng.

Cần biết

PostgreSQL thường không chịu trách nhiệm lưu mọi tệp tài liệu trong pipeline production. Một kiến trúc phổ biến giữ tài liệu trong lưu trữ đối tượng và lưu thông tin cần để quản lý những tài liệu đó trong cơ sở dữ liệu.

Cách tách biệt này cho phép mỗi thành phần tập trung vào việc nó làm tốt nhất:

  • PostgreSQL → siêu dữ liệu và trạng thái luồng công việc.
  • Lưu trữ đối tượng → tài liệu và tệp được tạo ra.
  • Chỉ mục tìm kiếm → nội dung tìm kiếm được.

Tài nguyên:

10. Lưu trữ đối tượng

Pipeline xử lý tài liệu cần nơi lưu trữ đáng tin cậy cho các tệp nó xử lý. Cơ sở dữ liệu rất tốt cho siêu dữ liệu và thông tin luồng công việc, nhưng không phải lúc nào cũng là lựa chọn tốt nhất để quản lý khối lượng lớn tài liệu, ảnh và tệp được tạo ra.

Lưu trữ đối tượng cung cấp cách mở rộng để lưu dữ liệu phi cấu trúc dưới dạng đối tượng trong bucket. Ứng dụng truy cập các đối tượng này qua API thay vì đối xử như tệp trên hệ thống tệp truyền thống.

Công cụ mã nguồn mở phổ biến cho bước này là MinIO. Nó cung cấp lưu trữ đối tượng tương thích S3 cho tài liệu gốc, tệp đã xử lý và sản phẩm tạo ra, đồng thời để cơ sở dữ liệu như PostgreSQL tập trung vào thông tin có cấu trúc.

10.1. MinIO

Tóm tắt

MinIO là hệ thống lưu trữ đối tượng mã nguồn mở cung cấp lưu trữ tương thích S3 cho dữ liệu phi cấu trúc. Trong pipeline xử lý tài liệu, nó thường được dùng để lưu tài liệu tải lên, tệp đã xử lý và đầu ra được tạo ra.

Điểm chính

  • Cung cấp lưu trữ đối tượng tương thích S3 qua API.
  • Lưu dữ liệu dưới dạng đối tượng trong bucket.
  • Được thiết kế cho dữ liệu phi cấu trúc như tài liệu, ảnh, bản sao lưu và kho lưu trữ.
  • Giữ việc lưu tệp lớn tách khỏi hệ thống siêu dữ liệu như PostgreSQL.
  • Làm việc với các công cụ và ứng dụng tương thích S3 hiện có.

Cần biết

MinIO không thay thế cơ sở dữ liệu. Nó giải quyết một vấn đề khác.

Một pipeline xử lý tài liệu điển hình tách trách nhiệm như sau:

  • MinIO → lưu tài liệu gốc và tệp được tạo ra.
  • PostgreSQL → lưu siêu dữ liệu, trạng thái xử lý và thông tin luồng công việc.
  • Search engine → lưu nội dung tài liệu tìm kiếm được.

Cách tách biệt này cho phép mỗi thành phần tập trung vào khối lượng công việc nó xử lý tốt nhất.

Tài nguyên:

11. Chỉ mục tìm kiếm

Xử lý tài liệu chỉ có ích khi người dùng và ứng dụng tìm được thông tin họ cần. Sau khi văn bản đã được trích xuất, pipeline cần cách tìm kiếm nội dung đó nhanh chóng.

Chỉ mục tìm kiếm lưu một biểu diễn tối ưu của nội dung và siêu dữ liệu tài liệu để người dùng tìm thông tin qua tìm kiếm toàn văn, lọc và truy vấn dựa trên độ liên quan.

Các công cụ mã nguồn mở phổ biến cho bước này gồm OpenSearch và Elasticsearch. Chúng lập chỉ mục văn bản đã trích xuất và siêu dữ liệu tài liệu, cho phép người dùng tìm tài liệu mà không phải mở từng tệp.

11.1. OpenSearch

Tóm tắt

OpenSearch là bộ công cụ tìm kiếm và phân tích mã nguồn mở dùng để lập chỉ mục, tìm kiếm, trực quan hóa và phân tích dữ liệu. Trong pipeline xử lý tài liệu, nó thường được dùng để làm nội dung tài liệu đã trích xuất trở nên tìm kiếm được.

Điểm chính

  • Cung cấp khả năng tìm kiếm toàn văn.
  • Lập chỉ mục văn bản đã trích xuất và siêu dữ liệu tài liệu.
  • Hỗ trợ lọc, xếp hạng và phân tích.
  • Được thiết kế cho khối lượng tìm kiếm phân tán.
  • Có thể mở rộng qua plugin để thêm khả năng.

Điều thú vị

OpenSearch được tạo ra như một bản fork mã nguồn mở của Elasticsearch và Kibana từ các phiên bản 7.10.2 (7.10.2). Từ đó nó đã phát triển thành dự án tìm kiếm và phân tích riêng dưới Apache License.

Tài nguyên:

11.2. Elasticsearch

Tóm tắt

Elasticsearch là engine tìm kiếm và phân tích phân tán, thiết kế cho tìm kiếm, lập chỉ mục và phân tích nhanh dữ liệu có cấu trúc lẫn phi cấu trúc. Trong pipeline xử lý tài liệu, nó thường được dùng để cung cấp tìm kiếm nhanh trên nội dung đã trích xuất.

Điểm chính

  • Cung cấp tìm kiếm toàn văn và truy vấn có cấu trúc.
  • Hỗ trợ lập chỉ mục, lọc và tính điểm liên quan.
  • Xử lý khối lượng tìm kiếm phân tán.
  • Thường được dùng cho tìm kiếm tài liệu, khả năng quan sát và phân tích.
  • Cung cấp hệ sinh thái tích hợp và công cụ rộng lớn.

Cần biết

OpenSearch và Elasticsearch giải quyết vấn đề tương tự, nhưng ngày nay là hai dự án riêng biệt. Việc chọn cái nào phụ thuộc vào các yếu tố như sở thích về giấy phép, yêu cầu hệ sinh thái, kinh nghiệm vận hành và hạ tầng hiện có.

Tài nguyên:

12. Giám sát

Pipeline xử lý tài liệu có thể hỏng theo nhiều cách. Worker có thể không khả dụng, tác vụ OCR có thể chậm lại, dung lượng lưu trữ có thể đầy, hoặc hàng đợi có thể tăng nhanh hơn tốc độ xử lý.

Giám sát cho người vận hành khả năng nhìn thấy điều gì đang diễn ra bên trong hệ thống. Thay vì phát hiện vấn đề sau khi người dùng báo lỗi, đội ngũ có thể theo dõi hiệu năng, xác định nút thắt cổ chai và phản ứng trước khi sự cố lớn hơn.

Các công cụ mã nguồn mở phổ biến cho bước này gồm Prometheus và Grafana. Prometheus thu thập và lưu số liệu, còn Grafana biến số liệu đó thành dashboard giúp dễ hiểu sức khỏe hệ thống hơn.

12.1. Prometheus

Tóm tắt

Prometheus là bộ công cụ giám sát và cảnh báo mã nguồn mở, thu thập và lưu số liệu chuỗi thời gian. Trong pipeline xử lý tài liệu, nó có thể theo dõi hiệu năng ứng dụng, sức khỏe worker, hoạt động hàng đợi và số liệu hạ tầng.

Điểm chính

  • Thu thập và lưu số liệu chuỗi thời gian.
  • Dùng mô hình kéo để thu thập số liệu từ các target đã cấu hình.
  • Hỗ trợ đánh giá quy tắc cảnh báo và làm việc với Alertmanager để xử lý thông báo.
  • Cung cấp PromQL để truy vấn và phân tích số liệu.
  • Làm việc tốt với hệ thống phân tán và cloud-native.

Bạn có biết?

Prometheus tập trung vào số liệu, không phải lưu trữ tài liệu hay log ứng dụng. Ví dụ, nó có thể theo dõi thời gian xử lý, mức dùng CPU, mức dùng bộ nhớ, độ dài hàng đợi và tỷ lệ lỗi, trong khi công cụ riêng xử lý log và tệp.

Tài nguyên:

12.2. Grafana

Tóm tắt

Grafana là nền tảng trực quan hóa và khả năng quan sát mã nguồn mở, dùng để tạo dashboard từ số liệu và các nguồn dữ liệu khác. Trong pipeline xử lý tài liệu, nó giúp đội ngũ hiểu hiệu năng hệ thống bằng hình ảnh.

Điểm chính

  • Tạo dashboard từ nhiều nguồn dữ liệu.
  • Thường làm việc với Prometheus để trực quan hóa số liệu.
  • Giúp xác định xu hướng, nút thắt cổ chai và lỗi.
  • Hỗ trợ các luồng trực quan hóa, khám phá và cảnh báo.
  • Có thể hiển thị số liệu, log, trace và dữ liệu khác tùy nguồn được kết nối.

Cần biết

Prometheus và Grafana giải quyết vấn đề khác nhau:

  • Prometheus → thu thập và lưu số liệu.
  • Grafana → truy vấn nguồn dữ liệu và trực quan hóa thông tin qua dashboard.

Dùng cả hai cùng lúc cho người vận hành cả phép đo lẫn khả năng nhìn thấy cần thiết để duy trì pipeline production.

Tài nguyên:

13. Quản lý log

Pipeline xử lý tài liệu tạo ra hàng nghìn sự kiện trong quá trình vận hành. Worker bắt đầu và hoàn tất tác vụ, engine OCR xử lý tệp, cơ sở dữ liệu ghi thay đổi, dịch vụ báo cảnh báo hoặc lỗi.

Số liệu cho thấy xu hướng và mẫu hình, nhưng không phải lúc nào cũng đủ chi tiết để điều tra từng sự kiện. Log cung cấp bản ghi chi tiết cần thiết để hiểu hành vi hệ thống, gỡ lỗi và điều tra sự cố.

Các công cụ mã nguồn mở phổ biến cho bước này gồm Grafana Loki và Graylog. Chúng thu thập, lưu trữ và giúp tìm kiếm, phân tích log ứng dụng và hạ tầng dễ hơn.

13.1. Grafana Loki

Tóm tắt

Grafana Loki là hệ thống tổng hợp log mã nguồn mở, thiết kế để thu thập và truy vấn log hiệu quả. Trong pipeline xử lý tài liệu, nó có thể tập trung log từ worker, dịch vụ và thành phần hạ tầng.

Điểm chính

  • Tổng hợp log từ nhiều nguồn.
  • Tổ chức log bằng nhãn gắn vào các luồng log.
  • Tích hợp chặt với dashboard Grafana.
  • Làm việc tốt cùng hệ thống giám sát dựa trên Prometheus.
  • Dùng LogQL để truy vấn và phân tích log.

Cần biết

Loki không phải engine tìm kiếm toàn văn truyền thống. Thay vì lập chỉ mục toàn bộ nội dung từng dòng log, nó lập chỉ mục nhãn siêu dữ liệu và lưu dữ liệu log riêng. Thiết kế này có thể giảm chi phí lưu trữ và lập chỉ mục mà vẫn giữ log tìm kiếm được.

Tài nguyên:

13.2. Graylog

Tóm tắt

Graylog là nền tảng quản lý log mã nguồn mở dùng để thu thập, tìm kiếm, phân tích và quản lý dữ liệu log từ ứng dụng và hạ tầng.

Điểm chính

  • Thu thập log từ nhiều nguồn.
  • Cung cấp khả năng tìm kiếm và lọc.
  • Giúp tập trung log ứng dụng và hạ tầng.
  • Hỗ trợ dashboard và phân tích vận hành.
  • Hữu ích để gỡ lỗi hệ thống phân tán.

Cần biết

Graylog và công cụ giám sát giải quyết vấn đề khác nhau:

  • Số liệu trả lời: "Hệ thống có đang hoạt động bình thường không?"
  • Log trả lời: "Những sự kiện nào đã xảy ra?"

Dùng cả hai cùng lúc cho người vận hành khả năng nhìn thấy tốt hơn vào hệ thống production.

Tài nguyên:

14. Đóng gói container (Container) và triển khai

Pipeline xử lý tài liệu gồm nhiều thành phần: API, worker, cơ sở dữ liệu, message broker, hệ thống lưu trữ, search engine và công cụ giám sát.

Cài đặt và quản lý từng thành phần trực tiếp trên máy chủ có thể trở nên khó khăn khi hệ thống lớn dần. Các công cụ khác nhau có thể yêu cầu phiên bản, phụ thuộc và cách cấu hình khác nhau.

Đóng gói container (Container) giải quyết vấn đề này bằng cách gói ứng dụng cùng phụ thuộc vào môi trường cô lập. Nhờ vậy các thành phần dễ triển khai, tái lập, nâng cấp và di chuyển giữa các hệ thống hơn.

Các công cụ container mã nguồn mở phổ biến trên Linux gồm Docker và Podman.

14.1. Docker

Tóm tắt

Docker là nền tảng container dùng để build, đóng gói và chạy ứng dụng trong container. Trong pipeline xử lý tài liệu, nó đơn giản hóa việc triển khai các dịch vụ xử lý và hạ tầng phụ trợ.

Điểm chính

  • Đóng gói ứng dụng và phụ thuộc vào image container.
  • Cung cấp môi trường nhất quán giữa phát triển, kiểm thử và production.
  • Dùng image làm khuôn mẫu để tạo container.
  • Hỗ trợ triển khai nhiều container qua công cụ như Docker Compose.
  • Có hệ sinh thái image và tích hợp rộng lớn.

Những gì chạy trong container Docker trong pipeline này?

Container ứng dụng:

  • API tiếp nhận tài liệu.
  • Worker Celery thực hiện OCR, xử lý ảnh và tác vụ trích xuất.
  • Các dịch vụ liên quan đến luồng công việc.

Container hạ tầng:

  • RabbitMQ → message broker.
  • Redis → cache và backend kết quả tác vụ tùy chọn.
  • PostgreSQL → cơ sở dữ liệu siêu dữ liệu và luồng công việc.
  • MinIO → lưu trữ đối tượng tài liệu.
  • OpenSearch → chỉ mục tìm kiếm.
  • Prometheus → thu thập số liệu.
  • Grafana → dashboard.
  • Loki → tổng hợp log.

Cần biết

Container không phải máy ảo. Container dùng chung nhân hệ điều hành máy chủ trong khi cô lập ứng dụng và phụ thuộc của chúng.

Bản thân tài liệu không được lưu bên trong container. Container chạy các dịch vụ xử lý và quản lý tài liệu, còn dữ liệu bền vững được lưu riêng.

Ví dụ:

Container
└── MinIO service
Persistent Storage
├── invoice-001.pdf
├── contract-002.pdf
└── report-003.pdf

Cách tách biệt này cho phép tạo lại hoặc nâng cấp container mà không mất dữ liệu tài liệu.

Tài nguyên:

14.2. Podman

Tóm tắt

Podman là engine container mã nguồn mở, không cần daemon, thiết kế để build, chạy và quản lý container cùng image. Nó cung cấp trải nghiệm dòng lệnh tương thích Docker và hỗ trợ container không cần root.

Điểm chính

  • Hỗ trợ image container tương thích OCI.
  • Chạy mà không cần daemon trung tâm.
  • Hỗ trợ thực thi container không cần root.
  • Cung cấp giao diện dòng lệnh quen thuộc với người dùng Docker.
  • Tích hợp tốt với hệ thống Linux và công cụ container.

Podman thay thế gì trong pipeline này?

Podman có thể chạy cùng các loại container mô tả ở trên:

  • Worker Celery.
  • PostgreSQL.
  • RabbitMQ.
  • Redis.
  • MinIO.
  • OpenSearch.
  • Các dịch vụ giám sát.

Khác biệt không nằm ở kiến trúc pipeline mà ở container runtime dùng để thực thi các dịch vụ đó.

Cần biết

Docker và Podman giải quyết vấn đề tương tự nhưng có thiết kế khác nhau:

  • Docker → dùng kiến trúc client-daemon.
  • Podman → dùng kiến trúc không daemon và chú trọng tích hợp gốc với Linux.

Việc chọn cái nào phụ thuộc vào sở thích vận hành, yêu cầu bảo mật và hạ tầng hiện có.

Tài nguyên:

15. Điều phối container (Container)

Đóng gói container giúp đóng gói và chạy từng dịch vụ dễ hơn, nhưng quản lý nhiều container bằng tay trở nên khó khi hệ thống lớn dần.

Pipeline xử lý tài liệu có thể chứa nhiều API, worker xử lý, cơ sở dữ liệu, message broker, hệ thống lưu trữ, dịch vụ tìm kiếm và thành phần giám sát. Khi số dịch vụ tăng, đội ngũ cần cách quản lý triển khai, mở rộng, mạng và xử lý lỗi.

Điều phối container giải quyết vấn đề này bằng cách tự động hóa việc quản lý ứng dụng đóng gói trong container.

Nền tảng điều phối mã nguồn mở được dùng rộng rãi nhất là Kubernetes (Kubernetes).

15.1. Kubernetes (Kubernetes)

Tóm tắt

Kubernetes (Kubernetes) là nền tảng mã nguồn mở để quản lý khối lượng công việc và dịch vụ đóng gói trong container. Nó tự động hóa triển khai, mở rộng, mạng và quản lý vòng đời ứng dụng chạy trong container.

Điểm chính

  • Tự động hóa triển khai và quản lý ứng dụng đóng gói trong container.
  • Duy trì trạng thái mong muốn của khối lượng công việc đang chạy.
  • Hỗ trợ tăng hoặc giảm số dịch vụ theo yêu cầu khối lượng công việc.
  • Cung cấp khả năng khám phá dịch vụ và mạng.
  • Khởi động lại container lỗi và thay thế khối lượng công việc không khỏe mạnh.
  • Hỗ trợ cập nhật ứng dụng có kiểm soát qua các chiến lược triển khai.

Kubernetes phù hợp thế nào với pipeline này

Kubernetes đặc biệt hữu ích để quản lý khối lượng công việc ứng dụng như:

  • API tiếp nhận tài liệu.
  • Worker Celery.
  • Dịch vụ xử lý.
  • Thành phần luồng công việc.

Nó cũng có thể chạy các dịch vụ hạ tầng phụ trợ như:

  • RabbitMQ.
  • Redis.
  • PostgreSQL.
  • MinIO.
  • OpenSearch.
  • Thành phần giám sát.

Tuy vậy, chạy dịch vụ có trạng thái bên trong Kubernetes cần lập kế hoạch thêm về:

  • Lưu trữ bền vững.
  • Sao lưu.
  • Tính sẵn sàng cao.
  • Phục hồi dữ liệu.

Với nhiều hệ thống production, đội ngũ có thể chọn chạy một số dịch vụ có trạng thái riêng trong khi dùng Kubernetes chủ yếu cho khối lượng công việc ứng dụng.

Cần biết

Kubernetes không thay thế container. Nó quản lý container.

Mối quan hệ là:

Docker / Podman (Docker / Podman)
|
v
Container images (Container Images)
|
v
Kubernetes (Kubernetes)
|
v
Deployment, scaling, networking, recovery (Deployment, Scaling, Networking, Recovery)

Container trả lời:

"Làm sao đóng gói và chạy một dịch vụ?"

Kubernetes trả lời:

"Làm sao vận hành nhiều dịch vụ một cách đáng tin cậy?"

Tài nguyên:

15.2. Helm

Tóm tắt

Helm là trình quản lý gói cho Kubernetes, giúp định nghĩa, cài đặt, nâng cấp và quản lý ứng dụng Kubernetes bằng các gói tái sử dụng gọi là chart.

Điểm chính

  • Đóng gói tài nguyên Kubernetes thành chart tái sử dụng.
  • Đơn giản hóa triển khai ứng dụng phức tạp.
  • Giúp quản lý khác biệt cấu hình giữa các môi trường.
  • Khiến việc cài đặt và nâng cấp ứng dụng dễ tái lập hơn.
  • Thường được dùng để triển khai thành phần hạ tầng và bộ ứng dụng.

Cần biết

Một ứng dụng Kubernetes thường cần nhiều định nghĩa tài nguyên, như Deployment, Service, ConfigMap và cấu hình lưu trữ.

Helm đóng gói các tài nguyên này vào một chart để đội ngũ có thể cài đặt và quản lý ứng dụng như một đơn vị duy nhất thay vì duy trì nhiều tệp cấu hình riêng lẻ.

Tài nguyên:

16. Bảo mật pipeline

Hệ thống xử lý tài liệu production thường xuyên nhận tệp từ người dùng, khách hàng, nhà cung cấp, API, tệp đính kèm email và luồng tự động. Khác với dữ liệu ứng dụng có cấu trúc, những tài liệu này đến từ ngoài tầm kiểm soát của bạn và luôn phải được coi là đầu vào không tin cậy.

Vì vậy bảo mật không phải một tính năng đơn lẻ mà là chuỗi biện pháp bảo vệ áp dụng xuyên suốt pipeline. Bằng cách cô lập khối lượng công việc xử lý, giới hạn quyền, kiểm tra tệp tải lên, bảo vệ thông tin xác thực nhạy cảm và duy trì trách nhiệm giải trình, bạn có thể giảm đáng kể cả rủi ro vận hành lẫn rủi ro bảo mật.

16.1. Coi tài liệu là không tin cậy

Mọi tài liệu tải lên phải được giả định là có thể độc hại hoặc sai định dạng cho đến khi được kiểm tra.

Trước khi bắt đầu xử lý, hãy xác minh:

  • Loại và định dạng tệp
  • Giới hạn kích thước tệp
  • Bảo vệ bằng mật khẩu
  • Tính toàn vẹn của tệp
  • Loại tài liệu được hỗ trợ

Từ chối hoặc cách ly sớm tài liệu không hợp lệ giúp giảm xử lý không cần thiết và bảo vệ hệ thống phía sau.

16.2. Cô lập khối lượng công việc xử lý

Các thư viện xử lý tài liệu phải xử lý định dạng phức tạp như PDF và ảnh. Nếu một lỗ hổng bị khai thác, cô lập giúp hạn chế tác động.

Chạy xử lý tài liệu trong môi trường cô lập và tránh cấp cho worker quyền truy cập không cần thiết vào hệ thống máy chủ.

Công nghệ Linux được khuyến nghị gồm:

Worker cũng nên chạy dưới người dùng không phải root chuyên dụng, theo nguyên tắc đặc quyền tối thiểu. Tránh container có đặc quyền và chỉ cấp những quyền cần thiết cho xử lý.

16.3. Quét và giới hạn tài nguyên

Tệp tải lên nên được quét phần mềm độc hại đã biết trước khi vào pipeline xử lý. Tài liệu đáng ngờ nên được cách ly để điều tra thay vì xử lý tự động.

Công cụ mã nguồn mở được khuyến nghị gồm:

Để ngăn cạn kiệt tài nguyên và tấn công từ chối dịch vụ, hãy cấu hình các giới hạn vận hành hợp lý như:

  • Kích thước tải lên tối đa
  • Số trang tối đa
  • Giới hạn CPU và bộ nhớ
  • Thời gian chờ xử lý
  • Giới hạn số worker đồng thời

16.4. Bảo vệ dữ liệu và thông tin xác thực

Xử lý tài liệu thường tạo tệp tạm trong quá trình chuyển đổi, tiền xử lý và OCR. Những tệp này nên được lưu trong thư mục làm việc cô lập và tự động xóa sau khi xử lý xong.

Thông tin xác thực của ứng dụng không bao giờ được nhúng trong mã nguồn, tệp cấu hình hoặc image container. Thay vào đó, hãy lấy thông tin xác thực an toàn lúc chạy bằng giải pháp quản lý bí mật chuyên dụng hoặc cơ chế gốc của nền tảng.

Giải pháp mã nguồn mở được khuyến nghị gồm:

16.5. Kiểm soát truy cập và duy trì nhật ký kiểm toán

Áp dụng nguyên tắc đặc quyền tối thiểu trên toàn nền tảng. Giao diện quản trị, API, lưu trữ đối tượng, hệ thống luồng công việc và dashboard giám sát đều phải yêu cầu xác thực và phân quyền phù hợp.

Duy trì nhật ký kiểm toán cho các sự kiện quan trọng, gồm:

  • Tải tài liệu lên
  • Các lần xác thực
  • Hành động quản trị
  • Thay đổi quyền
  • Lỗi xử lý
  • Xóa tài liệu

Nhật ký kiểm toán được bảo vệ hỗ trợ gỡ lỗi, ứng phó sự cố và yêu cầu tuân thủ, đồng thời cho khả năng nhìn thấy cách tài liệu đi qua pipeline.

Như mọi công đoạn của pipeline xử lý tài liệu sẵn sàng cho production, bảo mật nên được thiết kế vào kiến trúc ngay từ đầu thay vì thêm vào sau khi triển khai. Cách tiếp cận nhiều lớp giúp giảm rủi ro trong khi vẫn đảm bảo pipeline đáng tin cậy, dễ bảo trì và có khả năng phục hồi khi lớn dần.

Kết luận

Xây dựng pipeline xử lý tài liệu sẵn sàng cho production không phải là tìm engine OCR hoàn hảo hay gom thật nhiều công cụ mã nguồn mở. Đó là thiết kế một hệ thống đáng tin cậy, tiếp tục xử lý tài liệu chính xác, hiệu quả và an toàn khi khối lượng công việc tăng.

Trong bài này, chúng ta đã điểm qua các công cụ và công nghệ mã nguồn mở khác nhau cần để xây dựng một nền tảng xử lý tài liệu hoàn chỉnh trên Linux.

Những pipeline xử lý tài liệu tốt nhất không được định nghĩa bởi engine OCR chúng dùng. Chúng được định nghĩa bởi cách xử lý tài liệu thực tế, phục hồi sau lỗi và tiếp tục cho kết quả đáng tin cậy khi khối lượng công việc tăng.