Dưới đây là bản dịch tiếng Việt của tài liệu được cung cấp, giữ nguyên cấu trúc, các tiêu đề, và các liên kết của bài gốc (đã thay đổi thành dấu chấm để phù hợp với yêu cầu). Các thuật ngữ như “Data Warehouse”, “Data Lake”, “Deep Learning”, “Big Data” được giữ nguyên. Các khái niệm được dịch sang tiếng Việt nhưng giữ từ gốc tiếng Anh trong ngoặc. Các phần liên quan đến hình ảnh được đánh dấu để bạn cập nhật trên WordPress.

---

Sử dụng Azure Synapse Analytics để thiết kế giải pháp BI doanh nghiệp

Power BI . Azure Synapse Analytics . Azure Data Factory . Microsoft Entra ID . Azure Blob Storage

Bài viết này mô tả cách chuyển dữ liệu từ một Data Warehouse tại chỗ (on-premises) sang môi trường đám mây và sau đó sử dụng mô hình trí tuệ kinh doanh (business intelligence – BI) để phục vụ dữ liệu. Bạn có thể sử dụng phương pháp này như mục tiêu cuối cùng hoặc bước đầu tiên hướng tới hiện đại hóa hoàn toàn với các thành phần dựa trên đám mây.

Hướng dẫn này dựa trên kịch bản từ đầu đến cuối của Azure Synapse Analytics. Quy trình này sử dụng các pipeline của Azure Synapse Analytics để nhập dữ liệu từ cơ sở dữ liệu SQL vào các SQL pool. Sau đó, nó thực hiện chuyển đổi dữ liệu để phân tích. Bài viết này tập trung vào các pipeline của Azure Synapse Analytics, nhưng bạn cũng có thể sử dụng các pipeline của Azure Data Factory hoặc Fabric Data Factory để thực hiện các tác vụ này.

Khi nào nên sử dụng kiến trúc này

Bạn có thể sử dụng nhiều phương pháp khác nhau để đáp ứng các yêu cầu kinh doanh cho BI doanh nghiệp. Các yêu cầu kinh doanh được xác định bởi nhiều yếu tố, chẳng hạn như đầu tư công nghệ hiện tại, kỹ năng con người, thời gian biểu cho việc hiện đại hóa, mục tiêu tương lai, và liệu bạn có ưu tiên cho nền tảng dưới dạng dịch vụ (Platform as a Service – PaaS) hay phần mềm dưới dạng dịch vụ (Software as a Service – SaaS).

Hãy xem xét các cách tiếp cận thiết kế sau:

• Một lakehouse trong Microsoft Fabric.
• Fabric và Azure Databricks dành cho khách hàng đã đầu tư vào Azure Databricks và Power BI và muốn hiện đại hóa với Fabric.
• BI doanh nghiệp cho các doanh nghiệp vừa và nhỏ sử dụng hệ sinh thái Azure SQL và Fabric.
• Data Warehouse hoàn toàn trên Fabric cho khách hàng ưu tiên SaaS.

Kiến trúc trong bài viết này giả định rằng bạn sử dụng Data Warehouse của Azure Synapse Analytics làm tầng lưu trữ lâu dài (persistent layer) của mô hình ngữ nghĩa doanh nghiệp (enterprise semantic model) và sử dụng Power BI cho trí tuệ kinh doanh. Cách tiếp cận PaaS này có tính linh hoạt để đáp ứng các yêu cầu và sở thích kinh doanh khác nhau.

Kiến trúc

Hình ảnh: [Đánh dấu để cập nhật trên WordPress – Kiến trúc sơ đồ]

---

Tải xuống tệp Visio của kiến trúc này.

Quy trình làm việc

Nguồn dữ liệu

• Cơ sở dữ liệu SQL Server trên Azure chứa dữ liệu nguồn. Để mô phỏng môi trường tại chỗ, các kịch bản triển khai cho tình huống này cấu hình một cơ sở dữ liệu Azure SQL. Cơ sở dữ liệu mẫu AdventureWorks được sử dụng làm lược đồ dữ liệu nguồn và dữ liệu mẫu. Để biết thêm thông tin, xem Sao chép và chuyển đổi dữ liệu đến và từ SQL Server.

Nhập và lưu trữ dữ liệu

• Azure Data Lake Storage là khu vực tạm thời (staging area) trong quá trình nhập dữ liệu. Bạn có thể sử dụng PolyBase để sao chép dữ liệu vào SQL pool chuyên dụng của Azure Synapse Analytics.
• Azure Synapse Analytics là một hệ thống phân tán thực hiện phân tích trên dữ liệu lớn (Big Data). Nó hỗ trợ xử lý song song quy mô lớn (massive parallel processing), vì vậy có thể chạy các phân tích hiệu suất cao. SQL pool chuyên dụng của Azure Synapse Analytics là đích đến cho việc nhập dữ liệu liên tục từ môi trường tại chỗ. SQL pool có thể phục vụ dữ liệu cho Power BI thông qua DirectQuery và thực hiện xử lý thêm.
• Các pipeline của Azure Synapse Analytics điều phối việc nhập và chuyển đổi dữ liệu trong không gian làm việc của Azure Synapse Analytics.

