Hồ dữ liệu là gì?

Scrapeless Web Unlocker lấy nội dung web công khai mà các nhóm dữ liệu có thể xác minh, bảo tồn và chuyển thành dữ liệu nguồn quản lý trong một hồ dữ liệu.

TL;DR

Hồ dữ liệu lưu trữ dữ liệu đa dạng với sự chuyển đổi hạn chế ban đầu. Các đối tượng thô, bán cấu trúc, cấu trúc và nhị phân có thể chia sẻ một môi trường lưu trữ đã được quản lý.
Chỉ lưu trữ không tạo ra một hồ. Danh mục, quyền sở hữu, chính sách truy cập, kiểm tra chất lượng và quy tắc vòng đời làm cho nội dung có thể sử dụng.
Sơ đồ thường được áp dụng khi dữ liệu được đọc. Người tiêu dùng có thể định hình cùng một nguồn để khám phá, học máy, hoặc thu thập sau này.
Các định dạng tệp mở cải thiện khả năng tương tác. Các định dạng cột và bảng cho phép nhiều động cơ làm việc trên dữ liệu chia sẻ mà không có ranh giới cơ sở dữ liệu độc quyền nào.
Một hồ bổ sung cho các hệ thống được quản lý. Các bảng kho đáng tin cậy và sản phẩm dữ liệu có thể được xây dựng từ các vùng hồ quản lý thay vì thay thế mọi kho phân tích.

Định nghĩa Hồ Dữ Liệu

Hồ dữ liệu là một kho lưu trữ và mô hình quản lý để giữ lại một lượng lớn dữ liệu ở các hình thức gần với đại diện nguồn của chúng. Nó thường sử dụng lưu trữ đối tượng hoặc tệp bền vững và chấp nhận các bảng cấu trúc, JSON, nhật ký, tài liệu, phương tiện, và các định dạng tệp phân tích trước khi mọi sử dụng hạ nguồn được quyết định.

Hồ tách lưu trữ khỏi nhiều động cơ tính toán. Một động cơ truy vấn, sổ tay, công việc biến đổi, hoặc quy trình học máy có thể đọc các đối tượng đã được phê duyệt thông qua một danh mục và áp dụng sơ đồ cần thiết cho nhiệm vụ đó. Tính linh hoạt này chỉ hữu ích khi danh tính và chính sách dữ liệu tồn tại sau khi hấp thụ. Thuật ngữ chính được sử dụng ở đây theo hướng dẫn kiến trúc hồ dữ liệu của Microsoft, cái mà đưa ra khái niệm một ranh giới kỹ thuật cụ thể thay vì coi nó như một nhãn thương mại.

Một định nghĩa hữu ích cũng nói lên những gì khái niệm không làm. Hồ dữ liệu không phải là một thùng không có nhãn, một sự thay thế cho tất cả các cơ sở dữ liệu, hoặc quyền giữ lại mọi đối tượng đã thu thập vô thời hạn. Nó cũng không đảm bảo báo cáo doanh nghiệp độ trễ thấp mà không có sự quản lý, lập chỉ mục, siêu dữ liệu bảng, và tính toán theo khối công việc cụ thể. Giữ cho ranh giới đó luôn rõ ràng ngăn chặn các sơ đồ kiến trúc gán đảm bảo cho một thành phần thuộc về một lớp khác.

Cách Dữ Liệu Di Chuyển Qua Một Hồ

Một thiết kế hồ hữu ích coi việc hấp thụ là một quá trình chuyển tiếp có kiểm soát từ chứng cứ nguồn đến tài sản có thể phát hiện. Mỗi giai đoạn thêm siêu dữ liệu hoặc chất lượng mà không xóa đi ngữ cảnh ban đầu cần thiết cho việc xử lý lại sau này.

