Ngân hàng đề — Microsoft Azure Data Fundamentals

Đáp án

A — Có! Azure có SQL Server 2017 và 2019 trên Linux.

Vì sao đúng

⚠ Từ SQL Server 2017, Microsoft hỗ trợ chính thức Linux: | Hệ điều hành hỗ trợ | Nội dung | |---|---| | ⚠ Red Hat Enterprise Linux | | | ⚠ SUSE Linux Enterprise Server | | | ⚠ Ubuntu | | | ⚠ Container Docker | | | ⚠ Azure Marketplace | ⚠ có sẵn ảnh máy ảo dựng sẵn |

⚠ SQL Server 2017: bản đầu tiên có Linux
⚠ SQL Server 2019: thêm Big Data Clusters
⚠ SQL Server 2022: bản mới nhất, cũng có Linux

Vì sao các phương án khác sai

• B (Không, SQL Server chỉ chạy trên Windows) — ⚠ SAI từ năm 2017.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề nêu ⚠ phiên bản đã cũ.

⚠ Điểm khác biệt khi chạy SQL Server trên Linux: | Có | Không có | |---|---| | ⚠ Engine cơ sở dữ liệu đầy đủ | ⚠ một số tính năng Windows-only | | ⚠ Always On availability groups | ⚠ Analysis Services, Reporting Services | | ⚠ SQL Agent | ⚠ FILESTREAM, một số tính năng phân tán | | ⚠ TDE, Always Encrypted | | | ⚠ Quản lý bằng SSMS từ máy Windows | | | ⚠ Trước khi chuyển | ⚠ kiểm tra danh sách tính năng không hỗ trợ |

Từ khoá nhận diện:

"SQL Server trên Linux" → ⚠ có từ 2017 "container SQL Server" → ⚠ có, chạy Docker "Analysis Services trên Linux" → ⚠ KHÔNG có "Big Data Clusters" → ⚠ đã ngừng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tính năng đang dùng có hỗ trợ trên Linux không | | | Đội có kỹ năng vận hành Linux không | | | Có thể dùng PaaS thay vì tự quản lý VM không | |

Và điều đáng cân nhắc trước khi chọn tự vận hành SQL Server trên Linux, dù nó tiết kiệm giấy phép Windows: Managed Instance vẫn bỏ đi toàn bộ việc vá lỗi và sao lưu, và đó thường là khoản tiết kiệm lớn hơn.

Đáp án

D — Azure Databricks.

Vì sao đúng

⚠ Đề mô tả đúng định vị của Databricks: | Yếu tố trong đề | Databricks | |---|---| | ⚠ Nhiều vai trò cộng tác | ⚠ nhà phân tích, khoa học dữ liệu, kỹ sư | | ⚠ Không gian làm việc tương tác | ⚠ notebook chia sẻ | | ⚠ Nằm trong cụm Apache Spark | ⚠ đúng kiến trúc Databricks |

⚠ Workspace
   ⚠ Notebook dùng chung
   ⚠ Nhiều người sửa cùng lúc
   ⚠ Bình luận, phiên bản
        ↓ ⚠ chạy trên
⚠ Cụm Spark do Databricks quản lý

Vì sao các phương án khác sai

• A (Synapse Analytics) — ⚠ cũng có notebook và Spark, ⚠ nhưng ⚠ định vị là nền tảng phân tích tích hợp, ⚠ không phải "không gian cộng tác trên cụm Spark" như đề mô tả.

• C (Data Factory) — ⚠ công cụ ĐIỀU PHỐI, không phải môi trường phân tích.

• B (Azure SQL Database) — ⚠ CSDL quan hệ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #19601 trong cùng lô.

⚠ Bốn dịch vụ dữ liệu — định vị một câu: | Dịch vụ | Định vị | |---|---| | ⚠ Databricks | ⚠ cộng tác trên Spark, mạnh về ML | | ⚠ Synapse | ⚠ nền tảng phân tích tích hợp, mạnh về SQL | | ⚠ Data Factory | ⚠ điều phối luồng dữ liệu | | ⚠ Azure ML | ⚠ vòng đời mô hình học máy |

Từ khoá nhận diện:

