只有數據模型將數據有序的組織和存儲起來之后，大數據才能得到高性能、低成本、高效率、高質量的使用。

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

數據關系條理化：源系統間存在復雜的數據關系，比如客戶信息同時存在于核心系統、信貸系統、理財系統、資金系統，取數時該如何決策呢？數據倉庫會對相同主題的數據進行統一建模，把復雜的數據關系梳理成條理清晰的數據模型，使用時就可避免上述問題了。

2）數據血緣追蹤：簡單來講可以這樣理解，我們最終給業務誠信的是一能直接使用的張業務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地定位到問題，并清楚它的危害范圍。
3）數據復用，減少重復開發：規范數據分層，開發一些通用的中間層數據，能夠減少極大的重復計算。數據的逐層加工原則，下層包含了上層數據加工所需要的全量數據，這樣的加工方式避免了每個數據開發人員都重新從源系統抽取數據進行加工。通過匯總層的引人，避免了下游用戶邏輯的重復計算， 節省了用戶的開發時間和精力，同時也節省了計算和存儲。極大地減少不必要的數據冗余，也能實現計算結果復用，極大地降低存儲和計算成本。
4）把復雜問題簡單化。講一個復雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便于維護數據的準確性，當數據出現問題之后，可以不用修復所有的數據，只需要從有問題的步驟開始修復。

5）屏蔽原始數據的(影響) ，屏蔽業務的影響。業務或系統發生變化時，不必改一次業務就需要重新接入數據。提高數據穩定性和連續性。

屏蔽源頭業務系統的復雜性：源頭系統可能極為繁雜，而且表命名、字段命名 、字段含義等可能五花八門，通過 DW 層來規范和屏蔽所有這些復雜性，保證下游數據用戶使用數據的便捷和規范。如果源頭系統業務發生變更，相關的變更由 DW 層來處理，對下游用戶透明，無須改動下游用戶的代碼和邏輯。數據倉庫的可維護性：分層的設計使得某一層的問題只在該層得到解決，無須更改下一層的代碼和邏輯。大數據系統需要數據模型方法來幫助更好地組織和存儲數據，以便在性能、成本、效率和質量之間取得最佳平衡！ETL(extractiontransformation loading)負責將分散的、異構數據源中的數據抽取到臨時中間層后進行清洗、轉換、集成，最后加載到數據倉庫或數據集市中。ETL 是實施數據倉庫的核心和靈魂，ETL規則的設計和實施約占整個數據倉庫搭建工作量的 60%～80%。

數據抽取（extraction），包括初始化數據裝載和數據刷新：初始化數據裝載主要關注的是如何建立維表、事實表，并把相應的數據放到這些數據表中；而數據刷新關注的是當源數據發生變化時如何對數據倉庫中的相應數據進行追加和更新等維護(比如可以創建定時任務，或者觸發器的形式進行數據的定時刷新)。

數據清洗（cleaning）主要是針對源數據庫中出現的二義性、重復、不完整、違反業務或邏輯規則等問題的數據進行統一的處理。即清洗掉不符合業務或者沒用的的數據。比如通過編寫hive或者MR清洗字段中長度不符合要求的數據。

數據轉換（transformation）主要是為了將數據清洗后的數據轉換成數據倉庫所需要的數據：來源于不同源系統的同一數據字段的數據字典或者數據格式可能不一樣(比如A表中叫id,B表中叫ids)，在數據倉庫中需要給它們提供統一的數據字典和格式，對數據內容進行歸一化；另一方面，數據倉庫所需要的某些字段的內容可能是源系統所不具備的，而是需要根據源系統中多個字段的內容共同確定。

