Analytics, BI & Data ServingAnalytics, BI & Data Serving

Thuộc bộ kiến thức Data Engineer Roadmap.

Tổng quan

Từ đầu đến giờ, các bài trong bộ kiến thức này đều xoay quanh việc đưa dữ liệu vào một nơi được tổ chức tốt: ingest dữ liệu (./03-data-sources-and-ingestion.md), modeling vào warehouse (./06-data-modeling-and-warehousing.md), và di chuyển qua các pipeline (./08-etl-elt-and-data-pipelines.md). Tất cả công sức đó chỉ thực sự có giá trị khi có ai đó — hoặc hệ thống nào đó — thật sự tiêu thụ (consume) kết quả. Serving layer (tầng phục vụ dữ liệu) là giai đoạn cuối cùng của data engineering lifecycle: nơi dữ liệu đã được modeling, đáng tin cậy, được expose ra cho con người thông qua dashboard và các công cụ self-service BI, cho hệ thống khác thông qua API và reverse ETL, và cho các mô hình machine learning thông qua feature store. Công việc của một data engineer chưa hoàn thành khi một dbt run chạy thành công; nó chỉ hoàn thành khi một nhân viên sales nhìn thấy đúng con số trong Salesforce, một lãnh đạo tin tưởng biểu đồ revenue trên dashboard, hay một model fraud detection chấm điểm một giao dịch theo thời gian thực bằng các feature được tính đúng.

Bài này cố tình tập trung vào “chặng cuối cùng” (last mile). Nó không giải thích lại cách modeling warehouse hay xây pipeline — nó giải thích điều xảy ra sau khi công việc đó hoàn tất: các công cụ BI như Tableau, Looker, Power BI biến một warehouse được modeling tốt thành dashboard nhanh và đáng tin cậy như thế nào; tại sao cần một semantic layer để ngăn năm dashboard hiển thị năm con số khác nhau cho “revenue”; các công cụ nhẹ như Streamlit nằm ở đâu so với các nền tảng BI đầy đủ; data engineer giúp analyst phân tích sâu hơn mà không tự làm phân tích đó như thế nào; kỷ luật kỹ thuật đứng sau việc A/B testing đáng tin cậy; và vấn đề đặc thù của serving layer — training-serving skew — mà feature store được sinh ra để giải quyết.

Kiến thức nền tảng

Serving layer — giai đoạn cuối của lifecycle

Có thể hình dung data engineering lifecycle kết thúc bằng một điểm phân nhánh (fan-out) chứ không phải một đích đến duy nhất. Sau khi dữ liệu được extract, lưu trữ, và transform thành các bảng modeling sạch, nó tỏa ra bất cứ nơi nào tạo ra giá trị:

Warehouse đã modelingmarts

• con người khám phá trực quan
  BI toolTableau, Looker, Power BI
• các công cụ SaaS vận hành
  Reverse ETL
• ML training & inference
  Feature store
• analyst, data scientist
  Ad-hoc SQL / notebook

Mỗi consumption pattern này có yêu cầu khác nhau về độ tươi (freshness), độ trễ (latency), và hình dạng truy vấn (query shape), và mỗi cái sẽ hỏng theo một cách riêng nếu data engineer coi “model đã build xong” là vạch đích. Một mart hoàn hảo cho việc refresh BI hằng đêm có thể quá chậm, hoặc quá cũ, để phục vụ một feature store cho inference thời gian thực. Thiết kế serving layer tốt nghĩa là hiểu, với từng consumer, không chỉ dữ liệu gì họ cần mà còn nhanh đến đâu, tần suất ra sao, và hình dạng nào — và sự hiểu biết đó phải có trước khi pipeline được xây, chứ không phải sau khi phát hiện dashboard chậm đến mức không dùng được.

Business Intelligence (BI) tools