"cộng tác, notebook, Spark" → ⚠ Databricks "SQL pool, kho dữ liệu, tất cả trong một" → ⚠ Synapse "pipeline, copy, trigger" → ⚠ Data Factory "đăng ký mô hình, endpoint" → ⚠ Azure ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội có nhiều vai trò cần làm việc chung không | | | Có cần SQL engine riêng không | ⚠ thì cân nhắc Synapse | | Cụm có tự tắt khi rảnh không | |

Và giá trị thật của một nền tảng dữ liệu hợp nhất, khó đo bằng tính năng nhưng thấy rõ trong thực tế: bốn vai trò khác nhau làm việc trên cùng một bộ dữ liệu mà không phải chuyển đổi công cụ và sao chép dữ liệu qua lại.

Đáp án

C — Treemap (bản đồ cây).

Vì sao đúng

⚠ Treemap biểu diễn dữ liệu bằng các hình chữ nhật lồng nhau:

⚠ ┌──────────────┬──────┬────┐
⚠ │              │      │    │
⚠ │   Sản phẩm A ├──────┼────┤
⚠ │              │  B   │ C  │
⚠ └──────────────┴──────┴────┘
        ↓
⚠ DIỆN TÍCH = giá trị (doanh thu, số lượng)
⚠ MÀU SẮC = một chiều khác (lợi nhuận, vùng)

Vì sao các phương án khác sai

• B (Pie chart) — ⚠ hình tròn chia lát, không phải hình chữ nhật; ⚠ chỉ hợp khi có ⚠ ít hạng mục.

• A (Scatter chart) — ⚠ các điểm trên hai trục, để xem tương quan.

• D (Matrix) — ⚠ bảng có hàng và cột, giống PivotTable.

Ghi nhớ

⚠ Chọn trực quan theo CÂU HỎI cần trả lời: | Câu hỏi | Trực quan | |---|---| | ⚠ So sánh giữa các hạng mục | ⚠ bar chart, column chart | | ⚠ Xu hướng theo thời gian | ⚠ line chart | | ⚠ Tỉ trọng trong tổng thể | ⚠ pie, donut, treemap | | ⚠ Tương quan giữa hai chỉ số | ⚠ scatter chart | | ⚠ Dữ liệu chi tiết theo hàng cột | ⚠ table, matrix | | ⚠ Phân bố địa lý | ⚠ map | | ⚠ Một con số quan trọng | ⚠ card, KPI |

Từ khoá nhận diện:

"hình chữ nhật kích thước khác nhau" → ⚠ treemap "bảng hàng cột" → ⚠ matrix "điểm rời rạc, tương quan" → ⚠ scatter "đường theo thời gian" → ⚠ line chart

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trực quan này trả lời câu hỏi gì | | | Có bao nhiêu hạng mục | ⚠ quyết định pie hay treemap hay bar | | Trục có bắt đầu từ 0 không | |

Và nguyên tắc trực quan hoá dữ liệu ít được nói tới nhưng có cơ sở khoa học: mắt người ước lượng chiều dài chính xác hơn nhiều so với ước lượng diện tích. Đó là lý do biểu đồ cột đơn giản thường truyền đạt tốt hơn treemap hay biểu đồ tròn.

Đáp án

A — Azure Blob Storage.

Vì sao đúng

⚠ Đề nói rõ: dữ liệu ảnh NHỊ PHÂN, lưu để lấy lại sau: | Yêu cầu | Blob Storage | |---|---| | ⚠ Dữ liệu nhị phân | ⚠ đúng mục đích của blob | | ⚠ Ảnh có thể lớn | ⚠ không giới hạn thực tế | | ⚠ Lấy lại sau | ⚠ theo tên hoặc URL | | ⚠ Chi phí thấp | |

⚠ Azure Function nhận request
        ↓
⚠ Đọc body nhị phân
        ↓
⚠ Upload vào container blob
        ↓
⚠ Lưu URL hoặc tên vào CSDL nếu cần

Vì sao các phương án khác sai

• D (Cosmos DB) — ⚠ giới hạn 2MB mỗi item và ⚠ rất đắt cho dữ liệu nhị phân.