數據加載（loading）是將最后上面處理完的數據導入到對應的存儲空間里（hbase，mysql等）以方便給數據集市提供，進而可視化。 一般大公司為了數據安全和操作方便，都是自己封裝的數據平臺和任務調度平臺，底層封裝了大數據集群比如hadoop集群，spark集群，sqoop,hive,zookeepr,hbase等只提供web界面，并且對于不同員工加以不同權限，然后對集群進行不同的操作和調用。以數據倉庫為例，將數據倉庫分為邏輯上的幾個層次。這樣對于不同層次的數據操作，創建不同層次的任務，可以放到不同層次的任務流中進行執行（大公司一個集群通常每天的定時任務有幾千個等待執行，甚至上萬個，所以劃分不同層次的任務流，不同層次的任務放到對應的任務流中進行執行，會更加方便管理和維護）。數倉層內部的劃分不是為了分層而分層，分層是為了解決 ETL 任務及工作流的組織、數據的流向、讀寫權限的控制、不同需求的滿足等各類問題。業界較為通行的做法將整個數倉層又劃分成了 DWD、DWT、DWS、DIM、DM等很多層。然而我們卻始終說不清楚這幾層之間清晰的界限是什么，或者說我們能說清楚它們之間的界限，復雜的業務場景卻令我們無法真正落地執行。所以數據分層這塊一般來說三層是最基礎的，至于DW層如何進行切分，是根據具體的業務需求和公司場景自己去定義。

數據中臺包含的內容很多，對應到具體工作中的話，它可以包含下面的這些內容：

系統架構：以Hadoop、Spark等組件為中心的架構體系

數據架構：頂層設計，主題域劃分，分層設計，ODS-DW-ADS

數據建模：維度建模，業務過程-確定粒度-維度-事實表

數據管理：資產管理，元數據管理、質量管理、主數據管理、數據標準、數據安全管理

輔助系統：調度系統、ETL系統、監控系統

數據服務：數據門戶、機器學習數據挖掘、數據查詢、分析、報表系統、可視化系統、數據交換分享下載
數據倉庫標準上可以分為四層。但是注意這種劃分和命名不是唯一的，一般數倉都是四層，但是不同公司可能叫法不同。但是核心的理念都是從四層數據模型而來。

數據引入層（ODS，Operational Data Store，又稱數據基礎層）：將原始數據幾乎無處理地存放在數據倉庫系統中，結構上與源系統基本保持一致，是數據倉庫的數據準備區。這一層的主要職責是將基礎數據同步、存儲。一般來說 ODS 層的數據和源系統的數據是同構的，主要目的是簡化后續數據加工處理的工作。從數據粒度上來說 ODS 層的數據粒度是細的。ODS 層的表通常包括兩類，一個用于存儲當前需要加載的數據，一個用于存儲處理完后的歷史數據。歷史數據一般保存 3-6 個月后需要清除，以節省空間。但不同的項目要區別對待，如果源系統的數據量不大，可以保留更長的時間，甚至全量保存。

注意：

在這層，理應不是簡單的數據接入，而是要考慮一定的數據清洗，比如異常字段的處理、字段命名規范化、時間字段的統一等，一般這些很容易會被忽略，但是卻至關重要。特別是后期我們做各種特征自動生成的時候，會十分有用。

有的公司ODS層不會做太多數據過濾處理,會放到DWD層來處理。有的公司會在一開始時就在ODS層做數據相對精細化的過濾.這個并沒有明確規定,看每個公司自己的想法和技術規范。

數據來源區分

數據按照時間分區存儲,一般是按照天,也有公司使用年、月、日三級分區做存儲的。

進行最基本的數據處理,如格式錯誤的丟棄,關鍵信息丟失的過濾掉等等。

數據實時離線

離線方面：每日定時任務型：跑批任務，業務庫，比如我們典型的日計算任務，這里經常會使用 Sqoop 來抽取，比如我們每天定時抽取一次。每天凌晨算前一天的數據，早上起來看報表。這種任務經常使用 Hive、Spark 來計算，最終結果寫入 Hive、Hbase、Mysql、Es 或者 Redis 中。

實時數據：日志埋點數據或者業務庫，這部分主要是各種實時的系統使用，比如我們的實時推薦、實時用戶畫像，一般我們會用 Spark Streaming、Flink 來計算，最后會落入 Es、Hbase 或者 Redis 中。數據源是業務數據庫，可以考慮用 Canal 監聽 Mysql 的 Binlog，實時接入即可，然后也是收集到消息隊列中，最終再由 Camus 拉取到 HDFS。

