本文由 dbaplus 社羣授權轉載。
本次分享主要從以下部分展開：
- 數據中臺的產生： 數據工作的痛點、數據中臺的產生、中臺的實質；
- 愛奇藝數據中臺的定義： 理解數據中臺、數據中臺的發展歷程、輸出和定位；
- 愛奇藝數據中臺的建設： 中臺建設、Pingback體系、數倉體系、數倉平臺、離線數倉架構、大數據平臺、數據平臺架構；
- 數據中臺的應用場景： 統一化、個性化、定製化。
一、數據中臺的產生
1、數據工作的痛點
說到數據中臺的產生，我們不得不從數據工作的痛點來切入。我總結了八個方向，這八個方向可能不足以覆蓋數據工作中的所有痛點，但肯定是數據工作中最痛的八個點。
- 使用門檻高 ：數據工作是一個專業性特別強的一個工作，對於人員的要求比較高。在一些數據的工作當中需要人員有專業的數據基礎能力，這樣就導致了數據人力的缺失，可能會影響業務的數據支持力度；
- 口徑不一致 ：在使用數據過程當中，口徑不一致是特別常見的一種問題，這種問題可能會導致一種數據使用和分析的差異，而且會降低業務的數據分析效率，最終對業務決策造成嚴重影響；
- 數據可靠性低 ：在生產過程中，降低業務的數據分析效率，最終會對業務決策造成嚴重的影響，不僅數據鏈路過程很長，其中還會引入很多數據質量問題。並且，由於環節過多，也帶來了生產時間延遲的問題，可能直接影響到後續核心報表，推薦、模型的優化；
- 跨業務難度大 ：因爲我們缺少一個統一的數據建設的規劃、標準和規範，所以難以指導各個業務或者整個生產鏈路的各個環節，以擁有一個標準化的生產和處理過程，就導致了多個業務的數據難以融合，難以發揮更大的數據價值；
- 接入成本高 ：這主要應用在一個新的業務場景下，也就是說，如果我們有新的業務接入或者新的場景需要使用數據，很多工作都需要人工處理。去申請各種資源、權限、找數據並且串聯整個數據的採集、生產、計算、同步和展示等各個環節，這是一個耗時長、效率低，最終還是很容易出錯的過程；
- 投遞質量低 ：因爲說到數據的話肯定離不開投遞，投遞是我們用來記錄用戶行爲的一連串的數據信息。如果投遞過程缺少標準化或者流程管控的話，都會導致投遞質量比較差；
- 獲取數據難 ：可能在大家日常工作中會發現，我們數據的生產到最終使用，中間可能要經歷一個比較長的時間週期或者一個比較寬的團隊跨度，用戶可能無法很快地找到想要的數據，或者數據團隊生產出來的數據並沒有真正觸達到業務，來達到它的數據價值；
- 數據資產模糊 ：這個點可能和獲取數據難有一點點關聯，數據資產模糊的話更多的是在說我們需要對公司的數據資產做一個整體的管理，如果沒有這個整體的管理，就會導致對數據資產的級別和我們自己擁有什麼數據資產都很模糊。最終就是導致數據的優勢難以發揮出來，而且雖然我們耗費了很多計算資源、人力資源、存儲資源，但沒有帶來相應的價值，最終導致資源效率極低。
基於這些數據工作的一些痛點，我們就會引入“數據中臺”的概念。
2、數據中臺的產生
數據中臺的產生，在國內其實是阿里巴巴首先在2015年首先提出來的。提出這個概念指的是，我們通用能力的落地通過大中臺加小前臺的方式來實現。
但是，中臺並不適合所有的公司。數據中臺和其他中臺可能適用的場景，也就是一個公司或者一個集團有多個業務並行發展且需要不斷地沉澱通用能力的時候。
下面列舉愛奇藝數據的中臺化的轉變過程：
左邊是剛開始的狀態。我們每一個團隊都負責一個業務線的數據處理、報表開發，最終輸出的數據也要提供給一些橫向的團隊使用，比如說推薦、運營和用戶畫像的工作。
但是，每個團隊或者每條業務線所覆蓋的數據場景可能都不一樣，每個團隊的能力或者標準也不一樣，這樣輸出數據的質量或者口徑就會參差不齊。最終導致在下游使用的時候，成本會急劇增加。特別是在這個業務快速發展了一段時間之後，這個問題就會越發地突現出來。
通過中臺化建設，組織架構上靠一個團隊去支撐，把數據的通用能力抽象出來，並且統一維護這套通用的能力。再將這一套通用的能力附加到每條業務線上，把每一條業務線或者說把每一個業務線輸出的數據，做成一個標準化、流程化的數據體系，最終輸出給下游方使用。下游方就是我們的業務，包括推薦、運營，都是整個公司運轉起來的各個支持方向。
做完這個中臺化之後，從下游應用的角度來說，它的口徑和效率都得到了一個很明顯的提升。
所以對於中臺化建設，我們的目標就是避免煙囪式和重複建設，要實現抽象公共的通用能力，而且這個通用能力需要不斷沉澱和更新，並不是一成不變的。同時，需要提供相關的標準和規範來指導用戶共同打造和使用中臺，因爲單靠一個團隊去支持所有標準化的事情是不太現實的。
在此背景下，中臺團隊有一項特別重要的工作就是提供標準和規範，讓大家能以一個統一的標準去開展工作。這樣按照標準化流程生產出來的數據或者是其他的技術能力都可以快速複用。
最終，其實我們還是希望能夠打造一個數據生態的閉環，覆蓋生產、處理、存儲、治理、服務整個過程。
3、數據中臺的實質
數據中臺更像一種企業架構，是一套結合互聯網技術和行業特性，在企業發展的不確定性中，尋找確定性，並且持續沉澱和抽象企業核心能力，最終支持企業快速、高效、低成本進行業務創新和增強的企業架構。
進一步，數據中臺的實質就是抽象通用的數據能力，解決公司業務發展遇到的一些實際問題，降低數據的使用成本，通過數據促進業務的發展。
二、愛奇藝數據中臺的定義
說了很多關於數據中臺的概念，下面我們結合愛奇藝的數據中臺來討論下數據中臺的定義。
1、理解數據中臺
這個圖其實是一個很簡略的圖，但是能比較清晰地劃分出後臺、中臺、前臺的分界線。
數據後臺：
我們大家平時更多用到了大數據集羣，也就是說Hadoop、Spark、Flink以及其他OLAP工具。但是這些只是數據後臺的一個概念，並沒有做成一個標準化、通用化、門檻相對來說比較低的中臺化的概念。
數據中臺：
數據中臺其實是一個數據即服務的產品概念，它包括了數據服務、數據平臺、數據中臺產生的數據以及在所有的數據工作中產生的標準和規範，這一些組成了我們所謂的數據中臺。
數據前臺：
數據前臺就是我們實際的產品落地的具體例子，主要包括了幾個大的方向：
- 分析體系，比如說用戶分析、內容分析、業務報表等；
- 數據應用，比如說即席查詢、可視化查詢工具；
- 數據產品，類似於畫像和推薦業務，可能都是一些數據最終形成的產品，直接面向用戶服務。
所以數據中臺抽象出來，就是指“平臺+服務+數據+標準化”的概念，它是將數據的生產、收集、處理、存儲和服務進行封裝，並且面向不同層級的用戶提供不同的服務形式。
在數據標準化過程中，數據中臺可以防止數據重複建設，避免口徑問題，提高數據的使用效率。
在我們的數據的生產使用過程中，可能會因爲歷史的原因，或者業務快速發展所帶來的弊端，導致數據生產出來，並沒有得到有效的使用或者生產出來的數據不夠穩定、質量不夠高。這個時候我們就需要對數據進行有效的治理，以提升數據傳輸的穩定性和準確性，同時提升資源的利用率。
從另外一個角度看，數據中臺最終的目的是爲了屏蔽數據工作的複雜性，讓用戶能夠更方便、更高效地發現和使用數據，以此來滿足快速發業務快速發展的需求。
2、數據中臺的發展歷程
下圖是愛奇藝數據中臺的一個發展歷程，雖然相對粗粒度了一些，但是基本上能代表業界數據工作的一個發展歷程。
2017年及以前：
2017年及以前大家的數據工作都是一個相對零散化的狀態，用Hadoop client或者是其他的客戶端進行數據工作的開發，並且通過腳本化對數據任務進行管理和運維。
但是數據生產更多是需求導向的，來一個需求，我們就可以做一個數據。而不是，我們根據業務的發展的方向去擴展數據的需求並且提前把擴展性做好，這樣會導致數據比較零散，缺少統一的規劃。而缺少這種標準化的建設過程也符合當時業務快速發展的需要。
2018年：
2018年愛奇藝開始推進平臺化建設的事情，也就是數據平臺的建設。
平臺化的過程中，我們主要是完成了以下幾項工作：
- 離線計算的任務的開發和運維管理；
- 對應的流式計算的開發和運維管理；
- 爲了高效穩定地把外部的數據同步到我們的數據中臺，或者把數據產出同步到其他的業務系統下，我們開發了自己的數據集成模塊，用於實現不同存儲數據之間的數據同步功能；
- 我們對數據進行了一些簡單的管理，即數據表的創建到、維護、管理，都通過平臺化的形式去進行的。
2019年：
在平臺化初步建成之後，我們開始着手做一些標準化的工作。
標準化工作幾乎覆蓋了整個數據生命週期，從日誌投遞環節開始實施，針對Pingback2.0的規範，做了相應的工具來支持這個規範落地。同時結合公司業務制定了數據倉庫規範，用於指導整個的建模流程，也對指標和維度體系都做了一個明確的定義和規範。
進一步，把數據的生產流程進行了流程化的管理，最終給下游提供了統一的數據接口能力。這個數據接口能力更多偏向應用層，我們通過前面一系列的數據開發工作，在平臺上定義數據接口和數據服務，最終通過REST API的形式，對下游提供數據查詢或接入能力。
2020年：
完成了上述的平臺化和標準化工作之後，其實已經初步達到了中臺化建設的要求。
前面提到的平臺化和標準化更多的是給中臺團隊定義了一套統一的流程，讓使用方按照這套流程做操作和處理。而中臺化，其實是完成了一個從統一化到定製化的一個轉變。也就是說，中臺可以提供各種各樣在不同環節的工具或者平臺，業務方根據自己的需要進行靈活組裝，把這種模塊化的數據能力，定製化地輸出到業務當中。
同時，我們開始了數據治理的體系。數據治理包括制定數據資產的定級標準、梳理整個數據鏈路、數據存儲形式和數據使用審計等環節。所以可以認爲，數據治理是一個持續性的工作，不像項目制工作有結項的節點和計劃，這和平臺化、標準化的事情還是有一定差異的。
還有就是我們在基於平臺化、標準化的過程中，對新的業務抽象出一套通用的處理模板，幫助業務快速、自動化地完成接入，這種方式適合公司內部孵化的一些新業務快速接入我們的數據能力。
最後，是一個持續化的過程，即通用能力的不斷沉澱。因爲數據工作，或者其他技術類工作都是類似的，在實際的發展過程中技術和理念的升級，都會帶來一些通用能力的抽象沉澱，所以這個不斷沉澱的過程也是一個發展的過程。
3、數據中臺的輸出
數據中臺面向不同的用戶和場景，它的呈現形式是都不一樣。因爲中颱的目的是服務業務和用戶，它區別於平臺一個特別關鍵的點就是它可以滿足不同場景和不同用戶，通過數據中臺的模塊化能力構建一套定製化的數據處理流程，以此來滿足不同業務的個性化的數據解決方案。
數據中臺輸出形式分爲以下幾個：
- 服務： 指可以提供對外信息查詢、可視化查詢、數據接口、元數據接口等服務形式，用戶可以直接訪問或者通過協議對接到自己的平臺或者服務當中；
- 數據： 指數據工作中一個核心的產出，最終以一個統一數倉的形式呈現出來。統一數倉完成一些標準化的工作，把業務都需要的一些通用邏輯進行抽象處理，避免下游使用方在使用過程中的重複處理。因爲在重複的處理過程中，可能會引入不一致的口徑或者維度，造成資源的浪費。而且，因爲數據發展可能要經歷業務的很多階段，所以我們在做統一數倉的時候，需要把這些歷史的演進過程，幫用戶屏蔽掉，讓大家在用數據時，不需要再去考慮歷史的演進問題。而且我們在對於不同業務之間也做了一個標準化的處理，方便用戶跨業務地去使用數據；
- 平臺： 更多面向數據開發人員，對整個的大數據的能力進行了平臺化的封裝。提供界面化的數據開發能力，並且數據任務的運維和管理更加高效，同時也會把工作中常用到的信息以更好的組織形式展現出來。除了這些能力之外，還有其他便於用戶使用和加工數據的能力，比如HA、補跑數據等；
- 投遞： 數據來源中比較重要的一塊。在形成了一套投遞標準之後，去建立一些對應的投遞工具用於進行投遞管理。進一步，在測試和灰度階段也增加了兩個平臺用於保證投遞質量，分別是統計測試平臺和灰度監測平臺。在這兩個階段對質量進行監控，最終保證數據在真正投遞出來之前穩定可靠且質量比較高；
- 標準/規範： 是數據中臺能力最基礎的組成部分。也就是說，中臺要輸出標準流程和規範來讓大家可以快速按照流程和規範去開展工作，而且這個流程和規範一定是方便用戶接受的。如果一些標準流程過於複雜，就要儘可能地通過平臺化、工具化的方式協助用戶理解。
4、數據中臺的定位
說到數據中臺定位，因爲數據中臺和前臺、後臺都需要有一個明確的劃分，數據中臺定位提供了這種抽象通用的能力來支持前臺團隊在此基礎之上進行定製化，最終在複用通用能力的同時，能夠滿足業務快速發展的個性化的需求，達到一個全局最優化的狀態。
三、愛奇藝數據中臺建設
下面給大家介紹一下愛奇藝數據中臺的建設過程。
1、建設
我們主要是從五個角度去輸出中臺能力，分別是服務、數據、平臺、投遞、標準/規範。在愛奇藝數據中臺的實施過程中，我們劃分出了三個大方向：
- 生產，也就是我們所說的投遞體系；
- 數據，也就是統一數倉的體系，是數據的核心；
- 大數據平臺能力：包括開發、治理、服務。
日誌投遞：
這部分我們輸出了投遞規範，進一步針對投遞規範，我們需要對公司的相關員工進行培訓，讓大家深刻地理解投遞是爲了做什麼，並且怎樣才能達到我們對於用戶的行爲足夠深入的分析要求。
在平臺和工具這個角度，我們封裝了Pingback SDK來滿足不同端的投遞工作，比如安卓、iPhone等；通過Pingback SDK去幫助業務實現通用化的工作。同時我們幫助投遞管理的同學提供了一個管理平臺，並且在數據的使用當中提供統計測試平臺和灰度監測平臺。
大數據平臺：
我們有一線開發、對應的運維管理、實時開發對應的運維管理，以及數據治理、數據圖譜、數據服務和即席查詢。即席查詢是我們數據服務裏的一個子項，但是因爲應用面比較廣，就單獨拎出來了。
統一數倉：
最後一塊是統一數倉的能力，也就是爲下游提供離線和實時的兩種數倉能力。爲了方便大家實現跨離線和實時混合使用的場景，需要進行標準化的工作，也就是離線輸出的字段、定義、口徑、格式和實時數據要儘可能一致，即實時數據向離線數據看齊。
同時，數倉在提供數據本身的能力之外，我們還要維護整個公司級別的指標體系和統一維度，讓所有的數據系統平臺和都會對接到統一的維度指標體系。而且，爲了幫助數倉建設過程中的數據建模和統計指標的管理，我們建設了一個對應的數據平臺，也是按照數據規範的標準建設，以此來支持使用方使用平臺依照規範去建設數倉的流程化工作。
2、Pingback體系
Pingback的體系就是投遞體系，那麼具體爲什麼要做這個事情呢？
投遞工作面臨的問題主要有以下幾個點：
- 缺乏整體的規劃，投遞數據使用難度大。 就是大家可能在使用的過程中說，在不同業務當中同樣的字段不一樣，或者不一樣的還以同樣的字段，或者在同一個業務因爲時間的前後性，在一年前做的字段還有用但一年之後它就代表了另外一種含義，又或者產生了一個相同含義的另一個字段，這就造成了後續使用數據的難度特別大；
- 管理力度不足，後期維護成本極高。 這其實也是一個雙刃劍，如果管理力度過高的話，業務在使用起來就會覺得約束性比較強，效率就會有所降低。但如果管理力度不夠的話，就會造成一種隨用隨投的過程，最終導致了歷史延續性很差，維護成本極高。同時，如果沒有工具和平臺去統一維護和管理的話，大家會以各種形式來傳遞這些信息，導致溝通成本也相當高；
- 缺少共用的約束和校驗環節，投遞質量難以保證。 由於沒有一個統一的規範，導致後續對投遞質量校驗和監測的過程中，也就沒有統一的標準，最終導致投遞質量難以保障；
- 字段等定義不一致，跨業務數據打通很難。 作爲一個公司，不同業務線的數據在各自業務線發揮的價值要遠遠小於數據能跨業務向打通的這種價值。所以，當字段的這種跨業務線定義產生很大的差異，或者完全不一致的情況下，這種跨業務數據難打通造成的數據的價值流失特別嚴重。
3、數倉體系
下圖右側是一個簡化流程，依據Pingback規範建設Pingback管理平臺，同時開發了一整套的Pingback SDK。業務在使用SDK的時候，把這些用戶行爲投遞出來並進行收集，通過ETL輸出到測試統計和灰度監測這兩個平臺上，通過兩個環節對數據質量進行校驗，儘可能地把投遞問題堵截在全量發佈之前。
數倉體系幾個要解決的痛點：
- 數據重複建設和資源浪費。 這個資源浪費不是簡簡單單的存儲和計算資源，人力資源的浪費可能更爲明顯；
- 維度和指標定義混亂。 能描述同一個統計口徑指標，名稱完全不一樣，或者名稱完全一樣，但是口徑是完全不一致的，維度也會有類似的問題；
- 口徑不統一。 比如說我們在算轉化率的時候，跨業務線的統一口徑，或者同一個業務不同的需求下口徑也不一致，導致後續的數據使用過程中，經常出現數據撞車的情況，這就需要花大量人力和精力去排查解決；
- 業務處理邏輯複雜。 因爲每一個業務都有自己特有的業務邏輯，並且在投遞過程中可能會產生一些投遞問題，所以需要在數據處理過程中把這些問題修復掉。但是，修復的過程如果沒有一個統一的處理節點，就會造成每一處下游使用時都要做額外的處理，大大提高了業務處理的邏輯複雜度；
- 數據質量參差不齊。 因爲大家各自去構建自己的數據產出流程，數據質量參差不齊，越底層數據的質量問題對下游的影響度就越大；
- 數據使用的溝通成本高。 在缺少規劃的背景下，接收到一個或一批數據需求時，都會輸出一些新的數據表或者數據產出。在後續複用的情況下，沒有一個統一標準去維護和管理，或者我們在建設數據的過程中也沒有統一標準，就會造成使用過程中也需要去反覆地溝通和確認，才能真正找到對應的數據，而且找到的數據也不見得口徑一定一致。
4、數倉平臺
數倉平臺主要是爲了做業務建模、數據建模、物理建模、維度管理、指標管理和數倉管理。
數倉平臺的特性：
- 數據表創建的約束性： 比如我們需要對錶有的命名規範要求，如果沒有一個工具去管理，可能會因爲大家對規範的理解不一致，最終導致落地過程中依然存在各種各樣的差異性；
- 數據信息的可描述性： 指在創建表的過程中，爲了快速地滿足業務，很少去添加一些相關的描述信息，導致數據缺少描述性。所以需要通過平臺，要求用戶在數據創建的過程中把信息描述的足夠精細，方便後續的數據使用過程；
- 數據建模體系的完整性： 指我們需要一個三步的建模過程，即業務建模後，有對應的數據建模；數據建模之後，針對這個數據建模，有不同的物理建模的形式。整體是一個流程化的工作，避免用戶爲了快速地滿足業務需求跳過某些過程，最終導致建模的擴展性較差；
- 數據關係的維度與指標管理的系統性： 通過提供一套統一的維度和指標管理體系來作爲一箇中心，對外輸出統一的指標和維度，讓大家在使用的過程中，可以使用這些標準化後的並且集中管理的元數據；
- 數據關係的可追溯性： 是指通過數倉建設、建模的過程，促使我們後續數據表和字段的相互關係是有記錄可查詢的，也就是我們所說的數據血緣關係。
5、離線數倉架構
下面是數倉的簡化架構，主要是體現了離線數倉部分。其中帶顏色的一部分是統一數倉，其他的淺顏色的就是一些數據應用，包括數據集市和主題數倉。
6、大數據平臺
最後一個大方向就是大數據平臺：
我們大數據平臺經歷了五個階段，第一個階段和第二個階段聯繫更加緊密：
開發： 我們在第一階段完成了整個數據開發的平臺化、可視化能力，降低了開發門檻，並提升開發標準化。
運維： 在開發之後，需要提升任務的管理和運維能力。通過建設運維管理模塊的建設，保證用戶更方便地對任務進行管理，並且對任務產出的穩定性和數據產出的時效性實現了有效的監控。
質量： 在提供了數據開發和管理相關能力之後，需要進一步對數據產出進行質量校驗，避免生產出的數據在未關注數據質量的情況下直接被使用，造成數據問題的快速擴散。
數據質量這一部分主要是爲了及早地發現質量問題，儘可能地把問題解決在數據鏈路的更上游的階段，避免造成數據的生產延遲和資源浪費。
使用： 數據使用也是一個數據發現的過程。比如生產了很多數據，如何讓用戶看到這些數據，並將其更好地應用在業務需求當中。
針對這個痛點，我們完成數據圖譜模塊的發佈，把各種的數據元信息進行收集、加工、管理，最終把完整的數據信息以一種更友好的形式提供出來，幫助大家快速地發現數據，進一步去了解數據元信息、快速準確地使用數據。
治理： 是數據生態的最後一個環節，也是打造健康生態閉環的重要部分。有的公司可能是把治理放到比較靠前的環節，但是在一些場景下，比如說業務快速發展的過程中，治理往往是跟不上業務需求的。
所以我們採取的方式是，等業務發展到一定程度，再去補充數據治理的能力，對存量去治理，對增量去管控。治理工作的內容主要包括對數據和任務進行日常審計，然後通過數據血緣和使用情況，對數據的冗餘度進行有效評估，並進行相應的優化，以減少資源和人力的浪費。同時在生產過程中，如果出現生產不穩定的情況，我們也可以快速地發現問題，進而優化整個的生產鏈路，提高整個數據生態的健康度。
7、數據平臺架構
這就是數據平臺的一個大體的架構：
最底層是一個數據層，比如說我們的投遞服務器的日誌，包括業務的數據或者其他數據來源，通過我們的採集層和傳輸層達到我們的計算層。計算層的話，更多的是大數據集羣服務，也包括一些任務調度能力；再上層是我們所提到的平臺層，包括離線和流式任務的開發管理、機器學習平臺、數倉平臺，然後下面是對於整個的數據的ETL的一個平臺化的處理，還有外部數據的一個同步能力的模塊，稱爲數據集成。在擁有這些開發能力或管理能力的同時，我們還需要對投遞管理、數據安全、數據質量、數據圖譜做一些有效的建設，並且在整個數據體系中去做數據治理工作。最終是以即席查詢、實時分析，數據服務、元數據服務多種形式對下游提供服務能力。
四、應用場景
數據中臺的應用場景，其實面向不同階段來提供不同的接入方式：
- 第一個階段是 統一化 的形式。我們有一套通用的模板，它的優點和缺點都很明顯，優點是接入起來很簡單，缺點就是不夠個性化和定製化，只能支持這種通用的數據能力。所以它比較適合於業務初期，能夠進行快速接入，並且自動化地完成這種數據的處理和服務；
- 第二個階段是 個性化 的能力。也就是說，我們把整個流程確定下來，業務在使用過程中可以針對某些環節做定製化的開發，拓展現存數據模塊的能力來滿足一些個性化需求，所以它更適用於業務的成長期的階段；
- 第三個階段是 定製化 的能力。定製化更多面向一些特別成熟的業務，也就是對於數據這一塊的需求有多方面的、深層次的使用場景，並且通用的和個性化的架構已經不足以滿足數據需求的情況下，可以採用定製化的能力。定製化能力也就是我們提供數據模塊化的能力，然後業務再根據自己的需求去對應選取這些模塊化能力，並進行組裝和擴展，來滿足自己定製化的需求。
以下是一個自動化接入流程：
新業務接入，做出一個產品，然後使用我們投遞的SDK去進行投遞，通過平臺的工具進行投遞的管理，最終數據採集、存儲、監控，到統一數倉的加工，數據結果的輸出，這整一個流程都是有統一的模板去執行的。比如我們常見的DAU、留存、新增、轉化率、點擊率，其實靠通用模板就能達到。
最終輸出的形式，比如用戶行爲分析或者我們提供不同層級的數據產出物，像是MID層的聚合數據或者DWD層的明細數據等。用戶可以通過自主查詢的能力對數據進行查詢和使用，同時業務線也會有自己的核心報表或者通用報表，可以通過這套自動化的流程產出，最終反哺到新業務當中。
這是一個快速，並且成本極其低的一個過程，更適用於業務的初期階段。
以下是一個定製化的接入過程：
定製化的用戶更多的可以參與到數據的整個處理過程當中。比如說生產和定製化的開發、業務基於統一數倉建設自己的數倉、關注自己的數據質量、輸出數據結果、數據業務集市，最終能輸出成自助查詢的一些數據元。
然後，一些定製化的報表、用戶行爲的分析，都也可以去定製化自己的元數據服務和數據服務能力來對接到自己的平臺或者服務上，這是一個相對來說比較定製化的過程。大家可以在某一個環節或者是某些環節去接入，更多地把自己的一個業務的特點應用到數據的整個處理過程當中。
Q & A
Q1：請問沒有做過數據倉庫，可以一步到位建設數據中臺嗎？
不建議這麼做，數據工作的核心是數據，而數據倉庫是數據的主要組織形式，是應該最早建設起來的，可以脫離數據中臺的其他部分發揮數據價值；同時建設數據中臺工作是一個長期迭代的過程，也不會是一步到位的。
Q2：數倉到數據中臺，和大數據平臺到數據中臺，哪種路徑會更好些？
這兩個方向並不衝突，數據中臺更着重的是數據的通用能力輸出，無論是數倉還是大數據平臺都是數據中臺不可或缺的重要組成部分；如果非要選擇一個的話，我建議先建數倉，因爲大數據平臺是可以通過直接使用大數據集羣完成相關數據工作的能力。
Q3：建設數據倉庫的方法論是什麼？主要用到什麼系統？
主要是依賴Kimball的多維建模方法論，但是針對一些實體分析的場景，如用戶數倉、內容數倉等等，則需要引入Anchor建模方式，這兩種建模方式是目前我們主要採用的；我們目前是自建的數倉平臺，是依賴自身制定的數倉規範進行建設的，主要有建模流程、模型管理、維度管理和指標管理等子模塊。
Q4：數據倉庫裏，拉鍊表多嗎？
目前拉鍊表較少，拉鍊表的生產和使用成本相對較高，而使用的場景又相對有限；如果確實有這方面的需求，可以考慮在特定的場景對快照表進行相應的處理，以實現拉鍊表所提供的能力。
Q5：請問投遞怎麼理解？是埋點或者訂閱嗎？主要涉及到哪些工作？
投遞可以理解爲用戶行爲的記錄，包括用戶啓動APP、播放視頻、瀏覽頁面和點擊內容等，可以記錄用戶在APP內的操作行爲；主要涉及投遞設計和管理，投遞出的日誌收集和ETL，包括用於監控投遞質量的統計平臺等。
Q6：請問什麼是埋點呢？埋點丟失時預警有做嗎？
埋點可以理解爲用戶行爲的記錄，即在用戶的某種行爲下會觸發行爲日誌的投遞；埋點丟失的預警可以有兩個角度，一個是功能角度，即用戶級別的監測，這依賴前端的投遞SDK，用於記錄投遞失敗的次數和信息；另一個是統計角度，即從相對粗的粒度進行行爲統計，根據其他事件或者歷史情況進行對比，確認數據是否有丟失。
Q7：數據重跑是怎樣的？
數據重跑的場景可以分爲幾種情況，數據修復、口徑變化、新增指標等；我們會通過數據平臺的任務管理來創建重跑任務，指定重跑時間段、相關參數和並行度等，然後執行重跑任務，最後在數據重跑後進行數據的驗證。
Q8：數據質量平臺稽覈任務的執行，對接的數據存儲一般用哪些？關係型數據庫還是Hive？
數據中臺的數據主要是離線和實時兩種形式，離線數據主要以Hive爲載體，其中包括從關係型數據庫接入的業務數據；實時數據主要以Kafka爲載體；數據質量平臺主要針對這兩種形式的數據進行數據稽覈。
Q9：在中臺上如何開放目錄或者地圖，讓業務方或者其他應用開發者快速獲取所需數據？
數據中臺中有數據圖譜模塊，以搜索和地圖等形式將元數據以更爲合理的形式輸出，方便用戶發現數據，並在平臺一站式的完成數據的權限申請和使用。
Q10：數據治理是放到數據服務之後嗎？數據治理主要是治理哪塊？數據質量？數據標準？
數據治理是貫穿整個數據生命週期的，和數據服務沒有前後關係，可以認爲數據服務也是在數據治理的範疇之內；數據治理主要包括數據質量的分析、生產鏈路穩定性的分析、資源利用分析、數據標準化分析和使用審計等，數據治理的目的是爲了保障數據穩定高質的進行生產，並推進整體的資源優化，同時防止數據的泄露等。
Q11：對於數據生命週期怎麼處理？有做冷熱備份嗎？
數據有不同的資產等級，需要根據不同的資產等級制定TTL的設定；同時可以對數據進行垂直裁剪，將時效性要求較高的部分進行裁剪，以降低數據存儲的成本；另外，爲了滿足對歷史數據的追溯，可以將使用頻率極低的數據存儲到冷備，但需要考慮冷備的成本，包括恢復數據的經濟成本和時間成本。
Q12：請問支持爲多租戶分配平臺資源、工具、開發嗎？
支持，這是數據平臺必須的能力。
Q13：愛奇藝用到的大數據集羣是開源的還是CDH？
主要是基於CDH的，並在此基礎上進行了定製化的開發，包括內外部的各種補丁。
Q14：任務調度系統是自研的嗎？還是用的開源的，哪個會比較好呢？
目前任務調度系統是基於oozie進行二次開發的，主要是增加了一些參數和打通其他的數據中臺組件；目前主流的調度主要是oozie、airflow和azkaban等，各有優勢，主要還是得看具體的使用場景和取捨，進而選擇合適的調度系統。
Q15：請問下老師，大數據平臺目前對外輸出嗎？
暫時還沒有對外輸出，由於每個公司的具體場景存在差異性，數據中臺的體現形式也會稍有不同，不過後期可能會通過文章或者書籍的方式對外輸出我們的想法和建設感受。
作者介紹：
馬金韜，愛奇藝數據中臺負責人
- 目前主要負責愛奇藝數據中臺的規劃和建設，對廣告業務和大數據體系都有一定的瞭解；
- 北郵本碩畢業，先後在百度、阿里巴巴、墨跡和愛奇藝等多家公司從事廣告和大數據方向的工作。
原文鏈接：