Nhà sản xuất viết một đối tượng nguồn không thay đổi với siêu dữ liệu nguồn gốc, thời gian thu thập, chủ sở hữu và phân loại.
Kiểm tra xác thực định dạng, các trường dự kiến, phạm vi truy cập, và liệu đối tượng có đại diện cho nguồn đã dự định hay không.
Một danh mục ghi lại vị trí, quan sát sơ đồ, phân vùng, dòng dõi, trạng thái chất lượng, và những người chịu trách nhiệm cho dữ liệu.
Các công việc biến đổi tạo ra các tập dữ liệu chuẩn hóa hoặc đã được quản lý trong khi bảo tồn các liên kết trở lại với các đối tượng nguồn.
Người tiêu dùng truy vấn các vùng đã được phê duyệt thông qua các động cơ và quyền phù hợp cho việc khám phá, báo cáo, mô hình, hoặc xuất khẩu.

Lưu trữ đối tượng giữ các byte, các định dạng tệp tổ chức các bản ghi, siêu dữ liệu bảng theo dõi các tập hợp hợp lý, danh mục làm cho các tài sản có thể phát hiện, và các động cơ tính toán thực hiện công việc. Giữ cho các vai trò đó tách biệt cho phép các nhóm thay đổi một động cơ truy vấn mà không cần viết lại từng đối tượng nguồn. Hành vi này được tài liệu hóa đầy đủ hơn trong tài liệu Apache Parquet. Nguồn là hữu ích vì nó mô tả thực thi thực tế hoặc mô hình dữ liệu thay vì dựa vào một phép so sánh lỏng lẻo.

Các Lớp Hồ Dữ Liệu Cốt Lõi

Lớp	Công việc chính	Chứng cứ cần giữ lại
Vùng nguồn	Bảo tồn dữ liệu nhận được	Nguồn gốc, thời gian, kiểm tra tổng, ngữ cảnh thu thập
Vùng đã xác thực	Từ chối đầu vào bị sai hoặc không mong muốn	Kết quả xác thực và quan sát sơ đồ
Vùng tiêu chuẩn hóa	Chuẩn hóa tên, loại, và phân vùng	Phiên bản biến đổi và dòng dõi
Vùng đã được quản lý	Phục vụ một sử dụng kinh doanh hoặc mô hình xác định	Chủ sở hữu, hợp đồng, mục tiêu chất lượng
Lưu trữ hoặc xóa	Áp dụng chính sách giữ dữ liệu và pháp lý	Lý do và thẩm quyền xử lý

Tên khu vực có thể khác nhau, nhưng chuyển đổi trạng thái nên rõ ràng. Việc sao chép một tệp vào tiền tố mới mà không có sự thay đổi về chất lượng hoặc quyền sở hữu tạo ra tổ chức thị giác hơn là quản trị. Mỗi khu vực nên nói cho người tiêu dùng biết những giả định nào là an toàn.

Khối lượng công việc Dữ liệu Hồ Chung

Phân tích khám phá

Các nhà phân tích có thể kiểm tra các nguồn mới trước khi cam kết vào một mô hình kho ổn định hoặc hợp đồng sản phẩm.

Chuẩn bị máy học

Các nhóm có thể bảo tồn đầu vào đa chiều, bán cấu trúc và nhị phân với dòng biến đổi có thể tái sản xuất.

Giữ nguồn lâu dài

Chứng cứ không thể thay đổi hỗ trợ việc xử lý lại sau này khi bộ phân tích, lược đồ hoặc câu hỏi kinh doanh thay đổi.

Phân tích đa động cơ

Các động cơ SQL, sổ tay, công việc theo lô và bộ xử lý luồng có thể làm việc trên các định dạng được quản lý chung.

Các trường hợp sử dụng này chia sẻ một quy tắc lựa chọn: chọn một hồ dữ liệu vì mô hình thực hiện và quyền sở hữu của nó phù hợp với khối lượng công việc, không phải vì cái tên nghe có vẻ tiên tiến hơn. Một hồ ít hấp dẫn hơn khi khối lượng công việc nhỏ, giao dịch cao hoặc bị chi phối bởi các bảng điều khiển có thể dự đoán mà đã phù hợp với cơ sở dữ liệu phân tích đã chọn. Tính linh hoạt kiến trúc có chi phí hoạt động.