1）數據主要來源：

數據源是業務數據庫，公司所有的系統產生的數據

是通過在客戶端埋點上報，收集用戶的行為日志，以及一些后端日志的日志類型數據源。對于埋點行為日志來說，一般會經過一個這樣的流程，首先數據會上報到 Nginx 然后經過 Flume 收集，然后存儲到 Kafka 這樣的消息隊列，然后再由實時或者離線的一些拉取的任務，拉取到我們的離線數據倉庫 HDFS

外部數據（包括合作數據以及爬蟲獲得的數據），將所采集的數據匯總到一起

2）數據存儲策略（增量、全量）

實際應用中，可以選擇采用增量、全量存儲或拉鏈存儲的方式。

增量存儲：

為了滿足歷史數據分析需求，您可以在ODS層表中添加時間維度作為分區字段。以天為單位的增量存儲，以業務日期作為分區，每個分區存放日增量的業務數據。

說明：交易、日志等事務性較強的ODS表適合增量存儲方式。這類表數據量較大，采用全量存儲的方式存儲成本壓力大。此外，這類表的下游應用對于歷史全量數據訪問的需求較小（此類需求可通過數據倉庫后續匯總后得到）。例如，日志類ODS表沒有數據更新的業務過程，因此所有增量分區UNION在一起就是一份全量數據。

>>舉例如下：

1月1日，用戶A訪問了A公司電商店鋪B，A公司電商日志產生一條記錄t1。1月2日，用戶A又訪問了A公司電商店鋪C，A公司電商日志產生一條記錄t2。采用增量存儲方式，t1將存儲在1月1日這個分區中，t2將存儲在1月2日這個分區中。

1月1日，用戶A在A公司電商網購買了B商品，交易日志將生成一條記錄t1。1月2日，用戶A又將B商品退貨了，交易日志將更新t1記錄。采用增量存儲方式，初始購買的t1記錄將存儲在1月1日這個分區中，更新后的t1將存儲在1月2日這個分區中。

全量存儲：

以天為單位的全量存儲，以業務日期作為分區，每個分區存放截止到業務日期為止的全量業務數據。

>>舉例如下：

例如，1月1日，賣家A在A公司電商網發布了B、C兩個商品，前端商品表將生成兩條記錄t1、t2。1月2日，賣家A將B商品下架了，同時又發布了商品D，前端商品表將更新記錄t1，同時新生成記錄t3。采用全量存儲方式， 在1月1日這個分區中存儲t1和t2兩條記錄，在1月2日這個分區中存儲更新后的t1以及t2、t3記錄。

說明：對于小數據量的緩慢變化維度數據，例如商品類目，可直接使用全量存儲。

拉鏈存儲：

拉鏈存儲通過新增兩個時間戳字段（start_dt和end_dt），將所有以天為粒度的變更數據都記錄下來，通常分區字段也是這兩個時間戳字段。

>>舉例如下：

方案

概念：又稱為接口層(stage)，用于存儲每天的增量數據和變更數據

數據生成方式：直接從kafka接收源數據，需要業務表每天生成update,delete,inseret數據，只生成insert數據的業務表，數據直接入明細層。

討論方案：只把canal日志直接入緩沖層，如果其它有拉鏈數據的業務，也入緩沖層。

日志存儲方式：使用impala外表，parquet文件格式，方便需要MR處理的數據讀取。

日志刪除方式：長久存儲，可只存儲最近幾天的數據。討論方案：直接長久存儲。

表schema：一般按天創建分區，partitioned by 一般都是按照天進行存放。

