Data Lake vs Data Warehouse

So sánh trách nhiệm thay vì nhãn lưu trữ

Một data lake thường giữ lại dữ liệu nguồn không đồng nhất, trong khi một warehouse nhấn mạnh dữ liệu phân tích có tổ chức và phục vụ truy vấn. Phần so sánh data lake và warehouse mô tả các vai trò lưu trữ và phân tích khác nhau của chúng. Đây là những khuynh hướng kiến trúc hơn là các giới hạn tuyệt đối về định dạng được hỗ trợ.

Đối với một chương trình dữ liệu web, vai trò lake có thể là bảo toàn các phản hồi tìm kiếm gốc, ngữ cảnh thu thập và các bản ghi đã được chuẩn hoá. Vai trò warehouse có thể là cung cấp một bảng hàng ngày về domain và vị trí với một chính sách phạm vi được ghi lại. Cùng một tổ chức có thể cần cả hai vai trò mà không phải vận hành hai bản sao không liên quan của mọi tập dữ liệu.

Hãy bắt đầu với contract của bên sử dụng. Một nhà nghiên cứu đang điều tra một lĩnh vực mới phát hiện cần chi tiết nguồn. Một bảng điều khiển cho lãnh đạo cần một định nghĩa đã thống nhất về một lần thu thập hoàn tất và một mẫu số có thể diễn giải được. Không nhóm sử dụng nào nên bị buộc phải tự suy ra giả định của nhóm kia từ một thư mục không được ghi chép hay một tên bảng.

Dữ liệu thô và bảng chuẩn hoá cần các schema khác nhau

Lưu trữ thô nên giữ lại đủ thông tin về sự kiện thu thập để hỗ trợ việc giải thích sau này. Bao gồm ngữ cảnh yêu cầu, thời điểm quan sát, trạng thái kết quả và payload nguồn khi phù hợp để lưu trữ. Giữ thông tin đăng nhập và dữ liệu tài khoản riêng tư khỏi đối tượng được lưu trữ. Một phản hồi nguồn không có ngữ cảnh của nó có thể không thể so sánh đúng được.

Một bảng đã chuẩn hoá nên chắt lọc thông tin đó thành một contract phân tích ổn định. Hãy định nghĩa mỗi hàng biểu diễn điều gì, trường nào là bắt buộc, và một giá trị vắng mặt có ý nghĩa gì. Nếu một truy vấn không trả về kết quả organic nào, hãy quyết định xem lần thu thập đó vẫn là một quan sát hợp lệ hay không và nó xuất hiện như thế nào trong báo cáo phạm vi phủ.

Ví dụ, một bảng có thể mô tả các lần thu thập trong khi một bảng khác mô tả các kết quả thuộc về mỗi lần thu thập. Điều này bảo toàn sự khác biệt giữa một phản hồi rỗng hợp lệ và một sự kiện thu thập bị thiếu. Một bảng kết quả duy nhất không thể biểu đạt sự khác biệt đó khi một kết quả rỗng không tạo ra bất kỳ hàng nào.

Tính linh hoạt của schema là chuyển chỗ công việc chứ không phải loại bỏ nó

Tính linh hoạt của schema cho phép một nhóm giữ lại các trường chưa quen thuộc trước khi quyết định cách phân tích chúng. Nó không loại bỏ nhu cầu phải hiểu các trường đó. Vẫn cần có người xác định kiểu dữ liệu, khoá và ý nghĩa nghiệp vụ trước khi dữ liệu có thể hỗ trợ việc so sánh đáng tin cậy.

Trong một thiết kế thiên về lake, công việc đó có thể diễn ra khi một phép biến đổi hoặc truy vấn đọc nguồn. Trong một thiết kế thiên về warehouse, nhiều phần việc đó có thể diễn ra trong lúc ingest hoặc chuẩn hoá. Các nền tảng hiện đại hỗ trợ nhiều kiểu kết hợp, vì vậy hãy kiểm tra điểm thực sự áp đặt schema thay vì giả định rằng mọi lake đều không có schema và mọi warehouse chỉ chấp nhận đầu vào cứng nhắc.