• C (SQL Database) — ⚠ nhồi ảnh vào cột nhị phân là thiết kế tệ: ⚠ phình CSDL, sao lưu chậm.

• B (Redis Cache) — ⚠ lưu trong BỘ NHỚ: ⚠ đắt, ⚠ và là cache chứ không phải kho lưu trữ lâu dài.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #19574 ở lô trước.

⚠ Mẫu kiến trúc chuẩn — Function ghi vào Blob: | Bước | Nội dung | |---|---| | ⚠ Function dùng MANAGED IDENTITY | ⚠ không lưu khoá | | ⚠ Output binding tới blob | ⚠ hoặc dùng SDK | | ⚠ Đặt tên blob có ý nghĩa | ⚠ kèm timestamp hoặc GUID | | ⚠ Lưu metadata vào CSDL nếu cần truy vấn | | | ⚠ Lifecycle policy cho ảnh cũ | |

Từ khoá nhận diện:

"ảnh, video, tệp nhị phân" → ⚠ Blob "JSON nhỏ, truy vấn nhiều trường" → ⚠ Cosmos "cache tăng tốc" → ⚠ Redis "dữ liệu quan hệ, giao dịch" → ⚠ SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Function dùng managed identity hay khoá | | | Có kiểm tra kích thước và kiểu tệp không | | | Ảnh cũ có được chuyển tầng lạnh không | |

Và mẫu thiết kế cần nhớ mỗi khi hệ thống nhận tệp từ bên ngoài: tệp vào blob, metadata vào cơ sở dữ liệu. Nó đúng với ảnh, video, tài liệu và mọi thứ nhị phân khác.

Đáp án

B — Các yêu cầu sẽ bị yêu cầu THỬ LẠI sau.

Vì sao đúng

⚠ Vượt RU/s đã cấp phát thì Cosmos DB điều tiết:

⚠ Ứng dụng gửi nhiều yêu cầu hơn RU đã cấp
        ↓
⚠ Cosmos DB trả về HTTP 429
   ⚠ "Too Many Requests"
        ↓
⚠ Kèm header retry-after: N mili giây
        ↓
⚠ SDK TỰ ĐỘNG thử lại sau khoảng đó

Vì sao các phương án khác sai

• D (yêu cầu mất nhiều thời gian hơn dự kiến) — ⚠ hệ quả GIÁN TIẾP của việc thử lại, ⚠ nhưng cơ chế thật là ⚠ từ chối và bảo thử lại, không phải xử lý chậm.

• C (bị tính tiền cho phần RU vượt) — ⚠ SAI: ⚠ Cosmos ⚠ không cho vượt rồi tính thêm; ⚠ nó chặn lại.

• A (không có lỗi, chỉ có thông báo trên Portal) — ⚠ SAI: ⚠ ứng dụng ⚠ nhận lỗi 429 rõ ràng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ năm về RU của Cosmos DB qua ba lô.

⚠ Xử lý lỗi 429 đúng cách: | Bước | Nội dung | |---|---| | ⚠ Để SDK tự thử lại | ⚠ nó đọc header retry-after | | ⚠ Theo dõi số lượng 429 trong metrics | | | ⚠ Nếu thường xuyên: tăng RU hoặc bật autoscale | | | ⚠ Hoặc tối ưu truy vấn và partition key | | | ⚠ Đừng | ⚠ thử lại ngay lập tức không có backoff — làm tình hình tệ hơn |

Từ khoá nhận diện:

"429, too many requests" → ⚠ vượt RU "vẫn trả tiền dù không dùng" → ⚠ cấp dư "tự co giãn trong khoảng" → ⚠ autoscale "trả theo lượt dùng" → ⚠ serverless

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có phân vùng nào bị nóng không | ⚠ nguyên nhân 429 khó thấy nhất | | SDK có bật thử lại không | | | Số lỗi 429 mỗi ngày là bao nhiêu | |

Và nguyên nhân gây lỗi điều tiết khó chẩn đoán nhất trên Cosmos DB: một phân vùng nóng chạm trần trong khi tổng thông lượng vẫn còn dư. Nhìn con số tổng sẽ không bao giờ thấy được điều đó.