庫與表命名。庫名：ods,表名：初步考慮格式為ods日期業務表名,待定。 數據倉庫層(DW)層：數據倉庫層是我們在做數據倉庫時要核心設計的一層，本層將從 ODS 層中獲得的數據按照主題建立各種數據模型，每一個主題對應一個宏觀的分析領域，數據倉庫層排除對決策無用的數據，提供特定主題的簡明視圖。在DW層會保存BI系統中所有的歷史數據，例如保存10年的數據。DW層又細分為維度層（DIM）、明細數據層（DWD）和匯總數據層（DWS），采用維度模型方法作為理論基礎， 可以定義維度模型主鍵與事實模型中外鍵關系，減少數據冗余，也提高明細數據表的易用性。在匯總數據層同樣可以關聯復用統計粒度中的維度，采取更多的寬表化手段構建公共指標數據層，提升公共指標的復用性，減少重復加工。

維度層（DIM，Dimension）：以維度作為建模驅動，基于每個維度的業務含義，通過添加維度屬性、關聯維度等定義計算邏輯，完成屬性定義的過程并建立一致的數據分析維表。為了避免在維度模型中冗余關聯維度的屬性，基于雪花模型構建維度表。

明細數據層（DWD，Data Warehouse Detail）：以業務過程作為建模驅動，基于每個具體的業務過程特點，構建最細粒度的明細事實表。可將某些重要屬性字段做適當冗余，也即寬表化處理。

匯總數據層（DWS，Data Warehouse Summary）：以分析的主題對象作為建模驅動，基于上層的應用和產品的指標需求，構建公共粒度的匯總指標表。以寬表化手段物理化模型，構建命名規范、口徑一致的統計指標，為上層提供公共指標，建立匯總寬表、明細事實表。 1）公共維度層（DIM，Dimension）公共維度匯總層（DIM）主要由維度表（維表）構成。維度是邏輯概念，是衡量和觀察業務的角度。維表是根據維度及其屬性將數據平臺上構建的表物理化的表，采用寬表設計的原則。因此，構建公共維度匯總層（DIM）首先需要定義維度。

高基數維度數據：一般是用戶資料表、商品資料表類似的資料表。數據量可能是千萬級或者上億級別。

低基數維度數據：一般是配置表，比如枚舉值對應的中文含義，或者日期維表。數據量可能是個位數或者幾千幾萬。 完成維度定義后，您就可以對維度進行補充，進而生成維表了。

維表的設計需要注意：

建議維表單表信息不超過1000萬條。

維表與其他表進行Join時，建議您使用Map Join。

避免過于頻繁的更新維表的數據。

在設計維表時，您需要從下列方面進行考慮：

維表中數據的穩定性。例如A公司電商會員通常不會出現消亡，但會員數據可能在任何時候更新，此時要考慮創建單個分區存儲全量數據。如果存在不會更新的記錄，您可能需要分別創建歷史表與日常表。日常表用于存放當前有效的記錄，保持表的數據量不會膨脹；歷史表根據消亡時間插入對應分區，使用單個分區存放分區對應時間的消亡記錄。

是否需要垂直拆分。如果一個維表存在大量屬性不被使用，或由于承載過多屬性字段導致查詢變慢，則需考慮對字段進行拆分，創建多個維表。

是否需要水平拆分。如果記錄之間有明顯的界限，可以考慮拆成多個表或設計成多級分區。

核心的維表產出時間通常有嚴格的要求。

設計維表的主要步驟如下：

完成維度的初步定義，并保證維度的一致性。

確定主維表（中心事實表，本教程中采用星型模型）。此處的主維表通常是數據引入層（ODS）表，直接與業務系統同步。例如，s_auction是與前臺商品中心系統同步的商品表，此表即是主維表。

確定相關維表。數據倉庫是業務源系統的數據整合，不同業務系統或者同一業務系統中的表之間存在關聯性。根據對業務的梳理，確定哪些表和主維表存在關聯關系，并選擇其中的某些表用于生成維度屬性。以商品維度為例，根據對業務邏輯的梳理，可以得到商品與類目、賣家、店鋪等維度存在關聯關系。

確定維度屬性，主要包括兩個階段。第一個階段是從主維表中選擇維度屬性或生成新的維度屬性；第二個階段是從相關維表中選擇維度屬性或生成新的維度屬性。以商品維度為例，從主維表（s_auction）和類目 、賣家、店鋪等相關維表中選擇維度屬性或生成新的維度屬性。

