愛奇藝數據中臺建設方案

• **數據中臺的產生：**數據工作的痛點、數據中臺的產生、中臺的實質

• **愛奇藝數據中臺的定義：**理解數據中臺、數據中臺的發展歷程、輸出和定位

• **愛奇藝數據中臺的建設：**中臺建設、Pingback 體系、數倉體系、數倉平臺、離線數倉架構、大數據平臺、數據平臺架構

• **數據中臺的應用場景：**統一化、個性化、定製化

一、數據中臺的產生

1、數據工作的痛點

1. 使用門檻高：數據工作是一個專業性特別強的一個工作，對於人員的要求比較高。

2. 口徑不一致：在使用數據過程當中，口徑不一致是特別常見的一種問題，這種問題可能會導致一種數據使用和分析的差異，而且會降低業務的數據分析效率。

3. 數據可靠性低：在生產過程中，降低業務的數據分析效率，最終會對業務決策造成嚴重的影響，不僅數據鏈路過程很長，其中還會引入很多數據質量問題。

4. 跨業務難度大：因爲缺少一個統一的數據建設的規劃、標準和規範，所以難以指導各個業務或者整個生產鏈路的各個環節，以擁有一個標準化的生產和處理過程，就導致了多個業務的數據難以融合，難以發揮更大的數據價值。

5. 接入成本高：如果有新的業務接入或者新的場景需要使用數據，很多工作都需要人工處理。去申請各種資源、權限、找數據並且串聯整個數據的採集、生產、計算、同步和展示等各個環節，這是一個耗時長、效率低，最終還是很容易出錯的過程。

6. 投遞質量低：說到數據的話肯定離不開投遞，投遞是用來記錄用戶行爲的一連串的數據信息。如果投遞過程缺少標準化或者流程管控的話，都會導致投遞質量比較差。

7. 獲取數據難：數據的生產到最終使用，中間可能要經歷一個比較長的時間週期或者一個比較寬的團隊跨度，用戶可能無法很快地找到想要的數據，或者數據團隊生產出來的數據並沒有真正觸達到業務，來達到它的數據價值。

8. 數據資產模糊：這個點可能和獲取數據難有一點點關聯，數據資產模糊的話更多的是在說需要對公司的數據資產做一個整體的管理，如果沒有這個整體的管理，就會導致對數據資產的級別和擁有什麼數據資產都很模糊。最終就是導致數據的優勢難以發揮出來，而且雖然耗費了很多計算資源、人力資源、存儲資源，但沒有帶來相應的價值，最終導致資源效率極低。

2、數據中臺的實質

數據中臺更像一種企業架構，是一套結合互聯網技術和行業特性，在企業發展的不確定性中，尋找確定性，並且持續沉澱和抽象企業核心能力，最終支持企業快速、高效、低成本進行業務創新和增強的企業架構。

二、愛奇藝數據中臺的定義

1、理解數據中臺

數據後臺：

大家平時更多用到了大數據集羣，也就是說 Hadoop、Spark、Flink 以及其他 OLAP 工具。但是這些只是數據後臺的一個概念，並沒有做成一個標準化、通用化、門檻相對來說比較低的中臺化的概念。 

數據中臺：

數據中臺其實是一個數據即服務的產品概念，它包括了數據服務、數據平臺、數據中臺產生的數據以及在所有的數據工作中產生的標準和規範，這一些組成了我們所謂的數據中臺。

數據前臺：

數據前臺就是我們實際的產品落地的具體例子，主要包括了幾個大的方向：

• 分析體系，比如說用戶分析、內容分析、業務報表等；

• 數據應用，比如說即席查詢、可視化查詢工具；

• 數據產品，類似於畫像和推薦業務，可能都是一些數據最終形成的產品，直接面向用戶服務。

所以數據中臺抽象出來，就是指 “平臺 + 服務 + 數據 + 標準化” 的概念，它是將數據的生產、收集、處理、存儲和服務進行封裝，並且面向不同層級的用戶提供不同的服務形式。在數據標準化過程中，數據中臺可以防止數據重複建設，避免口徑問題，提高數據的使用效率。

2、數據中臺的發展歷程

3、數據中臺的輸出

數據中臺輸出形式分爲以下幾個：

4、數據中臺的定位

說到數據中臺定位，因爲數據中臺和前臺、後臺都需要有一個明確的劃分，數據中臺定位提供了這種抽象通用的能力來支持前臺團隊在此基礎之上進行定製化，最終在複用通用能力的同時，能夠滿足業務快速發展的個性化的需求，達到一個全局最優化的狀態。

三、愛奇藝數據中臺建設

1、建設

主要從五個角度去輸出中臺能力，分別是服務、數據、平臺、投遞、標準 / 規範。在愛奇藝數據中臺的實施過程中，劃分出了三個大方向：

• 生產，也就是我們所說的投遞體系；

• 數據，也就是統一數倉的體系，是數據的核心；

• 大數據平臺能力：包括開發、治理、服務。

日誌投遞：

這部分輸出了投遞規範，進一步針對投遞規範，需要對公司的相關員工進行培訓，讓大家深刻地理解投遞是爲了做什麼，並且怎樣才能達到我們對於用戶的行爲足夠深入的分析要求。

大數據平臺：

有一線開發、對應的運維管理、實時開發對應的運維管理，以及數據治理、數據圖譜、數據服務和即席查詢。即席查詢是我們數據服務裏的一個子項，但是因爲應用面比較廣，就單獨拎出來了。

統一數倉：

統一數倉的能力也就是爲下游提供離線和實時的兩種數倉能力。爲了方便大家實現跨離線和實時混合使用的場景，需要進行標準化的工作，也就是離線輸出的字段、定義、口徑、格式和實時數據要儘可能一致，即實時數據向離線數據看齊。