Các công cụ BI tồn tại để cho phép những người không viết SQL — hoặc không muốn viết SQL mỗi lần — khám phá dữ liệu trực quan và xây dashboard mà không cần đội engineering hỗ trợ. Ba cái tên thống trị đều đi từ cùng một ý tưởng nền tảng (kết nối tới warehouse, modeling hoặc map các bảng của nó, cho người dùng kéo-thả field lên canvas để tạo chart) nhưng khác nhau về triết lý:

Công cụ	Mô hình hoạt động	Điểm mạnh nổi bật
Tableau	Kết nối tới warehouse hoặc extract dữ liệu vào engine in-memory riêng (Hyper)	Khám phá trực quan và phân tích ad-hoc “kéo-thả” hàng đầu; phù hợp cho analyst muốn tự do đào sâu dữ liệu
Looker	Query-pushdown — luôn query trực tiếp warehouse, không bao giờ extract dữ liệu ra riêng	LookML, một semantic modeling layer được version-control (xem bên dưới) tập trung hóa định nghĩa metric và dimension
Power BI	Kết nối tới warehouse hoặc import dữ liệu vào engine columnar riêng (VertiPaq)	Tích hợp sâu với hệ sinh thái Microsoft (Excel, Azure, Teams); DAX cho các measure tính toán

Điểm chung của cả ba là chúng chỉ tốt bằng chất lượng dữ liệu bên dưới. Một BI tool là một thấu kính, không phải một cách sửa lỗi — nó hiển thị bất cứ thứ gì warehouse cung cấp, với tốc độ mà warehouse có thể trả lời một query. Đây là lý do bài về data modeling trước đó liên quan trực tiếp đến đây: một warehouse được modeling tốt — cụ thể là star schema (./06-data-modeling-and-warehousing.md) với các bảng fact và dimension sạch sẽ — chính là thứ khiến BI tool cảm giác nhanh và đáng tin cậy, còn một warehouse đầy các bảng raw không được quản trị và join tùy tiện là thứ khiến chúng cảm giác chậm và rối rắm.

Hai cơ chế cụ thể giải thích tại sao model lại quan trọng đến vậy:

• Tốc độ query. Một BI tool thường generate SQL ngay khi người dùng kéo field lên canvas. Nếu các bảng bên dưới đã là star schema denormalized — chỉ một join từ fact tới mỗi dimension — SQL được generate ra chỉ là vài join và aggregation đơn giản, và một warehouse columnar hiện đại trả lời trong vài giây. Nếu thay vào đó BI tool phải join tám bảng normalized và phải phân biệt cột created_at nào trong ba cột là “đúng”, mỗi lần load dashboard trở thành một query đắt đỏ, mong manh, và người dùng cảm nhận điều đó là “BI chậm”.
• Độ đáng tin cậy. Một star schema với các fact và dimension được đặt tên rõ ràng, tài liệu hóa đầy đủ (fct_orders, dim_customer) cho người dùng một bộ từ vựng nhỏ, dễ hiểu để xây dựng lên. Một đống bảng raw, không tài liệu sẽ khiến mỗi analyst định nghĩa “một đơn hàng” hay “một khách hàng active” hơi khác nhau một chút, và đó chính là mầm mống của vấn đề mà semantic layer (phần tiếp theo) được sinh ra để ngăn chặn.

Khám phá self-service và giới hạn của nó

Lời hứa của BI tool là self-service: một trưởng nhóm marketing tự xây biểu đồ hiệu suất chiến dịch của mình mà không cần mở ticket cho đội dữ liệu. Điều này thực sự hiệu quả khi warehouse được modeling tốt, bởi self-service exploration thực chất là “để người không phải kỹ sư tự kết hợp các khối xây dựng (fact, dimension, metric) đã được định nghĩa sẵn và đáng tin cậy”, chứ không phải “để bất kỳ ai viết SQL tùy ý trên dữ liệu raw”. Công việc của data engineer là xây và duy trì những khối xây dựng đó; BI tool và semantic layer là thứ khiến việc kết hợp chúng an toàn cho những người không có nền tảng data engineering.