公共維度匯總層（DIM）維表規范

命名規范：dim_{業務板塊名稱/pub}_{維度定義}[_{自定義命名標簽}]

所謂pub是與具體業務板塊無關或各個業務板塊都可公用的維度，如時間維度。

例如：公共區域維表dim_pub_area，商品維表dim_asale_itm 2）DWD（data warehouse detail）數據明細層，明細粒度事實層

DWD（Data Warehouse Detail?明細粒度事實層），是業務層與數據倉庫的隔離層，這一層主要解決一些數據質量問題和數據的完整度問題。以業務過程作為建模驅動，基于每個具體的業務過程特點，構建最細粒度的明細層事實表。可以結合企業的數據使用特點，將明細事實表的某些重要維度屬性字段做適當冗余，即寬表化處理。明細粒度事實層的表通常也被稱為邏輯事實表。該層一般保持和ODS層一樣的數據粒度，并且提供一定的數據質量保證，在ODS的基礎上對數據進行加工處理，提供更干凈的數據。同時，為了提高數據明細層的易用性，該層會采用一些維度退化手法，當一個維度沒有數據倉庫需要的任何數據時，就可以退化維度，將維度退化至事實表中，減少事實表和維表的關聯。例如：訂單id,這種量級很大的維度，沒必要用一張維度表來進行存儲，而我們一般在進行數據分析時訂單id又非常重要，所以我們將訂單id冗余在事實表中，這種維度就是退化維度。
DWD層做了哪些事？

①數據清洗過濾

去除廢棄字段,去除格式錯誤的信息

去除丟失了關鍵字段的信息

過濾核心字段無意義的數據，比如訂單表中訂單id為null，支付表中支付id為空

對手機號、身份證號等敏感數據脫敏

去除不含時間信息的數據(這個看公司具體業務,但一般數據中都會帶上時間戳,這樣方便后續處理時,進行時間維度上信息分析處理和提取)

有些公司還會在這一層將數據打平,不過這具體要看業務需求.這是因為kylin適合處理展平后數據,不適合處理嵌套的表數據信息

有些公司還會將數據session做切割,這個一般是app的日志數據,其他業務場景不一定適合.這是因為app有進入后臺模式,例如用戶上午打開app用了10分鐘,然后app切入后臺,晚上再打開,這時候session還是一個,實際上應該做切割才對.(也有公司會記錄app進入后臺,再度進入前臺的記錄,這樣來做session切割)

數據規范化,因為大數據處理的數據可能來資源公司不同部門,不同項目,不同客戶端,這時候可能相同業務數據字段,數據類型,空值等都不一樣,這時候需要在DWD層做抹平.否則后續處理使用時,會造成很大的困擾

如boolean,有使用0 1標識,也有使用true false標識的

如字符串空值,有使用"",也有使用null,的,統一為null即可

如日期格式,這種就差異性更大,需要根據實際業務數據決定,不過一般都是格式化為YYYY-MM-dd HH:mm:ss 這類標準格式

清洗掉多少數據算合理：1萬條數據清洗掉1條。

②數據映射,轉換

將GPS經緯度轉換為省市區詳細地址。業界常見GPS快速查詢一般將地理位置知識庫使用geohash映射,然后將需要比對的GPS轉換為geohash后跟知識庫中geohash比對,查找出地理位置信息當然,也有公司使用open api,如高德地圖,百度地圖的api進行GPS和地理位置信息映射,但這個達到一定次數需要花錢,所以大家都懂的

會將IP地址也轉換為省市區詳細地址。這個有很多快速查找庫,不過基本原理都是二分查找,因為ip地址可以轉換為長整數.典型的如ip2region庫

將時間轉換為年,月,日甚至周,季度維度信息

明細粒度事實表設計原則：

一個明細粒度事實表僅和一個維度關聯。

盡可能包含所有與業務過程相關的事實 。

只選擇與業務過程相關的事實。

分解不可加性事實為可加的組件。

在選擇維度和事實之前必須先聲明粒度。

在同一個事實表中不能有多種不同粒度的事實。