Phân tích và báo cáo

• Phương pháp mô hình hóa dữ liệu trong kịch bản này kết hợp mô hình doanh nghiệp (enterprise model) và mô hình ngữ nghĩa BI (BI semantic model). SQL pool chuyên dụng của Azure Synapse Analytics chứa mô hình doanh nghiệp. Dung lượng Power BI Premium F64 chứa mô hình ngữ nghĩa BI. Power BI truy cập dữ liệu thông qua DirectQuery.

Thành phần

Kịch bản này sử dụng các thành phần sau:

• Azure SQL Database là máy chủ SQL PaaS được lưu trữ trên Azure. Kiến trúc này sử dụng SQL Database để thể hiện luồng dữ liệu cho kịch bản di chuyển.
• Data Lake Storage cung cấp lưu trữ đám mây linh hoạt cho dữ liệu không cấu trúc (unstructured data) được sử dụng để lưu trữ kết quả trung gian của quá trình di chuyển.
• Azure Synapse Analytics là dịch vụ phân tích doanh nghiệp cho Data Warehouse và hệ thống Big Data. Azure Synapse Analytics đóng vai trò là bộ tính toán chính (main compute) và lưu trữ lâu dài trong mô hình ngữ nghĩa doanh nghiệp và phục vụ dữ liệu.
• Power BI Premium là công cụ BI trình bày và trực quan hóa dữ liệu trong kịch bản này.
• Microsoft Entra ID là bộ giải pháp danh tính và mạng đa đám mây (multicloud) hỗ trợ luồng xác thực (authentication) và ủy quyền (authorization).

Kiến trúc đơn giản hóa

Hình ảnh: [Đánh dấu để cập nhật trên WordPress – Sơ đồ kiến trúc đơn giản hóa]

Chi tiết kịch bản

Trong kịch bản này, một tổ chức có cơ sở dữ liệu SQL chứa Data Warehouse lớn tại chỗ. Tổ chức muốn sử dụng Azure Synapse Analytics để thực hiện phân tích, sau đó cung cấp những hiểu biết này qua Power BI cho người dùng và các phân tích.

Xác thực

Microsoft Entra ID xác thực người dùng kết nối với các bảng điều khiển (dashboards) và ứng dụng Power BI. Đăng nhập một lần (single sign-on) kết nối người dùng với nguồn dữ liệu trong SQL pool được cấp phép của Azure Synapse Analytics. Ủy quyền diễn ra tại nguồn.

Tải tăng dần (Incremental Loading)

Khi bạn chạy một quy trình tự động trích xuất, chuyển đổi, tải (extract, transform, load – ETL) hoặc trích xuất, tải, chuyển đổi (extract, load, transform – ELT), bạn nên chỉ tải dữ liệu đã thay đổi kể từ lần chạy trước. Quá trình này được gọi là tải tăng dần (incremental load). Ngược lại, tải toàn bộ (full load) sẽ tải tất cả dữ liệu. Để thực hiện tải tăng dần, hãy xác định cách nhận diện dữ liệu đã thay đổi. Bạn có thể sử dụng phương pháp giá trị mốc cao (high water mark), theo dõi giá trị mới nhất của một cột ngày-giờ (date-time) hoặc cột số nguyên duy nhất (unique integer) trong bảng nguồn.

Bạn có thể sử dụng bảng thời gian (temporal tables) trong SQL Server. Bảng thời gian là các bảng có phiên bản hệ thống (system-versioned tables) lưu trữ lịch sử thay đổi dữ liệu. Công cụ cơ sở dữ liệu tự động ghi lại lịch sử của mọi thay đổi trong một bảng lịch sử riêng biệt. Để truy vấn dữ liệu lịch sử, bạn có thể thêm mệnh đề FOR SYSTEM_TIME vào truy vấn. Bên trong, công cụ cơ sở dữ liệu truy vấn bảng lịch sử, nhưng điều này trong suốt với ứng dụng.

Bảng thời gian hỗ trợ dữ liệu chiều (dimension data), có thể thay đổi theo thời gian. Bảng sự kiện (fact tables) thường biểu thị một giao dịch bất biến (immutable transaction) như một lần bán hàng, trong trường hợp đó việc giữ lịch sử phiên bản hệ thống không có ý nghĩa. Thay vào đó, các giao dịch thường có một cột biểu thị ngày giao dịch (transaction date). Cột này có thể được sử dụng làm giá trị mốc (watermark value). Ví dụ, trong Data Warehouse AdventureWorks, các bảng SalesLT.* có trường LastModified.