Khái niệm chính

Semantic layer: một metric, định nghĩa một lần duy nhất

Ý tưởng quan trọng nhất trong bài này là semantic layer: một tầng được quản trị (governed), nằm giữa warehouse và mọi BI tool hay dashboard, nơi các metric và dimension nghiệp vụ được định nghĩa đúng một lần — “active user”, “revenue”, “churned customer” — và mọi consumer phía sau tham chiếu tới định nghĩa duy nhất đó thay vì tự tính lại.

Vấn đề mà semantic layer giải quyết rất quen thuộc với bất kỳ ai từng làm ở công ty có nhiều hơn một dashboard: năm dashboard khác nhau hiển thị năm con số khác nhau cho “revenue”, vì năm người khác nhau viết năm câu SQL khác nhau, mỗi câu mang một giả định hơi khác. “Revenue” của analyst này bao gồm thuế; của người khác thì loại trừ refund; người thứ ba join theo order_date trong khi người thứ tư join theo shipped_date. Không ai trong số họ nói dối — mỗi người chỉ đưa ra một lựa chọn nghe có vẻ hợp lý một cách độc lập, và không có một nơi duy nhất để tra cứu định nghĩa “chính thức”. Kết quả là một cuộc khủng hoảng niềm tin: ban lãnh đạo ngừng tin dashboard, và mỗi con số lại bị tranh cãi lại trong các cuộc họp thay vì thúc đẩy quyết định.

Semantic layer sửa vấn đề này về mặt cấu trúc chứ không dựa vào kỷ luật hay email nhắc nhở. Metric được định nghĩa một lần, thường ở dạng code:

# Ví dụ: một metric định nghĩa một lần trong semantic layer (kiểu dbt Semantic Layer / MetricFlow)
metrics:
  - name: revenue
    label: "Revenue"
    description: "Doanh thu thuần ghi nhận: tổng giá trị đơn hàng trừ refund, không tính thuế."
    type: simple
    type_params:
      measure: net_order_amount
    filter: |
      {{ Dimension('order__status') }} = 'completed'

# Ví dụ: cùng ý tưởng được thể hiện bằng LookML, semantic modeling layer của Looker
measure: revenue {
  type: sum
  sql: ${TABLE}.net_order_amount ;;
  filters: [order.status: "completed"]
  description: "Doanh thu thuần ghi nhận: tổng giá trị đơn hàng trừ refund, không tính thuế."
}

Mọi dashboard, mọi ad-hoc query đi qua semantic layer, và mọi BI tool kết nối tới nó giờ đây kế thừa cùng một revenue — thay đổi định nghĩa một lần (chẳng hạn bộ phận tài chính quyết định revenue nên được ghi nhận theo shipped_date thay vì order_date) và mọi consumer cập nhật đồng bộ, thay vì phải lùng sục và sửa mười hai câu SQL riêng lẻ nằm rải rác trong các dashboard mà không ai còn nhớ ai đã xây.

LookML đáng được nhắc riêng ở đây vì đây là một trong những triển khai được áp dụng rộng rãi sớm nhất của ý tưởng này: thay vì mỗi dashboard Looker chứa SQL riêng, LookML định nghĩa dimension và measure một lần, trong các file .lkml được version-control, và mọi “Explore” cũng như dashboard trong Looker được sinh ra từ model chung đó. dbt Semantic Layer gần đây hơn (xây trên nền MetricFlow) tổng quát hóa cùng ý tưởng đó ra ngoài phạm vi của bất kỳ một BI tool cụ thể nào — các metric được định nghĩa một lần trong dbt project cùng với các model mà chúng được xây dựng từ đó, và bất kỳ BI tool nào có tích hợp semantic layer (không riêng của một vendor) đều có thể query chúng một cách nhất quán. Công cụ cụ thể không quan trọng bằng nguyên tắc: định nghĩa metric thuộc về một tầng được quản trị, version-control, chứ không phải rải rác trong SQL riêng của từng dashboard.