Đáp án

A — Azure Data Lake Storage Gen2.

Vì sao đúng

⚠ Đề nêu bốn điều kiện, tất cả đều khớp Data Lake Gen2: | Điều kiện | Data Lake Gen2 | |---|---| | ⚠ Kho dữ liệu doanh nghiệp | ⚠ là nền của kiến trúc hiện đại | | ⚠ Khối lượng KHÔNG ước tính được | ⚠ co giãn gần như vô hạn | | ⚠ Có thể tới EXABYTE | ⚠ thiết kế cho quy mô đó | | ⚠ Dữ liệu từ nguồn bên ngoài | ⚠ nhận mọi định dạng |

⚠ Data Lake Gen2
   ⚠ = Blob Storage + namespace phân cấp
   ⚠ + giao diện tương thích HDFS
        ↓
⚠ Spark, Databricks, Synapse đọc trực tiếp
⚠ Chi phí lưu trữ rẻ như blob

Vì sao các phương án khác sai

• C (Blob Storage) — ⚠ bẫy gần đúng nhất: ⚠ Data Lake Gen2 ⚠ chính là Blob, ⚠ nhưng đề nói ⚠ kho dữ liệu doanh nghiệp và phân tích — ⚠ khi đó namespace phân cấp và ACL của Gen2 là bắt buộc.

• D (Synapse Analytics) — ⚠ là nền tảng PHÂN TÍCH, ⚠ không phải kho lưu trữ thô ban đầu.

• B (Cosmos DB) — ⚠ CSDL vận hành, ⚠ rất đắt cho quy mô exabyte.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19518 ở lô trước.

⚠ Blob và Data Lake Gen2 — khi nào chọn cái nào: | Nhu cầu | Chọn | |---|---| | ⚠ Lưu ảnh, video, sao lưu | ⚠ Blob thường | | ⚠ Phân tích dữ liệu lớn | ⚠ Data Lake Gen2 | | ⚠ Cần thư mục thật và ACL | ⚠ Gen2 | | ⚠ Spark, Databricks đọc trực tiếp | ⚠ Gen2 | | ⚠ Giá lưu trữ | ⚠ NHƯ NHAU | | ⚠ Vậy nên | ⚠ nếu có ý định phân tích, bật Gen2 ngay từ đầu |

Từ khoá nhận diện:

"kho dữ liệu, phân tích, quy mô lớn" → ⚠ Data Lake Gen2 "lưu tệp, ảnh, phục vụ web" → ⚠ Blob "truy vấn SQL trên dữ liệu" → ⚠ Synapse "CSDL vận hành toàn cầu" → ⚠ Cosmos DB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Namespace phân cấp đã bật chưa | ⚠ không bật được sau khi tạo | | Có quy ước tổ chức thư mục chưa | | | Dữ liệu đã xử lý có ở định dạng cột chưa | |

Và điều biến một data lake thành thứ vô dụng dù công nghệ hoàn toàn đúng: không có quy ước tổ chức và mô tả dữ liệu. Hàng petabyte mà không ai biết trong đó có gì thì cũng như không có gì.

Đáp án

B — 3 bản sao.

Vì sao đúng

⚠ LRS giữ ba bản trong CÙNG một trung tâm dữ liệu:

⚠ Một trung tâm dữ liệu
   ⚠ Bản sao 1 (rack A)
   ⚠ Bản sao 2 (rack B)
   ⚠ Bản sao 3 (rack C)
        ↓
⚠ Chịu được: hỏng ổ đĩa, hỏng rack
⚠ KHÔNG chịu được: mất cả trung tâm dữ liệu

Vì sao các phương án khác sai

• A (1 bản trong mỗi availability zone) — ⚠ đó là mô tả của ZRS, ⚠ và ZRS cũng là 3 bản.

• D (6 bản) — ⚠ là GRS hoặc GZRS.

• C (1 bản) — ⚠ không có mức nào chỉ giữ một bản.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về mức nhân bản qua ba lô.