Hãy viết các quy tắc tương thích cho thay đổi ở nguồn. Một trường tuỳ chọn mới có thể an toàn để giữ lại nhưng không liên quan đến một báo cáo hiện tại. Một đơn vị đo lường hoặc hạng mục kết quả thay đổi có thể làm mất hiệu lực các so sánh lịch sử ngay cả khi kiểu vật lý vẫn giống nhau. Ghi lại phiên bản phép biến đổi đã biến mỗi lần thu thập nguồn thành một hàng phân tích được xuất bản.

Định Dạng Bảng Thêm Cơ Chế Phối Hợp Cho Tệp

Một thư mục tệp cần siêu dữ liệu và cơ chế phối hợp trước khi nó có thể hoạt động như một bảng phân tích được quản lý. Tiêu chuẩn Apache Iceberg table specification mô tả một định dạng bảng với siêu dữ liệu, ảnh chụp nhanh (snapshot) và thông tin lược đồ. Những thành phần như vậy giải thích vì sao một hồ dữ liệu hiện đại có thể hỗ trợ các khả năng vốn trước đây gắn chủ yếu với hệ thống kho dữ liệu.

Sự khác biệt này quan trọng trong quá trình cập nhật. Nếu một bộ ghi (writer) xuất bản các tệp thay thế trong khi người đọc đang quét một tập dữ liệu, người đọc cần một định nghĩa nhất quán về tập tệp hiển thị. Phần mở rộng tệp đơn thuần không cung cấp ranh giới xuất bản đó. Hãy quyết định cách một snapshot đã hoàn tất được công bố và cách loại trừ phần công việc chưa hoàn thành.

Đừng thêm một định dạng bảng chỉ để sơ đồ kiến trúc trông có vẻ đầy đủ. Một kho lưu trữ bất biến nhỏ có thể chỉ cần một manifest và quy ước đặt tên rõ ràng. Một tập dữ liệu dùng chung với nhiều bộ ghi đồng thời sẽ có yêu cầu khác. Hãy khớp cơ chế phối hợp với mô hình cập nhật và đọc thực tế, bao gồm cách phát hiện một lần xuất bản bị lỗi.

Quản trị Áp Dụng Cho Mọi Bản Sao Được Giữ Lại

Quản trị phải theo sát cả bản chụp nguồn lẫn các bảng dẫn xuất. Quy tắc kiểm soát truy cập, lưu giữ, sở hữu và xoá đều quan trọng ngay cả khi dữ liệu là công khai. Một báo cáo dẫn xuất cũng có thể chứa thông tin mà kho lưu trữ thô không phơi lộ trực tiếp, vì vậy quyền truy cập nên đi theo cách sử dụng hơn là chỉ phân biệt đơn giản giữa dữ liệu thô và dữ liệu sạch.

Theo dõi nguồn gốc (provenance) giữa giai đoạn thu thập và phân tích. Mô hình nguồn gốc W3C provenance model mô tả các mối quan hệ giữa dữ liệu, các hoạt động và các tác nhân chịu trách nhiệm. Một triển khai thực tiễn có thể giữ lại ID lần thu thập, phiên bản biến đổi và ID xuất bản tập dữ liệu mà không cần áp dụng mọi phần của mô hình hình thức.

Gán cho mỗi bảng đã xuất bản một chủ sở hữu, người có thể trả lời các bản ghi có ý nghĩa gì và chúng được tạo ra lần cuối khi nào. Xác định ai phê duyệt thay đổi lược đồ và ai điều tra một khoảng trống về mức độ bao phủ. Một mục trong danh mục chỉ hữu ích nếu nó kết nối người dùng với hợp đồng hiện tại và một trách nhiệm bảo trì thực sự.