Khu vực, Danh mục và Quản trị

Quản trị bắt đầu từ quá trình tiêu thụ. Nhà sản xuất nên xác định nguồn, mục đích, chủ sở hữu, độ nhạy cảm, thời gian giữ, lược đồ mong đợi và kiểm tra chất lượng trước khi lô lớn đầu tiên đến.

Ưu tiên các đối tượng nguồn không thể thay đổi. Các phiên bản mới bảo tồn chứng cứ và làm cho các biến đổi có thể tái sản xuất mà không thay đổi lịch sử một cách âm thầm.
Sử dụng các định dạng kiểu mở. Các tệp cột di động giảm công việc quét và cải thiện khả năng tương tác giữa các động cơ phân tích.
Tạo danh mục cho mọi tài sản được quản lý. Khám phá, dòng dõi, quyền sở hữu và chính sách truy cập không nên phụ thuộc vào kiến thức bộ tộc hoặc tên đường dẫn.
Tách quyền hạn theo khu vực. Đầu vào nhạy cảm gây ra và các bảng tiêu dùng được quản lý hiếm khi cần cùng một đối tượng.
Dự trù cho việc kiểm soát tệp nhỏ. Chính sách nén và phân vùng ngăn ngừa chi phí siêu dữ liệu kiểm soát công việc truy vấn.

Định dạng bảng có thể thêm ảnh chụp nhanh, tiến hóa lược đồ, siêu dữ liệu phân vùng và phối hợp giao dịch trên lưu trữ đối tượng. Chúng không loại bỏ nhu cầu về hợp đồng nguồn hoặc quản trị truy cập; chúng làm cho một số thay đổi ở cấp độ lưu trữ an toàn hơn và dễ dàng hơn để truy vấn. Một tham chiếu chính liên quan là tài liệu Apache Iceberg, cái mà làm rõ các giả định lưu trữ, thực hiện hoặc khả năng tương tác đằng sau lựa chọn đó.

Cách Hồ Dữ Liệu Trở Thành Đầm Lầy Dữ Liệu

Một đầm lầy dữ liệu hình thành khi lưu trữ phát triển nhanh hơn sự hiểu biết. Những dấu hiệu cảnh báo là thiếu quyền sở hữu, nguồn trùng lặp, lược đồ không rõ ràng, quyền hạn rộng, thời gian giữ không giới hạn và người tiêu dùng xây dựng lại cùng một logic dọn dẹp.

Tổ chức chỉ bằng đường dẫn. Thư mục không thể thay thế một danh mục ghi lại ý nghĩa, dòng dõi và quyền sở hữu.
Suy nghĩ không có lược đồ. Mỗi người tiêu dùng áp dụng các giả định; những giả định không được tài liệu chỉ đơn giản là di chuyển công việc lược đồ xuống dòng.
Sao chép mà không có danh tính. Các tệp trùng lặp không có khóa nguồn hoặc quy tắc phiên bản tạo ra kết quả phân tích không nhất quán.
Một ranh giới quyền hạn. Việc cho tất cả người tiêu dùng quyền truy cập vào các khu vực thô và đã được quản lý mở rộng rủi ro và làm yếu đi giới hạn mục đích.
Giữ mặc định. Dữ liệu không có quy tắc vòng đời làm tăng chi phí, phơi bày pháp lý và gánh nặng khám phá.

Một lỗi nên được truy vết đến lớp nhỏ nhất chịu trách nhiệm. Khi một truy vấn sai, truy vết tài sản đã được quản lý đến biến đổi của nó, mục danh mục, kết quả xác thực và đối tượng nguồn không thể thay đổi trước khi thay đổi tính toán của người tiêu dùng. Thực hành này tạo ra một hành động sửa chữa hữu ích thay vì một hướng dẫn mơ hồ để thêm nhiều dung lượng.

Lưu trữ Dữ Liệu Web Công Cộng trong Hồ