Streamlit và các internal app nhẹ

Không phải nhu cầu dữ liệu nội bộ nào cũng đáng để chịu chi phí — về license, setup, và overhead quản trị — của một nền tảng BI đầy đủ. Streamlit (và các framework tương tự như Gradio hay Dash) cho phép data engineer hoặc analyst biến một script Python thành một web app tương tác chỉ trong vài chục dòng code, mà không cần đụng tới HTML, CSS, hay JavaScript:

import streamlit as st
import pandas as pd

df = pd.read_sql("select * from fct_orders", con=warehouse_connection)

st.title("Orders Dashboard")
region = st.selectbox("Region", df["region"].unique())
filtered = df[df["region"] == region]

st.metric("Total Revenue", f"${filtered['amount_usd'].sum():,.2f}")
st.bar_chart(filtered.groupby("order_month")["amount_usd"].sum())

Vị trí ngách của nó so với Tableau, Looker, hay Power BI hẹp nhưng có thật: các công cụ nội bộ nhanh gọn cho một nhóm người dùng nhỏ — một app khám phá dùng một lần cho đội data science, một công cụ QA nội bộ để review kết quả pipeline, một dashboard prototype trước khi quyết định một metric có xứng đáng có một “ngôi nhà” lâu dài trong stack BI thật sự hay không. Điều nó cố tình không cung cấp là chính điều mà một nền tảng BI đầy đủ được xây dựng để làm: governance cấp doanh nghiệp, row-level security, semantic layer dùng chung, phân phối theo lịch cho hàng trăm người dùng nghiệp vụ, hay trải nghiệm self-service bóng bẩy cho nhân viên không rành kỹ thuật. Quy tắc chung: dùng Streamlit khi đối tượng nhỏ, kỹ thuật, và nội bộ; dùng nền tảng BI khi đối tượng rộng, không rành kỹ thuật, và cần các metric khớp với mọi dashboard khác trong công ty.

Thực hành data analytics: analyst làm gì với những gì engineer xây

Đáng để làm rõ sự phân công lao động ngụ ý trong tất cả những gì ở trên. Descriptive analytics (mô tả — chuyện gì đã xảy ra) phần lớn là công việc của BI tool: nó trả lời các câu hỏi như “revenue quý trước là bao nhiêu” hay “khu vực nào tăng trưởng nhanh nhất”, và đây chính xác là loại câu hỏi mà một warehouse được modeling tốt cùng semantic layer được xây dựng để trả lời nhanh và nhất quán. Xa hơn nữa là phân tích sâu hơn: diagnostic analytics (tại sao chuyện đó xảy ra), và những công việc pha trộn vào data science — phân tích cohort, kiểm định thống kê, suy luận nhân quả (causal inference), dự báo (forecasting).

Vai trò của data engineer trong công việc sâu hơn này là hỗ trợ (enabling), không phải thực hiện. Data engineer thường không chạy hồi quy hay thiết kế phân tích cohort; data engineer đảm bảo pipeline nuôi phân tích đó tạo ra các data model sạch, tài liệu hóa đầy đủ, hiệu năng tốt, để analyst hoặc data scientist có thể dành thời gian cho câu hỏi phân tích thực sự thay vì cho việc “khảo cổ dữ liệu” — truy tìm tại sao một join tạo ra hàng trùng lặp, hay tại sao ý nghĩa của một cột thay đổi âm thầm ba tháng trước. Dấu hiệu rõ ràng nhất của một bàn giao lành mạnh là analyst dành phần lớn thời gian đặt và trả lời câu hỏi nghiệp vụ, và chỉ hiếm khi phải đào sâu vào bảng nguồn raw vì có gì đó trong tầng modeling không khớp.

Hạ tầng A/B testing

