DuckDB là gì?

Định nghĩa DuckDB

DuckDB là một hệ thống quản lý cơ sở dữ liệu quan hệ phân tích được thiết kế để chạy bên trong một quá trình khác. Nó phơi bày SQL và API khách trong khi engine thực thi cục bộ trong chương trình dòng lệnh, kernel sổ tay, quy trình dịch vụ hoặc ứng dụng đã tải nó. Mô hình nhúng này loại bỏ một máy chủ riêng biệt khỏi nhiều quy trình phân tích nút đơn.

Engine tập trung vào xử lý phân tích trực tuyến: quét các cột, lọc nhiều hàng, nối quan hệ và tính toán tổng hợp. Nó có thể đọc các định dạng tệp và cấu trúc dữ liệu được hỗ trợ thông qua các kết nối, sau đó đẩy các phần của một truy vấn về phía nguồn để các cột và hàng không cần thiết không di chuyển qua từng giai đoạn. Thuật ngữ chính được sử dụng ở đây theo tổng quan dự án DuckDB, điều này mang lại cho khái niệm một ranh giới kỹ thuật cụ thể thay vì coi nó là một nhãn tiếp thị.

Một định nghĩa hữu ích cũng cho biết những gì khái niệm không làm. DuckDB không phải là một dịch vụ kho dữ liệu đã quản lý, một bộ lập lịch cụm phân phối, hoặc một sự thay thế chung cho một cơ sở dữ liệu hoạt động mà phối hợp nhiều người viết ứng dụng đồng thời. Nó có thể giữ các cơ sở dữ liệu, nhưng việc triển khai và chia sẻ lựa chọn vẫn là trách nhiệm của chủ sở hữu ứng dụng. Giữ cho ranh giới đó rõ ràng ngăn ngừa các sơ đồ kiến trúc giao cho các cam kết cho một thành phần thuộc về một lớp khác.

Cách DuckDB thực thi các truy vấn phân tích

Một truy vấn DuckDB đi qua phân tích cú pháp, liên kết, lập kế hoạch logic, tối ưu hóa và thực thi vật lý bên trong quy trình chủ. Truy cập trực tiếp vào bộ nhớ và tệp cục bộ có thể loại bỏ các ranh giới tuần tự mà một cơ sở dữ liệu khách-máy chủ sẽ yêu cầu.

1. Ứng dụng chủ mở một cơ sở dữ liệu DuckDB trong bộ nhớ hoặc bền bỉ thông qua một API khách hoặc phiên dòng lệnh.
2. SQL được phân tích và liên kết với các bảng, chế độ xem, tệp hoặc đối tượng trong bộ nhớ đã đăng ký với các kiểu đã biết.
3. Bộ tối ưu hóa viết lại kế hoạch logic để giảm dữ liệu đã quét và chọn chiến lược nối và tổng hợp.
4. Các toán tử vector hóa xử lý các lô giá trị cột và có thể sử dụng nhiều lõi CPU cho công việc phù hợp.
5. Kết quả vẫn ở trong quy trình chủ hoặc di chuyển qua một lớp tương tác đến một DataFrame, bảng Arrow, tệp hoặc người tiêu dùng ứng dụng.

Ranh giới trong quá trình là lựa chọn thiết kế trung tâm. Nó đơn giản hóa việc triển khai cục bộ và có thể giảm chuyển động dữ liệu, nhưng sự cố quy trình, giới hạn bộ nhớ, hành vi hệ thống tệp và vòng đời ứng dụng ảnh hưởng trực tiếp đến cơ sở dữ liệu. Các kiểm soát tài nguyên thuộc về cùng một thiết kế hoạt động như truy vấn. Hành vi này được tài liệu hóa đầy đủ hơn trong bài báo cơ sở dữ liệu nhúng DuckDB. Nguồn này 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 ẩn dụ rộng rãi.

Kiến trúc DuckDB ở cái nhìn tổng quan

Mô hình nhúng là một lợi thế khi đơn vị phân tích thuộc về một quy trình và dữ liệu có thể truy cập từ máy chủ đó. Một dịch vụ chia sẻ, cách ly đa người dùng nghiêm ngặt, hoặc tính toán quy mô cụm có thể biện minh cho một giới hạn cơ sở dữ liệu khác ngay cả khi DuckDB vẫn hữu ích cho việc chuẩn bị hoặc thử nghiệm.