Đặt Dữ Liệu Tìm Kiếm Tại Một Ranh Giới Thu Thập Có Thể Đo Lường

Quá trình thu thập cho tìm kiếm nên kết thúc bằng một lần chụp có thể kiểm toán trước khi phân tích bắt đầu. Scrapeless Google Search API trả về dữ liệu tìm kiếm có cấu trúc; đường ống (pipeline) của bạn quyết định giữ lại gì và chiếu (project) như thế nào. Hãy lưu truy vấn, thị trường, ngôn ngữ và kết quả lần thu thập cùng với quan sát thay vì chỉ lưu các URL kết quả trả về.

hợp đồng chất lượng pipeline dữ liệu tìm kiếm tách biệt mức độ bao phủ của lần thu thập khỏi các phát hiện bên trong kết quả đã thu. Sự tách biệt đó giúp cả việc lưu giữ ở hồ dữ liệu và báo cáo trong kho dữ liệu. Một lần thu thập bị thiếu không nên được diễn giải là bằng chứng rằng một tên miền không có mức độ hiển thị.

Giữ chi phí thu thập tách biệt với chi phí lưu trữ và phục vụ phân tích. Sử dụng Scrapeless pricing hiện tại cho giai đoạn yêu cầu, sau đó đo lường lưu giữ, các bước biến đổi, quét truy vấn và công việc vận hành trong các nền tảng bạn chọn. So sánh chi phí trả lời một câu hỏi bắt buộc với độ mới chấp nhận được, chứ không chỉ chi phí lưu trữ byte.

Chọn Kiến Trúc Dựa Trên Câu Hỏi Và Chủ Sở Hữu

Chọn một lớp lưu giữ theo hướng hồ dữ liệu khi sự đa dạng nguồn, tái xử lý và bằng chứng lịch sử là trung tâm. Chọn khả năng phục vụ theo hướng kho dữ liệu khi các số đo được quản trị và khả năng truy cập phân tích có thể dự đoán là nhu cầu trước mắt. Kết hợp các vai trò khi cả hai yêu cầu đều thực và đội ngũ có thể duy trì hợp đồng giữa chúng.

Đối với một dự án mới, hãy bắt đầu với một lần thu thập nguồn tiêu biểu và một báo cáo quan trọng. Lần theo cách báo cáo xử lý một lần thu thập trống, một trường bị thay đổi và một quan sát đến muộn. Quyết định cách đầu ra lịch sử thay đổi sau một lần sửa biến đổi. Những trường hợp này làm lộ rõ các khoảng trống kiến trúc hơn là một danh sách tính năng nền tảng.

Tránh nhân đôi dữ liệu thô và dữ liệu đã tinh chỉnh nếu không có mục đích. Hãy nêu rõ bản sao nào là nguồn chuẩn cho nhiệm vụ nào, cách bảo toàn dòng dõi (lineage) và khi nào các bản sao cũ hết hiệu lực. Kiến trúc đơn giản nhất nhưng khả thi là kiến trúc cung cấp được bằng chứng và câu trả lời phân tích cần thiết với quyền sở hữu rõ ràng ở mỗi giai đoạn.

Kết luận

Tranh luận giữa Data Lake và Data Warehouse được giải quyết tốt nhất bằng cách gán các vai trò cụ thể cho việc lưu giữ nguồn và phục vụ phân tích. Giữ lại bối cảnh cần thiết để giải thích một quan sát, xuất bản các bảng với định nghĩa ổn định và theo dõi các biến đổi giữa chúng. Chọn các thành phần lưu trữ và truy vấn sau khi yêu cầu về quyền sở hữu, độ mới và quản trị đã rõ ràng.

Tài liệu tham khảo

• Ngữ cảnh mua lại Google Search API
• Scrapeless Google Search API
• Các kiểm tra chất lượng cho một đường ống dữ liệu tìm kiếm