Thử nghiệm (experimentation) là một trong những ví dụ sắc nét nhất về việc “data engineering vẫn quan trọng dù câu hỏi thú vị là một câu hỏi thống kê”. Một A/B test chỉ đáng tin cậy bằng chính các event nuôi nó, và có một số điểm hỏng đặc thù kỹ thuật có thể âm thầm vô hiệu hóa một thí nghiệm được thiết kế tốt về mặt thống kê:

• Ghi log assignment đáng tin cậy. Khi một người dùng được phân vào một variant, event assignment đó phải được ghi log đáng tin cậy và đúng một lần — ghi quá trễ, bị mất khi tải cao, hoặc ghi nhiều lần, và mẫu số của thí nghiệm (bao nhiêu người dùng thực sự tiếp xúc với mỗi variant) đã sai ngay cả trước khi xem xét đến dữ liệu kết quả.
• Ghi log outcome đáng tin cậy và join đúng. Event outcome (một giao dịch mua, một cú click, một lượt đăng ký) phải được join lại đúng với assignment tương ứng — bằng một định danh user hoặc session ổn định, trong đúng khung thời gian tương ứng với lúc tiếp xúc. Một bug pipeline join outcome sai với assignment (ví dụ dùng session ID reset qua các thiết bị, hoặc một khung thời gian để lọt hành vi trước-thí-nghiệm vào phân tích) có thể khiến một tính năng trung tính trông như thắng, hoặc một tính năng thắng trông như trung tính.
• Sample Ratio Mismatch (SRM). Nếu một thí nghiệm được cấu hình chia 50/50 nhưng dữ liệu assignment ghi lại cho thấy, chẳng hạn, tỷ lệ 52/48 có ý nghĩa thống kê, đó là sample ratio mismatch — một tín hiệu mạnh cho thấy có gì đó trong pipeline bị hỏng (một bug khiến event assignment của một variant bị rớt thường xuyên hơn, một lớp redirect hay cache hoạt động khác nhau theo variant, một rule lọc bot loại bỏ không cân đối một nhóm) chứ không phải một vấn đề ngẫu nhiên hóa thực sự. Kiểm tra SRM nên chạy tự động trước khi bất kỳ ai xem kết quả metric thực tế, bởi một thí nghiệm có SRM không đo được đúng cái nó tuyên bố đo, dù con số cuối cùng có thuyết phục đến đâu.

Yêu cầu kỹ thuật ở đây hẹp nhưng không thể thương lượng: một event pipeline (./08-etl-elt-and-data-pipelines.md, ./11-streaming-and-realtime-data.md) ghi nhận event assignment và outcome với đảm bảo delivery mạnh, định danh ổn định tồn tại suốt thời gian thí nghiệm, và giám sát tự động phát hiện SRM cùng các bất thường pipeline khác — bởi một nhà thống kê ở cuối chuỗi không thể sửa được dữ liệu thiếu hoặc join sai, dù bài kiểm định ý nghĩa có tinh vi đến đâu.

Feature store và training-serving skew

Việc tiêu thụ serving layer cho machine learning có một vấn đề mà BI dashboard không có: cùng một feature — chẳng hạn “số lần mua hàng của khách này trong 30 ngày qua” — phải được tính giống hệt nhau trong hai bối cảnh rất khác nhau. Trong quá trình training, nó được tính hàng loạt trên dữ liệu lịch sử, thường bằng một job SQL hoặc Spark batch. Trong quá trình inference (phục vụ dự đoán thời gian thực), nó phải được tính cho một entity duy nhất, ngay lúc này, thường với ngân sách độ trễ tính bằng mili giây, đôi khi từ một code path hoàn toàn khác hoặc thậm chí một service của một đội khác. Nếu hai phép tính này lệch nhau dù chỉ một chút — xử lý múi giờ khác nhau, lệch một đơn vị trong cửa sổ lookback, định nghĩa “giao dịch mua” hơi khác — model sẽ thấy giá trị feature khác trong production so với lúc nó được huấn luyện, và độ chính xác của nó âm thầm giảm sút. Đây là training-serving skew, và đây là một trong những nguyên nhân phổ biến nhất khiến một model chấm điểm tốt offline nhưng lại kém trong production.

