[ad_1]
Bảng Delta trong một kiến trúc huy chương thường được sử dụng để tạo ra các sản phẩm dữ liệu. Những sản phẩm dữ liệu này được sử dụng cho khoa học dữ liệu, phân tích dữ liệu và báo cáo. Tuy nhiên, một câu hỏi phổ biến là hiển thị các sản phẩm dữ liệu thông qua API REST. Ý tưởng là nhúng các API này vào các ứng dụng internet có yêu cầu hiệu suất nghiêm ngặt hơn. Các câu hỏi quan trọng như sau:
- Việc đọc dữ liệu từ bảng delta có đủ nhanh để phục vụ các ứng dụng internet không?
- Có cần lớp điện toán để giúp giải pháp có khả năng mở rộng tốt hơn không?
- Lớp lưu trữ có cần thiết để đạt được các yêu cầu nghiêm ngặt về hiệu suất không?
Để tìm hiểu sâu hơn về những câu hỏi này, ba kiến trúc được đánh giá như sau: kiến trúc A — thư viện trong API, kiến trúc B — lớp tính toán và kiến trúc C — lớp lưu trữ. Xem thêm hình ảnh dưới đây.
Trong phần còn lại của bài đăng trên weblog, ba kiến trúc sẽ được mô tả, triển khai và thử nghiệm. Sau đó, một kết luận được đưa ra.
2.1 Kiến trúc A: Thư viện trong API sử dụng DuckDB và PyArrow
Trong kiến trúc này, các API kết nối trực tiếp với các bảng delta và không có lớp điện toán nào ở giữa. Điều này ngụ ý rằng dữ liệu được phân tích bằng cách sử dụng bộ nhớ và tính toán của chính API. Để cải thiện hiệu suất, thư viện Python của cơ sở dữ liệu nhúng DuckDB Và PyMũi Tên được sử dụng. Các thư viện này đảm bảo rằng chỉ tải dữ liệu có liên quan (ví dụ: chỉ các cột mà API cần).
Ưu điểm của kiến trúc này là dữ liệu không cần phải trùng lặp và không cần có lớp nào giữa API và bảng delta. Điều này có nghĩa là ít bộ phận chuyển động hơn.
Nhược điểm của kiến trúc này là khó mở rộng quy mô hơn và tất cả công việc cần được thực hiện trong bộ nhớ và tính toán của chính API. Điều này đặc biệt khó khăn nếu có nhiều dữ liệu cần được phân tích. Điều này có thể đến từ nhiều bản ghi, cột lớn và/hoặc nhiều yêu cầu đồng thời.
2.2 Kiến trúc B: Lớp điện toán sử dụng Synapse, Databricks hoặc Cloth
Trong kiến trúc này, các API đang kết nối với lớp điện toán chứ không phải trực tiếp với các bảng delta. Lớp tính toán này lấy dữ liệu từ các bảng delta và sau đó phân tích dữ liệu. Lớp tính toán có thể Azure Synapse, Dữ liệu Azurehoặc Vải Microsoft và thường có quy mô tốt. Dữ liệu không được sao chép sang lớp điện toán, mặc dù bộ nhớ đệm có thể được áp dụng trong lớp điện toán. Trong phần còn lại của weblog này đã được thử nghiệm với Synapse không có máy chủ.
Ưu điểm của kiến trúc này là dữ liệu không bị trùng lặp và kiến trúc có quy mô tốt. Hơn nữa, nó có thể được sử dụng để xử lý các tập dữ liệu lớn.
Nhược điểm của kiến trúc này là cần có một lớp bổ sung giữa API và bảng delta. Điều này có nghĩa là cần phải bảo trì và bảo đảm nhiều bộ phận chuyển động hơn.
2.3 Kiến trúc C: Lớp lưu trữ được tối ưu hóa bằng Azure SQL hoặc Cosmos DB
Trong kiến trúc này, các API không kết nối với các bảng delta mà kết nối với một lớp lưu trữ khác trong đó các bảng delta được sao chép. Lớp lưu trữ khác nhau có thể là Azure SQL hoặc Cosmos DB. Lớp lưu trữ có thể được tối ưu hóa để truy xuất dữ liệu nhanh chóng. Phần còn lại của weblog này được thử nghiệm với Azure SQL.
Ưu điểm của kiến trúc này là lớp lưu trữ có thể được tối ưu hóa để đọc dữ liệu nhanh bằng cách sử dụng các chỉ mục, phân vùng và chế độ xem cụ thể hóa. Đây thường là một yêu cầu trong các tình huống của ứng dụng internet phản hồi yêu cầu.
Nhược điểm của kiến trúc này là dữ liệu cần được sao chép và cần có một lớp bổ sung giữa API và bảng delta. Điều này có nghĩa là cần phải bảo trì và bảo đảm nhiều bộ phận chuyển động hơn.
Trong phần còn lại của weblog, các kiến trúc sẽ được triển khai và thử nghiệm.
3.1 Triển khai kiến trúc
Để triển khai các kiến trúc, một dự án GitHub được tạo để triển khai ba giải pháp như đã thảo luận trong chương trước. Dự án có thể được tìm thấy trong liên kết dưới đây:
https://github.com/rebremer/expose-deltatable-via-restapi
Những điều sau đây sẽ được triển khai khi dự án GitHub được thực thi:
- Bảng delta có nguồn gốc từ tập dữ liệu thử nghiệm tiêu chuẩn WideWorldImporterdDW đầy đủ. Tập dữ liệu thử nghiệm bao gồm 50M bản ghi và 22 cột với 1 cột mô tả lớn.
- Tất cả các kiến trúc: Chức năng Azure hoạt động như API.
- Kiến trúc B: Synapse Serverless đóng vai trò là lớp điện toán.
- Kiến trúc C: Azure SQL hoạt động như lớp lưu trữ được tối ưu hóa.
Sau khi triển khai, các thử nghiệm có thể được thực hiện. Các bài kiểm tra được mô tả trong đoạn tiếp theo.
3.2 Kiến trúc thử nghiệm
Để kiểm tra kiến trúc, các loại truy vấn khác nhau và tỷ lệ khác nhau sẽ được áp dụng. Các loại truy vấn khác nhau có thể được mô tả như sau:
- Tra cứu 20 bản ghi với 11 cột nhỏ (char, số nguyên, datetime).
- Tra cứu 20 bản ghi với 2 cột trong đó có một cột mô tả lớn chứa hơn 500 ký tự cho mỗi trường.
- Tổng hợp dữ liệu sử dụng nhóm theo, có, tối đa, trung bình.
Các truy vấn được mô tả dưới đây.
-- Question 1: Level lookup 11 columns with out massive texts
SELECT SaleKey, TaxAmount, CityKey, CustomerKey, BillToCustomerKey, SalespersonKey, DeliveryDateKey, Bundle
FROM silver_fact_sale
WHERE CityKey=41749 and SalespersonKey=40 and CustomerKey=397 and TaxAmount > 20
-- Question 2: Description column with greater than 500 characters
SELECT SaleKey, Description
FROM silver_fact_sale
WHERE CityKey=41749 and SalespersonKey=40 and CustomerKey=397 and TaxAmount > 20
-- Question 3: Aggregation
SELECT MAX(DeliveryDateKey), CityKey, AVG(TaxAmount)
FROM silver_fact_sale
GROUP BY CityKey
HAVING COUNT(CityKey) > 10
Việc chia tỷ lệ có thể được mô tả như sau:
- Đối với kiến trúc A, việc xử lý dữ liệu sẽ được thực hiện trong chính API. Điều này có nghĩa là khả năng tính toán và bộ nhớ của API được sử dụng thông qua kế hoạch dịch vụ ứng dụng. Những điều này sẽ được thử nghiệm với cả hai Mã hàng cơ bản (1 lõi và bộ nhớ 1,75 GB) và SKU P1V3 SKU (2 lõi, bộ nhớ 8 GB). Đối với kiến trúc B và C, điều này không liên quan vì quá trình xử lý được thực hiện ở nơi khác.
- Đối với kiến trúc B, Synapse Serverless được sử dụng. Việc chia tỷ lệ sẽ được thực hiện tự động.
- Đối với kiến trúc C, cơ sở dữ liệu Azure SQL của cấp tiêu chuẩn được chụp với 125 DTU. Sẽ có thử nghiệm không có chỉ mục và có chỉ mục trên CityKey.
Trong đoạn tiếp theo, kết quả được mô tả.
3.3 Kết quả
Sau khi triển khai và thử nghiệm các kiến trúc, có thể thu được kết quả. Đây là bản tóm tắt kết quả:
Kiến trúc A không thể được triển khai với SKU B1. Trong trường hợp sử dụng SKU P1V3 thì kết quả có thể được tính trong vòng 15 giây trong trường hợp kích thước cột không quá lớn. Lưu ý rằng tất cả dữ liệu được phân tích trong gói dịch vụ ứng dụng API. Nếu tải quá nhiều dữ liệu (thông qua nhiều hàng, cột lớn và/hoặc nhiều yêu cầu đồng thời), kiến trúc này khó có thể mở rộng quy mô.
Kiến trúc B sử dụng Synapse Serverless sẽ hoạt động trong vòng 10–15 giây. Quá trình tính toán được thực hiện trên Synapse Serverless, được điều chỉnh tự động để tìm nạp và phân tích dữ liệu. Hiệu suất nhất quán cho cả ba loại truy vấn.
Kiến trúc C sử dụng Azure SQL hoạt động tốt nhất khi tạo chỉ mục. Để tra cứu truy vấn 1 và 2, API sẽ phản hồi sau khoảng 1 giây. Truy vấn 3 yêu cầu quét toàn bộ bảng và hiệu suất ít nhiều tương đương với các giải pháp khác.
Bảng Delta trong một kiến trúc huy chương thường được sử dụng để tạo ra các sản phẩm dữ liệu. Những sản phẩm dữ liệu này được sử dụng cho khoa học dữ liệu, phân tích dữ liệu và báo cáo. Tuy nhiên, một câu hỏi phổ biến là hiển thị các bảng delta thông qua API REST. Trong bài đăng trên weblog này, ba kiến trúc được mô tả cùng với những ưu và nhược điểm của nó.
Kiến trúc A: Thư viện trong API sử dụng DuckDB và PyArrow.
Trong kiến trúc này, các API kết nối trực tiếp với các bảng delta và không có lớp nào ở giữa. Điều này ngụ ý rằng tất cả dữ liệu được phân tích trong bộ nhớ và tính toán của Chức năng Azure.
- Ưu điểm của kiến trúc này là không cần thêm tài nguyên. Điều này có nghĩa là ít bộ phận chuyển động cần được bảo trì và bảo đảm hơn.
- Nhược điểm của kiến trúc này là nó không có khả năng mở rộng tốt vì tất cả dữ liệu cần được phân tích trong chính API. Vì vậy, nó chỉ được sử dụng cho lượng dữ liệu nhỏ.
Kiến trúc B: Lớp tính toán sử dụng Synapse, Databricks hoặc Cloth.
Trong kiến trúc này, các API đang kết nối với lớp điện toán. Lớp tính toán này tìm nạp và phân tích dữ liệu từ các bảng delta.
- Ưu điểm của kiến trúc này là nó có khả năng mở rộng tốt và dữ liệu không bị trùng lặp. Nó hoạt động tốt cho các truy vấn thực hiện tổng hợp và xử lý các tập dữ liệu lớn.
- Nhược điểm của kiến trúc này là không thể nhận được phản hồi trong vòng 5 giây để tra cứu truy vấn một cách nhất quán. Ngoài ra, các nguồn lực bổ sung cần được bảo đảm và duy trì.
Kiến trúc C: Lớp lưu trữ được tối ưu hóa bằng Azure SQL hoặc Cosmos DB.
Trong kiến trúc này, các API đang kết nối với lớp lưu trữ được tối ưu hóa. Các bảng Delta được sao chép trước vào lớp lưu trữ này và lớp lưu trữ được sử dụng để tìm nạp và phân tích dữ liệu.
- Ưu điểm của kiến trúc này là nó có thể được tối ưu hóa để truy vấn nhanh các tra cứu bằng cách sử dụng chỉ mục, phân vùng, chế độ xem cụ thể hóa. Đây thường là yêu cầu đối với các ứng dụng internet phản hồi yêu cầu.
- Nhược điểm của kiến trúc này là dữ liệu được sao chép sang một lớp lưu trữ khác, cần được giữ đồng bộ. Ngoài ra, các nguồn lực bổ sung cần được bảo đảm và duy trì.
Thật không could, không có giải pháp viên đạn bạc. Bài viết này nhằm mục đích đưa ra hướng dẫn trong việc chọn kiến trúc tốt nhất để hiển thị các bảng delta thông qua API REST.
[ad_2]
Source link