Nơi DuckDB phù hợp nhất

Các trường hợp sử dụng này chia sẻ một quy tắc lựa chọn: chọn DuckDB vì mô hình thực thi và 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. Chọn DuckDB khi tính biểu cảm SQL và thực thi phân tích cục bộ đơn giản hóa quy trình làm việc. Chọn một giới hạn dịch vụ khi người dùng cần mở rộng độc lập, quản lý khối lượng công việc tập trung, tính khả dụng cao hoặc nhiều người viết đồng thời.

Tệp, Bộ nhớ và Giới hạn Quy trình

Các quyết định áp dụng nên xác định đơn vị cách ly. Quyết định xem liệu một notebook, công việc theo lô, ứng dụng desktop, yêu cầu, hoặc dịch vụ chạy lâu dài sở hữu kết nối cơ sở dữ liệu, tệp, ngân sách bộ nhớ và vòng đời kết quả.

• Đẩy bộ lọc và hình chiếu sớm. Chỉ đọc các hàng và cột mà kết quả phân tích yêu cầu.
• Giữ kết quả lớn ở dạng cột. Tránh chuyển đổi một kết quả phân tích nhỏ gọn thành hàng triệu đối tượng ngôn ngữ máy chủ mà không cần thiết.
• Kiểm soát bộ nhớ và vị trí trào ra. Quy trình máy chủ và động cơ truy vấn chia sẻ tài nguyên máy và nên có ngân sách rõ ràng.
• Xem tệp như các tập dữ liệu. Các tên phân vùng, lược đồ, phiên bản và bản kê xác định liệu các truy vấn tệp trực tiếp có thể tái sản xuất hay không.
• Định nghĩa quyền sở hữu người viết. Các quy trình đồng thời không nên giả định rằng có thể ghi chép không hạn chế vào một tệp cơ sở dữ liệu cục bộ.

Parquet là một đối tác phổ biến vì bố cục cột và siêu dữ liệu của nó cho phép một động cơ phân tích tránh đọc các cột không liên quan và đôi khi bỏ qua các nhóm hàng. Chất lượng tệp, chiến lược phân vùng và sự nhất quán lược đồ vẫn quan trọng; một định dạng mở không tự động tạo ra một tập dữ liệu được quản lý. Một tài liệu tham khảo chính liên quan là Tài liệu Apache Parquet, điều này làm rõ các giả định về lưu trữ, thực thi hoặc khả năng tương tác đằng sau sự lựa chọn đó.

Các Hình Thức Lạm Dụng và Thất Bại của DuckDB

DuckDB dễ dàng khởi động, điều này có thể ẩn đi các giả định trong sản xuất. Một notebook hoạt động trên một tệp không xác định giới hạn bộ nhớ, danh tính đầu vào, độ trôi lạc lược đồ, chia sẻ hoặc khôi phục cho một pipeline đã lên lịch.

• Hiện thực hóa mọi thứ. Chuyển đổi kết quả truy vấn đầy đủ thành các đối tượng máy chủ có thể chiếm ưu thế bộ nhớ và xóa lợi thế cột.
• Xem đường dẫn tệp như quản lý. Một đường dẫn đơn không xác định phiên bản nguồn, lược đồ, chủ sở hữu, chất lượng hoặc thời gian lưu giữ.
• Giả định về ngữ nghĩa máy chủ. Một động cơ nhúng chia sẻ vòng đời quy trình máy chủ và không cung cấp mọi hành vi dịch vụ được quản lý.
• Bỏ qua độ trôi lạc kiểu. Sự suy diễn CSV và việc thay đổi các trường JSON có thể làm thay đổi kết quả trừ khi các kiểu tiếp nhận được kiểm soát.
• Đánh giá dữ liệu thử nghiệm được lưu cache. Một bài kiểm tra hữu ích bao gồm các tệp tiêu biểu, kết hợp, di chuyển kết quả, đọc lạnh, và công việc downstream.

Một thất bại nên được truy tìm về lớp chịu trách nhiệm nhỏ nhất. Khi một công việc chậm lại, hãy kiểm tra kế hoạch truy vấn, các tệp đã quét, các bộ lọc đã đẩy, trung gian đã hiện thực hóa, bộ nhớ, đường dẫn trào ra, và chuyển đổi kết quả trước khi thay thế động cơ. Thực hành này tạo ra một hành động khắc phục hữu ích thay vì chỉ dẫn mơ hồ để thêm nhiều dung lượng hơn.