數倉在提供數據本身的能力之外，還要維護整個公司級別的指標體系和統一維度，讓所有的數據系統平臺和都會對接到統一的維度指標體系。而且，爲了幫助數倉建設過程中的數據建模和統計指標的管理，建設了一個對應的數據平臺，也是按照數據規範的標準建設，以此來支持使用方使用平臺依照規範去建設數倉的流程化工作。

2、Pingback 體系

Pingback 的體系就是投遞體系，那麼具體爲什麼要做這個事情呢？

投遞工作面臨的問題主要有以下幾個點：

3、數倉體系

數倉體系幾個要解決的痛點：

4、數倉平臺

數倉平臺主要是爲了做業務建模、數據建模、物理建模、維度管理、指標管理和數倉管理。

數倉平臺的特性：

• **數據表創建的約束性：**比如我們需要對錶有的命名規範要求，如果沒有一個工具去管理，可能會因爲大家對規範的理解不一致，最終導致落地過程中依然存在各種各樣的差異性；

• **數據信息的可描述性：**指在創建表的過程中，爲了快速地滿足業務，很少去添加一些相關的描述信息，導致數據缺少描述性。所以需要通過平臺，要求用戶在數據創建的過程中把信息描述的足夠精細，方便後續的數據使用過程；

• **數據建模體系的完整性：**指我們需要一個三步的建模過程，即業務建模後，有對應的數據建模；數據建模之後，針對這個數據建模，有不同的物理建模的形式。整體是一個流程化的工作，避免用戶爲了快速地滿足業務需求跳過某些過程，最終導致建模的擴展性較差；

• **數據關係的維度與指標管理的系統性：**通過提供一套統一的維度和指標管理體系來作爲一箇中心，對外輸出統一的指標和維度，讓大家在使用的過程中，可以使用這些標準化後的並且集中管理的元數據；

• **數據關係的可追溯性：**是指通過數倉建設、建模的過程，促使我們後續數據表和字段的相互關係是有記錄可查詢的，也就是我們所說的數據血緣關係。

5、離線數倉架構

下面是數倉的簡化架構，主要是體現了離線數倉部分。其中帶顏色的一部分是統一數倉，其他的淺顏色的就是一些數據應用，包括數據集市和主題數倉。

6、大數據平臺

愛奇藝大數據平臺經歷了五個階段：

**開發：**在第一階段完成了整個數據開發的平臺化、可視化能力，降低了開發門檻，並提升開發標準化。

**運維：**在開發之後，需要提升任務的管理和運維能力。通過建設運維管理模塊的建設，保證用戶更方便地對任務進行管理，並且對任務產出的穩定性和數據產出的時效性實現了有效的監控。

**質量：**在提供了數據開發和管理相關能力之後，需要進一步對數據產出進行質量校驗，避免生產出的數據在未關注數據質量的情況下直接被使用，造成數據問題的快速擴散。

**使用：**數據使用也是一個數據發現的過程。比如生產了很多數據，如何讓用戶看到這些數據，並將其更好地應用在業務需求當中。針對這個痛點，完成數據圖譜模塊的發佈，把各種的數據元信息進行收集、加工、管理，最終把完整的數據信息以一種更友好的形式提供出來，幫助大家快速地發現數據，進一步去了解數據元信息、快速準確地使用數據。

**治理：**是數據生態的最後一個環節，也是打造健康生態閉環的重要部分。有的公司可能是把治理放到比較靠前的環節，但是在一些場景下，比如說業務快速發展的過程中，治理往往是跟不上業務需求的。所以愛奇藝採取的方式是，等業務發展到一定程度，再去補充數據治理的能力，對存量去治理，對增量去管控。治理工作的內容主要包括對數據和任務進行日常審計，然後通過數據血緣和使用情況，對數據的冗餘度進行有效評估，並進行相應的優化，以減少資源和人力的浪費。

7、數據平臺架構

• 最底層是數據層，比如投遞服務器的日誌，包括業務的數據或者其他數據來源，通過採集層和傳輸層達到我們的計算層。

• 計算層，更多的是大數據集羣服務，也包括一些任務調度能力。

• 平臺層包括離線和流式任務的開發管理、機器學習平臺、數倉平臺，然後下面是對於整個的數據的 ETL 的一個平臺化的處理，還有外部數據的一個同步能力的模塊，稱爲數據集成。在擁有這些開發能力或管理能力的同時，還需要對投遞管理、數據安全、數據質量、數據圖譜做一些有效的建設，並且在整個數據體系中去做數據治理工作。

• 服務層是以即席查詢、實時分析，數據服務、元數據服務多種形式對下游提供服務能力。

四、應用場景

數據中臺的應用場景，面向不同階段來提供不同的接入方式：

• 第一個階段是統一化的形式。有一套通用的模板，它的優點和缺點都很明顯，優點是接入起來很簡單，缺點就是不夠個性化和定製化，只能支持這種通用的數據能力。所以它比較適合於業務初期，能夠進行快速接入，並且自動化地完成這種數據的處理和服務；

• 第二個階段是個性化的能力。把整個流程確定下來，業務在使用過程中可以針對某些環節做定製化的開發，拓展現存數據模塊的能力來滿足一些個性化需求，所以它更適用於業務的成長期的階段；

• 第三個階段是定製化的能力。定製化更多面向一些特別成熟的業務，也就是對於數據這一塊的需求有多方面的、深層次的使用場景，並且通用的和個性化的架構已經不足以滿足數據需求的情況下，可以採用定製化的能力。定製化能力也就是我們提供數據模塊化的能力，然後業務再根據自己的需求去對應選取這些模塊化能力，並進行組裝和擴展，來滿足自己定製化的需求。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/POZUVdUKfbh0W5JrgbWL3g