怎么建個(gè)自己的網(wǎng)站seo建站收費(fèi)地震
摘要
數(shù)據(jù)建模設(shè)計(jì)是數(shù)據(jù)治理體系中的關(guān)鍵組成，承載著數(shù)據(jù)標(biāo)準(zhǔn)化、資產(chǎn)化與高質(zhì)量使用的核心目標(biāo)。本文從治理視角出發(fā)，深入探討數(shù)據(jù)建模在保障企業(yè)數(shù)據(jù)一致性、復(fù)用性和共享性方面的重要作用。文章首先梳理了建模的三層體系：概念模型、邏輯模型與物理模型，并分析它們在治理流程中的職責(zé)分工與協(xié)同機(jī)制。接著，重點(diǎn)介紹了維度建模（如星型、雪花模型）與范式建模的特點(diǎn)與適用場景，特別是在大數(shù)據(jù)環(huán)境下的實(shí)踐差異。在建模規(guī)范方面，文章提出應(yīng)遵循統(tǒng)一命名、粒度控制、鍵值管理和維度共享等標(biāo)準(zhǔn)，確保數(shù)據(jù)模型在多系統(tǒng)、多主題下的兼容性與可控性。圍繞一致性維度、數(shù)據(jù)總線架構(gòu)和交叉探查等關(guān)鍵設(shè)計(jì)方法，進(jìn)一步強(qiáng)化了跨主題的數(shù)據(jù)整合與業(yè)務(wù)聯(lián)動能力。結(jié)合阿里巴巴等領(lǐng)先企業(yè)實(shí)踐，文章總結(jié)出以業(yè)務(wù)為主線、共享為導(dǎo)向、標(biāo)準(zhǔn)為底座的數(shù)據(jù)建模治理方法論，強(qiáng)調(diào)數(shù)據(jù)模型不僅是數(shù)據(jù)管理工具，更是企業(yè)數(shù)字化治理能力的重要體現(xiàn)。
1. 為什么需要數(shù)據(jù)建模
在大數(shù)據(jù)系統(tǒng)中，數(shù)據(jù)建模是指通過定義數(shù)據(jù)結(jié)構(gòu)、關(guān)系、規(guī)則和約束，將現(xiàn)實(shí)世界的業(yè)務(wù)需求轉(zhuǎn)化為可計(jì)算的數(shù)字化模型的過程。其核心目標(biāo)是高效組織、存儲和處理海量數(shù)據(jù)，確保數(shù)據(jù)可被系統(tǒng)理解、分析和應(yīng)用?，F(xiàn)代架構(gòu)中（如Lambda架構(gòu)），還會引入實(shí)時(shí)數(shù)倉（如Apache Doris）和Data Lake（如Delta Lake），進(jìn)一步擴(kuò)展建模靈活性。
1.1. 為什么需要數(shù)據(jù)建模？
- 結(jié)構(gòu)化數(shù)據(jù)，降低復(fù)雜度
大數(shù)據(jù)環(huán)境通常包含多源異構(gòu)數(shù)據(jù)（如日志、文本、圖像等）。數(shù)據(jù)建模通過分類、關(guān)聯(lián)和標(biāo)準(zhǔn)化（如星型模型、寬表設(shè)計(jì)）將雜亂數(shù)據(jù)轉(zhuǎn)化為有邏輯的體系，減少處理復(fù)雜度。 - 提升查詢與分析效率
合理的模型設(shè)計(jì)（如列式存儲、分區(qū)鍵選擇）能顯著優(yōu)化查詢性能。例如，在Hive中通過分區(qū)和分桶減少I/O開銷；在ClickHouse中使用預(yù)聚合模型加速分析。 - 支持業(yè)務(wù)需求
模型需反映業(yè)務(wù)邏輯（如用戶行為漏斗、供應(yīng)鏈鏈路）。例如，電商場景的“用戶-訂單-商品”關(guān)系模型直接影響推薦算法的準(zhǔn)確性。 - 數(shù)據(jù)一致性與質(zhì)量
通過約束（如主外鍵、非空校驗(yàn)）和標(biāo)準(zhǔn)化（如維度建模中的緩慢變化維處理），避免數(shù)據(jù)冗余和沖突，確保下游應(yīng)用（如BI報(bào)表、AI訓(xùn)練）的可靠性。 - 適應(yīng)技術(shù)棧特性
不同大數(shù)據(jù)工具對模型有特定要求。例如：
-
- HBase：需設(shè)計(jì)行鍵（RowKey）以實(shí)現(xiàn)高效隨機(jī)讀寫。
- Kafka：通過Topic分區(qū)策略影響消息并行處理能力。
- 圖數(shù)據(jù)庫（如Neo4j）：需明確節(jié)點(diǎn)與邊的屬性以優(yōu)化遍歷查詢。
- 成本優(yōu)化
模型設(shè)計(jì)直接影響存儲和計(jì)算成本。例如：
-
- 數(shù)據(jù)湖中合理的分區(qū)策略可減少掃描數(shù)據(jù)量，降低AWS S3請求費(fèi)用。
- 列式存儲（Parquet/ORC）結(jié)合壓縮技術(shù)節(jié)省存儲空間。
1.2. 大數(shù)據(jù)建模的關(guān)鍵方法
- 維度建模（如Kimball模型）：面向分析場景，構(gòu)建事實(shí)表（交易記錄）與維度表（用戶、時(shí)間等）。
- 數(shù)據(jù)倉庫分層（ODS→DWD→DWS→ADS）：逐層加工，平衡冗余與效率。
- 流式數(shù)據(jù)模型：處理實(shí)時(shí)數(shù)據(jù)時(shí)需考慮時(shí)間窗口、狀態(tài)管理等（如Flink的Keyed State）。
- NoSQL模型：如文檔數(shù)據(jù)庫（MongoDB）的嵌套結(jié)構(gòu)、時(shí)序數(shù)據(jù)庫（InfluxDB）的時(shí)間線設(shè)計(jì)。
1.3. 實(shí)際案例
- 推薦系統(tǒng)：用戶畫像模型需整合行為日志（點(diǎn)擊、購買）、社交關(guān)系等，建模為特征向量供算法使用。
- 風(fēng)控系統(tǒng)：通過圖模型關(guān)聯(lián)設(shè)備、IP、交易記錄，識別欺詐團(tuán)伙。
2. 關(guān)系數(shù)據(jù)庫系統(tǒng)與數(shù)據(jù)倉庫
關(guān)系數(shù)據(jù)庫系統(tǒng)（RDBMS）和數(shù)據(jù)倉庫（Data Warehouse）在數(shù)據(jù)建模中扮演不同的角色，但共同服務(wù)于數(shù)據(jù)的組織、存儲和分析。以下是它們的核心作用對比及協(xié)同關(guān)系：
2.1. 關(guān)系數(shù)據(jù)庫系統(tǒng)（RDBMS）的建模作用
核心目標(biāo)：支持事務(wù)處理（OLTP），保證數(shù)據(jù)的實(shí)時(shí)性、一致性和完整性。
典型場景：業(yè)務(wù)系統(tǒng)（如ERP、CRM）、在線交易（如電商訂單）。
建模特點(diǎn)：
- 范式化設(shè)計(jì)（3NF或更高）：通過消除冗余（如拆分表、外鍵關(guān)聯(lián)）確保數(shù)據(jù)一致性。例如，用戶表、訂單表、商品表分開存儲，通過主外鍵關(guān)聯(lián)。
- ACID事務(wù)支持：模型需滿足原子性、一致性（如轉(zhuǎn)賬操作必須同時(shí)更新雙方賬戶）。
- 優(yōu)化高頻小查詢：索引設(shè)計(jì)（如B樹索引）加速點(diǎn)查詢（如按訂單ID查詳情）。
局限性：復(fù)雜分析查詢（如多表JOIN、聚合）性能較差，因范式化導(dǎo)致多次表關(guān)聯(lián)。
2.2. 數(shù)據(jù)倉庫的建模作用
核心目標(biāo)：支持分析決策（OLAP），實(shí)現(xiàn)高性能復(fù)雜查詢和歷史數(shù)據(jù)分析。
典型場景：BI報(bào)表、趨勢分析、數(shù)據(jù)挖掘。
建模特點(diǎn)：
- 維度建模（星型/雪花模型）：
-
- 事實(shí)表：存儲業(yè)務(wù)度量（如銷售額、點(diǎn)擊量），通常為數(shù)值型且數(shù)據(jù)量大。
- 維度表：描述業(yè)務(wù)上下文（如時(shí)間、用戶、地區(qū)），通過外鍵與事實(shí)表關(guān)聯(lián)。
- 反范式化設(shè)計(jì)：允許冗余（如將常用維度屬性直接嵌入事實(shí)表）以減少JOIN操作。
- 分層架構(gòu)（ODS→DWD→DWS→ADS）：
逐層加工，從原始數(shù)據(jù)（ODS）到主題寬表（DWS），最終生成應(yīng)用層聚合結(jié)果（ADS）。 - 優(yōu)化批量分析：
列式存儲（如Parquet）、分區(qū)（按日期）、預(yù)聚合（如物化視圖）加速聚合查詢。
局限性：不適合高頻寫入或?qū)崟r(shí)事務(wù)，通常通過ETL定期從RDBMS同步數(shù)據(jù)。
2.3. 兩者在數(shù)據(jù)建模中的協(xié)同關(guān)系
| 維度 | 關(guān)系數(shù)據(jù)庫（OLTP） | 數(shù)據(jù)倉庫（OLAP） |
| 建模目標(biāo) | 支持事務(wù)，確保數(shù)據(jù)精確 | 支持分析，提升查詢性能 |
| 設(shè)計(jì)范式 | 高度范式化（減少冗余） | 反范式化（允許冗余） |
| 查詢類型 | 簡單查詢（單行增刪改查） | 復(fù)雜查詢（多表聚合、時(shí)間窗口分析） |
| 數(shù)據(jù)時(shí)效性 | 實(shí)時(shí) | 近實(shí)時(shí)或T+1（依賴ETL調(diào)度） |
| 典型工具 | MySQL、PostgreSQL、Oracle | Snowflake、Redshift、Hive、ClickHouse |
2.4. 協(xié)同流程示例：
- 數(shù)據(jù)產(chǎn)生：業(yè)務(wù)系統(tǒng)的RDBMS處理交易（如用戶下單），模型需滿足高并發(fā)寫入。
- ETL同步：通過工具（如Airflow、Kafka）將RDBMS數(shù)據(jù)抽取到數(shù)據(jù)倉庫，建模轉(zhuǎn)為星型模型。
- 分析應(yīng)用：數(shù)據(jù)倉庫中預(yù)計(jì)算指標(biāo)（如月度銷售額TOP10），供BI工具（如Tableau）展示。
2.5. 實(shí)際案例對比
- 電商場景：
-
- RDBMS模型：訂單表（
orders）與用戶表（users）分開，通過user_id關(guān)聯(lián)。 - 數(shù)據(jù)倉庫模型：寬表
dws_orders直接包含用戶姓名、地區(qū)等維度字段，避免分析時(shí)JOIN用戶表。
- RDBMS模型：訂單表（
- 性能差異：
-
- RDBMS查詢：
SELECT * FROM orders WHERE order_id = 1001（毫秒級響應(yīng)）。 - 數(shù)據(jù)倉庫查詢：
SELECT region, SUM(sales) FROM dws_orders GROUP BY region（秒級響應(yīng)，但處理億級數(shù)據(jù)）。
- RDBMS查詢：
2.6. 關(guān)系數(shù)據(jù)庫與數(shù)倉總結(jié)
- 關(guān)系數(shù)據(jù)庫建模是業(yè)務(wù)系統(tǒng)的基石，確保數(shù)據(jù)的準(zhǔn)確性和事務(wù)安全。
- 數(shù)據(jù)倉庫建模是分析的引擎，通過犧牲部分實(shí)時(shí)性換取分析效率。
- 兩者互補(bǔ)：RDBMS為數(shù)據(jù)倉庫提供高質(zhì)量數(shù)據(jù)源，數(shù)據(jù)倉庫釋放RDBMS的分析壓力。
3. 典型的數(shù)據(jù)倉庫建模方法
數(shù)據(jù)倉庫建模方法論的核心是將數(shù)據(jù)高效組織為適合分析的結(jié)構(gòu)，兼顧查詢性能、靈活性和可維護(hù)性。以下是幾種典型方法論及其應(yīng)用場景：
| 建模方法 | 簡要定義 | 典型使用場景 | 為什么使用該方法 |
| 維度建模（維度模型） | 以“事實(shí)表 + 維度表”的結(jié)構(gòu)設(shè)計(jì)，強(qiáng)調(diào)數(shù)據(jù)可讀性和分析便利性 | BI 報(bào)表分析、運(yùn)營分析、用戶行為分析、銷售分析等 OLAP 場景 | - 易理解、面向業(yè)務(wù)人員 |
| 范式建模（規(guī)范化模型） | 數(shù)據(jù)高度規(guī)范化，避免冗余，通過主外鍵連接形成結(jié)構(gòu)復(fù)雜的模型 | ERP、CRM、銀行核心系統(tǒng)、強(qiáng)一致性業(yè)務(wù)系統(tǒng)等 OLTP 場景 | - 數(shù)據(jù)一致性強(qiáng) |
| Data Vault 建模 | 將數(shù)據(jù)拆分為 Hub（主鍵）、Link（關(guān)系）、Satellite（屬性）三類表 | 跨系統(tǒng)數(shù)據(jù)整合、企業(yè)級數(shù)據(jù)倉庫建設(shè)、數(shù)據(jù)湖倉融合項(xiàng)目 | - 支持歷史追蹤（變化記錄） |
| 寬表建模（扁平建模） | 將多個(gè)維度字段拉平到一個(gè)大表中（避免 JOIN） | 實(shí)時(shí)報(bào)表、指標(biāo)計(jì)算、面向應(yīng)用的查詢（如大屏、接口） | - 查詢簡單、性能高（特別是 NoSQL/OLAP 引擎） |
| 分層建模（數(shù)倉分層架構(gòu)） | 按數(shù)據(jù)處理粒度、加工深度將數(shù)據(jù)劃分為多個(gè)層級 | 大型企業(yè)數(shù)倉、實(shí)時(shí)數(shù)倉、銀行/保險(xiǎn)等典型業(yè)務(wù)數(shù)倉 | - 邏輯清晰、利于治理 |
3.1. 維度建模（Dimensional Modeling）
核心理念：以業(yè)務(wù)過程為中心，構(gòu)建事實(shí)表+維度表的星型/雪花模型，直觀易用且優(yōu)化分析性能。
適用場景：BI報(bào)表、即席查詢（如零售銷售分析、用戶行為漏斗）。
3.1.1. 關(guān)鍵組件：
- 事實(shí)表（Fact Table）
-
- 存儲業(yè)務(wù)過程的度量值（如銷售額、點(diǎn)擊量），通常是數(shù)值型、可聚合的字段。
- 類型：事務(wù)型（每條記錄獨(dú)立）、周期快照型（如每日庫存）、累積快照型（如訂單全鏈路狀態(tài)）。
- 維度表（Dimension Table）
-
- 描述業(yè)務(wù)上下文（如時(shí)間、用戶、產(chǎn)品），包含文本屬性用于過濾和分組。
- 特殊處理：緩慢變化維（SCD）解決維度屬性隨時(shí)間變化的問題（如用戶地址變更）。
3.1.2. 模型變體：
- 星型模型：維度表直接關(guān)聯(lián)事實(shí)表，查詢簡單但可能存在冗余。
- 雪花模型：維度表進(jìn)一步規(guī)范化（如地區(qū)維度拆分為國家、省、市），減少冗余但增加JOIN復(fù)雜度。
3.2. 規(guī)范化建模（Inmon方法）
核心理念：先構(gòu)建企業(yè)級原子數(shù)據(jù)倉庫（EDW），高度范式化（3NF），再按主題生成數(shù)據(jù)集市。
適用場景：大型企業(yè)需要長期維護(hù)單一數(shù)據(jù)源（如金融行業(yè)合規(guī)報(bào)表）。
3.2.1. 特點(diǎn)：
- 自上而下：先集中整合全企業(yè)數(shù)據(jù)，確保一致性，再按部門需求派生數(shù)據(jù)集市。
- 強(qiáng)調(diào)整體性：數(shù)據(jù)冗余少，但ETL復(fù)雜，初期投入大。
3.3. Data Vault建模
核心理念：適應(yīng)數(shù)據(jù)變化的混合模型（結(jié)合范式化和維度建模），強(qiáng)調(diào)可追溯性和靈活性。
適用場景：數(shù)據(jù)集成復(fù)雜、需求變化快的場景（如醫(yī)療數(shù)據(jù)合并、供應(yīng)鏈追蹤）。
3.3.1. 關(guān)鍵組件：
- Hub：業(yè)務(wù)實(shí)體核心標(biāo)識（如客戶ID、訂單ID）。
- Link：實(shí)體間關(guān)系（如客戶-訂單關(guān)聯(lián)）。
- Satellite：實(shí)體的詳細(xì)屬性（如客戶姓名、訂單金額），支持歷史跟蹤。
優(yōu)勢：
- 易于擴(kuò)展，新增數(shù)據(jù)源時(shí)只需添加Hub/Link/Satellite，不影響現(xiàn)有結(jié)構(gòu)。
- 天然支持?jǐn)?shù)據(jù)血緣和審計(jì)。
3.4. 寬表模型（寬列模型）
核心理念：將常用維度屬性冗余存儲到事實(shí)表中，形成“一行包含所有分析字段”的寬表。
適用場景：實(shí)時(shí)分析、高并發(fā)查詢（如廣告點(diǎn)擊日志分析）。
3.4.1. 特點(diǎn)：
- 反范式化極致：減少JOIN操作，適合列式存儲（如Parquet、ClickHouse）。
- 預(yù)計(jì)算友好：可直接嵌入衍生指標(biāo)（如UV、轉(zhuǎn)化率）。
3.5. 分層建模（數(shù)據(jù)倉庫分層）
通用實(shí)踐：將數(shù)據(jù)加工流程分為多層，每層有明確職責(zé)。常見分層：
- ODS（Operational Data Store）：原始數(shù)據(jù)鏡像，保留細(xì)節(jié)，不做清洗。
- DWD（Data Warehouse Detail）：清洗后的明細(xì)數(shù)據(jù)，保持業(yè)務(wù)過程粒度。
- DWS（Data Warehouse Summary）：輕度匯總的主題寬表（如用戶行為寬表）。
- ADS（Application Data Store）：高度聚合的應(yīng)用層結(jié)果（如日報(bào)、風(fēng)控指標(biāo)）。
優(yōu)勢：平衡處理效率與數(shù)據(jù)復(fù)用，便于問題回溯。
3.6. 數(shù)倉建模方法論對比
| 方法 | 設(shè)計(jì)重點(diǎn) | 靈活性 | 查詢性能 | 適用階段 |
| 維度建模 | 業(yè)務(wù)過程直觀性 | 中 | 高 | 敏捷分析、部門級應(yīng)用 |
| Inmon范式化 | 企業(yè)數(shù)據(jù)一致性 | 低 | 中 | 企業(yè)級EDW建設(shè) |
| Data Vault | 變化適應(yīng)性和追溯性 | 高 | 中低 | 數(shù)據(jù)集成、長期演進(jìn) |
| 寬表模型 | 極致查詢速度 | 低 | 極高 | 實(shí)時(shí)分析、日志場景 |
3.7. 數(shù)倉建模選擇
| 場景 | 推薦建模方法 | 理由 |
| BI 報(bào)表分析 （銷售、用戶行為） | 維度建模（星型） | 面向分析，支持多維度、聚合查詢 |
| 高并發(fā)寫入、事務(wù)性操作 | 范式建模（3NF） | 數(shù)據(jù)一致性高，減少冗余 |
| 企業(yè)級整合數(shù)據(jù)倉庫 | Data Vault | 支持異構(gòu)源整合、變化追蹤、數(shù)據(jù)血緣 |
| 實(shí)時(shí)接口或大屏展示 | 寬表建模 | 查詢快、結(jié)構(gòu)簡單，減少延遲 |
| 通用大數(shù)據(jù)數(shù)倉 | 分層建模（ODS-DWD-DWS-ADS） | 結(jié)構(gòu)清晰、支撐全鏈路數(shù)據(jù)處理與管控 |
4. 阿里數(shù)據(jù)建模設(shè)計(jì)
阿里巴巴集團(tuán)在大數(shù)據(jù)建設(shè)方面積累了豐富實(shí)踐經(jīng)驗(yàn)，其大數(shù)據(jù)方法論具有高度系統(tǒng)性和工程化能力，常被業(yè)內(nèi)稱為“大數(shù)據(jù)中臺”或“數(shù)據(jù)中臺”架構(gòu)。阿里巴巴的大數(shù)據(jù)方法論核心：以分層建模為基礎(chǔ)、以原子指標(biāo)為核心、以 OneModel 為抽象、以工程化平臺為保障、以數(shù)據(jù)服務(wù)化為目標(biāo)。這種方法論既能支撐復(fù)雜的業(yè)務(wù)場景，又能保障數(shù)據(jù)資產(chǎn)的質(zhì)量、復(fù)用和可控性，是目前許多大型企業(yè)模仿與借鑒的標(biāo)桿。
| 核心要素 | 內(nèi)容說明 |
| 1. 分層建模（分層設(shè)計(jì)） | 基于“數(shù)倉分層思想”，將數(shù)據(jù)建模分為多個(gè)層級： |
| 2. 原子指標(biāo) & 輕聚合 | 所有指標(biāo)先分解為最小粒度原子指標(biāo)（如交易金額、訂單數(shù)），聚合邏輯分離，避免“報(bào)表越做越亂”的問題，支持靈活復(fù)用。 |
| 3. 數(shù)據(jù)中臺思維 | 抽象業(yè)務(wù)邏輯，沉淀為“公共、復(fù)用、標(biāo)準(zhǔn)”的數(shù)據(jù)資產(chǎn)，提供統(tǒng)一的接口服務(wù)化輸出能力，服務(wù)于多個(gè)業(yè)務(wù)前臺（如天貓、淘寶、餓了么等）。 |
| 4. 血緣分析 & 數(shù)據(jù)質(zhì)量治理 | 全鏈路數(shù)據(jù)血緣管理：字段級追蹤、任務(wù)依賴關(guān)系；建立數(shù)據(jù)質(zhì)量體系（如數(shù)據(jù)稽核、校驗(yàn)、告警）確?？捎眯耘c可靠性。 |
| 5. OneModel 模型體系 | 建立標(biāo)準(zhǔn)的數(shù)據(jù)模型（如交易模型、會員模型、商品模型），實(shí)現(xiàn)模型復(fù)用、語義統(tǒng)一，支撐各種報(bào)表、分析、機(jī)器學(xué)習(xí)任務(wù)。 |
| 6. 指標(biāo)中心 + 數(shù)據(jù)服務(wù)化 | 所有業(yè)務(wù)指標(biāo)統(tǒng)一進(jìn)入“指標(biāo)平臺”管理，實(shí)現(xiàn)指標(biāo)的定義、計(jì)算、口徑說明、版本控制、權(quán)限管理，并以 API / SQL / 可視化方式統(tǒng)一服務(wù)輸出。 |
| 7. 工程化開發(fā)流程（OneData） | 阿里內(nèi)部打造了一整套標(biāo)準(zhǔn)化數(shù)據(jù)開發(fā)平臺與流程（如 MaxCompute + DataWorks），支持自動生成 SQL、自動運(yùn)維、調(diào)度、測試、發(fā)布全流程。 |
| 8. 全域數(shù)據(jù)統(tǒng)一編碼體系（OneID） | 將不同系統(tǒng)中的用戶、商品、店鋪、設(shè)備、交易等標(biāo)識統(tǒng)一映射到 OneID，打通數(shù)據(jù)孤島，支撐用戶畫像、精準(zhǔn)推薦等算法模型。 |
4.1. 系統(tǒng)架構(gòu)
- 業(yè)務(wù)板塊：由于阿里巴巴集團(tuán)業(yè)務(wù)生態(tài)龐大，所以根據(jù)業(yè)務(wù)的屬性劃分出幾個(gè)相對獨(dú)立的業(yè)務(wù)板塊，業(yè)務(wù)板塊之間的指標(biāo)或業(yè)務(wù)重疊性較小。如電商業(yè)務(wù)板塊涵蓋淘系、B2B系和AliExpress系等。
- 規(guī)范定義：阿里數(shù)據(jù)業(yè)務(wù)龐大，結(jié)合行業(yè)的數(shù)據(jù)倉庫建設(shè)經(jīng)驗(yàn)和阿里數(shù)據(jù)自身特點(diǎn)，設(shè)計(jì)出的一套數(shù)據(jù)規(guī)范命名體系，規(guī)范定義將會被用在模型設(shè)計(jì)中。后面章節(jié)將會詳細(xì)說明。
- 模型設(shè)計(jì)：以維度建模理論為基礎(chǔ)，基于維度建?？偩€架構(gòu)，構(gòu)建一致性的維度和事實(shí)（進(jìn)行規(guī)范定義)。同時(shí)，在落地表模型時(shí)，基于阿里自身業(yè)務(wù)特點(diǎn)，設(shè)計(jì)出一套表規(guī)范命名體系。
4.2. 規(guī)范定義
規(guī)范定義指以維度建模作為理論基礎(chǔ)，構(gòu)建總線矩陣，劃分和定義數(shù)據(jù)域、業(yè)務(wù)過程、維度、度量/原子指標(biāo)、修飾類型、修飾詞、時(shí)間周期、派生指標(biāo)。
- 數(shù)據(jù)域：指面向業(yè)務(wù)分析，將業(yè)務(wù)過程或者維度進(jìn)行抽象的集合。其中，業(yè)務(wù)過程可以概括為一個(gè)個(gè)不可拆分的行為事件，在業(yè)務(wù)過程之下，可以定義指標(biāo)；維度是指度量的環(huán)境，如買家下單事件，買家是維度。為保障整個(gè)體系的生命力，數(shù)據(jù)域是需要抽象提煉，并且長期維護(hù)和更新的，但不輕易變動。在劃分?jǐn)?shù)據(jù)域時(shí)，既能涵蓋當(dāng)前所有的業(yè)務(wù)需求，又能在新業(yè)務(wù)進(jìn)入時(shí)無影響地被包含進(jìn)已有的數(shù)據(jù)域中和擴(kuò)展新的數(shù)據(jù)域指企業(yè)的業(yè)務(wù)活動事件，如下單、支付、退款都是業(yè)務(wù)過程。請注意，業(yè)務(wù)過程。
- 業(yè)務(wù)過程：是一個(gè)不可拆分的行為事件，通俗地講，業(yè)務(wù)過程就是企業(yè)活動中的事件。
- 時(shí)間周期：用來明確數(shù)據(jù)統(tǒng)計(jì)的時(shí)間范圍或者時(shí)間點(diǎn)，如最近30天、自然周、截至當(dāng)日等是對修飾詞的一種抽象劃分。修飾類型從屬于某個(gè)業(yè)務(wù)域，如日志域的訪問終端。
- 修飾類型：類型涵蓋無線端、PC端等修飾詞指除了統(tǒng)計(jì)維度以外指標(biāo)的業(yè)務(wù)場景限定抽象。修飾詞隸屬于一種修飾類型，如修飾詞在日志域的訪問終端類型下，有修飾詞PC端、無線端等。
- 度量/原原子指標(biāo)：度量/原原子指標(biāo)和度量含義相同，基于某一業(yè)務(wù)事件行為下的度量，是業(yè)務(wù)定義中不可子指標(biāo)再拆分的指標(biāo)，具有明確業(yè)務(wù)含義的名詞，如支付金額。
- 維度：維度是度量的環(huán)境，用來反映業(yè)務(wù)的一類屬性，這類屬性的集合構(gòu)成一個(gè)維度，也可以稱為實(shí)體對象。維度屬于一個(gè)數(shù)據(jù)域，如地理維度（其中包括國家、地區(qū)、省以及城市等級別的內(nèi)容)入、時(shí)間維度（其中包括年、季、月、周、日等級別的內(nèi)容）。
- 維度屬性：維度屬性隸屬于一個(gè)維度，如地理維度里面的國家名稱、國家D、省份名稱等都屬于維度屬性。
- 派生指標(biāo)：派生指標(biāo)=一個(gè)原子指標(biāo)+多個(gè)修飾詞（可選）+時(shí)間周期?？梢岳斫鉃閷υ又概缮笜?biāo)標(biāo)業(yè)務(wù)統(tǒng)計(jì)范圍的圈定。如原子指標(biāo)：支付金額，最近1天海外買家支付金額則為（最近1天為時(shí)間周期，海外為修飾詞，買家作為維度，而不作為修飾詞）。
4.3. 指標(biāo)體系
4.3.1. 組成體系之間關(guān)系
派生指標(biāo)由原子指標(biāo)、時(shí)間周期修飾詞、若干其他修飾詞組合得到。
- 原子指標(biāo)、修飾類型及修飾詞，直接歸屬在業(yè)務(wù)過程下，其中修飾詞繼承修飾類型的數(shù)據(jù)域。
- 派生指標(biāo)可以選擇多個(gè)修飾詞，修飾詞之間的關(guān)系為“或”或者“且”，由具體的派生指標(biāo)語義決定。
- 派生指標(biāo)唯一歸屬一個(gè)原子指標(biāo)，繼承原子指標(biāo)的數(shù)據(jù)域，與修飾詞的數(shù)據(jù)域無關(guān)。
一般而言，事務(wù)型指標(biāo)和存量型指標(biāo)（見下文定義)只會唯一定位到一個(gè)業(yè)務(wù)過程，如果遇到同時(shí)有兩個(gè)行為發(fā)生、需要多個(gè)修飾詞、生成一個(gè)派生指標(biāo)的情況，則選擇時(shí)間靠后的行為創(chuàng)建原子指標(biāo)，選擇時(shí)間靠前的行為創(chuàng)建修飾詞。原子指標(biāo)有確定的英文字段名、數(shù)據(jù)類型和算法說明；派生指標(biāo)要繼承原子指標(biāo)的英文名、數(shù)據(jù)類型和算法要求。
4.3.2. 命名約定
命名所用術(shù)語。指標(biāo)命名，盡量使用英文簡寫，其次是英文，當(dāng)指標(biāo)英文名太長時(shí)，可考慮用漢語拼音首字母命名。如中國質(zhì)造，用zgzc。在OneData工具中維護(hù)著常用的名詞術(shù)語，以用來進(jìn)行命名。
- 業(yè)務(wù)過程。英文名：用英文或英文的縮寫或者中文拼音簡寫；中文名：具體的業(yè)務(wù)過程中文即可。
- 關(guān)于存量型指標(biāo)（見下文定義)對應(yīng)的業(yè)務(wù)過程的約定：實(shí)體對象英文名+stock。如在線會員數(shù)、一星會員數(shù)等，其對應(yīng)的業(yè)務(wù)過程為mbr_stock；在線商品數(shù)、商品SKU種類小于5的商品數(shù)，其對應(yīng)的業(yè)務(wù)過程為itm_stock。
- 原子指標(biāo)。英文名：動作+度量；中文名：動作+度量。
- 原子指標(biāo)必須掛靠在某個(gè)業(yè)務(wù)過程下。
- 修飾詞。只有時(shí)間周期才會有英文名，且長度為2位，加上“_”為3位，例如_1d。其他修飾詞無英文名。
- 派生指標(biāo)。英文名：原子指標(biāo)英文名+時(shí)間周期修飾詞（3位，例如1d)+序號（4位，例如001)；中文名：時(shí)間周期修飾詞+[其他修飾詞]+原子指標(biāo)。
4.3.3. 操作細(xì)則
派生指標(biāo)的種類
- 派生指標(biāo)可以分為三類：事務(wù)型指標(biāo)、存量型指標(biāo)和復(fù)合型指標(biāo)。按照其特性不同，有些必須新建原子指標(biāo)，有些可以在其他類型原子指標(biāo)的基礎(chǔ)上增加修飾詞形成派生指標(biāo)。
- 事務(wù)型指標(biāo)：是指對業(yè)務(wù)活動進(jìn)行衡量的指標(biāo)。例如新發(fā)商品數(shù)、重發(fā)商品數(shù)、新增注冊會員數(shù)、訂單支付金額，這類指標(biāo)需維護(hù)原子指標(biāo)及修飾詞，在此基礎(chǔ)上創(chuàng)建派生指標(biāo)。
- 存量型指標(biāo)：是指對實(shí)體對象（如商品、會員)某些狀態(tài)的統(tǒng)計(jì)。例如商品總數(shù)、注冊會員總數(shù)，這類指標(biāo)需維護(hù)原子指標(biāo)及修飾詞，在此基礎(chǔ)上創(chuàng)建派生指標(biāo)，對應(yīng)的時(shí)間周期一般為“歷史截至當(dāng)前某個(gè)時(shí)間”。
- 復(fù)合型指標(biāo)：是在事務(wù)型指標(biāo)和存量型指標(biāo)的基礎(chǔ)上復(fù)合而成的。例如瀏覽UV下單買家數(shù)轉(zhuǎn)化率，有些需要?jiǎng)?chuàng)建新原子指標(biāo)，有些則可以在事務(wù)型或存量型原子指標(biāo)的基礎(chǔ)上增加修飾詞得到派生指標(biāo)。
復(fù)合型指標(biāo)的規(guī)則
- 比率型：創(chuàng)建原子指標(biāo)，如CTR、瀏覽UV下單買家數(shù)轉(zhuǎn)化率、滿意率等。例如，“最近1天店鋪首頁CTR”,原子指標(biāo)為“CTR”,時(shí)間周期為“最近1天”，修飾類型為“頁面類型”，修飾詞為“店鋪首頁”。
- 比例型：創(chuàng)建原子指標(biāo)，如百分比、占比。例如“最近1天無線支付金額占比”，原子指標(biāo)為“支付金額占比”，修飾類型為“終端類型”，修飾詞為“無線”。
- 變化量型：不創(chuàng)建原子指標(biāo)，增加修飾詞，在此基礎(chǔ)上創(chuàng)建派生指標(biāo)。例如，“最近1天訂單支付金額上1天變化量”，原子指標(biāo)為“訂單支付金額”，時(shí)間周期為“最近1天”，修飾類型為“統(tǒng)計(jì)方法”，修飾詞為“上1天變化量”。
- 變化率型：創(chuàng)建原子指標(biāo)。例如，“最近7天海外買家支付金額上7天變化率”，原子指標(biāo)為“支付金額變化率”，修飾類型為“買家地域”，修飾詞為“海外買家”。
- 統(tǒng)計(jì)型（均值、分位數(shù)等)：不創(chuàng)建原子指標(biāo)，增加修飾詞，在此基礎(chǔ)上創(chuàng)建派生指標(biāo)；在修飾類型“統(tǒng)計(jì)方法”下增加修飾詞，如人均、日均、行業(yè)平均、商品平均、90分位數(shù)、70分位數(shù)等。例如，“自然月日均UV”,原子指標(biāo)為“UV”,修飾類型為“統(tǒng)計(jì)方法”，修飾詞為“日均”。
- 排名型：創(chuàng)建原子指標(biāo)，一般為top xxx xxx,有時(shí)會同時(shí)選擇rank和top_XXXXXX組合使用。創(chuàng)建派生指標(biāo)時(shí)選擇對應(yīng)的修飾詞如下：
-
- 統(tǒng)計(jì)方法（如降序、升序）。
- 排名名次（如TOP10)。
- 排名范圍（如行業(yè)、省份、一級來源等)。
- 根據(jù)什么排序（如搜索次數(shù)、PV)。
4.4. 模型設(shè)計(jì)
阿里巴巴集團(tuán)數(shù)據(jù)公共層設(shè)計(jì)理念遵循維度建模思想，據(jù)模型的維度設(shè)計(jì)主要以維度建模理論為基礎(chǔ)，基于維度數(shù)據(jù)模型總線架構(gòu)，構(gòu)建一致性的維度和事實(shí)。阿里巴巴的數(shù)據(jù)團(tuán)隊(duì)把表數(shù)據(jù)模型分為三層：操作數(shù)據(jù)層(ODS)、公共維度模型層(CDM)和應(yīng)用數(shù)據(jù)層(ADS),其中公共維度模型層包括明細(xì)數(shù)據(jù)層(DWD)和匯總數(shù)據(jù)層(DWS)。
操作數(shù)據(jù)層(ODS)：把操作系統(tǒng)數(shù)據(jù)幾乎無處理地存放在數(shù)據(jù)倉庫系統(tǒng)中。
- 同步：結(jié)構(gòu)化數(shù)據(jù)增量或全量同步到MaxCompute。
- 結(jié)構(gòu)化：非結(jié)構(gòu)化（日志)結(jié)構(gòu)化處理并存儲到MaxCompute。
- 累積歷史、清洗：根據(jù)數(shù)據(jù)業(yè)務(wù)需求及稽核和審計(jì)要求保存歷史數(shù)據(jù)、清洗數(shù)據(jù)。
公共維度模型層(CDM): 存放明細(xì)事實(shí)數(shù)據(jù)、維表數(shù)據(jù)及公共指標(biāo)匯總數(shù)據(jù)，其中明細(xì)事實(shí)數(shù)據(jù)、維表數(shù)據(jù)一般根據(jù)ODS層數(shù)據(jù)加工生成；公共指標(biāo)匯總數(shù)據(jù)一般根據(jù)維表數(shù)據(jù)和明細(xì)事實(shí)數(shù)據(jù)加工生成。CDM層又細(xì)分為DWD層和DWS層，分別是明細(xì)數(shù)據(jù)層和匯總數(shù)據(jù)層，采用維度模型方法作為理論基礎(chǔ)，更多地采用一些維度退化手法，將維度退化至事實(shí)表中，減少事實(shí)表和維表的關(guān)聯(lián)，提高明細(xì)數(shù)據(jù)表的易用性；同時(shí)在匯總數(shù)據(jù)層，加強(qiáng)指標(biāo)的維度退化，采取更多的寬表化手段構(gòu)建公共指標(biāo)數(shù)據(jù)層，提升公共指標(biāo)的復(fù)用性，減少重復(fù)加工。其主要功能如下：
- 組合相關(guān)和相似數(shù)據(jù)：采用明細(xì)寬表，復(fù)用關(guān)聯(lián)計(jì)算，減少數(shù)據(jù)掃描。
- 公共指標(biāo)統(tǒng)一加工：基于OneData體系構(gòu)建命名規(guī)范、口徑一致和算法統(tǒng)一的統(tǒng)計(jì)指標(biāo)，為上層數(shù)據(jù)產(chǎn)品、應(yīng)用和服務(wù)提供公共指標(biāo)；建立邏輯匯總寬表。
- 建立一致性維度：建立一致的數(shù)據(jù)分析維表，降低數(shù)據(jù)計(jì)算口徑、算法不統(tǒng)一的風(fēng)險(xiǎn)。
應(yīng)用數(shù)據(jù)層（ADS): 存放數(shù)據(jù)產(chǎn)品個(gè)性化的統(tǒng)計(jì)指標(biāo)數(shù)據(jù)，根據(jù)CDM層與ODS層加工生成。
- 個(gè)性化指標(biāo)加工：不公用性、復(fù)雜性（指數(shù)型、比值型、排名型指標(biāo))。
- 基于應(yīng)用的數(shù)據(jù)組裝：大寬表集市、橫表轉(zhuǎn)縱表、趨勢指標(biāo)串。
4.5. 基本原則
4.5.1. 高內(nèi)聚和低耦合
一個(gè)邏輯或者物理模型由哪些記錄和字段組成，應(yīng)該遵循最基本的軟件設(shè)計(jì)方法論的高內(nèi)聚和低耦合原則。主要從數(shù)據(jù)業(yè)務(wù)特性和訪問特性兩個(gè)角度來考慮：將業(yè)務(wù)相近或者相關(guān)、粒度相同的數(shù)據(jù)設(shè)計(jì)為一個(gè)邏輯或者物理模型；將高概率同時(shí)訪問的數(shù)據(jù)放一起，將低概率同時(shí)訪問的數(shù)據(jù)分開存儲。
4.5.2. 核心模型與擴(kuò)展模型分離
建立核心模型與擴(kuò)展模型體系，核心模型包括的字段支持常用的核心業(yè)務(wù)，擴(kuò)展模型包括的字段支持個(gè)性化或少量應(yīng)用的需要，不能讓擴(kuò)展模型的字段過度侵入核心模型，以免破壞核心模型的架構(gòu)簡潔性與可維護(hù)性。
4.5.3. 公共處理邏輯下沉及單一
越是底層公用的處理邏輯越應(yīng)該在數(shù)據(jù)調(diào)度依賴的底層進(jìn)行封裝與實(shí)現(xiàn)，不要讓公用的處理邏輯暴露給應(yīng)用層實(shí)現(xiàn)，不要讓公共邏輯多處同時(shí)存在。
4.5.4. 成本與性能平衡
適當(dāng)?shù)臄?shù)據(jù)冗余可換取查詢和刷新性能，不宜過度冗余與數(shù)據(jù)復(fù)制。
4.5.5. 數(shù)據(jù)可回滾
處理邏輯不變，在不同時(shí)間多次運(yùn)行數(shù)據(jù)結(jié)果確定不變。
4.5.6. 一致性
具有相同含義的字段在不同表中的命名必須相同，必須使用規(guī)范定義中的名稱。
4.5.7. 命名清晰、可理解
表命名需清晰、一致，表名需易于消費(fèi)者理解和使用。
4.6. 模型實(shí)施過程
4.6.1. Kimball維度建模
Kimball維度建模主要探討需求分析、高層模型、詳細(xì)模型和模型審查整個(gè)過程。構(gòu)建維度模型一般要經(jīng)歷三個(gè)階段：第一個(gè)階段是高層設(shè)計(jì)時(shí)期，定義業(yè)務(wù)過程維度模型的范圍，提供每種星形模式的技術(shù)和功能描述；第二個(gè)階段是詳細(xì)模型設(shè)計(jì)時(shí)期，對每個(gè)星形模型添加屬性和度量信息；第三個(gè)階段是進(jìn)行模型的審查、再設(shè)計(jì)和驗(yàn)證等工作，第四個(gè)階段是產(chǎn)生詳細(xì)設(shè)計(jì)文檔，提交ETL設(shè)計(jì)和開發(fā)。
高層模型
高層模型設(shè)計(jì)階段的直接產(chǎn)出目標(biāo)是創(chuàng)建高層維度模型圖，它是對業(yè)務(wù)過程中的維表和事實(shí)表的圖形描述。確定維表創(chuàng)建初始屬性列表，為每個(gè)事實(shí)表創(chuàng)建提議度量。
詳細(xì)模型
詳細(xì)的維度建模過程是為高層模型填補(bǔ)缺失的信息，解決設(shè)計(jì)問題，并不斷測試模型能否滿足業(yè)務(wù)需求，確保模型的完備性。確定每個(gè)維表的屬性和每個(gè)事實(shí)表的度量，并確定信息來源的位置、定義，確定屬性和度量如何填入模型的初步業(yè)務(wù)規(guī)則。
模型審查、再設(shè)計(jì)和驗(yàn)證
本階段主要召集相關(guān)人員進(jìn)行模型的審查和驗(yàn)證，根據(jù)審查結(jié)果對詳細(xì)維度進(jìn)行再設(shè)計(jì)。
提交ETL設(shè)計(jì)和開發(fā)
最后，完成模型詳細(xì)設(shè)計(jì)文檔，提交ETL開發(fā)人員，進(jìn)入ETL設(shè)計(jì)和開發(fā)階段，由ETL人員完成物理模型的設(shè)計(jì)和開發(fā)。
4.6.2. Inmon模型實(shí)施過程
Inmon對數(shù)據(jù)模型的定位是：扮演著通往數(shù)據(jù)倉庫其他部分的智能路線圖的角色。由于數(shù)據(jù)倉庫的建設(shè)不是一蹴而就的，為了協(xié)調(diào)不同人員的工作以及適應(yīng)不同類型的用戶，非常有必要建立一個(gè)路線圖一數(shù)據(jù)模型，描述數(shù)據(jù)倉庫各部分是如何結(jié)合在一起的。
Inmon將模型劃分為三個(gè)層次，分別是ERD (Entity IRelationshipDiagram,實(shí)體關(guān)系圖)層、DIS(Data Item Set,數(shù)據(jù)項(xiàng)集)層和物理層(Physical Model,物理模型)。
ERD層是數(shù)據(jù)模型的最高層，該層描述了公司業(yè)務(wù)中的實(shí)體或主題域以及它們之間的關(guān)系；ERD層是中間層，該層描述了數(shù)據(jù)模型中的關(guān)鍵字、屬性以及細(xì)節(jié)數(shù)據(jù)之間的關(guān)系；物理層是數(shù)據(jù)建模的最底層，該層描述了數(shù)據(jù)模型的物理特性。
Inmon對于構(gòu)建數(shù)據(jù)倉庫模型建議采用螺旋式開發(fā)方法，采用迭代方式完成多次需求。但需要采用統(tǒng)一的ERD模型，才能夠?qū)⒚看蔚慕Y(jié)果整合在一起。ERD模型是高度抽象的數(shù)據(jù)模型，描述了企業(yè)完整的數(shù)據(jù)。而每次迭代則是完成ERD模型的子集，通過DIS和物理數(shù)據(jù)模型實(shí)現(xiàn)。
4.6.3. 其他模型實(shí)施過程
在實(shí)踐中經(jīng)常會用到如下數(shù)據(jù)倉庫模型層次的劃分，和KimballInmon的模型實(shí)施理論有一定的相通性，但不涉及具體的模型表達(dá)。
- 業(yè)務(wù)建模，生成業(yè)務(wù)模型，主要解決業(yè)務(wù)層面的分解和程序化。
- 領(lǐng)域建模，生成領(lǐng)域模型，主要是對業(yè)務(wù)模型進(jìn)行抽象處理，生成領(lǐng)域概念模型。
- 邏輯建模，生成邏輯模型，主要是將領(lǐng)域模型的概念實(shí)體以及實(shí)體之間的關(guān)系進(jìn)行數(shù)據(jù)庫層次的邏輯化。
- 物理建模，生成物理模型，主要解決邏輯模型針對不同關(guān)系數(shù)據(jù)庫的物理化以及性能等一些具體的技術(shù)問題。
4.7. OneData實(shí)施過程
首先，在建設(shè)大數(shù)據(jù)數(shù)據(jù)倉庫時(shí)，要進(jìn)行充分的業(yè)務(wù)調(diào)研和需求分析。這是數(shù)據(jù)倉庫建設(shè)的基石，業(yè)務(wù)調(diào)研和需求分析做得是否充分直接決定了數(shù)據(jù)倉庫建設(shè)是否成功。其次，進(jìn)行數(shù)據(jù)總體架構(gòu)設(shè)計(jì)，主要是根據(jù)數(shù)據(jù)域?qū)?shù)據(jù)進(jìn)行劃分；按照維度建模理論，構(gòu)建總線矩陣、抽象出業(yè)務(wù)過程和維度。再次，對報(bào)表需求進(jìn)行抽象整理出相關(guān)指標(biāo)體系，使用OneData工具完成指標(biāo)規(guī)范定義和模型設(shè)計(jì)。最后，就是代碼研發(fā)和運(yùn)維。本文將會重點(diǎn)講解物理模型設(shè)計(jì)之前（含）步驟的內(nèi)容。
4.7.1. 數(shù)據(jù)調(diào)研
業(yè)務(wù)調(diào)研：整個(gè)阿里集團(tuán)涉及的業(yè)務(wù)涵蓋電商、數(shù)字娛樂、導(dǎo)航（高德）、移動互聯(lián)網(wǎng)服務(wù)等領(lǐng)域。各個(gè)領(lǐng)域又涵蓋多個(gè)業(yè)務(wù)線，如電商領(lǐng)域就涵蓋了C類（淘寶、天貓、天貓國際）與B類（阿里巴巴中文站、國際站、速賣通)業(yè)務(wù)。數(shù)據(jù)倉庫是要涵蓋所有業(yè)務(wù)領(lǐng)域，還是各個(gè)業(yè)務(wù)領(lǐng)域獨(dú)自建設(shè)，業(yè)務(wù)領(lǐng)域內(nèi)的業(yè)務(wù)線也同樣面臨著這個(gè)問題。所以要構(gòu)建大數(shù)據(jù)數(shù)據(jù)倉庫，就需要了解各個(gè)業(yè)務(wù)領(lǐng)域、業(yè)務(wù)線的業(yè)務(wù)有什么共同點(diǎn)和不同點(diǎn)，以及各個(gè)業(yè)務(wù)線可以細(xì)分為哪幾個(gè)業(yè)務(wù)模塊，每個(gè)業(yè)務(wù)模塊具體的業(yè)務(wù)流程又是怎樣的。業(yè)務(wù)調(diào)研是否充分，將會直接決定數(shù)據(jù)倉庫建設(shè)是否成功。
在阿里巴巴，一般各個(gè)業(yè)務(wù)領(lǐng)域獨(dú)自建設(shè)數(shù)據(jù)倉庫，業(yè)務(wù)領(lǐng)域內(nèi)的業(yè)務(wù)線由于業(yè)務(wù)相似、業(yè)務(wù)相關(guān)性較大，進(jìn)行統(tǒng)一集中建設(shè)。如圖所示是粗粒度的C類電商業(yè)務(wù)調(diào)研，不難發(fā)現(xiàn)幾個(gè)功能模塊業(yè)務(wù)線除了淘寶無供應(yīng)鏈管理外，其他幾乎一樣。
4.7.2. 需求調(diào)研
可以想象一下，在沒有考慮分析師、業(yè)務(wù)運(yùn)營人員的數(shù)據(jù)需求的情況下，根據(jù)業(yè)務(wù)調(diào)研建設(shè)的數(shù)據(jù)倉庫無疑等于閉門造車。了解了業(yè)務(wù)系統(tǒng)的業(yè)務(wù)后并不代表就可以進(jìn)行實(shí)施了，此刻要做的就是收集數(shù)據(jù)使用者的需求，可以去找分析師、業(yè)務(wù)運(yùn)營人員了解他們有什么數(shù)據(jù)訴求，此時(shí)更多的就是報(bào)表需求。
需求調(diào)研的途徑有兩種：一是根據(jù)與分析師、業(yè)務(wù)運(yùn)營人員的溝通(郵件、M)獲知需求；二是對報(bào)表系統(tǒng)中現(xiàn)有的報(bào)表進(jìn)行研究分析。通過需求調(diào)研分析后，就清楚數(shù)據(jù)要做成什么樣的。很多時(shí)候，都是由具體的數(shù)據(jù)需求驅(qū)動數(shù)據(jù)倉庫團(tuán)隊(duì)去了解業(yè)務(wù)系統(tǒng)的業(yè)務(wù)數(shù)據(jù)，這兩者并沒有嚴(yán)格的先后順序。
舉例：分析師需要了解大淘寶（淘寶、天貓、天貓國際）一級類目的成交金額。當(dāng)獲知這個(gè)需求后，我們要分析根據(jù)什么（維度)匯總，以及匯總什么（度量），這里類目是維度，金額是度量；明細(xì)數(shù)據(jù)和匯總數(shù)據(jù)應(yīng)該怎樣設(shè)計(jì)？這是一個(gè)公用的報(bào)表嗎？是需要沉淀到匯總表里面，還是在報(bào)表工具中進(jìn)行匯總？
4.7.3. 數(shù)據(jù)域
數(shù)據(jù)域劃分：數(shù)據(jù)域是指面向業(yè)務(wù)分析，將業(yè)務(wù)過程或者維度進(jìn)行抽象的集合。業(yè)務(wù)過程可以概括為一個(gè)個(gè)不可拆分的行為事件，如下單、支付、退款。為保障整個(gè)體系的生命力，數(shù)據(jù)域需要抽象提煉，并且長期維護(hù)和更新，但不輕易變動。在劃分?jǐn)?shù)據(jù)域時(shí)，既能涵蓋當(dāng)前所有的業(yè)務(wù)需求，又能在新業(yè)務(wù)進(jìn)入時(shí)無影響地被包含進(jìn)已有的數(shù)據(jù)域中或者擴(kuò)展新的數(shù)據(jù)域。如表9.4所示是功能模塊/業(yè)務(wù)線的業(yè)務(wù)動作（部分示例)。
構(gòu)建總線矩陣：在進(jìn)行充分的業(yè)務(wù)調(diào)研和需求調(diào)研后，就要構(gòu)建總線矩陣了。需要做兩件事情：明確每個(gè)數(shù)據(jù)域下有哪些業(yè)務(wù)過程；業(yè)務(wù)過程與哪些維度相關(guān)，并定義每個(gè)數(shù)據(jù)域下的業(yè)務(wù)過程和維度。
4.7.4. 規(guī)范定義
規(guī)范定義主要定義指標(biāo)體系，包括原子指標(biāo)、修飾詞、時(shí)間周期和派生指標(biāo)。
4.7.5. 模型設(shè)計(jì)
模型設(shè)計(jì)主要包括維度及屬性的規(guī)范定義，維表、明細(xì)事實(shí)表和匯總事實(shí)表的模型設(shè)計(jì)。
博文參考
- 《阿里巴巴大數(shù)據(jù)實(shí)踐》