Dữ liệu web công cộng thường đến dưới dạng HTML, văn bản, JSON, ảnh chụp màn hình hoặc trường đã trích xuất. Một hồ có thể bảo tồn đại diện đã thu được và sau đó tạo ra các bảng Parquet đã chuẩn hóa hoặc được quản lý cho phân tích, miễn là ống dẫn giữ được danh tính nguồn và bối cảnh thu thập.

Đối với đầu vào web công cộng, lớp thu thập nên ghi lại URL yêu cầu, URL cuối cùng, thời gian thu thập, chế độ phản hồi và kiểm tra nội dung trước khi quá trình xử lý phía dưới bắt đầu. Lưu trữ URL yêu cầu và cuối cùng, loại nội dung, checksum, thời gian thu thập và kết quả xác thực bên cạnh đối tượng hoặc trong một bản tóm tắt liên kết. Đó là sự chuyển giao cung cấp cho các nhà phân tích một hồ sơ nguồn có thể tái sản xuất và giữ hành vi thu thập tách biệt khỏi diễn giải.

Scrapeless xử lý bước thu thập mạng được quản lý được mô tả trong câu mở đầu. Ứng dụng vẫn sở hữu sự phê duyệt nguồn, định nghĩa trường, giới hạn khối lượng công việc, thời gian giữ, kiểm soát truy cập, và xác thực. Scrapeless thực hiện việc lấy thông tin yêu cầu, trong khi nền tảng dữ liệu quyết định các nguồn được phê duyệt, đặt tên đối tượng, phân vùng, đăng ký danh mục, quyền hạn, thời gian giữ và hợp đồng phía dưới. Một hợp đồng rõ ràng giữa các lớp đó làm cho các thay đổi sau này dễ dàng hơn để kiểm tra.

Ống dẫn nên bảo tồn cả chứng cứ thô và đầu ra đã được quản lý khi trường hợp sử dụng cần đến khả năng kiểm toán. Tài liệu thô hỗ trợ việc xử lý lại sau khi một bộ phân tích hoặc lược đồ thay đổi; các bảng đã được quản lý hỗ trợ phân tích ổn định. Bảo tồn chứng cứ thô chỉ khi mục đích và chính sách giữ nó xác đáng, sau đó xuất bản sản phẩm đã được quản lý với các trường và kỳ vọng chất lượng đã được tài liệu. Hai đại diện trả lời các câu hỏi vận hành khác nhau và không nên bị hiểu nhầm là trùng lặp.

Danh sách kiểm tra kiến trúc Data Lake

Hãy sử dụng các câu hỏi sau trong quá trình xem xét thiết kế. Một câu trả lời bằng văn bản có giá trị hơn một mặc định giả định vì nó chỉ ra nơi mà các nhóm không đồng ý về một data lake.

Những cách biểu diễn nguồn nào phải giữ nguyên không thay đổi?
Thông tin siêu dữ liệu nào khiến mỗi đối tượng có thể phát hiện và tái tạo?
Những định dạng và tiêu chuẩn bảng nào mà nhiều công cụ phải chia sẻ?
Làm thế nào để phát hiện sự thay đổi sơ đồ và những thay đổi không tương thích?
Ai sở hữu từng tập dữ liệu đã được chỉnh sửa và phê duyệt người tiêu dùng của nó?
Sự khác biệt giữa quyền truy cập thô và quyền truy cập đã được chỉnh sửa là gì?
Những quy tắc nén và phân vùng nào kiểm soát bố cục tệp?
Khi nào dữ liệu được lưu trữ hoặc xóa, và quyết định đó được ghi lại ở đâu?

Một hồ chứa sẵn sàng khi một người tiêu dùng mới có thể phát hiện một tài sản, hiểu hợp đồng của nó, xác minh nguồn gốc của nó, yêu cầu quyền truy cập thích hợp và tái tạo quá trình biến đổi từ chứng cứ đã được lưu giữ. Hãy xem xét lại các câu trả lời sau khi hình dạng khối lượng công việc, khối lượng dữ liệu, giới hạn dịch vụ, hoặc kỳ vọng của người tiêu dùng thay đổi. Một kiến trúc hợp lý cho một lô hàng khám phá có thể không phù hợp cho một đường dẫn sản xuất liên tục.