事實的單位要保持一致。粒度

謹慎處理Null值。

使用退化維度提高事實表的易用性。

明細粒度事實表整體設計流程

方案

概念：是數據倉庫的細節數據層，是對STAGE層數據進行沉淀，減少了抽取的復雜性，同時ODS/DWD的信息模型組織主要遵循企業業務事務處理的形式，將各個專業數據進行集中，明細層跟stage層的粒度一致，屬于分析的公共資源

數據生成方式：部分數據直接來自kafka，部分數據為接口層數據與歷史數據合成。canal日志合成數據的方式待研究。

討論方案：canal數據的合成方式為：每天把明細層的前天全量數據和昨天新數據合成一個新的數據表，覆蓋舊表。同時使用歷史鏡像，按周/按月/按年 存儲一個歷史鏡像到新表。

日志存儲方式：直接數據使用impala外表，parquet文件格式，canal合成數據為二次生成數據，建議使用內表，下面幾層都是從impala生成的數據，建議都用內表+靜態/動態分區。

日志刪除方式：長久存儲。

表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。

庫與表命名。庫名：ods,表名：初步考慮格式為ods日期業務表名,待定。

舊數據更新方式：直接覆蓋

明細粒度事實層（DWD）規范

命名規范為：dwd_{業務板塊/pub}_{數據域縮寫}_{業務過程縮寫}[_{自定義表命名標簽縮寫}] _{單分區增量全量標識}

pub表示數據包括多個業務板塊的數據。單分區增量全量標識通常為：i表示增量，f表示全量。

例如：dwd_asale_trd_ordcrt_trip_di（A電商公司航旅機票訂單下單事實表，日刷新增量），dwd_asale_itm_item_df（A電商商品快照事實表，日刷新全量）。 3）DWS（ data warehouse service）數據服務層，匯總層寬表

基于 DWD 明細數據層，我們會按照一些分析場景、分析實體等去組織我們的數據，組織成一些分主題的匯總數據層 DWS。明細粒度 ==> 匯總粒度DWS層（數據匯總層）寬表，面向主題的匯總，維度相對來說比較少，DWS是根據DWD層基礎數據按各個維度ID進行粗粒度匯總聚合，如按交易來源，交易類型進行匯合。整合匯總成分析某一個主題域的服務數據，一般是寬表。以DWD為基礎，按天進行輕度匯總。統計各個主題對象的當天行為，（例如，購買行為，統計商品復購率）。該層數據表會相對比較少，大多都是寬表(一張表會涵蓋比較多的業務內容，表中的字段較多)。按照主題劃分，如訂單、用戶等，生成字段比較多的寬表，用于提供后續的業務查詢，OLAP分析，數據分發等。融合多個中間層數據，基于主題形成事實表，比如用戶事實表、渠道事實表、終端事實表、資產事實表等等，事實表一般是寬表，在本層上實現企業級數據的一致性。

DWS層做了哪些事？

DWS將DWD層的數據按主題進行匯總，按照主題放到一個表中，

比如用戶主題下會將用戶注冊信息、用戶收貨地址、用戶的征信數據放到同一張表中，而這些在DWD層是對應多張表的,按照業務劃分，如流量、訂單、用戶等，生成字段比較多的寬表。

方案

概念：又稱數據集市或寬表。按照業務劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用于提供后續的業務查詢，OLAP分析，數據分發等。

數據生成方式：由輕度匯總層和明細層數據計算生成。

日志存儲方式：使用impala內表，parquet文件格式。

表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。

庫與表命名。庫名：dws, 表名：初步考慮格式為：dws日期業務表名,待定。

舊數據更新方式：直接覆蓋

聚集是指針對原始明細粒度的數據進行匯總。DWS公共匯總層是面向分析對象的主題聚集建模。在本教程中，最終的分析目標為：最近一天某個類目（例如：廚具）商品在各省的銷售總額、該類目Top10銷售額商品名稱、各省用戶購買力分布。因此，我們可以以最終交易成功的商品、類目、買家等角度對最近一天的數據進行匯總。

注意：

