​

一什麼是資料倉庫

1.1資料倉庫概念

資料倉庫，英文名稱為Data Warehouse，可簡寫為DW或DWH。資料倉庫，是為企業所有級別的決策制定過程，提供所有型別資料支援的戰略集合。它出於分析性報告和決策支援目的而建立。

1.2資料倉庫特點

1.2.1面向主題

普通的操作型資料庫主要面向事務性處理，而資料倉庫中的所有資料一般按照主題進行劃分。主題是對業務資料的一種抽象，是從較高層次上對資訊系統中的資料進行歸納和整理。

面向主題的資料可以劃分成兩部分----根據原系統業務資料的特點進行主題的抽取和確定每個主題所包含的資料內容。例如客戶主題、產品主題、財務主題等；而客戶主題包括客戶基本資訊、客戶信用資訊、客戶資源資訊等內容。分析資料倉庫主題的時候，一般方法是先確定幾個基本的主題，然後再將範圍擴大，最後再逐步求精

1.2.2整合性

面向操作型的資料庫通常是異構的、並且相互獨立，所以無法對資訊進行概括和反映信

息的本質。而資料倉庫中的資料是經過資料的抽取、清洗、切換、載入得到的，所以為了保證資料不存在二義性，必須對資料進行編碼統一和必要的彙總，以保證資料倉庫內資料的一致性。資料倉庫在經歷資料整合階段後，使資料倉庫中的資料都遵守統一的編碼規則，並且消除許多冗餘資料。

·

1.2.3穩定性

資料倉庫中的資料反映的都是一段歷史時期的資料內容，它的主要操作是查詢、分析而

不進行一般意義上的更新（資料整合前的操作型資料庫主要完成資料的增加、修改、刪除、查詢），一旦某個資料進入到資料倉庫後，一般情況下資料會被長期保留，當超過規定的期限才會被刪除。通常資料倉庫需要做的工作就是載入、查詢和分析，一般不進行任何修改操作，是為了企業高層人員決策分析之用。

·

1.2.4反映歷史變化

資料倉庫不斷從操作型資料庫或其他資料來源獲取變化的資料，從而分析和預測需

要的歷史資料，所以一般資料倉庫中資料表的鍵碼（維度）都含有時間鍵，以表明資料的歷史時期資訊，然後不斷增加新的資料內容。通過這些歷史資訊可以對企業的發展歷程和趨勢做出分析和預測。資料倉庫的建設需要大量的業務資料作為積累，並將這些寶貴的歷史資訊經過加工、整理，最後提供給決策分析人員，這是資料倉庫建設的根本目的。

1.3資料倉庫發展歷程

資料倉庫的發展大致經歷了這樣的三個過程：

1. 簡單報表階段：這個階段，系統的主要目標是解決一些日常的工作中業務人員需要的報表，以及生成一些簡單的能夠幫助領導進行決策所需要的彙總資料。這個階段的大部分表現形式為資料庫和前端報表工具。

2. 資料集市階段：這個階段，主要是根據某個業務部門的需要，進行一定的資料的採集，整理，按照業務人員的需要，進行多維報表的展現，能夠提供對特定業務指導的資料，並且能夠提供特定的領導決策資料。

3. 資料倉庫階段：這個階段，主要是按照一定的資料模型，對整個企業的資料進行採集，整理，並且能夠按照各個業務部門的需要，提供跨部門的，完全一致的業務報表資料，能夠通過資料倉庫生成對對業務具有指導性的資料，同時，為領導決策提供全面的資料支援。

通過資料倉庫建設的發展階段，我們能夠看出，資料倉庫的建設和資料集市的建設的重要區別就在於資料模型的支援。因此，資料模型的建設，對於我們資料倉庫的建設，有著決定性的意義。

1.4資料倉庫意義

• 建立公司統一資料中心

• 為資料BP。運營人員提供資料支援

• 為領導提供決策支援

1.5資料庫和資料倉庫的區別

1.5.1資料庫

是一種邏輯概念，用來存放資料的倉庫，通過資料庫軟體來實現，資料庫由許多表組成，表是二維的，一張表裡面可以有很多欄位，資料庫的表，在與能夠用二維表現多維關係。

1.5.2資料倉庫

是資料庫概念的升級。從邏輯上理解，資料庫和資料倉庫沒有區別，都是通過資料庫軟體實現的存放資料的地方，只不過從資料量來說，資料倉庫要比資料庫更龐大得多。資料倉庫主要用於資料探勘和資料分析，輔助領導做決策。

資料庫與資料倉庫的區別實際講的是OLTP與OLAP的區別。

1.5.3對比

操作型處理，叫聯機事務處理OLTP（On-Line Transaction Processing，），也可以稱面向交易的處理系統，它是針對具體業務在資料庫聯機的日常操作，通常對少數記錄進行查詢、修改。使用者較為關心操作的響應時間、資料的安全性、完整性和併發支援的使用者數等問題。傳統的資料庫系統作為資料管理的主要手段，主要用於操作型處理。

分析型處理，叫聯機分析處理OLAP（On-Line Analytical Processing）一般針對某些主題的歷史資料進行分析，支援管理決策。

二離線資料倉庫架構

2.1資料調研

2.1.1業務調研

資料倉庫是要涵蓋所有業務領域，還是各個業務領域獨自建設，業務領域內的業務線也同樣面臨著這個問題。所以要構建大資料資料倉庫，就需要了解各個業務領域、業務線的業務有什麼共同點和不同點，以及各個業務線可以細分為哪幾個業務模組，每個業務模組具體的業務流程又是怎樣的。業務調研是否充分，將會直接決定資料倉庫建設是否成功。

2.1.2需求調研

瞭解業務系統的業務後不等於說就可以實施數倉建設了，還需要收集資料使用者的需求，及找分析師、運營人員、產品人員等了解他們對資料的訴求。通常需求調研分下面兩種途徑：

1.根據與分析師、運營人員、產品人員的溝通獲取需求。

2.對現有報表、資料進行研究分析獲取資料建設需求。

2.1.3資料調研

需要了解資料庫型別，資料來源，全量資料情況及資料每年增長情況，更新機制；還需要了解資料是否結構化，是否清洗，是介面呼叫還是直接訪問庫，有哪些型別的資料，資料結構之怎樣的。

2.2資料採集

2.2.1日誌資料

2.2.1.1埋點日誌

• 瀏覽日誌(h5,web,app)

• 點選日誌(h5,web,app)

2.2.1.2服務日誌

• 應用訪問日誌

• 介面呼叫日誌

2.2.1.3 NG日誌

(h5,web,app)

2.2.1.4採集欄位

account         string,           

appId           string,           

appVersion      string,           

carrier         string,           

deviceId        string,           

deviceType      string,           

eventId         string,           

ip              string,           

latitude        double,           

longitude       double,           

netType         string,           

osName          string,           

osVersion       string,           

properties      map<string,string>,                            

releaseChannel  string,           

resolution      string,           

sessionId       string,           

`timeStamp`       bigint

......

2.2.2業務資料

• Mysql

• MongoDB

• Oracle

2.2.3爬蟲資料

• 競品資料

• 維表資料

2.2 ETL

ETL是將業務系統的資料經過抽取、清洗轉換之後載入到資料倉庫的過程，目的是將企業中的分散、零亂、標準不統一的資料整合到一起，為企業的決策提供分析依據

2.2.1資料抽取(Extract)

主要是從業務庫把資料抽取到資料倉庫或者把日誌採集到資料倉庫

2.2.1.1業務資料抽取

2.2.1.1.1前言

sqoop和datax作為2款優秀的資料同步工具，備受資料開發人員喜愛，如何選擇也是件非常頭疼的事，下面就這兩種工具來分析分析吧...

2.2.1.1.2sqoop

sqoop是apache旗下一款“Hadoop中的各種儲存系統（HDFS、HIVE、HBASE） 和關係資料庫（mysql、oracle、sqlserver等）伺服器之間傳送資料”的工具。

匯入資料：MySQL，Oracle匯入資料到Hadoop的HDFS、HIVE、HBASE等資料儲存系統

匯出資料：從Hadoop的檔案系統中匯出資料到關係資料庫mysql等Sqoop的本質還是一個命令列工具。

底層工作機制

將匯入或匯出命令翻譯成MapReduce程式來實現

在翻譯出的MapReduce中主要是對InputFormat和

OutputFormat進行定製

 sqoop import   \

--connect jdbc:mysql://hadoop:3306/mysql   \

--username root  \

--password 123456   \

--table order_info   \

--target-dir /user/project/t_order_info  \

--fields-terminated-by '\t'  \

--split-by order_id \

-m 2

2.2.1.1.3datax