Một feature store (Feast, Tecton, hoặc dịch vụ native trên cloud như SageMaker Feature Store) là serving layer chuyên biệt được xây để đóng khoảng cách này. Nó tính một feature một lần, từ một định nghĩa transformation duy nhất, và lưu trữ dưới hai dạng được giữ nhất quán với nhau: một offline store (thường là warehouse hoặc lake, chứa giá trị feature lịch sử để training) và một online store (một key-value store độ trễ thấp, thường dựa trên Redis, chứa giá trị hiện tại của mỗi feature để tra cứu inference thời gian thực). Vì cả hai store đều được nạp từ cùng một định nghĩa feature, một model được huấn luyện với giá trị lịch sử của offline store sẽ thấy đúng ngữ nghĩa feature đó tại thời điểm inference từ online store — loại bỏ skew bằng thiết kế thay vì bằng quy ước.

Vai trò của data engineer trong ML pipeline phản ánh vai trò của họ trong analytics: tính toán feature đáng tin cậy, không phải huấn luyện model. Xây dựng và vận hành các pipeline tính feature đúng, backfill giá trị lịch sử cho training, và giữ online store luôn cập nhật (thường theo cơ chế streaming cho các feature cần phản ánh hoạt động rất gần đây) chính là công việc data engineering; chọn kiến trúc model và tinh chỉnh nó là công việc thuộc về vai trò machine learning. Phần nội dung ML/MLOps sâu hơn — huấn luyện model, đánh giá, triển khai — nếu có ở nơi khác trong bộ kiến thức này, thì bài này chỉ giới hạn trong nửa serving layer của ranh giới đó.

Các mẫu tiêu thụ và điểm hỏng thường gặp

Các consumer khác nhau của serving layer cần những thứ khác nhau từ data engineer, và việc bỏ bê serving layer sẽ làm hỏng mỗi cái theo một cách đặc trưng:

Consumption pattern	Data engineer cần cung cấp gì	Điểm hỏng thường gặp nếu bị bỏ bê
BI dashboard	Star schema được modeling tốt, hiệu năng query nhanh, metric được định nghĩa trong semantic layer dùng chung	Dashboard chậm, hoặc năm dashboard mâu thuẫn về cùng một metric vì mỗi cái được xây bằng SQL ad-hoc
Reverse ETL	Bảng mart đáng tin cậy, đã khử trùng lặp, với key ổn định khớp với dữ liệu ở hệ thống đích	Dữ liệu sai hoặc cũ bị đẩy vào CRM/công cụ marketing, âm thầm làm hỏng hệ thống vận hành mà đội nghiệp vụ dựa vào
ML feature store	Feature được tính giống hệt cho training (offline) và inference (online), refresh theo nhịp/độ trễ đã biết	Training-serving skew — model suy giảm hiệu năng trong production dù chấm điểm tốt offline, và nguyên nhân vô hình nếu không so sánh trực tiếp giá trị feature offline và online
Ad-hoc analyst query	Các bảng sạch, tài liệu hóa, hiệu năng tốt, đặt tên và lineage rõ ràng	Analyst tốn thời gian đảo ngược các bảng raw, hoặc rút ra kết luận sai từ cột/join không được tài liệu hóa

Best Practices