Dưới đây là luồng chung cho pipeline ELT:

1. Đối với mỗi bảng trong cơ sở dữ liệu nguồn, theo dõi thời điểm cắt (cutoff time) khi công việc ELT cuối cùng chạy. Lưu trữ thông tin này trong Data Warehouse. Trong thiết lập ban đầu, tất cả các thời điểm được đặt là 1-1-1900.
2. Trong bước xuất dữ liệu, thời điểm cắt được truyền dưới dạng tham số cho một tập hợp các thủ tục lưu trữ (stored procedures) trong cơ sở dữ liệu nguồn. Các thủ tục lưu trữ này truy vấn bất kỳ bản ghi nào được thay đổi hoặc tạo sau thời điểm cắt. Đối với tất cả các bảng trong ví dụ, bạn có thể sử dụng cột ModifiedDate.
3. Khi việc di chuyển dữ liệu hoàn tất, cập nhật bảng lưu trữ thời điểm cắt.

Pipeline dữ liệu

Kịch bản này sử dụng cơ sở dữ liệu mẫu AdventureWorks làm nguồn dữ liệu. Mô hình tải dữ liệu tăng dần đảm bảo rằng chỉ dữ liệu được sửa đổi hoặc thêm vào sau lần chạy pipeline gần nhất được tải.

Công cụ sao chép dựa trên siêu dữ liệu (Metadata-driven Copy Tool)

Công cụ sao chép dựa trên siêu dữ liệu tích hợp trong các pipeline của Azure Synapse Analytics tải tăng dần tất cả các bảng chứa trong cơ sở dữ liệu quan hệ.

1. Sử dụng giao diện wizard để kết nối Công cụ Sao chép Dữ liệu (Copy Data Tool) với cơ sở dữ liệu nguồn.
2. Sau khi kết nối, cấu hình tải tăng dần hoặc tải toàn bộ cho mỗi bảng.
3. Công cụ Sao chép Dữ liệu tạo các pipeline và kịch bản SQL cần thiết để tạo bảng điều khiển (control table). Bảng này lưu trữ dữ liệu, chẳng hạn như giá trị mốc cao hoặc cột cho mỗi bảng, cho quá trình tải tăng dần.
4. Sau khi các kịch bản này chạy, pipeline tải tất cả các bảng Data Warehouse nguồn vào SQL pool chuyên dụng của Azure Synapse Analytics.

Trước khi công cụ tải dữ liệu, nó tạo ba pipeline để lặp qua các bảng trong cơ sở dữ liệu. Các pipeline thực hiện các tác vụ sau:

• Đếm số lượng đối tượng, chẳng hạn như các bảng, sẽ được sao chép trong lần chạy pipeline.
• Lặp qua mỗi đối tượng sẽ được tải hoặc sao chép.
• Sau khi pipeline lặp qua mỗi đối tượng, nó thực hiện các tác vụ sau:
• Kiểm tra xem có cần tải delta (delta load) hay không. Nếu không, pipeline hoàn thành tải toàn bộ bình thường.
• Lấy giá trị mốc cao từ bảng điều khiển.
• Sao chép dữ liệu từ các bảng nguồn vào tài khoản tạm trong Data Lake Storage.
• Tải dữ liệu vào SQL pool chuyên dụng thông qua phương pháp sao chép được chọn, chẳng hạn như PolyBase hoặc lệnh Copy.
• Cập nhật giá trị mốc cao trong bảng điều khiển.

Tải dữ liệu vào SQL pool của Azure Synapse Analytics

Hoạt động sao chép (copy activity) sao chép dữ liệu từ cơ sở dữ liệu SQL vào SQL pool của Azure Synapse Analytics. Cơ sở dữ liệu SQL trong ví dụ này nằm trên Azure, vì vậy nó sử dụng Azure integration runtime để đọc dữ liệu từ cơ sở dữ liệu SQL và ghi dữ liệu vào môi trường tạm được chỉ định.

Câu lệnh sao chép sau đó tải dữ liệu từ môi trường tạm vào SQL pool chuyên dụng của Azure Synapse Analytics.

Sử dụng các pipeline của Azure Synapse Analytics

Các pipeline trong Azure Synapse Analytics xác định một tập hợp các hoạt động được sắp xếp để hoàn thành mô hình tải tăng dần. Các trình kích hoạt thủ công (manual triggers) hoặc tự động (automatic triggers) khởi động pipeline.

Chuyển đổi dữ liệu