DataX是一個異構資料來源離線同步工具，致力於實現包括關係型資料庫(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各種異構資料來源之間穩定高效的資料同步功能。

核心架構

DataX本身作為離線資料同步框架，採用Framework + plugin架構構建。將資料來源讀取和寫入抽象成為Reader/Writer外掛，納入到整個同步框架中。

• Reader：Reader為資料採集模組，負責採集資料來源的資料，將資料傳送給Framework。

• Writer：Writer為資料寫入模組，負責不斷向Framework取資料，並將資料寫入到目的端。

• Framework：Framework用於連線reader和writer，作為兩者的資料傳輸通道，並處理緩衝，流控，併發，資料轉換等核心技術問題。

核心模組介紹

DataX完成單個數據同步的作業，我們稱之為Job，DataX接受到一個Job之後，將啟動一個程序來完成整個作業同步過程。DataX Job模組是單個作業的中樞管理節點，承擔了資料清理、子任務切分(將單一作業計算轉化為多個子Task)、TaskGroup管理等功能。

DataXJob啟動後，會根據不同的源端切分策略，將Job切分成多個小的Task(子任務)，以便於併發執行。Task便是DataX作業的最小單元，每一個Task都會負責一部分資料的同步工作。

切分多個Task之後，DataX Job會呼叫Scheduler模組，根據配置的併發資料量，將拆分成的Task重新組合，組裝成TaskGroup(任務組)。每一個TaskGroup負責以一定的併發執行完畢分配好的所有Task，預設單個任務組的併發數量為5。

每一個Task都由TaskGroup負責啟動，Task啟動後，會固定啟動Reader—>Channel—>Writer的執行緒來完成任務同步工作。

DataX作業執行起來之後，Job監控並等待多個TaskGroup模組任務完成，等待所有TaskGroup任務完成後Job成功退出。否則，異常退出，程序退出值非0

DataX排程流程：

舉例來說，使用者提交了一個DataX作業，並且配置了20個併發，目的是將一個100張分表的mysql資料同步到odps裡面。DataX的排程決策思路是：

DataXJob根據分庫分表切分成了100個Task。

根據20個併發，DataX計算共需要分配4個TaskGroup。

4個TaskGroup平分切分好的100個Task，每一個TaskGroup負責以5個併發共計執行25個Task。

下面以datax抽取mysql資料寫入hdfs為例：

{
"job": {
"setting": {
"speed": {
"channel": 3

},

"errorLimit": {
"record": 0,

"percentage": 0.02

}

},

"content": [{
"reader": {
"name": "mysqlreader",

"parameter": {
"username": "root",

"password": "root",

"column": ['id',

'name'

],

"where":"gmt_created>='$bizdate' and gmt_created<DATE_ADD('$bizdate',INTERVAL 1 DAY)",

"splitPk": "id",

"connection": [{
"table": [

"table"

],

"jdbcUrl": [

"jdbc:mysql://127.0.0.1:3306/database"

]

}]

}

},

"writer": {
"name": "hdfswriter",

"parameter": {
"defaultFS": "hdfs://xxx:port",

"fileType": "orc",

"path": "/user/hive/warehouse/writerorc.db/orcfull",

"fileName": "xxx",

"column": [{
"name": "id",

"type": "BIGINT"

},

{
"name": "name",

"type": "STRING"

}

],

"writeMode": "append",

"fieldDelimiter": "\t",

"compress": "GZIP"

}

}

}]

}

}

2.2.1.1.4對比

功能	datax	sqoop
執行模式	單程序多執行緒	mr
hive讀寫	單機壓力大	擴充套件性好
分散式	不支援	支援
執行資訊	執行時間，資料量，消耗資源，髒資料稽核	不支援
流量控制	支援	不支援
社群	開源不久，不太活躍	活躍

2.2.1.1.5總結

對於sqoop和datax，如果只是單純的資料同步，其實兩者都是ok的，但是如果需要整合在大資料平臺，還是比較推薦使用datax，原因就是支援流量控制，支援執行資訊收集，及時跟蹤資料同步情況。

大資料私房菜提了一個問題

那麼你們公司使用的是sqoop還是datax呢？是怎麼考慮的？

附：

（有很多朋友私信問datax能操作哪些資料庫或者檔案，以下把datax各子工程貼出來了，下面有的就是支援的，否則就需要二次開發了）

2.2.1.2日誌採集

2.2.1.2.1 flume

Apache Flume是一個從可以收集例如日誌，事件等資料資源，並將這些數量龐大的資料從各項資料資源中集中起來儲存的工具/服務。flume具有高可用，分散式和豐富的配置工具，其結構如下圖所示：

Flume：是一個數據採集工具；可以從各種各樣的資料來源（伺服器）上採集資料傳輸（匯聚）到大資料生態的各種儲存系統中（Hdfs、hbase、hive、kafka）；

開箱即用！（安裝部署、修改配置檔案）

Flume是一個分散式、可靠、和高可用的海量日誌採集、匯聚和傳輸的系統。

Flume可以採集檔案，socket資料包（網路埠）、資料夾、kafka、mysql資料庫等各種形式源資料，又可以將採集到的資料(下沉sink)輸出到HDFS、hbase、hive、kafka等眾多外部儲存系統中

一般的採集、傳輸需求，通過對flume的簡單配置即可實現；不用開發一行程式碼！

Flume針對特殊場景也具備良好的自定義擴充套件能力，因此，flume可以適用於大部分的日常資料採集場景

Flume中最核心的角色是agent，flume採集系統就是由一個個agent連線起來所形成的一個或簡單或複雜的資料傳輸通道。

對於每一個Agent來說,它就是一個獨立的守護程序(JVM),它負責從資料來源接收資料，併發往下一個目的地，如下圖所示：

每一個agent相當於一個數據(被封裝成Event物件)傳遞員，內部有三個元件：

Source：採集元件，用於跟資料來源對接，以獲取資料；它有各種各樣的內建實現；

Sink：下沉元件，用於往下一級agent傳遞資料或者向最終儲存系統傳遞資料

Channel：傳輸通道元件，用於從source將資料傳遞到sink

採集需求：比如業務系統使用log4j生成的日誌，日誌內容不斷增加，需要把追加到日誌檔案中的資料實時採集到hdfs

根據需求，首先定義以下3大要素

採集源，即source——監控檔案內容更新: exec ‘tail -F file’

下沉目標，即sink——HDFS檔案系統: hdfs sink

Source和sink之間的傳遞通道——channel，可用file channel也可以用 記憶體channel

配置檔案編寫：

agent1.sources = source1 agent1.sinks = sink1 agent1.channels = channel1 # Describe/configure tail -F source1 agent1.sources.source1.type = exec agent1.sources.source1.command = tail -F /home/hadoop/logs/access_log agent1.sources.source1.channels = channel1 #configure host for source agent1.sources.source1.interceptors = i1 agent1.sources.source1.interceptors.i1.type = host agent1.sources.source1.interceptors.i1.hostHeader = hostname # Describe sink1 agent1.sinks.sink1.type = hdfs #a1.sinks.k1.channel = c1 agent1.sinks.sink1.hdfs.path =hdfs://hadoop1:9000/weblog/flume-collection/%y-%m-%d/%H-%M agent1.sinks.sink1.hdfs.filePrefix = access_log agent1.sinks.sink1.hdfs.maxOpenFiles = 5000 agent1.sinks.sink1.hdfs.batchSize= 100 agent1.sinks.sink1.hdfs.fileType = DataStream agent1.sinks.sink1.hdfs.writeFormat =Text agent1.sinks.sink1.hdfs.rollSize = 102400 agent1.sinks.sink1.hdfs.rollCount = 1000000 agent1.sinks.sink1.hdfs.rollInterval = 60 agent1.sinks.sink1.hdfs.round = true agent1.sinks.sink1.hdfs.roundValue = 10 agent1.sinks.sink1.hdfs.roundUnit = minute agent1.sinks.sink1.hdfs.useLocalTimeStamp = true # Use a channel which buffers events in memory agent1.channels.channel1.type = memory agent1.channels.channel1.keep-alive = 120 agent1.channels.channel1.capacity = 500000 agent1.channels.channel1.transactionCapacity = 600 # Bind the source and sink to the channel agent1.sources.source1.channels = channel1 agent1.sinks.sink1.channel = channel1

2.2.1.2.2 logstash

Logstash是一個開源的伺服器端資料處理管道，它可以同時從多個源中提取資料，對其進行轉換，然後將其傳送其他儲存。

主要由input filter和output組成

原始日誌檔案：

[2019-01-14 00:02:11] [INFO] - com.test.pushTest(PushMessageExecutor.java:103) -訊息推送結果:響應狀態(200)、狀態描述(成功。)、響應反饋()、請求響應耗時(232ms),deviceToken:7b64436eeea34a3ab4e0873b0682ad98e,userId:1659034,auId:null, globalMessageId:2d09f8d389524c1f9c66b61,appId:p_ios,title:null,subTitle:null,alertBody:請及時查閱。.

配置檔案demo：

input { file { path => "/data/liuzc/test_log/*" type => "aa" start_position => "beginning" sincedb_path => "/dev/null" } } filter { multiline { pattern => "%{DATESTAMP}" negate => true what => "previous" } if [type] == "aa" { grok { match => { "message" => " - %{NOTSPACE:pushExecute} - %{NOTSPACE:apns_push_result},deviceToken:%{NOTSPACE:deviceToken},userId:%{NOTSPACE:userId},auId:%{NOTSPACE:auId},globalMessageId:%{NOTSPACE:globalMessageId},appId:%{NOTSPACE:appId},title:%{NOTSPACE:title},subTitle:%{NOTSPACE:subTitle},alertBody:%{NOTSPACE:alertBody}" } } } else { grok { match => { "message" => "%{DATESTAMP:time_local} %{LOGLEVEL:log_level}" } } } #ruby { # code => ' # event["datestr"] = event["@timestamp"].time.getlocal("+08:00").strftime "%Y-%m-%d" # event["hours"] = event["@timestamp"].time.getlocal("+08:00").strftime("%H").to_i # ' # } date { match => ["time_local", "yy/MM/dd-HH:mm:ss.SSS"] } } output { stdout{codec=>"rubydebug"} }

解析結果：

{ "message" => "[2019-01-14 00:02:11] [INFO] - com.test.pushTest(PushMessageExecutor.java:103) -訊息推送結果:響應狀態(200)、狀態描述(成功。)、響應反饋()、請求響應耗時(232ms),deviceToken:7b64436eeea34a3ab4e0873b0682ad98e,userId:1659034,auId:null,globalMessageId:2d09f8d389524c1f9c66b61,appId:p_ios,title:null,subTitle:null,alertBody:請及時查閱。.", "@version" => "1", "@timestamp" => "2019-01-17T01:16:06.468Z", "host" => "xy1", "path" => "/data/liuzc/test_log/test-2019-01-14.log", "type" => "aa", "time_local" => "2019-01-14 00:02:11", "log_level" => "INFO", "pushExecute" => "com.test.pushExecute(PushMessageExecutor.java:103)", "apns_push_result" => "訊息推送結果:響應狀態(200)、狀態描述(成功。)、響應反饋()、請求響應耗時(232ms)", "deviceToken" => "7b64436eeea34a3ab4e0873b0682ad98e", "userId" => "1659034", "auId" => "null", "globalMessageId" => "2d09f8d389524c1f9c66b61", "appId" => "p_ios", "title" => "null", "subTitle" => "null", "alertBody" => "請及時查閱。." }

Logstash grok線上驗證地址：

l國內：http://grok.qiexun.net/

l國外：http://grokdebug.herokuapp.com/

2.2.1.2.3對比

lLogstash和flume都能作為日誌採集工具

lLogstash是由ruby開發，flume使用java語言開發

lLogstash每起一個程序，預設佔用1G記憶體，如果程序起的多的話給應用伺服器帶來很大的壓力

2.2.2資料清洗轉換(Cleaning、Transform)

資料清洗的任務是過濾那些不符合要求的資料

資料轉換的任務主要進行不一致的資料轉換、資料粒度的轉換，以及一些業務規則的計算。

2.2.2.1 ID-MAPPING

登入狀態下，日誌中會採集到使用者的登入id（account），可以做到使用者身份的精確標識；而在匿名狀態下，日誌中沒有采集到使用者的登入id，準確標識使用者，成為一件極其棘手的事情

解決方案：關聯裝置ID和登入ID（動態修正）

一個裝置ID被繫結到某個登陸ID（A）之後，如果該裝置在後續一段時間（比如一個月內）被一個新的登陸ID（B）更頻繁使用，則該裝置ID會被調整至繫結登陸ID（B）

2.2.2.2資料清洗

• 單位統一，比如金額單位統一為元

• 欄位型別統一

• 註釋補全

• 空值用預設值或者中位數填充

• 時間欄位格式統一，如2020-10-16,2020/10/16,20201016統一格式為2020-10-16

• 過濾沒有意義的資料

• ......

2.2.2.3資料轉換

下面會介紹模型建設

2.2.3資料載入(load)

資料同步到其他儲存系統，如mysql，hbase

2.3資料儲存

資料儲存在hdfs，包含元資料和主資料的儲存

2.4資料應用

• 資料同步到mysql提供介面

• 資料同步到需求方mysql庫直接呼叫

• 資料同步到kylin(olap)做預計算，為需求方提供資料做多維分析

• 資料同步到hbase提供介面服務

• 資料同步到pg提供資料

• 使用者畫像

• 推薦系統

• 運營系統

• 報表系統

• 業務系統

• BI視覺化

2.5簡單架構

三資料建模

3.1前言

3.1.1什麼是資料建模

資料建模簡單來說就是基於對業務的理解，將各種資料進行整合和關聯，並最終使得這些資料可用性，可讀性增強，讓使用方能快速的獲取到自己關心的有價值的資訊並且及時的作出響應，為公司帶來效益。

3.1.2為什麼要資料建模

資料建模是一套方法論，主要是對資料的整合和儲存做一些指導，強調從各個角度合理的儲存資料。

·進行全面的業務梳理，改進業務流程。

在業務模型建設的階段，能夠幫助我們的企業或者是管理機關對本單位的業務進行全面的梳理。通過業務模型的建設，我們應該能夠全面瞭解該單位的業務架構圖和整個業務的執行情況，能夠將業務按照特定的規律進行分門別類和程式化，同時，幫助我們進一步的改進業務的流程，提高業務效率，指導我們的業務部門的生產。

·建立全方位的資料視角，消滅資訊孤島和資料差異。

通過資料倉庫的模型建設，能夠為企業提供一個整體的資料視角，不再是各個部門只是關注自己的資料，而且通過模型的建設，勾勒出了部門之間內在的聯絡，幫助消滅各個部門之間的資訊孤島的問題，更為重要的是，通過資料模型的建設，能夠保證整個企業的資料的一致性，各個部門之間資料的差異將會得到有效解決。

·解決業務的變動和資料倉庫的靈活性。

通過資料模型的建設，能夠很好的分離出底層技術的實現和上層業務的展現。當上層業務發生變化時，通過資料模型，底層的技術實現可以非常輕鬆的完成業務的變動，從而達到整個資料倉庫系統的靈活性。

·幫助資料倉庫系統本身的建設。

通過資料倉庫的模型建設，開發人員和業務人員能夠很容易的達成系統建設範圍的界定，以及長期目標的規劃，從而能夠使整個專案組明確當前的任務，加快整個系統建設的速度。

有了合適的資料模型，是會帶來很多好處的：

• 查詢使用效能提升

• 使用者效率提高，改善使用者體驗

• 資料質量提升

• 降低企業成本

• ......

所以大資料系統需要資料模型方法來更好的組織和儲存，以便在效能,成本，效率和質量之間取的平衡。

3.2建模工具

PowerDesigner：

Power Designer是Sybase公司的CASE工具集，使用它可以方便地對管理資訊系統進行分析設計，他幾乎包括了資料庫模型設計的全過程。利用Power Designer可以製作資料流程圖、概念資料模型、物理資料模型，還可以為資料倉庫製作結構模型，也能對團隊設計模型進行控制。他可以與許多流行的軟體開發工具，例如PowerBuilder、Delphi、VB等相配合使開發時間縮短和使系統設計更優化。

power designer是能進行資料庫設計的強大的軟體，是一款開發人員常用的資料庫建模工具。使用它可以分別從概念資料模型(Conceptual Data Model)和物理資料模型(Physical Data Model)兩個層次對資料庫進行設計。在這裡，概念資料模型描述的是獨立於資料庫管理系統(DBMS)的實體定義和實體關係定義；物理資料模型是在概念資料模型的基礎上針對目標資料庫管理系統的具體化。

3.3Kimball和Inmon架構

3.3.1Inmon架構

輻射狀企業資訊工廠(CIF)方法由Bill Inmon及業界人士倡導的。在這個環境下，資料從操作性資料來源中獲取，在ETL系統中處理，將這一過程稱為資料獲取，從這一過程中獲得的原子資料儲存在滿足第三正規化的資料庫中，這種規範化的原子資料的倉庫被稱為CIF架構下的企業級資料倉庫(EDW)

與Kimball方法相似，CIF提倡企業資料協調與整合，但CIF認為要利用規範化的EDW承擔這一角色，而Kimball架構強調具有一致性維度的企業匯流排的重要作用

Inmon企業級資料倉庫的分析資料庫通常以部門為中心（而不是圍繞業務過程來組織），而且包含彙總資料，並不是原子級別資料，如果ETL過程中資料所應用的業務規則超越了基本概要，如部門改名了或者其他的類似計算，要將分析資料庫與EDW原子資料聯絡起來將變得很困難

3.3.2Kimball架構

Kimball架構利用了CIF中處於中心地位的EDW，但是此次的EDW完全與分析與報表使用者隔離，僅作為資料來源，其中資料是維度的，原子的，以過程為中心的，與企業級資料倉庫匯流排結構保持一致。

3.3.3架構對比

3.3.3.1流程

Inmon架構是自頂向下，即從資料抽取-->資料倉庫-->資料集市，以資料來源為導向，是一種瀑布流開發方法，模型偏向於3NF，

Kimball:架構是自下向上，即從資料集市(主題劃分)-->資料倉庫-->資料抽取，是以需求為導向的，一般使用星型模型

3.3.3.2事實表和維表

Inmon架構下，不強調事實表和維表的概念，因為資料來源變化可能會比較大，更加強調的是資料清洗的工作

kimball架構強調模型由事實表和維表組成，注重事實表與維表的設計

3.3.3.3資料集市

Inmon架構中，資料集市有自己的物理儲存，是真實存在的。

Kimball資料倉庫架構中，資料集市是一個邏輯概念，只是多維資料倉庫中的主題域劃分，並沒有自己的物理儲存，也可以說是虛擬的資料集市。是資料倉庫的一個訪問層，是按主題域組織的資料集合，用於支援部門級的決策。

3.3.3.4中心

Inmon架構是以部門為中心，而Kimball架構是以業務過程為中心

3.3.3.5EDW的訪問

Inmon架構中使用者可以直接訪問企業資料倉庫(EDW)

Kimball架構中使用者不可以直接訪問企業資料倉庫(EDW)，只能訪問展現區資料

企業開發中一般選擇Kimball維度建模

3.4數倉建模階段劃分

3.4.1業務模型

生成業務模型，主要解決業務層面的分解和程式化

1. 劃分整個單位的業務，一般按照業務部門的劃分，進行各個部分之間業務工作的界定，理清各業務部門之間的關係。

2. 深入瞭解各個業務部門的內具體業務流程並將其程式化。

3. 提出修改和改進業務部門工作流程的方法並程式化。

4. 資料建模的範圍界定，整個資料倉庫專案的目標和階段劃分。

3.4.2領域模型

生成領域模型，主要是對業務模型進行抽象處理，生成領域概念模型。

1. 抽取關鍵業務概念，並將之抽象化。

2. 將業務概念分組，按照業務主線聚合類似的分組概念。

3. 細化分組概念，理清分組概念內的業務流程並抽象化。

4. 理清分組概念之間的關聯，形成完整的領域概念模型。

3.4.3邏輯模型

生成邏輯模型，主要是將領域模型的概念實體以及實體之間的關係進行資料庫層次的邏輯化。

1. 業務概念實體化，並考慮其具體的屬性

2. 事件實體化，並考慮其屬性內容

3. 說明實體化，並考慮其屬性內容

3.4.4物理模型

生成物理模型，主要解決，邏輯模型針對不同關係型資料庫的物理化以及效能等一些具體的技術問題。

1. 針對特定物理化平臺，做出相應的技術調整

2. 針對模型的效能考慮，對特定平臺作出相應的調整

3. 針對管理的需要，結合特定的平臺，做出相應的調整

4. 生成最後的執行指令碼並完善。

3.5模型建設方法

3.5.1 ER模型

ER模型是屬於三正規化的，是企業級的主題抽象而不是單獨描述某個業務

3.5.1.1什麼是正規化

當分類不可再分時，這種關係是規範化的，一個低階正規化分解轉換為更高階的正規化時，就叫做規範化

資料表可以分為1-5NF，第一正規化是最低要求，第五正規化則是最高要求

最常用的正規化有第一正規化（1NF）、第二正規化（2NF）、第三正規化（3NF）

3.5.1.2第一正規化

表中的每一列都是不可拆分的原子項

由上圖可知，phone欄位裡面存了2個值，具有可分割性，不符合1NF，可以改成：

3.5.1.3第二正規化

第二正規化要同時滿足下面兩個條件：

• 滿足第一正規化

• 沒有部分依賴

上圖可以看出，如果一個使用者下了很多訂單，則使用者名稱，收穫地址和手機號有重複出現的情況造成資料冗餘，很明顯不太符合第二正規化，可以改成：

3.5.1.4第三正規化

第三正規化要同時滿足下面兩個條件：

• 滿足第二正規化

• 沒有傳遞依賴

簡單點說，關係重複，能互相推匯出來

如上圖所示，如果知道了zip郵編，其實是能推出來省市區的，相反，知道了省市區，也是可以推出郵編的，有傳遞依賴，造成了冗餘，不符合第三正規化，需要改造:

3.5.1.5小結

在關係資料模型設計中，一般需要滿足第三正規化的要求。如果一個表有良好的主外來鍵設計，就應該是滿足3NF的表。

規範化帶來的好處是通過減少資料冗餘提高更新資料的效率，同時保證資料完整性。然而，我們在實際應用中也要防止過度規範化的問題。規範化程度越高，劃分的表就越多，在查詢資料時越有可能使用表連線操作。

而如果連線的表過多，會影響查詢的效能。關鍵的問題是要依據業務需求，仔細權衡資料查詢和資料更新的關係，制定最適合的規範化程度。還有一點需要注意的是，不要為了遵循嚴格的規範化規則而修改業務需求。

3.5.2維度建模

維度建模是一種將大量資料結構化的邏輯設計手段，包含維度和指標，它不像ER模型目的是消除冗餘資料，維度建模是面向分析，最終目的是提高查詢效能，所以會增加資料冗餘，並且違反三正規化。

維度建模也是重點關注讓使用者快速完成需求分析且對於複雜查詢及時響應，維度建模一般可以分為三種：

• 星型模型

• 雪花模型

• 星座模型

其中最常用的其實是星型模型

3.5.2.1背景

在多維分析的商業智慧解決方案中，根據事實表和維度表的關係，又可將常見的模型分為星型模型，雪花型模型及星座模型。在設計邏輯型資料的模型的時候，就應考慮資料是按照星型模型，雪花型模型還是星座模型進行組織。

3.5.2.2事實表和維度表

3.5.2.2.1事實表（Fact Table）

指儲存有事實記錄的表，如系統日誌、銷售記錄等；事實表的記錄在不斷地動態增長，所以它的體積通常遠大於其他表。

事實表作為資料倉庫建模的核心，需要根據業務過程來設計，包含了引用的維度和業務過程有關的度量。

作為度量業務過程的事實，一般為整型或浮點型的十進位制數值，有可加性，半可加性和不可加性三種類型

3.5.2.2.2可加

最靈活最有用的事實是完全可加，可加性度量可以按照與事實表關聯的任意維度彙總。比如訂單總金額

3.5.2.2.3半可加

半可加度量可以對某些維度彙總，但不能對所有維度彙總。差額是常見的半可加事實，除了時間維度外，他們可以跨所有維度進行操作。(比如每天的餘額加起來毫無意義)

3.5.2.2.4不可加

一些度量是完全不可加的，例如：比率。對非可加事實，一種好的方法是，分解為可加的元件來實現聚集

3.5.2.2.5維度表

維度表（Dimension Table）或維表，有時也稱查詢表（Lookup Table），是與事實表相對應的一種表；它儲存了維度的屬性值，可以跟事實表做關聯；相當於將事實表上經常重複出現的屬性抽取、規範出來用一張表進行管理。常見的維度表有：日期表（儲存與日期對應的周、月、季度等的屬性）、地點表（包含國家、省／州、城市等屬性）等。維度是維度建模的基礎和靈魂。

3.5.2.2.6優點

• 縮小了事實表的大小。

• 便於維度的管理和維護，增加、刪除和修改維度的屬性，不必對事實表的大量記錄進行改動。

• 維度表可以為多個事實表重用，以減少重複工作。

3.5.2.2.7下鑽

下鑽是商業使用者分析資料的最基本的方法。下鑽僅需要在查詢上增加一個行頭指標，新行的頭指標是一個維度屬性，附加了sql語言的group by表示式，屬性可以來自任何與查詢使用的事實表關聯的維度，下鑽不需要預先存在層次的定義，或者是下鑽路徑。

3.5.2.2.8退化維度

有時，維度除了主鍵外沒有其他內容，例如，當某一發票包含多個數據項時，資料項事實行繼承了發票的所有描述性維度外來鍵，發票除了外來鍵無其他項，但發票數量仍然是在此資料項級別的合法維度鍵。這種退化維度被放入事實表中，清楚的表明沒有關聯的維度表，退化維度常見於交易和累計快照事實表中。

3.5.2.3事實表和維表的關係

3.5.2.3星型模型

星形模型中有一張事實表，以及零個或多個維度表，事實表與維度表通過主鍵外來鍵相關聯，維度表之間沒有關聯，當所有維表都直接連線到“事實表”上時，整個圖解就像星星一樣，故將該模型稱為星型模型。星形模型是最簡單，也是最常用的模型。由於星形模型只有一張大表，因此它相比於其他模型更適合於大資料處理。其他模型可以通過一定的轉換，變為星形模型。

星型架構是一種非正規化的結構，多維資料集的每一個維度都直接與事實表相連線，不存在漸變維度，所以資料有一定的冗餘，如在地域維度表中，存在國家A省B的城市C以及國家A省B的城市D兩條記錄，那麼國家A和省B的資訊分別儲存了兩次，即存在冗餘。

3.5.2.4雪花模型

當有一個或多個維表沒有直接連線到事實表上，而是通過其他維表連線到事實表上時，其圖解就像多個雪花連線在一起，故稱雪花模型。雪花模型是對星型模型的擴充套件。它對星型模型的維表進一步層次化，原有的各維表可能被擴充套件為小的維度表，形成一些區域性的"層次"區域，這些被分解的表都連線到主維度表而不是事實表。如圖，將地域維表又分解為國家，省份，城市等維表。它的優點是:通過最大限度地減少資料儲存量以及聯合較小的維表來改善查詢效能。雪花型結構去除了資料冗餘。

3.5.2.5星座模型

星座模型是由星型模型延伸而來，星型模型是基於一張事實表而星座模式是基於多張事實表，並且共享維度表資訊，這種模型往往應用於資料關係比星型模型和雪花模型更復雜的場合。星座模型需要多個事實表共享維度表，因而可以視為星形模型的集合，故亦被稱為星系模型

3.5.2.6對比

• 星型模型因為資料的冗餘所以很多統計查詢不需要做外部的連線，因此一般情況下效率比雪花型模型要高。

• 星型結構不用考慮很多正規化的因素，設計與實現都比較簡單。

• 雪花型模型由於去除了冗餘，有些統計就需要通過表的聯接才能產生，所以效率比較低。

• 正規化也是一種比較複雜的過程，相應的資料庫結構設計、資料的ETL、以及後期的維護都要複雜一些。

3.5.2.7小結

通過對比，我們可以發現數據倉庫大多數時候是比較適合使用星型模型構建底層資料Hive表，通過大量的冗餘來減少表查詢的次數從而提升查詢效率，星型模型對OLAP的分析引擎支援比較友好，這一點在Kylin中比較能體現。而雪花模型在關係型資料庫中如MySQL，Oracle中非常常見，尤其像電商的資料庫表。在資料倉庫中雪花模型和星座模型的應用場景比較少，但也不是沒有，所以在具體設計的時候，可以考慮是不是能結合兩者的優點參與設計，以此達到設計的最優化目的。

3.5.2.8建模原則

• 高內聚和低輯合

將業務相近或者相關、粒度相同的資料設計為一個邏輯或者物理模型：將高概率 同時訪問的資料放一起，將低概率同時訪問的資料分開儲存。

• 核心模型與擴充套件模型分離

建立核心模型與擴充套件模型體系，核心模型包括的宇段支援常用的核心業務，擴充套件模 型包括的欄位支援個性化或少量應用的需要，不能讓擴充套件模型的宇段過度侵人核心模型，以免破壞核心模型的架構簡潔性與可維護性。

• 公共處理邏輯下沉及單一

越是底層公用的處理邏輯越應該在資料排程依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用層實現，不要讓公共邏輯多處同時存在。

• 成本與效能平衡

適當的資料冗餘可換取查詢和重新整理效能，不宜過度冗餘與資料複製。

• 資料可回滾

不改變處理邏輯，不修改程式碼的情況下重跑任務結果不變

• 一致性

欄位命名及定義必須一致

• 命名清晰、可理解

表命名需清晰、一致，表名需易於使用方理解

3.5.2.9星型模型設計步驟

1. 選擇需要進行分析決策的業務過程,比如下單

2. 選擇粒度。在事件分析中，我們要預判所有分析需要細分的程度，從而決定選擇的粒度。比如訂單粒度，粒度是維度的一個組合。

3. 識別維表。選擇好粒度之後，就需要基於此粒度設計維表，包括維度屬性，用於分析時進行分組和篩選。

4. 選擇事實。確定分析需要衡量的指標

3.5.3 Data Vault模型

Data Vault Dan Linstedt發起建立的一種模型，它是模型的衍生，其設計的出發點也是為了實現資料的整合，但不能直接用於資料分析決策。它強調建立一個可審計的基礎資料層，也就是強調資料的歷史性、可追溯性和原子性，而不要求對資料進行過度的一致性處理和整合；

同時它基於主題概念將企業資料進行結構化組織，並引入了更進一步的正規化處理來優化模型，以應對源系統變更的擴充套件性。Data Vault型由以下幾部分組成。

• Hub：是企業的核心業務實體，由 實體key、資料倉庫序列代理鍵、裝載時間、資料來源組成。

• Link：代表Hub之間的關係。這裡與 模型最大的區別是將關係作為一個獨立的單元抽象，可以提升模型的擴充套件性。它可以直接描述1:1 1:n n:n的關係，而不需要做任何變更。它由Hub的代理鍵、裝載時間、資料來源組成。

• Satellite：是Hub的詳細描述內容， 一個Hub可以有多個Satellite它由Hub的代理鍵、裝載時間、來源型別、詳細的Hub描述資訊組成。

Data Vault模型比ER模型更容易設計和產出，它的ETL加工可實現配置化。

3.5.4 Anchor模型

進一步規範化處理，其核心思想是所有的擴充套件只新增而不是修改，因此將模型規範到6NF，基本程式設計了K-V結構化模型。

　　那麼總的來說，分為三個階段：

1. 將資料以源表結構相同的方式同步到Oracle，資料工程師基於ODS資料進行統計。

2. 通過一些模型技術改變煙囪式的開發模型，消除一些冗餘，提升資料的一致性。（經驗）在不太成熟、快速變化的業務面前，構建ER模型的風險非常大，不太適合去構建ER模型。

3. 選擇了以Kimball的維度建模為核心理念的模型方法論，同時對其進行了一定的升級和擴充套件，構建了公共層模型資料架構體系。

3.6開發規範

3.6.1開發流程

1. 需求分析調研(資料調研，需求調研，業務調研)：明確口徑，評估排期，需求正規流程提交

2. 指標管理：完善指標命名規範，指標同名同義，指標與業務強相關，明確指標構成要素

3. 模型設計：完善開發流程規範，標準化業務調研，知識庫文件集中管理，建立模型評審機制

4. ETL開發：ODS->DWD->DW->DWS->ADS

5. 資料驗證：制定資料測試標準

6. 任務排程：規範化排程引數配置

7. 上線管理

3.6.2分層規範

3.6.2.1前言

資料倉庫一般分為三層，自上而下分別為資料貼源層（ODS，Operation Data Store）、資料公共層（CDM，Common Data Model）和資料應用層（ADS，Application Data Service）。

3.6.2.2 ODS層

貼源層，與業務庫保持一致，不做任何處理

3.6.2.3 CDM層

資料公共層CDM（Common Data Model，又稱通用資料模型層），包括DIM維度表、DWD,DW和DWS，由ODS層資料加工而成。主要完成資料加工與整合，建立一致性的維度，構建可複用的面向分析和統計的明細事實表，以及彙總公共粒度的指標

公共維度層（DIM）：基於維度建模理念思想，建立企業一致性維度。降低資料計算口徑和演算法不統一風險。 公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應。

明細粒度事實層（DWD）：對資料進行規範化編碼轉換，清洗，統一格式，脫敏等，不做橫向整合

主題寬表層(DW)對dwd各種資訊進行整合，輸出主題寬表(面向業務過 程，不同業務過程的資訊不冗餘建設，採用外來鍵形式)

公共彙總粒度事實層（DWS）：以分析的主題物件作為建模驅動，基於上層的應用和產品的指標需求，構建公共粒度的彙總指標事實表，以寬表化手段物理化模型。構建命名規範、口徑一致的統計指標，為上層提供公共指標，建立彙總寬表、明細事實表。

公共彙總粒度事實層的表通常也被稱為彙總邏輯表，用於存放派生指標資料。

3.6.2.4 ADS層

資料應用層ADS（Application Data Service）：面向業務需求定製開發，存放資料產品個性化的統計指標資料。

3.6.2.5邏輯分層架構

3.6.2.6分層的好處

• 清晰資料結構：每一個數據分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。

• 資料血緣追蹤：簡單來講可以這樣理解，我們最終給業務呈現的是一張能直接使用的張業務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地定位到問題，並清楚它的危害範圍。

• 減少重複開發：規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算。

• 把複雜問題簡單化：將一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護資料的準確性，當資料出現問題之後，可以不用修復所有的資料，只需要從有問題的步驟開始修復。

3.6.2.7資料流向

• 正常流向：ODS->DWD->DW->DWS->ADS，當出現ODS->DWD->DWS->ADS這種關係時，說明主題域未覆蓋全。應將DWD資料落到DW中，對於使用頻度非常低的表允許DWD->DWS。

• 儘量避免出現DWS寬表中使用DWD又使用（該DWD所歸屬主題域）DW的表。

• 同一主題域內對於DW生成DW的表，原則上要儘量避免，否則會影響ETL的效率。

• DW、DWS和ADS中禁止直接使用ODS的表，ODS的表只能被DWD引用。

• 禁止出現反向依賴，例如DW的表依賴DWS的表。

3.6.3表命名規範

• 表名、欄位名採用下劃線分隔詞根（consultorder->consult_order）

• 每部分使用小寫英文單詞，屬於通用欄位的必須滿足通用欄位資訊的定義。

• 表名、欄位名需以字母為開頭。

• 表名、欄位名最長不超過64個英文字元。

• 優先使用詞根中已有關鍵字（數倉標準配置中的詞根管理），定期Review新增命名的不合理性。

• 在表名自定義部分禁止採用非標準的縮寫。

3.6.3.1ods dwd層

建表表名一律小寫

表名命名規則：[層次].[業務]_[表內容]_[週期+處理方式]

3.6.3.2dw dws層

建表表名一律小寫

表名命名規則：[層次].[主題]_[表內容]_[週期+處理方式] 主題在dw層以後，表內容參考業務系統表名，做適當處理，分表規則可以沒有

如：ods.test_order_info_df

ods表示層次，test表示主題，order_info表示表內容，d表示週期(天)，f表示處理方式(全量抽取)

3.6.3.3臨時表tmp

臨時表命名規則：[層次].tb_目標表名_程式開始執行時間_序號

3.6.4欄位命名規範

• 有實際意義

• 根據詞根組合而成

如：order_amt訂單金額

3.6.5註釋規範

• 能實際說明欄位意義

• 字典需要註明id和desc

如：order_id varchar comment‘訂單id’

order_status tinyint comment‘1：已支付 2：已發貨 3：已簽收’

3.6.6資料型別規範

根據實際需求選擇欄位型別

3.6.6.1數字類

3.6.6.2日期時間類

3.6.6.3字串類

3.6.6.4 Misc類

3.6.6.5複合類

3.6.7分割槽規範

• 什麼情況需要分割槽

• 分割槽欄位選擇

• 分割槽欄位命名規範

目前90%以上的分割槽表都是以日期分割槽的，當然，一些日誌表還是有二級分割槽，如三端日誌

3.6.8詞根規範

3.6.8.1詞根評審

需要新增一個詞根的時候，需要部門評審，看看是否有必要新增，並且如果確定下來需要新增的話如何命名

比如cnt 這個詞代表的意思是count 數量，如果之前詞根裡面沒有的話，理論上來說，新增該詞根是沒毛病的

3.6.8.2詞根大全

3.6.9指標規範

3.6.9.1指標定義

指標的定義(口徑)需要與業務方，運營人員或者資料分析師綜合確定

現列舉一些常用流量指標：

• 日活躍度=當日啟動使用者/累計使用者*100%

• 周活躍度=周活躍使用者/累計使用者*100%

• 月活躍度=月活躍使用者/累計使用者*100%

• 頁面訪問次數：頁面被開啟的次數，同一頁面的多次訪問均會被計數。

• 頁面平均停留時長：每一次頁面訪問的停留時長的平均值

3.6.9.2指標命名

3.6.9.2.1基礎指標

主要是指不能再拆解的指標，通常表達業務實體原子量化屬性的且不可再分的概念集合，如訂單數

單個基礎指標詞根+修飾詞

3.6.9.2.2複合指標

建立在基礎指標之上，通過一定運算規則形成的計算指標集合，如人均費用=總費用/人數

3.6.9.2.3派生指標

指的是基礎指標或複合指標與維度成員，統計屬性，管理屬性等相結合產生的指標，如最近7天醫生接單量=醫生在過去7天一共接到的訂單

多個基礎指標詞根+修飾詞

3.5.9.3指標評審

每定一個指標都是需要業務方(或其他部門)與資料部門一起評審決定的，包括指標是否有必要新增，如何定義等

3.5.9.4指標儲存展示

可以通過自研WEB系統來進行展示

展示內容可以有：

• 指標名稱

• 指標編碼

• 業務口徑

• 指標型別

• 責任人

• 建立時間

• 狀態

• ......

3.6.10資料抽取規範

Mysql資料準備

第一天9月10號資料

第二天9月11號資料

對比mysql第一天和第二天的資料發現，第二天新增了訂單id為4和5這兩條資料，並且訂單id為2和3的狀態更新為了已支付

3.6.10.1全量表

每天的所有的最新狀態的資料。

• 全量表，有無變化，都要報

• 每次上報的資料都是所有的資料（變化的+沒有變化的）

9月10號全量抽取到ods層

9月11號全量抽取到ods層

全量抽取，每個分割槽保留歷史全量快照。

3.6.10.2增量表

增量表：新增資料，增量資料是上次匯出之後的新資料。

• 記錄每次增加的量，而不是總量；

• 增量表，只報變化量，無變化不用報

• 業務庫表中需有主鍵及建立時間，修改時間

9月10號全量抽取到ods層(全量初始化)

9月11號抽取更新的資料及當天新增的資料，即訂單id為2,3,4,5的資料

wedw_dwd.order_info_di表9月10號的分割槽資料與wedw_ods.order_info_20200911增量抽取的資料合併，有2種方案

a.兩個表通過主鍵關聯，dwd表存在並且ods表不存在的資料

union all一下wedw_ods.order_info_20200911表所有的資料，即全量資料插入到dwd表的9月11號的分割槽

b.兩個表資料union all一下，再根據order_id去重(根據order分組，更新時間降序，取第一條)

特殊增量表：da表，每天的分割槽就是當天的資料，其資料特點就是資料產生後就不會發生變化，如日誌表。

3.6.10.3拉鍊表

• 維護歷史狀態，以及最新狀態資料

• 資料量比較大

• 表中的部分欄位會被更新

• 需要檢視某一個時間點或者時間段的歷史快照資訊

• 檢視某一個訂單在歷史某一個時間點的狀態

• 某一個使用者在過去某一段時間，下單次數

• 更新的比例和頻率不是很大

如果表中資訊變化不是很大，每天都保留一份全量，那麼每次全量中會儲存很多不變的資訊，對儲存是極大的浪費

優點

• 滿足反應資料的歷史狀態

• 最大程度節省儲存

9月10號全量抽取到ods層

建立dwd層拉鍊表

增加兩個欄位：start_dt(表示該條記錄的生命週期開始時間——週期快照時的狀態)end_dt(該條記錄的生命週期結束時間)

end_dt=‘9999-12-31’ 表示該條記錄目前處於有效狀態

注：第一次加工的時候需要初始化所有資料，start_time設定為資料日期2020-09-10，end_time設定為9999-12-31

9月11號抽取更新的資料及當天新增的資料到ods層，即訂單id為2,3,4,5的資料

查詢當前的所有有效記錄：

查詢9月10號歷史快照:

查詢9月11號歷史快照:

3.6.10.4流水錶

對於表的每一個修改都會記錄，可以用於反映實際記錄的變更

3.6.10.5總結

• 在工作中，其實上述3種表都是很有可能會用到的，那麼我們應該怎麼選擇呢？

• 如果資料量不是很大(不超過20W)且預估後續增長的非常慢，可以考慮全量表抽取，這是最簡便的方法

• 如果資料量目前來說不是很大，但是業務發展很快，資料量一段時間後就會上來，建議增量抽取哦

• 目前資料量本身就非常大，肯定是需要增量抽取的，比如現在有10億資料，如果你每天全量抽取一遍，相信我，你會抽哭的

• 對於歷史狀態需要儲存的，這個時候就需要使用拉鍊表了，實際工作中，使用拉鍊表的場景並不會太多，比如訂單表，儲存訂單歷史狀態，維表(緩慢變化維的處理)

3.6.11緩慢變化維處理

3.6.11.1背景

眾所周知，雖然維度表屬性相對穩定，但是並不是一成不變的，儘管相當緩慢，維度值仍會隨時間而變化。比如商品類目的改變，醫院等級的改變

在一些情況下，保留歷史資料沒有什麼分析價值，而在另一些情況下,保留歷史資料是非常重要的

3.6.11.2解決方案

3.6.11.2.1重寫維度值

在維度表中，僅需以當前值重寫先前存在的值，不需要觸碰事實表

缺點：如果業務需要準確的跟蹤歷史變化，這種方案是沒法實現的，並且在以後想改變是非常困難的

修改之前

修改後：

3.6.11.2.2插入新的維度行

插入新的維度行。採用此種方式，保留歷史資料，

維度值變化前的事實和過去的維度值關聯，維度值變化後的事實和當前的維度值關聯

缺點：雖然此方案能夠區分歷史情況，但是該方式不能將變化前後記錄的事實歸一為變化前的維度或者歸一為變化後的維度

3.6.11.2.3新增維度列

有些是隻保留最新的維度值和最近的維度值，也有的是維度值一有變化就新增一個屬性欄位。都不是很好的解決方案

變化前：

變化後：

3.6.11.2.4拉鍊表處理

這是精確跟蹤緩慢變化維度屬性的主要技術，因為新維度行能夠自動劃分事實錶的歷史，所以這是一項非常好的技術

變化前：

變化後：

3.6.12多值維度及多值屬性(交叉維度)

3.6.12.1背景

正常情況下，維表和事實表之間是一對多的關係，維表中的一行記錄會連線事實表中的多行記錄，事實表中的一行記錄在維度表中只能關聯上一條記錄，不會發生資料發散的現象

想法是美好的，但是事實總是不盡人意。因為現實中不但事實表和維度表之間存在多對多的關係，維度表和維度表之間也存在多對多的關係

這兩種情況本質是相同的，但事實表和維度表之間的多對多關係少了唯一描述事實和維度組的中間維度。

對於這兩種情況，一種稱為橋接表的中間表就需要派上用場了，並且還可以支援更為複雜的多對多的關係

3.6.12.2事實表與維度表多對多(多值維度)

比如下單了一套學習課程，但是這套課程並不是某一個使用者買的，而是好幾個使用者合買的，所以為了處理這種情況，需要建立一個橋接表，將這些合買的使用者組成一個組

ETL過程需要對每條事實表中的使用者組，在橋接表中查詢相應的使用者主鍵,上圖所示的橋接表有重複計數的風險。如果按使用者累加購買金額，對某些分析而言結果是正確的，但對於其他情況仍會有重複計數的問題。要解決這個問題，可以向橋接表中新增權重。

權重是一個分數值，所有的使用者組的權重累加起來為1。將權重和累加事實相乘，以按照每個使用者在分組中的比重分配事實。

優點：

• 靈活簡化了生成報表的難度

• 借權重避免了多重計算

缺點：

橋接表的維護比較複雜，當出現一個新組合時，得先判斷橋接表中是否已存在

3.6.12.3維表與維表多對多(交叉維度)

從分析的角度來看，維度之間的多對多關係是一個很重要的概念，大多數維度都不是完全相互獨立的。

在銀行系統中，賬戶和顧客之間有直接關係，但不是一對一的關係。一個賬戶可以有一個或多個簽名確認的使用者，一個使用者也可有多個賬戶

有2種方案解決

和多值維度一樣，建立賬戶-使用者組橋接表來連線事實表

還有一種方法是利用賬戶和使用者之間的關係，如下圖

橋接表可以捕獲多對多關係，並且由於源系統中的關係是已知的，因此建立橋接表比多值維度手動構建維度表(橋接表)更容易

3.6.12.4總結

處理多值維度最好的辦法是降低事實表的粒度。這種處理方式也是維度建模的一個原則，即事實表應該建立在最細粒度上。這樣的處理，需要對事實表的事實進行分攤。

但是有些時候，事實表的粒度是不能降低的，多值維度的出現是無法避免的。如上述交叉維度，事實表與使用者維度沒有直接的關係，不能將資料粒度進行細分，即使細分的話帳戶餘額也很難分攤。這時，可以採用橋接表技術進行處理。在帳戶維度表和使用者維度表之間建立個帳戶-使用者橋接表。這個橋接表可以解決掉帳戶維度和使用者維度之間的多對多關係，也解決掉的帳戶維度表的多值維度問題。

總之，多值維度是應該儘量避免的，它給資料處理帶來了很大的麻煩。如果多值維度不能避免的話，應該建立橋接表來進行處理。

3.6.13碼錶規範

碼錶(編碼表)：

• 是一種程式碼說明表格。

• 用來幫助使用者明確無解釋資料和字元程式碼的含義。類似於資料字典

3.6.13.1碼錶註冊

disease_code	disease_name
7863	糖尿病
6575	高血壓
......

3.6.13.2碼值統一

一個疾病編碼只有一個對應的疾病名稱

3.6.14業務域

3.6.14.1主題域

主題域是對某個主題進行分析後確定的主題的邊界。

如使用者主題，日誌主題

3.6.14.2資料域

資料域是指面向業務分析，將業務過程或者維度進行抽象的集合

如訂單域，業務過程可能為：加入購物車->支付->發貨->收貨，整個業務過程的資料都屬於訂單域

3.7名詞概念

3.7.1寬表

寬表從字面意義上講就是欄位比較多的表。通常是指業務主題相關的指標、維度、屬性關聯在一起的表。

3.7.2粒度

粒度問題是設計資料倉庫的一個最重要方面。粒度是指資料倉庫的資料單位中儲存資料的細化或綜合程度的級別。細化程度越高，粒度級就越小；相反，細化程度越低，粒度級就越大。

籠統的說，粒度就是維度的組合

3.7.3退化維度

將一些常用的維度屬性直接寫到事實表中的維度操作稱為維度退化

3.7.4維度層次

維度中的一些描述屬性以層次方式或一對多的方式相互關聯，可以被理解為包含連續主從關係的屬性層次。層次的最底層代表維度中描述最低級別的詳細資訊，最高層代表最高級別的概要資訊。維度常常有多個這樣的嵌入式層次結構。

3.7.5下鑽

資料明細，粗粒度到細粒度的過程，會細化某些維度

下鑽是商業使用者分析資料的最基本的方法。下鑽僅需要在查詢上增加一個維度屬性，附加在SQL的GROUP BY語句中。屬性可以來自任何與查詢使用的事實表關聯的維度。下鑽不需要存在層次的定義或是下鑽路徑。

3.7.6上卷

資料的彙總聚合，細粒度到粗粒度的過程,會無視某些維度

3.7.8規範化

按照三正規化形成設計是事實和緯度表的方式管理資料稱為規範化

規範化常用於OLTP系統的設計

3.7.9反規範化

將維度的屬性層次合併到單個維度中的操作稱為反規範化

反規範化會產生包含全部資訊的寬表，形成資料冗餘；實現用維表的空間換取簡明性和查詢效能的效果，常用於OLAP系統的設計

3.8匯流排矩陣

3.8.1一致性維度

3.8.1.1共享維表

維表公用，所以基於這些公共維度進行的交叉探查不會存在任何問題

3.8.1.2一致性上卷

其中一個維度的屬性是另一個維度的維度屬性的子集，且兩個維度的公共維度屬性結構和內容相同

3.8.1.3交叉屬性

兩個維度具有部分相同的維度屬性

3.8.2一致性事實

3.8.3匯流排架構

四資料治理

4.1為什麼要資料治理

• 企業將獲得更乾淨、質量更高的資料，為進一步的資料活動打好基礎

• 標準化的資料資產管理方法、流程和策略，將有效提高資料運營效率

• 使資料更容易與業務建立緊密連繫，推動資料資產的變現

• 提高資料安全性，保證合規性

總體來說，資料治理能夠帶來的好處就在於，更高效地幫助企業將資料價值轉化成實際的業務價值。

4.2onedata理論

4.2.1背景

由於前期缺少規劃，隨著集團業務發展，暴露的問題越來越多，給資料治理工作帶來了很大的挑戰，在資料倉庫建設過程中，主要發現了以下幾個問題：

• 缺乏統一的標準，如：開發規範、指標口徑等。

• 缺乏統一資料質量監控，如：欄位資料不完整和不準確，資料發散等。

• 業務知識體系混亂，導致資料開發人員開發成本增加。

• 資料架構不合理，層級之間分工不明顯，資料流向混亂。

• 缺失統一維度和指標管理。

4.2.2統一規範

4.2.2.1特點

4.2.2.2模型規範

• 模型分層

• 模型資料流向

4.2.2.3主題劃分

• 面向業務：按照業務進行聚焦，降低對業務理解的難度，並能解耦複雜的業務。我們將實體關係模型進行變種處理為實體與業務過程模型。實體定義為業務過程的參與體；業務過程定義是由多個實體作用的結果，實體與業務過程都帶有自己特有的屬性。根據業務的聚合性，我們把業務進行拆分，形成了幾個核心主題。

• 面向分析：按照分析聚焦，提升資料易用性，提高資料的共享與一致性。按照分析主體物件不同及分析特徵，形成分析域主題在DWS進行應用，例如使用者分析域、訂單分析域。

4.2.2.4詞根

4.2.2.5命名規範

• 表命名

• 指標命名

4.2.3統一輸出

4.2.3.1資料資產管理

借用大資料平臺，我們實現了：

• 統一指標管理，保證了指標定義、計算口徑、資料來源的一致性。

• 統一維度管理，保證了維度定義、維度值的一致性。

• 統一維表管理，保證了維表及維表主鍵編碼的唯一性。

• 統一資料出口，實現了維度和指標元資料資訊的唯一出口，維值和指標資料的唯一出口。

4.2.4成就

4.2.4.1優化開發流程

4.2.4.2形成了資產管理體系

基於資料平臺形成的資產管理體系，如下圖所示：

4.3元資料管理

4.3.1概述

元資料通常定義為”關於資料的資料”，元資料貫穿了資料倉庫的整個生命週期，使用元資料驅動資料倉庫的開發，使資料倉庫自動化，視覺化。元資料打通了源資料、資料倉庫、資料應用，記錄資料從產生到消費的全過程。

例如我們看一部電影，電影本身就是資料，那麼元資料就是用來描述這部電影的資料。如下圖所示：

元資料主要記錄資料倉庫中模型的定義、各層級間的對映關係、監控資料倉庫的資料狀態及ETL的任務執行狀態。在資料倉庫系統中，元資料可以幫助資料倉庫管理員和開發人員非常方便地找到他們所關心的資料，用於指導其進行資料管理和開發工作，可以極大的提升工作的效率。

4.3.2元資料定義

將元資料按用途的不同分為兩類：

• 技術元資料（Technical Metadata)

• 業務元資料（Business Metadata）

4.3.2.1技術元資料

技術元資料是儲存關於資料倉庫系統技術細節的資料，是用於開發和管理資料倉庫使用的資料。常見的技術元資料有：

1.儲存元資料：

如表、欄位、分割槽等資訊。記錄了表的中英文名及表狀態。分割槽資訊、責任人資訊、對應主題，檔案大小、表型別，生命週期，許可權資訊

記錄列的欄位中英文名、欄位型別、欄位備註、是否是分割槽欄位，保密級別及許可權資訊等資訊。

2.執行元資料，

如大資料平臺上所有作業執行等資訊：類似於Hive Job日誌，包括作業型別、例項名稱、輸入輸出、SQL、執行引數、執行時間，執行引擎等。

3.資料開發平臺中資料同步、計算任務、任務排程等資訊

包括資料同步的輸入輸出表和欄位，以及同步任務本身的節點資訊：計算任務主要有輸入輸出、任務本身的節點資訊任務排程主要有任務的依賴型別、依賴關係等，以及不同型別排程任務的執行日誌等。

4.資料質量和運維相關元資料，如任務監控、運維報警、資料質量、故障等資訊，包括任務監控執行日誌、告警配置及執行日誌、故障資訊等。

4.3.2.2業務元資料

業務元資料從業務角度描述了資料倉庫中的資料，它提供了介於使用者和實際系統之間的語義層，使得不懂計算機技術的業務人員也能夠讀懂”資料倉庫中的資料。

常見的業務元資料有維度及屬性(包括維度編碼，欄位型別，建立人，建立時間，狀態等)、業務過程、指標(包含指標名稱,指標編碼，業務口徑，指標型別，責任人，建立時間，狀態，sql等)，安全等級，計算邏輯等的規範化定義，用於更好地管理和使用資料。資料應用元資料，如資料報表、資料產品等的配置和執行元資料。

4.3.3元資料管理

對於元資料管理，目前來說有三種方式可供選擇。

4.3.3.1 Excel手工錄入儲存

對於規模比較小，並且業務不大的公司，可能會用這種方式，但是這種方式太古老，且容易出錯

4.3.3.2自研系統

自研元資料管理系統或者在資料平臺開發元資料管理模組

很多公司會自研元資料管理系統或者相關模組，直接讀取hive元資料或者資料平臺配置的任務及排程元資料進行展示，相比較Excel人工匯入，會更智慧一點，但是相對於Atlas，成本更高且效果不一定有Atlas好，很多時候也需要批量匯入和手工錄入

4.3.3.3Atlas元資料管理(常用)

Atlas是一個可伸縮且功能豐富的元資料管理系統，深度對接了Hadoop大資料元件。

簡單理解就是一個跟Hadoop關係緊密的，可以用來做各類資料的元資料管理的一個軟體系統；

atlas本身從技術上來說，就是一個典型的JAVAWEB系統，其整體結構圖如下所示：

核心元件

• Core

• Integration

• Metadata source

• Applications

核心特性

• 資料分類管理

• 集中審計

• 搜尋與血緣管理

ATLAS的使用，包含兩個方面：

注入元資料資訊到atlas中（本質是：寫入元資料到atlas中）

注入方式1：通過atlas為資料系統開發好的hook來注入

注入方式2：通過atlas自帶的WEB-UI來人工填寫元資料資訊再注入

注入方式3：通過在自己的資料系統中呼叫atlas對外暴露的api，來靈活注入

使用atlas中的元資料資訊來為我們服務（本質是：從atlas中讀、改元資料）

方式1：通過atlas自帶的WEB-UI前端系統來檢視、修改元資料

方式2：通過呼叫atlas對外暴露的api，來開發自己的管理系統

4.3.4元資料價值

元資料有重要的應用價值，是資料管理、資料內容、資料應用的基礎，在資料管理方面為集團資料提供在計算、儲存、成本、質量、安全、模型等治理領域上的資料支援。例如在計算上可以利用元資料查詢超長執行節點，對這些節點進行專項治理，保障基線產出時間。在資料內容方面為集團資料進行資料域、資料主題、業務屬性等的提取和分析提供資料素材。例如可以利用元資料構建知識圖譜，給資料打標籤，清楚地知道現在有哪些資料。在資料應用方面打通產品及應用鏈路，保障產品資料準確、及時產出。例如打通DP和應用資料，明確資料產等級，更有效地保障產品資料。

4.3.5元資料應用

資料的真正價值在於資料驅動決策，通過資料指導運營。通過資料驅動的方法，我們能夠判斷趨勢 ，從而展開有效行動，幫助自己發現問題，推動創新或解決方案的產生。這就是資料化運營。同樣，對於元資料，可以用於指導資料相關人員進行日常工作，實現資料化“運營”。比如對於資料使用者，可以通過元資料讓其快速找到所需要的資料；對於ETL工程師，可以通過元資料指導其進行模型設計、任務優化和任務下線等各種日常ETL工作；對於運維工程師，可以通過元資料指導其進行整個叢集的儲存、計算和系統優化等運維工作。

4.4主資料管理

4.5資料質量管理

4.5.1資料質量基本概念

資料質量管理（Data Quality Management），是指對資料從計劃、獲取、儲存、共享、維護、應用、消亡生命週期的每個階段裡可能引發的各類資料質量問題，進行識別、度量、監控、預警等一系列管理活動，並通過改善和提高組織的管理水平使得資料質量獲得進一步提高

資料質量管理不是一時的資料治理手段，而是迴圈的管理過程。其終極目標是通過可靠的資料，提升資料在使用中的價值，並最終為企業贏得經濟效益

4.5.2影響因素

資料問題的來源可能產生於從資料來源頭到資料儲存介質的各個環節。在資料採集階段，資料的真實性、準確性、完整性、時效性都會影響資料質量。除此之外，資料的加工、儲存過程都有可能涉及對原始資料的修改，從而引發資料的質量問題。所以，技術、流程、管理等多方面的因素都有可能會影響到資料質量。

在企業中，隨著企業業務的增長，資料也是一個增量積累的過程。隨著資料型別、資料來源的不斷豐富以及資料數量的快速增長，企業在資料管理工作和資料流程中面臨越來越多的資料質量問題。而且資料質量的管理並沒有被企業重視起來，其根本原因還是ROI並沒有那麼明顯。資料質量管理相對來說成本比較高。因為它涉及到企業資料標準的制定、規範的落地、生命週期的管理等多個環節。從收益上來說，資料質量的效益和結果並不是十分明顯，大部分企業不會把資料質量作為KPI。在企業的不同系統中，業務領域的關鍵指標不一致，資料無法共享導致出現數據孤島，大量資料無法關聯，並且有明顯的資料冗餘等問題，還有資料的維護需要投入大量的人員、時間、軟硬體成本。所以資料的質量管理往往被會邊緣化甚至趨向於無。在此附上資料的生命週期圖，包括各環節的資料流轉和資料處理。

4.5.3評估維度

l完整性

資料完整性問題包含資料條目不完整，資料屬性不完整等

l一致性

多源資料的資料模型不一致，如命名不一致，資料編碼不一致，含義不一致，生命週期不一致等

l準確性

準確性也叫可靠性，不可靠的資料可能會導致嚴重的問題，會造成有缺陷的方法和糟糕的決策

l唯一性

用於識別和度量重複資料，冗餘資料，重複資料是導致業務無法協同，流程無法追溯的重要因素，也是資料治理需要解決的最基本的資料問題

l關聯性

資料關聯性問題是指存在資料關聯的資料關係缺失或錯誤，例如：函式關係、相關係數、主外來鍵關係、索引關係等。存在資料關聯性問題，會直接影響資料分析的結果，進而影響管理決策。

l真實性

資料必須真實準確的反映客觀的實體存在或真實的業務，真實可靠的 原始統計資料是企業統計工作的靈魂，是一切管理工作的基礎，是經營者進行正確經營決策必不可少的第一手 資料。

l及時性

資料的及時性(In-time)是指能否在需要的時候獲到資料，資料的及時性與企業的資料處理速度及效率有直接的關係，是影響業務處理和管理效率的關鍵指標。

l邏輯檢查

不同表字段之間可能會有邏輯關聯，需要稽核

l離群值檢查

部分資料可能會偏離其他資料，比如同一個商品金額大家都是100元，而有一條資料是1W

l自定義規則

由需求方自定義相關規則

l波動稽核

與上週環比稽核波動情況

l強弱規則

每個規則的權重應該是不一樣的，需要配置優先順序，這對後續的告警方式是有幫助的

我們最終的目的是希望做到頁面可配置

單表通用配置

質控規則	規則定義
唯一性	資料不能重複

多表自定義規則配置(自定義業務規則)

規則名稱	規則內容	責任人	訂閱人	操作

4.5.4實施流程

4.5.4.1事前定義質量規則

1. 梳理表，欄位等資訊

2. 確定資產等級

3. 制定檢驗規則

4.5.4.2事中監控資料質量

1. 在資料抽取過程中，可以對資料進行資料量稽核及唯一性，非空性稽核

2. ETL過程對髒資料進行清洗，保證資料質量

3. 指標計算過程中，可以對指標進行波動值稽核，保證指標變化在合理範圍內

4. 抽取結束後進行資料量稽核

以上如果有異常都需要郵件簡訊報警，對應負責人根據優先順序判斷是不是需要及時處理

4.5.4.3事後分析和問題跟蹤

• 每週定時跑一次程式，對全域性資料進行質量稽核控制，如唯一性，非空性等

• 對於程式跑出來的資料：資料質量概覽在資料質量管理系統查詢

• 資料質量明細資料在資料質量管理系統查詢

• 根據異常資料統計出來的各種資料質量報表也可以在資料質量管理系統查詢，包括表覆蓋率，歷史趨勢，綜合分析，排名分析等(質量報告支援匯出為word，pdf，excel)對異常進行評估、嚴重程度、影響範圍、問題分類等

• 可以訂閱自己比較關心的主題，表或者規則，郵件只會傳送訂閱內容

• 對於打分比較低的表或者業務，可以反推業務方進行整改

4.5.4.4重大問題告警及整改

1.警告郵件簡訊通知

2.資料整改問題跟蹤處理，故障review，規定時間內處理完成

4.5.5報表展示(部分)

4.5.6總結

資料質量管理貫穿資料生命週期的全過程，覆蓋質量評估、資料監控、資料探查、資料清洗、資料診斷等方面。資料來源在不斷增多，資料量在不斷加大，新需求推動的新技術也不斷誕生，這些都對大資料下的資料質量管理帶來了困難和挑戰。因此，資料質量管理要形成完善的體系，建立持續改進的流程和良性機制，持續監控各系統資料質量波動情況及資料質量規則分析，適時升級資料質量監控的手段和方法，確保持續掌握系統資料質量狀況，最終達到資料質量的平穩狀態，為業務系統提供良好的資料保障。

4.6資料安全

4.6.1背景

江湖傳言：資料玩的溜，牢飯吃的久？眾看官是不是聞風喪膽？

每個資料開發者都應該非常深刻的明白資料安全意味著什麼。簡直就是一根紅線，絲毫不能越過。

近幾年，國家對個人隱私資料保護越來越強，企業在使用資料的時候也非常注重資料安全，那麼，我們應該怎麼做，才能保護好自己，保護好公司的資料資產呢？

4.6.2資料脫敏

資料脫敏是保證資料安全的最基本的手段，脫敏方法有很多，最常用的就是使用可逆加密演算法，對數倉每一個敏感欄位都需要加密。

4.6.3資料許可權控制

需要開發一套完善的資料許可權控制體系，最好是能做到欄位級別，有些表無關人員是不需要查詢的，所以不需要任何許可權，有些表部分人需要查詢，除資料工程師外，其他人均需要通過OA流程進行許可權審批，需要檢視哪些表的哪些欄位，為什麼需要這個許可權等資訊都需要審批存檔。

4.6.4程式檢查

有些欄位明顯是敏感資料，比如身份證號，手機號等資訊，但是業務庫並沒有加密，而且從欄位名來看，也很難看出是敏感資訊，所以抽取到資料倉庫後需要使用程式去統一檢測是否有敏感資料，然後根據檢測結果讓對應負責人去確認是否真的是敏感欄位，是否需要加密等。

4.6.5流程化操作

流程化主要是體現在公司內部取數或者外部專案資料同步，取數的時候如果資料量很大或者包含了敏感資訊，是需要提OA 審批流程的，讓大家知道誰要取這些資料，取這些資料的意義在哪，出了問題可以回溯，快速定位到責任人。開發外部專案的時候，不同公司之間的資料同步，是需要由甲方出具同意書的，否則的話風險太大。

4.6.6敏感SQL實時審查及操作日誌分析

及時發現敏感sql的執行並詢問責任人，事後分析操作日誌，查出有問題的操作。

4.6.7部門重視資料安全

把資料安全當做一項KPI去考核，讓大家積極的參與到資料安全管理當中去。

4.6.8對自己負責

不要為了一時的利益，洩露公司資料資產，輕則行業名聲敗壞，重則要負法律責任，一定要三思而後行！

4.7資料血緣

目前來說我所瞭解的基本都是需要手工維護的，有些公司維護在excel中，有些公司維護在web系統中

4.7.1表血緣

4.7.2欄位血緣

4.7.3任務血緣

五指標體系建設

5.1拆解業務模組

5.1.1拆分準備

• 產品形態

• 業務邏輯

• 業務流程圖

5.1.2拆分方法

• 使用者行為法

• 業務拆分法

• 指標推進法

5.2定義核心業務指標

5.2.1定義核心指標標準

• 反映使用者體驗和產品核心價值

• 反映使用者的活躍程度

• 能夠反映公司發展的狀態

• 容易被團隊理解和交流

• 具有先導性

• 具有可操作性

5.2.2參考產品的生命週期

• 引入期：核心指標是使用者留存

• 成長期：核心是使用者轉化情況

• 成熟期：核心指標是營收

• 衰退期

5.3梳理常見指標

5.3.1流量類指標

• 獨立訪客數

• 頁面訪客數

• 日活

• 周活

• 月活

• 跳出率

5.3.2訂單指標

• 訂單量

• 成交金額

• 退單率

5.3.3營收指標

• 銷售金額

• 客單價

5.3.4考核指標

• 首回時間

• 首回時長

• 回覆平均時長

• 好評率

5.3.5整體指標

• 總銷售額

• 淨利潤

5.4搭建指標體系

六排程

6.1責任人

6.2輸出表名

6.3排程週期

6.4加工方式

6.5任務名稱

6.6優先順序

6.7依賴屬性

6.8版型資訊

七值班安排

7.1排班資訊

7.2值班週期

7.3任務延遲處理方式

7.4任務報錯處理方式

7.5告警機制

7.6責任劃分

7.7起夜率考核

7.8重要任務最晚產出時間列表

八技術棧

8.1總覽

8.2日誌採集

• Logstash

• flume

• logagent

8.3業務資料抽取

• Sqoop

• Datax

• Canal

• flink

8.4離線資料處理

• Sparksql

• hivesql

• mapreduce

8.5實時資料處理

• Sparkstreaming

• flink

8.6排程系統

• Airflow

• azkaban

• oozie

8.7資源管理

• yarn

8.8訊息中介軟體

• Kafka

8.9程式語言

• Java

• python

• scala

8.10資料儲存

• Hdfs

• hbase

• elasticsearch

• redis

• mysql

8.11 OLAP

• Druid

• Kylin

8.12報表展示

• Kibana

• PowerBI

• tableau

九實時數倉

Kafka+flink+clickhouse

敬請期待

word文件目錄長圖(此版本出的比較匆忙，是初版，之後會完善)：