• Coi semantic layer là hạ tầng bắt buộc, không phải “có thì tốt”. Ngay khi hơn một dashboard hoặc công cụ cần cùng một metric, hãy định nghĩa nó một lần trong một tầng được quản trị (LookML, dbt Semantic Layer, hoặc tương đương) thay vì để nó bị tính lại tùy tiện — vấn đề “năm dashboard, năm con số” rẻ hơn nhiều để ngăn chặn so với việc debug sau khi ban lãnh đạo đã mất niềm tin vào dữ liệu.
• Modeling theo consumer, không chỉ theo lưu trữ. Một star schema tối ưu cho tốc độ query BI có thể không phải hình dạng đúng cho việc tra cứu độ trễ thấp của feature store; thiết kế hình dạng serving xoay quanh cách dữ liệu thực sự được truy vấn, không chỉ xoay quanh cách lưu trữ rẻ nhất.
• Đừng bao giờ để BI tool che đậy một model tồi. Nếu một dashboard chậm hoặc rối, cách sửa hầu như luôn nằm ở thượng nguồn — modeling tốt hơn, join tốt hơn, tài liệu tốt hơn — chứ không phải một cách vá phức tạp hơn trong BI tool đặt chồng lên một warehouse lộn xộn.
• Trang bị cho pipeline A/B testing các kiểm tra SRM và delivery event tự động, và coi những kiểm tra đó là một cổng chạy trước khi bất kỳ ai xem kết quả thí nghiệm, vì một pipeline hỏng có thể tạo ra một câu trả lời tự tin nhưng sai, trông có vẻ hợp lệ về mặt thống kê.
• Xây dựng logic tính feature một lần và dùng chung giữa training và serving, thông qua một feature store hoặc một transformation dùng chung tương đương, thay vì để pipeline training và service inference tự triển khai lại độc lập cùng một logic feature — sự trùng lặp đó chính là nơi training-serving skew len lỏi vào.
• Dùng công cụ nhẹ (Streamlit) cho đối tượng nội bộ, kỹ thuật, quy mô nhỏ, và dùng nền tảng BI đầy đủ khi đối tượng rộng hoặc không rành kỹ thuật — khớp đúng công cụ với đối tượng giúp tránh cả việc over-engineer một script nội bộ dùng một lần lẫn việc phục vụ kém một nhu cầu báo cáo toàn công ty.
• Nhớ rằng “xong” nghĩa là “được tiêu thụ”, không phải “đã được modeling”. Một pipeline đưa dữ liệu hoàn hảo vào một mart không ai query, một feature không model nào dùng, hay một metric không dashboard nào tham chiếu thì chưa mang lại giá trị — khép lại vòng lặp với consumer thực sự, như được đề cập thêm ở ./20-career-and-best-practices.md, là một phần của công việc, không phải một điểm cộng thêm.

Tài liệu tham khảo

• Looker — LookML Terms and Concepts
• dbt Labs — The dbt Semantic Layer
• dbt Labs — MetricFlow
• Streamlit Documentation
• Feast — Feature Store Documentation
• Martin Fowler — What Do You Mean by “Event-Driven”?
• Microsoft — Detecting and Avoiding Sample Ratio Mismatch (SRM)
• Tecton — What is a Feature Store?

# Example: a metric defined once in a semantic layer (dbt Semantic Layer / MetricFlow style)
metrics:
  - name: revenue
    label: "Revenue"
    description: "Net revenue recognized: gross order amount minus refunds, excluding tax."
    type: simple
    type_params:
      measure: net_order_amount
    filter: |
      {{ Dimension('order__status') }} = 'completed'

# Example: the same idea expressed in LookML, Looker's semantic modeling layer
measure: revenue {
  type: sum
  sql: ${TABLE}.net_order_amount ;;
  filters: [order.status: "completed"]
  description: "Net revenue recognized: gross order amount minus refunds, excluding tax."
}

import streamlit as st
import pandas as pd

df = pd.read_sql("select * from fct_orders", con=warehouse_connection)

st.title("Orders Dashboard")
region = st.selectbox("Region", df["region"].unique())
filtered = df[df["region"] == region]

st.metric("Total Revenue", f"${filtered['amount_usd'].sum():,.2f}")
st.bar_chart(filtered.groupby("order_month")["amount_usd"].sum())