聚集是不跨越事實的。聚集是針對原始星形模型進行的匯總。為獲取和查詢與原始模型一致的結果，聚集的維度和度量必須與原始模型保持一致，因此聚集是不跨越事實的。

聚集會帶來查詢性能的提升，但聚集也會增加ETL維護的難度。當子類目對應的一級類目發生變更時，先前存在的、已經被匯總到聚集表中的數據需要被重新調整。

此外，進行DWS層設計時還需遵循以下原則：

數據公用性：需考慮匯總的聚集是否可以提供給第三方使用。您可以判斷，基于某個維度的聚集是否經常用于數據分析中。如果答案是肯定的，就有必要把明細數據經過匯總沉淀到聚集表中。

不跨數據域。數據域是在較高層次上對數據進行分類聚集的抽象。數據域通常以業務過程進行分類，例如交易統一劃到交易域下， 商品的新增、修改放到商品域下。

區分統計周期。在表的命名上要能說明數據的統計周期，例如_1d表示最近1天，td表示截至當天，nd表示最近N天。

公共匯總事實表規范

命名規范：dws_{業務板塊縮寫/pub}_{數據域縮寫}_{數據粒度縮寫}[_{自定義表命名標簽縮寫}]_{統計時間周期范圍縮寫}。

關于統計實際周期范圍縮寫，缺省情況下，離線計算應該包括最近一天（_1d），最近N天（_nd）和歷史截至當天（_td）三個表。如果出現_nd的表字段過多需要拆分時，只允許以一個統計周期單元作為原子拆分。即一個統計周期拆分一個表，例如最近7天（_1w）拆分一個表。不允許拆分出來的一個表存儲多個統計周期。

對于小時表（無論是天刷新還是小時刷新），都用_hh來表示。

對于分鐘表（無論是天刷新還是小時刷新），都用_mm來表示。

舉例如下：

dws_asale_trd_byr_subpay_1d（買家粒度交易分階段付款一日匯總事實表）

dws_asale_trd_byr_subpay_td（買家粒度分階段付款截至當日匯總表）

dws_asale_trd_byr_cod_nd（買家粒度貨到付款交易匯總事實表）

dws_asale_itm_slr_td（賣家粒度商品截至當日存量匯總表）

dws_asale_itm_slr_hh（賣家粒度商品小時匯總表）---維度為小時

dws_asale_itm_slr_mm（賣家粒度商品分鐘匯總表）---維度為分鐘

數據應用層（ADS，Application Data Store）：存放數據產品個性化的統計指標數據，報表數據。主要是提供給數據產品和數據分析使用的數據，通常根據業務需求，劃分成流量、訂單、用戶等，生成字段比較多的寬表，用于提供后續的業務查詢，OLAP分析，數據分發等。從數據粒度來說，這層的數據是匯總級的數據，也包括部分明細數據。從數據的時間跨度來說，通常是DW層的一部分，主要的目的是為了滿足用戶分析的需求，而從分析的角度來說，用戶通常只需要分析近幾年的即可。從數據的廣度來說，仍然覆蓋了所有業務數據。

方案

概念：應用層是根據業務需要，由前面三層數據統計而出的結果，可以直接提供查詢展現，或導入至Mysql中使用。

數據生成方式：由明細層、輕度匯總層，數據集市層生成，一般要求數據主要來源于集市層。

日志存儲方式：使用impala內表，parquet文件格式。

表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。

庫與表命名。庫名：暫定ads，另外根據業務不同，不限定一定要一個庫。

舊數據更新方式：直接覆蓋。

項目實戰：ADS 層復購率統計