Cơ sở dữ liệu mẫu trong kiến trúc tham chiếu này nhỏ, vì vậy các bảng sao chép không có phân vùng được tạo ra. Đối với khối lượng công việc sản xuất, các bảng phân tán (distributed tables) có thể cải thiện hiệu suất truy vấn. Để biết thêm thông tin, xem Hướng dẫn thiết kế bảng phân tán trong Azure Synapse Analytics. Các kịch bản ví dụ chạy các truy vấn thông qua một lớp tài nguyên tĩnh (static resource class).

Trong môi trường sản xuất, hãy xem xét tạo các bảng tạm (staging tables) có phân phối vòng tròn (round-robin distribution). Sau đó, chuyển đổi và di chuyển dữ liệu vào các bảng sản xuất có chỉ mục cột (clustered columnstore indexes), mang lại hiệu suất truy vấn tổng thể tốt nhất. Chỉ mục cột được tối ưu hóa cho các truy vấn quét nhiều bản ghi (scan many records).

Chỉ mục cột không hoạt động tối ưu cho các tra cứu đơn lẻ (singleton lookups), hoặc tra cứu một hàng duy nhất. Nếu bạn cần thực hiện tra cứu đơn lẻ thường xuyên, bạn có thể thêm một chỉ mục không phân cụm (nonclustered index) vào bảng, điều này làm tăng tốc độ. Tuy nhiên, tra cứu đơn lẻ thường ít phổ biến hơn trong các kịch bản Data Warehouse so với khối lượng công việc xử lý giao dịch trực tuyến (online transaction processing). Để biết thêm thông tin, xem Chỉ mục bảng trong Azure Synapse Analytics.

Lưu ý: Các bảng cột phân cụm không hỗ trợ các kiểu dữ liệu varchar(max), nvarchar(max), hoặc varbinary(max). Nếu bạn sử dụng các kiểu dữ liệu này, hãy xem xét sử dụng heap hoặc chỉ mục phân cụm. Bạn cũng có thể cân nhắc đặt các cột này vào một bảng riêng.

Sử dụng Power BI Premium để truy cập, mô hình hóa và trực quan hóa dữ liệu

Power BI Premium hỗ trợ nhiều tùy chọn để kết nối với các nguồn dữ liệu trên Azure. Bạn có thể sử dụng các SQL pool được cấp phép của Azure Synapse Analytics để thực hiện các tác vụ sau:

• Nhập (Import): Dữ liệu được nhập vào mô hình Power BI.
• DirectQuery: Dữ liệu được kéo trực tiếp từ bộ lưu trữ quan hệ (relational storage).
• Mô hình tổng hợp (Composite model): Kết hợp Nhập cho một số bảng và DirectQuery cho các bảng khác.

Kịch bản này sử dụng bảng điều khiển DirectQuery vì lượng dữ liệu nhỏ và độ phức tạp mô hình thấp. DirectQuery ủy quyền truy vấn cho công cụ tính toán mạnh mẽ bên dưới và sử dụng các khả năng bảo mật mở rộng trên nguồn. DirectQuery đảm bảo rằng kết quả luôn nhất quán với dữ liệu nguồn mới nhất.

Chế độ Nhập cung cấp thời gian phản hồi truy vấn nhanh nhất. Hãy xem xét chế độ Nhập nếu:

• Mô hình hoàn toàn phù hợp trong bộ nhớ của Power BI.
• Độ trễ dữ liệu giữa các lần làm mới là chấp nhận được.
• Bạn yêu cầu các phép chuyển đổi phức tạp giữa hệ thống nguồn và mô hình cuối cùng.

Trong trường hợp này, người dùng cuối muốn truy cập toàn bộ dữ liệu mới nhất mà không có độ trễ trong việc làm mới Power BI, và họ muốn tất cả dữ liệu lịch sử, vượt quá dung lượng tập dữ liệu Power BI. Tập dữ liệu Power BI có thể xử lý 25-400 GB, tùy thuộc vào kích thước dung lượng. Mô hình dữ liệu trong SQL pool chuyên dụng đã ở dạng lược đồ sao (star schema) và không yêu cầu chuyển đổi, vì vậy DirectQuery là lựa chọn phù hợp.

Sử dụng Power BI Premium để quản lý mô hình lớn, báo cáo phân trang và pipeline triển khai

Hãy tận dụng điểm cuối Azure Analysis Services tích hợp. Bạn cũng có thể có dung lượng chuyên dụng với giá trị độc đáo.

Khi mô hình BI phát triển hoặc độ phức tạp của bảng điều khiển tăng, bạn có thể chuyển sang các mô hình tổng hợp (composite models) và nhập một phần các bảng tra cứu thông qua các bảng lai (hybrid tables), đồng thời nhập dữ liệu tổng hợp trước (preaggregated data). Bạn có thể bật bộ nhớ đệm truy vấn (query caching) trong Power BI cho các tập dữ liệu được nhập và sử dụng các bảng kép (dual tables) cho thuộc tính chế độ lưu trữ.