Kết luận

Một data lake kết hợp lưu trữ linh hoạt với lập danh mục, quản trị và tính toán độc lập. Giá trị của nó đến từ việc bảo tồn dữ liệu nguồn đa dạng trong khi vẫn làm cho quyền sở hữu, chất lượng, nguồn gốc, quyền truy cập và vòng đời trở nên rõ ràng. Các định dạng mở và siêu dữ liệu bảng cải thiện khả năng tương tác, nhưng chúng không tạo ra lòng tin tự thân. Hồ chứa trở nên hữu ích khi mỗi tài sản có thể di chuyển qua một con đường được tài liệu hóa từ chứng cứ đến sản phẩm dữ liệu sẵn sàng cho người tiêu dùng.

Sẵn sàng để xây dựng một Data Lake Web được quản lý?

Thu thập bằng chứng công cộng đã được phê duyệt, bảo tồn nguồn gốc, và chuyển giao các đối tượng đã được xác thực cho quy trình thu thập của bạn.

Đăng ký ngay hôm nay và nhận $5 tín dụng miễn phí — không yêu cầu thẻ tín dụng.

Nhận Tín Dụng $5 của bạn →

Câu hỏi thường gặp

Mục đích chính của một data lake là gì?

Một data lake bảo tồn dữ liệu đa dạng cho nhiều mục đích tương lai mà không bắt buộc mỗi nguồn phải vào một sơ đồ kho hàng duy nhất tại điểm thu thập. Nó hỗ trợ khám phá, chuẩn bị machine-learning, chứng cứ dài hạn và phân tích đa động cơ. Tính linh hoạt đó phụ thuộc vào danh mục, quyền sở hữu, kiểm soát truy cập, kiểm tra chất lượng và chính sách giữ lại.

Một data lake có luôn được lưu trữ trên đám mây không?

Không. Một data lake có thể sử dụng lưu trữ đối tượng đám mây, hệ thống tệp phân phối, hoặc các môi trường lưu trữ bền bỉ khác. Các kho đối tượng đám mây khá phổ biến vì chúng tách biệt lưu trữ khỏi tính toán và quy mô hoạt động, nhưng những đặc điểm xác định là dữ liệu đã giữ linh hoạt cộng với quản trị và quyền truy cập phân tích, không phải một vị trí triển khai duy nhất.

Sơ đồ theo đọc có nghĩa là gì?

Sơ đồ theo đọc có nghĩa là một người tiêu dùng áp dụng hoặc diễn giải cấu trúc khi dữ liệu được truy vấn thay vì yêu cầu một sơ đồ phân tích cuối cùng trước khi nguồn được lưu trữ. Nguồn vẫn có định dạng vật lý và các trường quan sát. Các nền tảng hồ tốt ghi lại những sự thật đó và xác thực chúng thay vì giả vờ rằng sơ đồ không tồn tại.

Làm thế nào một data lake trở thành một đầm lầy dữ liệu?

Một hồ chứa trở thành đầm lầy khi người dùng không thể phát hiện, tin tưởng, hiểu hoặc truy cập an toàn vào nội dung của nó. Thiếu quyền sở hữu, nguồn gốc yếu, nguồn trùng lặp, sơ đồ không được tài liệu hóa, quyền truy cập rộng, và việc giữ lại không xác định là các nguyên nhân phổ biến. Nhiều lưu trữ hơn hoặc một động cơ truy vấn mới không sửa chữa những khoảng trống quản trị đó.

Dữ liệu web công cộng có thể vào một data lake không?

Có, khi tổ chức có một mục đích đã được phê duyệt và tuân theo các yêu cầu về quyền truy cập, quyền riêng tư, bản quyền, hợp đồng, và giữ lại áp dụng. Tài liệu thu thập nên bảo tồn URL nguồn, bối cảnh thu thập, trạng thái xác thực, và quyền sở hữu. Các đầu ra đã được chỉnh sửa nên duy trì nguồn gốc trở lại với đối tượng nguồn được quản lý.