CREATE TABLE app_usr_interact( user_id string COMMENT '用戶id',nickname string COMMENT '用戶昵稱',register_date string COMMENT '注冊日期',register_from string COMMENT '注冊來源',remark string COMMENT '細分渠道',province string COMMENT '注冊省份',pl_cnt bigint COMMENT '評論次數',ds_cnt bigint COMMENT '打賞次數',sc_add bigint COMMENT '添加收藏',sc_cancel bigint COMMENT '取消收藏',gzg_add bigint COMMENT '關注商品',gzg_cancel bigint COMMENT '取消關注商品',gzp_add bigint COMMENT '關注人',gzp_cancel bigint COMMENT '取消關注人',buzhi_cnt bigint COMMENT '點不值次數',zhi_cnt bigint COMMENT '點值次數',zan_cnt bigint COMMENT '點贊次數',share_cnts bigint COMMENT '分享次數',bl_cnt bigint COMMENT '爆料數',fb_cnt bigint COMMENT '好價發布數',online_cnt bigint COMMENT '活躍次數',checkin_cnt bigint COMMENT '簽到次數',fix_checkin bigint COMMENT '補簽次數',house_point bigint COMMENT '幸運屋金幣抽獎次數',house_gold bigint COMMENT '幸運屋積分抽獎次數',pack_cnt bigint COMMENT '禮品兌換次數',gold_add bigint COMMENT '獲取金幣',gold_cancel bigint COMMENT '支出金幣',surplus_gold bigint COMMENT '剩余金幣',event bigint COMMENT '電商點擊次數',gmv_amount bigint COMMENT 'gmv',gmv_sales bigint COMMENT '訂單數')PARTITIONED BY( dt string)--stat_dtdate COMMENT '互動日期',

①如何分析用戶活躍？

在啟動日志中統計不同設備 id 出現次數。

②如何分析用戶新增?

用活躍用戶表 left join 用戶新增表，用戶新增表中 mid 為空的即為用戶新增。

③如何分析用戶 1 天留存？

留存用戶=前一天新增 join 今天活躍

用戶留存率=留存用戶/前一天新增

④如何分析沉默用戶？

(登錄時間為 7 天前,且只出現過一次)

按照設備 id 對日活表分組，登錄次數為 1，且是在一周前登錄。

⑤如何分析本周回流用戶？

本周活躍 left join 本周新增 left join 上周活躍，且本周新增 id 和上周活躍 id 都為 null。

⑥如何分析流失用戶？

(登錄時間為 7 天前)

按照設備 id 對日活表分組，且七天內沒有登錄過。

⑦如何分析最近連續 3 周活躍用戶數？

按照設備 id 對周活進行分組，統計次數大于 3 次。

⑧如何分析最近七天內連續三天活躍用戶數？

查詢出最近 7 天的活躍用戶，并對用戶活躍日期進行排名

計算用戶活躍日期及排名之間的差值

對同用戶及差值分組，統計差值個數

將差值相同個數大于等于 3 的數據取出，然后去重，即為連續 3 天及以上活躍的用戶 ADS應用層優先調用數據倉庫公共層數據。如果已經存在CDM層數據，不允許ADS應用層跨過CDM中間層從ODS層重復加工數據。CDM中間層應該積極了解應用層數據的建設需求，將公用的數據沉淀到公共層，為其他數據層次提供數據服務。同時，ADS應用層也需積極配合CDM中間層進行持續的數據公共建設的改造。避免出現過度的ODS層引用、不合理的數據復制和子集合冗余。

總體遵循的層次調用原則如下：

ODS層數據不能直接被應用層任務引用。如果中間層沒有沉淀的ODS層數據，則通過CDM層的視圖訪問。CDM層視圖必須使用調度程序進行封裝，保持視圖的可維護性與可管理性。

CDM層任務的深度不宜過大（建議不超過10層）。

一個計算刷新任務只允許一個輸出表，特殊情況除外。

如果多個任務刷新輸出一個表（不同任務插入不同的分區），DataWorks上需要建立一個虛擬任務，依賴多個任務的刷新和輸出。通常，下游應該依賴此虛擬任務。

CDM匯總層優先調用CDM明細層，可累加指標計算。CDM匯總層盡量優先調用已經產出的粗粒度匯總層，避免大量匯總層數據直接從海量的明細數據層中計算得出。

CDM明細層累計快照事實表優先調用CDM事務型事實表，保持數據的一致性產出。

有針對性地建設CDM公共匯總層，避免應用層過度引用和依賴CDM層明細數據。