⚠ Mẹo nhớ bảng nhân bản: | Mẹo | Nội dung | |---|---| | ⚠ Không có chữ G | ⚠ 3 bản, một vùng | | ⚠ Có chữ G (Geo) | ⚠ 6 bản, hai vùng | | ⚠ Có chữ Z (Zone) | ⚠ trải qua các zone | | ⚠ Có RA- | ⚠ đọc được ở vùng phụ |

Từ khoá nhận diện:

"3 bản, một trung tâm dữ liệu" → ⚠ LRS "3 bản, ba zone" → ⚠ ZRS "6 bản, hai vùng" → ⚠ GRS "rẻ nhất" → ⚠ LRS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vùng đang dùng có availability zone không | ⚠ có thì ZRS đáng cân nhắc | | Dữ liệu có tái tạo được không | | | Đã có soft delete và versioning chưa | |

Và khác biệt thật sự giữa LRS và ZRS, dễ bỏ qua vì cả hai đều là ba bản sao: không phải số lượng bản sao mà là chúng nằm cách nhau bao xa. Ba bản trong cùng một toà nhà không cứu được gì khi toà nhà đó gặp sự cố.

Đáp án

A — Có.

Vì sao đúng

⚠ Data Factory có hơn 100 connector, bao gồm nhiều nguồn ngoài Azure: | Nhóm nguồn | Ví dụ | |---|---| | ⚠ Azure | ⚠ SQL, Blob, Cosmos, Synapse | | ⚠ Đám mây khác | ⚠ Amazon Redshift, S3, Google BigQuery | | ⚠ CSDL tại chỗ | ⚠ SQL Server, Oracle, MySQL, DB2 | | ⚠ SaaS | ⚠ Salesforce, SAP, Dynamics, ServiceNow | | ⚠ Giao thức chung | ⚠ REST, OData, ODBC, FTP |

⚠ Amazon Redshift
        ↓ ⚠ ADF Copy activity
⚠ Azure Data Lake / Synapse
        ↓
⚠ Có thể dùng UNLOAD qua S3 để tăng tốc

Vì sao các phương án khác sai

• B (Không) — ⚠ SAI: ⚠ ADF được thiết kế cho môi trường ⚠ đa đám mây và lai.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19517, #19570, #19572 về Data Factory.

⚠ Sao chép từ Redshift — điều cần biết: | Điểm | Nội dung | |---|---| | ⚠ Chế độ trực tiếp | ⚠ đơn giản, chậm với dữ liệu lớn | | ⚠ Chế độ UNLOAD qua S3 | ⚠ nhanh hơn nhiều với khối lượng lớn | | ⚠ Cần quyền trên Redshift và S3 | | | ⚠ Chú ý chi phí EGRESS của AWS | ⚠ hay bị quên |

Từ khoá nhận diện:

"kết nối nguồn ngoài Azure" → ⚠ ADF làm được "nguồn tại chỗ" → ⚠ cần self-hosted integration runtime "di chuyển một lần khi chuyển hệ thống" → ⚠ DMS "khối lượng cực lớn, mạng chậm" → ⚠ Data Box

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguồn có công khai hay trong mạng riêng | ⚠ quyết định loại IR | | Đã tính phí egress của bên kia chưa | | | Có nạp tăng dần được không | |

Và khoản chi phí hay bị bỏ sót khi kéo dữ liệu từ một đám mây khác về Azure: phí truyền dữ liệu ra ngoài mà nhà cung cấp kia tính. Azure không tính phí nhận, nhưng bên gửi thì có.

Đáp án

A — Matrix.

Vì sao đúng

⚠ Matrix là trực quan dạng bảng có hàng và cột, giống PivotTable:

⚠            │ Q1   │ Q2   │ Q3   │ Tổng
⚠ ───────────┼──────┼──────┼──────┼──────
⚠ Miền Bắc   │ 120  │ 135  │ 150  │ 405
⚠ Miền Trung │  80  │  85  │  90  │ 255
⚠ Miền Nam   │ 200  │ 210  │ 225  │ 635

Vì sao các phương án khác sai

• B (Treemap) — ⚠ các hình chữ nhật theo diện tích.

• C (Line chart) — ⚠ đường theo thời gian.