Trong mô hình tổng hợp, các tập dữ liệu đóng vai trò như một lớp truyền qua ảo (virtual pass-through layer). Khi người dùng tương tác với các hình ảnh trực quan, Power BI tạo các truy vấn SQL đến các SQL pool của Azure Synapse Analytics. Power BI xác định liệu sử dụng lưu trữ trong bộ nhớ (in-memory) hay DirectQuery dựa trên hiệu quả. Công cụ quyết định khi nào chuyển từ trong bộ nhớ sang DirectQuery và đẩy logic đến SQL pool của Azure Synapse Analytics. Tùy thuộc vào ngữ cảnh của các bảng truy vấn, chúng có thể hoạt động như các mô hình tổng hợp được lưu trữ (cached) hoặc không được lưu trữ. Bạn có thể chọn bảng nào để lưu vào bộ nhớ, kết hợp dữ liệu từ một hoặc nhiều nguồn DirectQuery, hoặc kết hợp dữ liệu nguồn DirectQuery và dữ liệu được nhập.

Khi sử dụng DirectQuery với SQL pool được cấp phép của Azure Synapse Analytics:

• Sử dụng bộ nhớ đệm tập hợp kết quả (result set caching) của Azure Synapse Analytics để lưu trữ kết quả truy vấn trong cơ sở dữ liệu người dùng cho việc sử dụng lặp lại. Phương pháp này cải thiện hiệu suất truy vấn xuống còn mili giây và giảm sử dụng tài nguyên tính toán. Các truy vấn sử dụng tập hợp kết quả được lưu trữ không tiêu tốn bất kỳ khe đồng thời (concurrency slots) nào trong Azure Synapse Analytics, vì vậy chúng không được tính vào giới hạn đồng thời hiện có.
• Sử dụng các chế độ xem vật chất hóa (materialized views) của Azure Synapse Analytics để tính toán trước, lưu trữ và duy trì dữ liệu như một bảng. Các truy vấn sử dụng toàn bộ dữ liệu hoặc một tập hợp con của dữ liệu trong các chế độ xem vật chất hóa có thể đạt được hiệu suất nhanh hơn mà không cần tham chiếu trực tiếp đến chế độ xem vật chất hóa đã xác định.

Các cân nhắc

Các cân nhắc này triển khai các trụ cột của Khung Kiến trúc Tốt của Azure (Azure Well-Architected Framework), là một tập hợp các nguyên tắc hướng dẫn mà bạn có thể sử dụng để cải thiện chất lượng của khối lượng công việc. Để biết thêm thông tin, xem Danh sách kiểm tra đánh giá thiết kế cho Khung Kiến trúc Tốt.

Bảo mật (Security)

Bảo mật cung cấp sự đảm bảo chống lại các cuộc tấn công có chủ ý và lạm dụng dữ liệu và hệ thống quý giá của bạn. Để biết thêm thông tin, xem Danh sách kiểm tra đánh giá thiết kế cho Bảo mật.

Việc hiện đại hóa đám mây đưa ra các mối quan ngại về bảo mật, chẳng hạn như vi phạm dữ liệu, lây nhiễm phần mềm độc hại (malware), và chèn mã độc (malicious code injection). Bạn cần một nhà cung cấp đámクラウド hoặc giải pháp dịch vụ có thể giải quyết các mối quan ngại của bạn vì các biện pháp bảo mật không đầy đủ có thể tạo ra các vấn đề lớn.

Kịch bản này giải quyết các mối quan ngại bảo mật đòi hỏi khắt khe nhất bằng cách sử dụng kết hợp các kiểm soát bảo mật phân lớp: kiểm soát mạng (network), danh tính (identity), quyền riêng tư (privacy), và ủy quyền (authorization). SQL pool được cấp phép của Azure Synapse Analytics lưu trữ hầu hết dữ liệu. Power BI truy cập dữ liệu thông qua DirectQuery thông qua đăng nhập một lần. Bạn có thể sử dụng Microsoft Entra ID để xác thực. Ngoài ra còn có các kiểm soát bảo mật mở rộng cho ủy quyền dữ liệu trong các pool được cấp phép.

Một số câu hỏi bảo mật phổ biến bao gồm:

• Xác định ai có thể thấy dữ liệu nào.
• Đảm bảo rằng dữ liệu của bạn tuân thủ các hướng dẫn liên bang, địa phương và công ty để giảm thiểu rủi ro vi phạm dữ liệu. Azure Synapse Analytics cung cấp nhiều khả năng bảo vệ dữ liệu để đạt được sự tuân thủ.
• Xác định cách xác minh danh tính của người dùng.
• Sử dụng Azure Synapse Analytics để kiểm soát ai có thể truy cập dữ liệu gì thông qua kiểm soát truy cập (access control) và xác thực.
• Chọn công nghệ bảo mật mạng để bảo vệ tính toàn vẹn (integrity), tính bảo mật (confidentiality), và quyền truy cập của mạng và dữ liệu của bạn.
• Giúp bảo mật Azure Synapse Analytics bằng cách sử dụng các tùy chọn bảo mật mạng.
• Chọn các công cụ để phát hiện và thông báo cho bạn về các mối đe dọa.
• Sử dụng các khả năng phát hiện mối đe dọa của Azure Synapse Analytics, chẳng hạn như kiểm toán SQL (SQL auditing), phát hiện mối đe dọa SQL (SQL threat detection), và đánh giá lỗ hổng (vulnerability assessment) để kiểm toán, bảo vệ và giám sát cơ sở dữ liệu.
• Xác định cách bảo vệ dữ liệu trong tài khoản lưu trữ của bạn.
• Sử dụng tài khoản Azure Storage cho các khối lượng công việc yêu cầu thời gian phản hồi nhanh và nhất quán hoặc có số lượng thao tác nhập/xuất (input/output operations – IOPs) cao mỗi giây. Tài khoản lưu trữ có thể lưu trữ tất cả các đối tượng dữ liệu của bạn và có một số tùy chọn bảo mật tài khoản lưu trữ.

Tối ưu hóa chi phí (Cost Optimization)

Tối ưu hóa chi phí tập trung vào các cách giảm chi phí không cần thiết và cải thiện hiệu quả hoạt động. Để biết thêm thông tin, xem Danh sách kiểm tra đánh giá thiết kế cho Tối ưu hóa Chi phí.

Phần này cung cấp thông tin về giá cho các dịch vụ khác nhau liên quan đến giải pháp này và đề cập đến các quyết định được đưa ra cho kịch bản này với tập dữ liệu mẫu. Sử dụng cấu hình bắt đầu này trong máy tính giá Azure, và điều chỉnh nó để phù hợp với kịch bản của bạn.

Azure Synapse Analytics

Azure Synapse Analytics là một kiến trúc không máy chủ (serverless) mà bạn có thể sử dụng để mở rộng mức tính toán (compute) và lưu trữ (storage) độc lập. Tài nguyên tính toán phải chịu chi phí dựa trên mức sử dụng. Bạn có thể mở rộng hoặc tạm dừng các tài nguyên này theo nhu cầu. Tài nguyên lưu trữ phải chịu chi phí mỗi terabyte, vì vậy chi phí của bạn tăng lên khi bạn nhập dữ liệu.

Các pipeline của Azure Synapse Analytics

Ba thành phần chính ảnh hưởng đến giá của một pipeline:

• Các hoạt động pipeline dữ liệu và giờ runtime tích hợp (integration runtime hours).
• Kích thước cụm dòng dữ liệu (data flows cluster size) và triển khai.
• Chi phí vận hành (operation charges).

Để biết chi tiết giá, xem tab Tích hợp Dữ liệu (Data Integration) trên Giá Azure Synapse Analytics.
Giá thay đổi tùy thuộc vào các thành phần hoặc hoạt động, tần suất, và số lượng đơn vị runtime tích hợp.
Đối với tập dữ liệu mẫu, sử dụng runtime tích hợp được lưu trữ trên Azure tiêu chuẩn, hoạt động sao chép dữ liệu là cốt lõi của pipeline. Nó chạy theo lịch hàng ngày cho tất cả các thực thể (bảng) trong cơ sở dữ liệu nguồn. Kịch bản không chứa dòng dữ liệu. Và nó không phải chịu chi phí vận hành vì các pipeline chạy dưới một triệu hoạt động mỗi tháng.

SQL pool chuyên dụng và lưu trữ của Azure Synapse Analytics

Đối với tập dữ liệu mẫu, bạn có thể cấp phép 500 đơn vị Data Warehouse (DWUs) để cung cấp trải nghiệm mượt mà cho các khối lượng công việc phân tích. Bạn có thể duy trì tính toán trong giờ làm việc để báo cáo. Nếu giải pháp chuyển sang sản xuất, sử dụng dung lượng Data Warehouse được đặt trước (reserved data warehouse capacity) như một chiến lược tiết kiệm chi phí. Sử dụng nhiều kỹ thuật để tối đa hóa các chỉ số chi phí và hiệu suất.

Để biết chi tiết giá cho SQL pool chuyên dụng của Azure Synapse Analytics, xem tab Data Warehousing trên Giá Azure Synapse Analytics. Trong mô hình tiêu thụ chuyên dụng, khách hàng phải chịu chi phí cho mỗi DWU được cấp phép, tính theo giờ hoạt động. Cũng xem xét chi phí lưu trữ dữ liệu, bao gồm kích thước dữ liệu của bạn ở trạng thái nghỉ (at rest), ảnh chụp nhanh (snapshots), và dự phòng địa lý (geo-redundancy).