Truy vấn Dữ liệu Web đã Thu thập bằng DuckDB

Một quy trình làm việc với dữ liệu web nhỏ gọn có thể lấy một trang đã được phê duyệt, trích xuất các quan sát đã gõ, ghi Parquet phân vùng và truy vấn kết quả bằng DuckDB. Các giai đoạn nên giữ tách biệt để một vấn đề thu thập không bị nhầm lẫn với một vấn đề SQL hoặc lược đồ.

Đố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 bắt đầu xử lý downstream. Hồ sơ đã chuẩn hóa nên giữ lại URL nguồn, thời gian quan sát, phiên bản trích xuất, và một khóa kinh doanh ổn định bên cạnh các trường phân tích. Sự chuyển giao đó mang đến 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 giải thích.

Scrapeless xử lý bước thu thập web được quản lý như đã 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 lưu giữ, kiểm soát truy cập, và xác thực. Scrapeless lấy nội dung công cộng được yêu cầu; mã phân tích xác định các trường; DuckDB thực hiện công việc phân tích cục bộ; ứng dụng xung quanh sở hữu quyền, giới hạn tài nguyên, xác thực, và công bố. 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 thử nghiệm hơn.

Pipeline nên bảo tồn cả bằng chứng thô và đầu ra đã biên soạn khi trường hợp sử dụng cần khả năng kiểm toán. Nguyên 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 đã biên soạn hỗ trợ phân tích ổn định. Bảo tồn bằng chứng nguồn khi cần thiết, nhưng truy vấn các tệp đã gõ theo kiểu để phân tích lặp lại để các thay đổi HTML hoặc trình bày không trở thành những thay đổi số liệu im lặng. 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ị nhầm lẫn là các bản sao.

Danh sách kiểm tra việc áp dụng DuckDB

Sử dụng các câu hỏi sau trong đánh giá thiết kế. Một câu trả lời bằng văn bản có giá trị hơn so với mặc định giả định vì nó cho thấy nơi các nhóm không đồng ý về DuckDB.

• Tải công việc có cần SQL phân tích trong một quá trình không?
• Tệp đầu vào nằm ở đâu, và các phiên bản được xác định như thế nào?
• Những bộ lọc và phép chiếu nào có thể được đẩy về phía nguồn?
• Ngân sách bộ nhớ và lưu trữ tạm thời là bao nhiêu?
• Các lược đồ và hành vi null sẽ được kiểm tra như thế nào?
• Ai sở hữu các ghi vào tệp cơ sở dữ liệu vĩnh viễn?
• Kết quả sau khi nó vượt vào ngôn ngữ chủ nhà lớn ra sao?
• Yêu cầu nào sẽ buộc một ranh giới dịch vụ được quản lý hoặc phân tán?

DuckDB rất phù hợp khi có một máy chủ có thể tiếp cận dữ liệu được quản lý, SQL diễn đạt quá trình chuyển đổi rõ ràng, và ranh giới quá trình cung cấp sự cách ly và vòng đời cần thiết. Xem lại các câu trả lời sau khi hình dạng tải công việc, thể tích 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ô thử nghiệm có thể không phù hợp cho một lộ trình sản xuất liên tục.

Kết luận

DuckDB là một động cơ SQL phân tích nhúng mang lại thực thi truy vấn theo cột, theo vector gần với tệp và bộ nhớ ứng dụng. Nó hoạt động tốt cho phân tích địa phương, các công việc pipeline, sổ tay, kiểm tra và sản phẩm dữ liệu nhúng. Việc sử dụng thành công vẫn yêu cầu các đầu vào được quản lý, các giới hạn tài nguyên rõ ràng, di chuyển kết quả có kiểm soát, và một ranh giới rõ ràng cho việc chia sẻ và ghi. Chọn nó cho hình dạng của đơn vị phân tích, không chỉ vì sự thuận tiện khi thiết lập.

Tài liệu tham khảo

• Giới thiệu về Scrapeless Web Unlocker
• Tổng quan về sản phẩm Scrapeless Web Unlocker
• Hướng dẫn Scrapeless về quy trình dữ liệu văn bản web sạch
• Các dự án mã nguồn mở Scrapeless trên GitHub