• D (Bar chart) — ⚠ các cột so sánh.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp với #19613 trong cùng lô — ⚠ hai câu dùng chung bộ bốn trực quan, hoán đổi khoá.

⚠ Table và Matrix trong Power BI — phân biệt: | Tiêu chí | Table | Matrix | |---|---|---| | ⚠ Cấu trúc | ⚠ danh sách phẳng | ⚠ nhóm theo hàng VÀ cột | | ⚠ Tổng phụ | ⚠ hạn chế | ⚠ tự động theo nhóm | | ⚠ Drill down | ⚠ không | ⚠ có | | ⚠ Giống với | ⚠ bảng Excel thường | ⚠ PivotTable |

Từ khoá nhận diện:

"bảng, hàng và cột, tổng phụ" → ⚠ Matrix "danh sách chi tiết phẳng" → ⚠ Table "hình chữ nhật theo diện tích" → ⚠ Treemap "xu hướng theo thời gian" → ⚠ Line chart

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng cần con số hay cần xu hướng | | | Có cần nhóm theo cả hàng và cột không | ⚠ thì dùng matrix | | Bảng có quá nhiều dòng không | |

Và sai lầm phổ biến khi thiết kế báo cáo, xuất phát từ ý tốt: vẽ biểu đồ cho dữ liệu mà người dùng chỉ muốn đọc con số chính xác. Đôi khi một bảng được định dạng tốt là trực quan hoá đúng nhất.

Đáp án

B — Mô tả (Descriptive).

Vì sao đúng

⚠ Bốn cấp độ phân tích, mỗi cấp trả lời một câu hỏi: | Cấp | Câu hỏi | Ví dụ | |---|---|---| | ⚠ Descriptive | ⚠ ĐÃ XẢY RA gì | ⚠ doanh thu quý trước là bao nhiêu | | ⚠ Diagnostic | ⚠ VÌ SAO xảy ra | ⚠ vì sao doanh thu giảm | | ⚠ Predictive | ⚠ SẼ xảy ra gì | ⚠ quý tới bán được bao nhiêu | | ⚠ Prescriptive | ⚠ NÊN LÀM gì | ⚠ nên giảm giá mặt hàng nào |

⚠ Độ phức tạp và giá trị TĂNG DẦN
⚠ Descriptive → Diagnostic
   ⚠ → Predictive → Prescriptive
        ↓
⚠ Phần lớn tổ chức mới ở hai cấp đầu

Vì sao các phương án khác sai

• C (Diagnostic) — ⚠ trả lời VÌ SAO, ⚠ cần đào sâu và tìm nguyên nhân.

• A (Prescriptive) — ⚠ KHUYẾN NGHỊ hành động, cấp cao nhất.

• D (Cognitive) — ⚠ đôi khi được nhắc như cấp thứ năm, ⚠ liên quan tới AI tự học; ⚠ không phải cấp mô tả dữ liệu lịch sử.

Ghi nhớ

⚠ Bốn cấp phân tích — bảng phải thuộc: | Cấp | Từ khoá trong đề | |---|---| | ⚠ Descriptive | ⚠ "đã xảy ra", "báo cáo", "lịch sử" | | ⚠ Diagnostic | ⚠ "vì sao", "nguyên nhân", "đào sâu" | | ⚠ Predictive | ⚠ "dự báo", "sẽ", "khả năng" | | ⚠ Prescriptive | ⚠ "nên làm gì", "khuyến nghị", "tối ưu" |

Từ khoá nhận diện:

"đã xảy ra gì trong quá khứ" → ⚠ Descriptive "vì sao con số giảm" → ⚠ Diagnostic "tháng sau bao nhiêu" → ⚠ Predictive "nên hành động thế nào" → ⚠ Prescriptive

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo này trả lời câu hỏi ở cấp nào | | | Có dẫn tới hành động cụ thể không | | | Dữ liệu có đủ sạch cho cấp cao hơn chưa | |

Và câu hỏi đáng đặt cho mọi báo cáo mô tả, quan trọng hơn việc nó có đẹp hay không: sau khi đọc xong, có ai làm gì khác đi không? Nếu không, đó là số liệu chứ chưa phải thông tin hữu ích.