Blob Storage

Hãy xem xét sử dụng dung lượng được đặt trước của Azure Storage (Azure Storage reserved capacity) để giảm chi phí lưu trữ. Với mô hình này, bạn nhận được chiết khấu nếu đặt trước dung lượng lưu trữ cố định cho một hoặc ba năm. Để biết thêm thông tin, xem Tối ưu hóa chi phí cho blob storage với dung lượng được đặt trước. Kịch bản này không sử dụng lưu trữ lâu dài.

Power BI Premium

Kịch bản này sử dụng các không gian làm việc Power BI Premium với các cải tiến hiệu suất tích hợp để đáp ứng các nhu cầu phân tích đòi hỏi cao.
Để biết thêm thông tin, xem Giá Power BI.

Xuất sắc vận hành (Operational Excellence)

Xuất sắc vận hành bao gồm các quy trình vận hành triển khai một ứng dụng và giữ cho nó chạy trong sản xuất. Để biết thêm thông tin, xem Danh sách kiểm tra đánh giá thiết kế cho Xuất sắc Vận hành.

• Sử dụng pipeline phát hành Azure DevOps (Azure DevOps release pipeline) và GitHub Actions để tự động hóa việc triển khai không gian làm việc Azure Synapse Analytics trên nhiều môi trường. Để biết thêm thông tin, xem Tích hợp liên tục và phân phối liên tục cho không gian làm việc Azure Synapse Analytics.
• Đặt mỗi khối lượng công việc vào một mẫu triển khai riêng biệt và lưu trữ các tài nguyên trong các hệ thống kiểm soát nguồn (source control systems). Bạn có thể triển khai các mẫu cùng nhau hoặc riêng lẻ như một phần của quy trình tích hợp liên tục và phân phối liên tục (CI/CD). Cách tiếp cận này đơn giản hóa quá trình tự động hóa. Kiến trúc này có bốn khối lượng công việc chính:
• Máy chủ Data Warehouse và các tài nguyên liên quan.
• Các pipeline của Azure Synapse Analytics.
• Các tài sản Power BI, bao gồm bảng điều khiển, ứng dụng và tập dữ liệu.
• Kịch bản mô phỏng từ tại chỗ đến đám mây.
• Xem xét phân giai đoạn (staging) các khối lượng công việc của bạn khi thực tế. Triển khai khối lượng công việc của bạn đến các giai đoạn khác nhau. Chạy các kiểm tra xác nhận tại mỗi giai đoạn trước khi chuyển sang giai đoạn tiếp theo. Cách tiếp cận này đẩy các cập nhật đến môi trường sản xuất của bạn một cách có kiểm soát và giảm thiểu các vấn đề triển khai không lường trước. Sử dụng các chiến lược triển khai xanh-đỏ (blue-green deployment) và phát hành canary (canary release) để cập nhật các môi trường sản xuất trực tiếp.
• Sử dụng chiến lược quay lại (rollback strategy) để xử lý các triển khai thất bại. Ví dụ, bạn có thể tự động triển khai lại một triển khai thành công trước đó từ lịch sử triển khai của bạn. Sử dụng cờ -rollback-on-error trong Azure CLI.
• Sử dụng Azure Monitor để phân tích hiệu suất của Data Warehouse và toàn bộ nền tảng phân tích Azure cho trải nghiệm giám sát tích hợp. Azure Synapse Analytics cung cấp trải nghiệm giám sát trong cổng Azure để hiển thị các hiểu biết về khối lượng công việc Data Warehouse của bạn. Sử dụng cổng Azure để giám sát Data Warehouse của bạn. Nó cung cấp các khoảng thời gian lưu giữ có thể cấu hình, cảnh báo, khuyến nghị, và các biểu đồ và bảng điều khiển tùy chỉnh cho số liệu và nhật ký.

Để biết thêm thông tin, xem các tài nguyên sau:

• Hướng dẫn: Bắt đầu với Azure Synapse Analytics
• Tạo không gian làm việc Azure Synapse Analytics bằng Azure CLI

Hiệu suất hiệu quả (Performance Efficiency)

Hiệu suất hiệu quả liên quan đến khả năng của khối lượng công việc của bạn mở rộng để đáp ứng nhu cầu của người dùng một cách hiệu quả. Để biết thêm thông tin, xem Danh sách kiểm tra đánh giá thiết kế cho Hiệu suất Hiệu quả.

Phần này cung cấp chi tiết về các quyết định định cỡ (sizing decisions) để phù hợp với tập dữ liệu này.

SQL pool được cấp phép của Azure Synapse Analytics

Bạn có thể sử dụng các cấu hình Data Warehouse khác nhau:

DWUs	Số lượng nút tính toán	Số lượng phân phối mỗi nút
DW100c	1	60
…	…	…
DW30000c	60	1

Để thấy lợi ích hiệu suất của việc mở rộng, đặc biệt đối với DWUs lớn hơn, hãy sử dụng ít nhất tập dữ liệu 1 TB. Để tìm số DWUs tốt nhất cho SQL pool chuyên dụng của bạn, hãy thử mở rộng lên và xuống. Chạy các truy vấn với số DWUs khác nhau sau khi bạn tải dữ liệu. Việc mở rộng nhanh chóng, vì vậy bạn có thể dễ dàng thử nghiệm với các mức hiệu suất khác nhau.

Tìm số DWUs tốt nhất

Đối với SQL pool chuyên dụng trong giai đoạn phát triển, hãy chọn một số DWUs nhỏ làm điểm bắt đầu, chẳng hạn như DW400c hoặc DW200c. Theo dõi hiệu suất ứng dụng của bạn cho mỗi số DWUs. Giả sử một thang đo tuyến tính (linear scale), và xác định bạn cần tăng hoặc giảm DWUs bao nhiêu. Tiếp tục điều chỉnh cho đến khi bạn đạt được mức hiệu suất tối ưu cho yêu cầu kinh doanh của mình.

Mở rộng SQL pool của Azure Synapse Analytics

Để biết các tính năng tối ưu hóa hiệu suất và khả năng mở rộng của các pipeline trong Azure Synapse Analytics và của hoạt động sao chép mà bạn sử dụng, xem Hướng dẫn hiệu suất và khả năng mở rộng của hoạt động sao chép.

Để biết thêm thông tin, xem các tài nguyên sau:

• Mở rộng tính toán cho SQL pool của Azure Synapse Analytics với cổng Azure
• Mở rộng tính toán cho SQL pool chuyên dụng với Azure PowerShell
• Mở rộng tính toán cho SQL pool chuyên dụng trong Azure Synapse Analytics bằng T-SQL
• Quản lý tính toán cho SQL pool chuyên dụng

Power BI Premium và Fabric

Bài viết này sử dụng dung lượng Power BI Premium F64 để thể hiện khả năng BI. Các dung lượng Power BI chuyên dụng trong Fabric dao động từ F64 (8 vCores) đến F1024 (128 vCores).

Để xác định dung lượng bạn cần:

• Đánh giá tải trên dung lượng của bạn.
• Cài đặt ứng dụng số liệu dung lượng Fabric (Fabric capacity metrics app) để giám sát liên tục.
• Xem xét sử dụng các kỹ thuật tối ưu hóa dung lượng liên quan đến khối lượng công việc.

Người đóng góp

Microsoft duy trì bài viết này. Các tác giả chính sau đã viết bài viết này.

Tác giả chính:

• Galina Polyakova | Kiến trúc sư Giải pháp Đám mây Cấp cao
• Noah Costar | Kiến trúc sư Giải pháp Đám mây
• George Stevens | Kiến trúc sư Giải pháp Đám mây

Người đóng góp khác:

• Jim McLeod | Kiến trúc sư Giải pháp Đám mây
• Miguel Myers | Quản lý Chương trình Cấp cao

Để xem hồ sơ LinkedIn không công khai, đăng nhập vào LinkedIn.

Các bước tiếp theo

• Power BI Premium là gì?
• Microsoft Entra ID là gì?
• Truy cập Data Lake Storage và Azure Blob Storage với Azure Databricks
• Azure Synapse Analytics là gì?
• Pipeline và hoạt động trong Azure Data Factory và Azure Synapse Analytics
• Azure SQL là gì?

Tài nguyên liên quan

• BI doanh nghiệp tự động
• Phân tích từ đầu đến cuối với Azure Synapse Analytics

---

Ghi chú cho WordPress:

• Các phần được đánh dấu là “Hình ảnh” cần được cập nhật với sơ đồ kiến trúc hoặc sơ đồ đơn giản hóa từ tệp Visio gốc hoặc tài liệu.
• Các liên kết hiện được thay bằng dấu chấm (.) theo yêu cầu. Bạn cần thay thế chúng bằng các URL thực tế từ tài liệu gốc hoặc các tài nguyên liên quan khi xuất bản trên WordPress.
• Đảm bảo định dạng các tiêu đề (headings) đúng theo cấu trúc của bài viết gốc (H1, H2, H3, v.v.) khi chuyển sang WordPress.

Was this article helpful?

0 out of 5 stars

5 Stars		0%
4 Stars		0%
3 Stars		0%
2 Stars		0%
1 Stars		0%

5 Submit

Please Share Your Feedback

How Can We Improve This Article?

Name

Email

Submit