概述
前面大概介紹了數據數據的質量如何維護，成本如何降到最低，數據服務的功能。現在給大家講解一下數據安全，數據研發，數據分析以及最賤實踐的例子。
數據安全
在剛開始構建數據中台的時候，我們就重點考慮了數據中台的安全保障，我把它歸結為五大法寶。
接下來，我就帶你深入分析一下，希望學完這部分內容之后，
你可以回答這樣三個問題：如何解決數據誤刪除問題；如何解決敏感數據泄露問題；如何解決開發和生產物理隔離問題。
它們是你在數據中台建設中一定會面臨的，學完之后，你一定可以找到解決這些問題的方法。
數據備份與恢復
對於絕大多數的企業，數據中台的數據都存儲在 HDFS 中，即使是實時的數據（存儲於 Kafka），也會歸檔一份到 HDFS，因為要保存歷史數據進行回算或者補數據。所以我們要解決的核心問題是 HDFS 的數據備份。HDFS 數據的備份，是基於 HDFS 快照 + DistCp + EC 實現的。
我們分為線上集群和冷備集群兩個集群，數據加工任務訪問的是線上集群，存儲采用的是 HDFS 默認的 3 副本。而冷備集群，主要考慮到存儲成本的因素，采用的是 EC 存儲。
為了讓你了解 EC 存儲的基本原理，我多說幾句。其實，Hadoop 在 3.x 就正式引入了 EC 存儲，它是一種基於糾刪碼實現的數據容錯機制，通過將數據進行分塊，然后基於一定的算法計算一些冗余的校驗塊，當其中一部分數據塊丟失的時候，可以通過這些冗余的校驗塊和剩余的數據塊，恢復出丟失的數據塊。這么說可能不太形象，我做個比喻。比如有三個數據塊，分別存儲的是 1、2 和 3。我們非常擔心其中一個數據塊壞了，丟失內容。所以增加了一個塊，這個塊存儲的內容是前面三個數據塊之和。那么如果其中任意一個數據塊壞了，我們可以根據現有的數據塊計算出丟失的數據塊內容。 比如 1 丟失了，我們可以根據 6-3-2 計算出 1，當然這個只是最簡單的 EC 算法，只能容忍一個數據塊丟失，實際的 EC 算法要再復雜一些 。在這里我只想告訴你的是，EC 存儲，在不降低可靠性的前提下（與 HDFS 3 副本可靠性相同），通過犧牲了一定的計算性能（因為計算校驗塊需要消耗額外的計算資源），將數據存儲成本降低了一半，非常適合低頻訪問的冷數據的存儲，而備份數據就是這種類型的數據。
那線上集群的數據又是如何同步到冷備集群的呢？在回答這個問題前，你有必要先了解一下快照的基本原理，因為這樣你才能理解后續的數據同步流程。Hadoop 在 2.x 版本就已經支持了對某個文件或者目錄創建快照，你可以在幾秒內完成一個快照操作。在做快照前，你首先要對某個目錄或者文件啟用快照，此時對應目錄下面會生成一個.snapshot 的文件夾。
在上圖中， 我們對 /helloword 目錄啟用快照，然后創建一個 s1 的備份。此時，在.snapshot 下存在 s1 文件。然后我們刪除 /helloword/animal/lion 文件時，HDFS 會在 animal 目錄創建 differ 文件，並把 diifer 文件關聯到 s1 備份，最后把 lion 文件移動到 differ 目錄下。通過這個案例，我們不難發現，HDFS 快照實際只記錄了產生快照時刻之后的，所有的文件和目錄的變化，非常適合每天只有少數文件被更新的數據中台，代價和成本也很低。有了快照之后，我們就需要把快照拷貝到冷備集群中，這里選擇的是 Hadoop 自帶的 DistCp。為什么考慮 DistCp 呢？因為它支持增量數據的同步。它有一個 differ 參數，可以對比兩個快照，僅拷貝增量的數據。同時，DistCp 是基於 MapReduce 框架實現的數據同步工具，可以充分利用 Hadoop 分布式計算的能力，保證數據的拷貝性能。我提供給你一張詳細的圖，透過這張圖，你可以看到具體的數據從線上集群拷貝到冷備集群的流程。
首先，對於第一次開始數據備份的文件，我們會先創建一個快照，然后利用 DistCp 拷貝全量的備份數據到冷備集群。然后后續的每一天，我們都會定時生成一個快照，並和前一天的快照基於 distcp --differ 參數進行對比，將有更新的部分再同步到冷備集群。同步完成以后，會刪除前一天的快照，這樣就完成了每日數據的增量同步。這里需要特別注意的是，拷貝數據會對線上 I/O 產生比較大的壓力，所以盡量在任務運行的低峰期進行同步（比如白天 12 點到晚上 24 點之間的時間），同時 DistCp 的 bandwidth 參數可以限制同步的速率，你可以根據 I/O 負載和數據同步速率，動態調整。比如說，I/O 利用率 100%，應該限制數據拷貝帶寬，為 10MB/s。講到這兒，你已經了解了數據中台中，文件目錄的備份了，但是光這些還不夠，我們還需要備份數據的產出任務，表相關的信息：
任務的備份，要保存任務代碼、任務的依賴關系、任務的調度配置以及任務的告警、稽核監控等信息；表的備份主要是備份表的創建語句。
我們提供了產品化的解決方案，數據開發可以在我們提供的數據管理平台上，選擇一張表，創建備份，然后系統就會自動地完成任務、文件和表的備份。平台也提供了一鍵恢復的功能，系統會自動地幫數據開發創建任務和表，拷貝數據從冷備集群到線上集群。那么你可能會有疑問：什么樣的數據應該備份呢？ 在我看來，數據的備份策略應該和數據資產等級打通，對於核心數據資產，數據中台應該強制進行備份。那假如說，數據沒有備份，但我們誤刪除了，還有沒有其他的補救方法呢？ 你可以試一下接下來地的這個機制。
垃圾回收箱設計
HDFS 本身提供了垃圾回收站的功能，對於意外刪除的文件，可以在指定時間內進行恢復，通過在 Core-site.xml 中添加如下配置就可以開啟了，默認是關閉狀態。
1 <property> 2 <name>fs.trash.interval</name> 3 <value>1440</value> 4 </property>
當 HDFS 一旦開啟垃圾回收功能后，用戶通過命令行執行 rm 文件操作的時候，HDFS 會將文件移到 /user/[用戶名]/.trash/current/ 目錄下。這個目錄下的文件會在 fs.trash.interval 配置的時間過期后被系統自動刪除。當你需要恢復文件的時候，只需要把 /user/[用戶名]/.trash/current/ 被刪除文件移到要恢復的目錄即可。聽到這兒，你是不是感覺問題已經解決了呢？但是我想強調的是 HDFS 垃圾回收機制在實際應用過程中，存在重大的缺陷。因為它只能支持通過命令行執行 rm 操作，對於在代碼中通過 HDFS API 調用 Delete 接口時，會直接刪除文件，垃圾回收機制並不生效。尤其是我們在 Hive 中執行 drop table 刪除一個 Hive 內表，此時刪除的數據文件並不會進入 trash 目錄，會存在巨大的安全隱患。
那你要怎么解決呢？我建議你可以對 HDFS 的 Client 進行修改，對 Delete API 通過配置項控制，改成跟 rm 相同的語義。也就是說，把文件移到 trash 目錄。對於 Hive 上的 HDFS Client 進行了替換，這樣可以確保用戶通過 drop table 刪除表和數據時，數據文件能夠正常進入 HDFS trash 目錄。
通過這種方式，你可以解決數據誤刪除的問題。但 HDFS 回收站不宜保留時間過長，因為回收站中的數據還是三副本配置，會占用過多的存儲空間。所以我給出的一個配合解決方案是，回收站保留 24 小時內的數據。這樣解決的是數據還沒來得及被同步到冷備集群，誤刪除的情況。對於一天以上的數據恢復，建議采取基於冷備集群的數據備份來恢復。好了，講完如何解決數據的誤刪除之后，接下來我們來解決第二個問題，就是如何避免敏感數據的泄露，而這離不開精細化的權限管理。
精細化的權限管理
數據權限是數據中台實現數據復用的前提和必要條件。如果剛開始系統沒有開啟權限，后期接入權限，任務的改造成本會非常高的，幾乎涉及到所有的任務。所以權限這個問題，在數據中台構建之初，必須提前規划好。網易數據中台支撐技術體系是基於 OpenLDAP + Kerberos + Ranger 實現的一體化用戶、認證、權限管理體系。
試想一下，如果有幾千台機器，卻沒有一個統一的用戶管理服務，當我們想添加一個用戶時，需要到幾千台服務器上去創建初始化用戶，這個管理和運維的效率有多低。而 OpenLDAP 就幫我們解決了這個問題。OpenLDAP 是一個輕量化的目錄服務，數據以樹型結構進行存儲，能夠提供高性能的查詢服務，非常適合用戶管理的場景。
Hadoop 可以使用 LdapGroupsMappings 同步 LDAP 創建的用戶和用戶組，這樣當我們在 LDAP 中添加用戶和組時，會自動同步到 Hadoop 集群內的所有機器上。通過這個方式，你就可以解決用戶管理的問題了，而接下來要解決的就是認證的問題。在非安全網絡中，除了客戶端要證明自己是誰，對於服務端而言，同樣也需要證明我是我。為了實現雙向的認證，我們在生產環境啟用了安全等級最高的，基於共享密鑰實現的 Kerberos 認證。說起 Kerberos 認證的原理，我想舉一個有趣的例子。
你肯定去過游樂場吧！ 為了進游樂場，首先你需要提供你的身份證，實名購買一張與你身份綁定的門票。在進入游樂場之后呢，每個游樂設施前，都有一個票據授權機器，你需要刷一下你的門票，授權機器會生成一個該游樂設施的票據，你拿着這個票據就可以玩這個游樂設施了。當然，當你想玩另外一個游樂設施的時候，同樣需要刷一下你們的門票，生成對應游樂設施的票據。而且你的門票是有有效期的，在有效期內，你可以盡情地玩游樂設施，一旦超過有效期，你需要重新購買你的門票。
Kerberos 認證與上面這個故事類似，在上面的故事中，TGT（Ticket-granting ticket）可以看作是門票，Client 首先使用自己的密鑰文件 Keytab 和用戶標識 Principal 去認證服務器（AS）購買 TGT，認證服務器確認是合法的用戶，Client 會獲得 TGT，而這個 TGT 使用了 TGS（Ticket-granting service）的 Keytab 加密，所以 Client 是沒辦法偽造的。在訪問每個 Server 前，Client 需要去票據授權服務（TGS）刷一下 TGT，獲取每個服務的票據（ST），ST 使用了 Client 要訪問的 Server 的 Keytab 加密，里面包含了 TGS 認證的用戶信息，Client 是無法偽造 ST 的。最后基於每個服務的票據，以及客戶端自己生成的加密客戶認證信息（Autenticator）訪問每個服務。每個 Server 都有歸屬於自己的 Keytab，Server 只有使用 Server 自己的 Keytab 才能解密票據（ST），這就避免了 Client 傳給了錯誤的 Server。與此同時，解密后票據中包含 TGS 認證的客戶信息，通過與 Authenticator 中 Client 生成的客戶信息進行對比，如果是一致的，就認為 Client 是認證通過的。一般在 Hadoop 中，我們會使用 Kinit 工具完成 TGT 的獲取，TGT 一般保存 24 小時內。我介紹 Kerberos 原理，其實是想讓你知道，Kerberos 對於 Hadoop 集群來說，是一個非常安全的認證實現機制，我推薦你使用 Kerberos 實現 Hadoop 集群的安全認證。
你可能會問，Kerberos 使用的是 Principal 標識用戶的，它又是怎么和 OpenLDAP 中的用戶打通的呢？ 其實我們訪問 HDFS，使用的是 Principal，Hadoop 可以通過配置 hadoop.security.auth_to_local，將 Principal 映射為系統中的 OpenLDAP 的用戶。用戶注冊時，平台會為每一個新注冊的用戶生成 Principal 以及相對應的 Keytab 文件。認證完成之后呢，就要解決哪些客戶可以訪問哪些數據的問題了。我推薦你使用 Ranger 來解決權限管理的問題。為什么要選擇 Ranger 呢？因為 Ranger 提供了細粒度的權限控制（Hive 列級別），基於策略的訪問控制機制，支持豐富的組件以及與 Kerberos 的良好集成。權限管理的本質，可以抽象成一個模型：“用戶 - 資源 - 權限”。數據就是資源，權限的本質是解決哪些人對哪些資源有權限。
在 Ranger 中，保存了很多策略，每一個資源都對應了一條策略，對於每個策略中，包含了很多組許可，每個一個許可標識哪個用戶或者組擁有 CRUD 權限。講完了用戶、認證和權限實現機制，那你可能會問，權限的申請流程是什么樣子的呢? 在數據中台中，每一張表都有對應的負責人，當我們在數據地圖中找到我們想要的數據的時候，可以直接申請表的訪問權限，然后就會發起一個權限申請的工單。表的負責人可以選擇授權或者拒絕申請。申請通過后，就可以基於我們自己的 Keytab 訪問該表了。另外，需要特別強調的是，由於數據中台中會有一些涉及商業機密的核心數據，所以數據權限要根據數據資產等級，制訂不同的授權策略，會涉及到不同的權限審批流程，對於一級機密文件，可能需要數據中台負責人來審批，對於一般的表，只需要表的負責人審批就可以了。
操作審計機制
進行到第三步，權限控制的時候，其實已經大幅降低了數據泄露的風險了，但是一旦真的出現了數據泄露，我們必須能夠追查到到底誰泄露了數據，所以，數據中台必須具備審計的功能。
由於用戶每次訪問數據，都要對權限進行驗證，所以在校驗權限的同時，可以獲取用戶訪問表的記錄，Ranger 支持審計的功能，用戶的訪問記錄會由部署在各個服務（HDFS，HBase 等等）上的插件推送到 Audit Server 上，然后存儲在 Solr 中，Ranger 提供了 API 接口查詢表的訪問記錄。但是必須指出的是，Ranger 開啟 Audit 后，會對服務內的插件性能產生影響。除了敏感數據泄露的風險，我還看到一些企業想要對開發和生產環境進行物理隔離。為什么企業會有這個訴求呢？
首先，很多傳統公司的數據開發都是外包人員，從企業的角度，不希望數據開發直接使用生產環境的數據進行測試，從安全角度，他們希望生產和測試從物理集群上完全隔離，數據脫敏以后，給開發環境進行數據測試。其次，涉及一些基礎設施層面的組件升級（比如 HDFS、Yarn、Hive、Spark 等），貿然直接在生產環境升級，往往會造成兼容性的事故，所以從安全性的角度，企業需要有灰度環境，而用開發環境承擔灰度環境的職能，是一個不錯的選擇。最后，雖然可以為生產和開發環境設置不同的庫和隊列，從而實現隔離，避免開發任務影響線上任務和數據，但會導致任務上線需要改動代碼，所以最理想的，還是實現開發和生產環境兩套集群，同一套代碼，在開發環境對應的就是開發集群，提交上線后，就發布到生產集群。這些就是企業希望開發和生產集群物理隔離的原因，那我們接下來看一看該如何滿足。
開發和生產集群物理隔離
一部分來自傳統企業，尤其是金融行業，他們對安全性的要求遠大於對效率的訴求，嚴格禁止數據開發使用線上數據進行測試，他們希望有兩套完全不同的環境，包括操作平台，任務在開發環境進行開發，配置任務依賴，設置稽核規則和報警，然后由運維人員進行審核后，一鍵發布到生產環境。當數據開發需要對數據進行測試時，可以同步生產環境的局部數據（部分分區），數據會進行脫敏。
上圖是該模式下的部署架構。通過這張圖我們可以看到，開發和測試環境本身是兩套完全獨立的平台，因為每次數據測試，都需要同步生產環境的數據，所以這種模式下，數據開發的效率會有比較大的影響，但是優勢在於對數據安全實現了最高級別的保護。與這部分客戶不同的是，很多企業需要同時兼顧安全和效率，他們沒有辦法接受同步生產環境數據，而是需要在開發環境能夠直接使用線上的數據進行測試。
上圖展示了該模式下的部署架構。我們可以看到，大數據平台和任務調度系統（Azkaban）都是一套，然后 Hive，Yarn 和 HDFS 都是兩套，兩套集群通過 Metastore 共享元數據。這樣做的一個好處在於，一個集群的 Hive 可以直接訪問另外一個集群的數據。在同一個 Metastore 中，開發環境的數據在 _dev 庫中，生產環境的數據在 _online 庫中，用戶在代碼中不需要指定庫，在任務執行時，根據運行環境，自動匹配庫。例如在開發環境執行，Hive 默認會使用 _dev 庫下的表，而在生產環境執行，Hive 默認會使用 _online 庫下的表，從而實現了不需要改代碼可以實現一鍵發布。上面兩種部署模式，你可以根據你所在的企業實際情況進行選擇，對安全性要求高，推薦第一種方案，對於效率要求高，同時兼顧一定的安全性，就推薦第二種方案。
數據建設
對企業來說，用好數據非常關鍵，從我多年的數據建設經驗來看，我把數據在企業的應用划分成三個階段。
我們就從這三個階段，談一談如何用好數據中台的數據。
初級階段。一般企業的數據應用都是從數據報表開始的，分析師會為業務部門的負責人、運營制作一些 BI 報表，把數據通過可視化的方式呈現出來，這是數據應用的初始階段。
發展階段。只是可視化的展現數據已經不能滿足業務的需求，業務需要根據數據持續監控業務過程，發現問題、診斷分析，並給出決策建議，最后需要一鍵執行，形成完成的業務過程閉環，這個時候就要借助數據產品來實現，網易也是在 2018 年才開始大規模構建數據產品體系。
高級階段。無論是數據報表、還是數據產品，它們呈現的都是固化的分析思路，只能解決知道的業務問題，但是日常工作還有很多未知的業務問題，比如銷售額指標突然下降了，需要基於數據進行探索分析。這個時候，如果都依賴分析師，肯定不現實，那么就要實現自助取數，讓每個人都能基於數據去做分析和決策，實現普惠大數據。我認為這是數據應用的最高級階段，網易在 2019 年開始開放越來越多的中台數據，讓更多的非技術人員去使用數據。
數據中台該如何賦能 BI 工具
很多人對數據的了解，都是從 BI 工具做的報表開始的。關於 BI 工具的產品本身，不是我想說的重點，我主要想和你討論的是數據中台時代，如何讓數據中台幫助 BI 工具更強大。我會從四個方面帶你了解這部分內容。
第一，統一報表指標業務口徑。數據報表上會存在指標口徑不一致的問題，相同指標名稱，兩個報表里的數據卻相差很大，這會讓數據使用者對數據失去信任。而數據中台的所有的指標都是由指標系統統一管理的，如果能在數據報表上直接看到指標系統中，指標的口徑定義，就可以讓看報表的人准確理解數據的含義，也可以避免不同報表之間指標口徑不一致的問題。同時，如果我們在指標系統上修改了指標的口徑定義，也可以同步到所有的呈現該指標的數據報表中。
第二，掌握任務影響了哪些數據報表。當某個任務異常，影響了下游多個任務時，我們往往要根據任務的影響范圍，決定任務恢復的優先級。如果任務影響了老板每天看的一張報表，而你卻不知道，沒有優先修復它，那你就等着被批吧。那我們要怎么知道一個 任務影響了哪些數據報表呢？在網易，數據報表在保存時，BI 工具可以把報表和數據的鏈路關系，推送給數據中台的元數據中心。當數據中台的任何一個任務出現異常，我們通過數據血緣，就可以快速找到這個任務影響了哪些數據報表，尤其是在故障恢復的時候，根據報表的優先級，我們可以優先恢復高優先級的報表。
第三，治理低價值的數據報表。根據數據中台的全鏈路數據血緣，我們可以計算每一個報表上游所有的數據加工成本，然后得到這個報表的成本。然后根據報表的訪問量和訪問人群，我們可以計算報表的 ROI（投入產出比），下線低價值的數據報表。
第四，全維度鑽取。在制作報表時，分析師只能依靠經驗去判斷一個指標有哪些可分析維度。如果 BI 工具能根據元數據中心提供的所有指標可分析維度，自動根據指標在各個維度下的取值，找出指標波動的原因，那這就是全維度鑽取了，它是目前業界最為熱門的研究領域，增強分析的一個方向。比如，有一個單車租賃公司，發現 8 月份的營業額下降了，系統通過根據各個維度的數據對比和分析發現，8 月份營業額下降，是因為那個月雨天的天數增多導致的。如果分析師不知道用天氣的維度去分析營業額，很可能就不知道原因。但是全維度鑽取，可以基於數據中台營業額的所有可分析維度，包括天氣，自動計算出雨天的銷售額相比晴天的銷售額低，同時進行交叉分析，發現 8 月份的雨天數量比其他月份多，最后找到問題的原因。你看，數據中台是不是很大程度上增強了 BI 工具的產品能力？ 在 BI 工具的基礎上制作數據報表，這才是數據應用的初級階段，接下來，咱們繼續看一下，基於數據中台，我們能做出什么數據產品，提升業務的運營效率。
讓技術人員不再是數據的搬運工，釋放取數效能
對於傳統行業來說，BI 部門一般有兩項職責，一個是做報表，一個是取數。而取數的工作量遠遠多於報表的工作量。一年中做的報表可能就幾百張，但是取數，一年可能要取幾千次，或者上萬次。而大部分傳統企業的取數會依賴技術人員，因為他們離數據更近，取數還涉及寫代碼，所以，如果你是非技術人員，根本不可能基於數據去做探索式的分析。所以，大量的取數工作就落在了懂技術的數據開發的頭上。
靠別人取數，會存在大量的溝通和協作的成本，同時因為公共集市層數據不完善，導致無法基於現有的數據，直接完成取數，需要數據開發加工新的數據，所以耗時會非常的長，一般需要一周時間。高昂的取數成本，壓制了取數的需求，也導致探索式的數據分析，根本不可能大規模的使用。對於數據開發來說，他們更希望自己的工作重心放在建設公共集市層的數據上，因為公共集市層越完善，取數的成本就越低，不需要額外的開發。但是他們忙於臨時的取數需求，根本就沒有時間和精力去做這些工作。最后就形成了不良循環，越是集市層數據不完善，取數的工作量就會越大（要開發新的模型），越多的時間去臨時取數，集市層越沒人建設。
這個問題該如何破解呢？ 我們研發了一個自助取數平台，叫 EasyFetch（意為簡單取數）。這個平台主要有這樣幾個優點：用圖形化的方式，替代了寫 SQL 的方式；提供了對業務人員比較友好的業務過程、指標、維度的概念，替換了表、字段；每個指標的業務口徑都能夠直接顯示；用戶通過選取一些指標和維度，添加一些篩選值，就可以完成取數過程；界面非常簡潔，使用門檻非常低。
數據研發
建設數據中台是一項系統性的工程，你不但要有技術的思維，更要有管理者的視角。所以接下來，我會帶你了解數據中台中三個最常見的協作流程：數據研發、數據分析、資產管理。我們一起看一下，不同角色使用場景化的工具產品是如何進行高效協作的？
也許在很多人的印象中，數據研發就是寫代碼，其實對大規模、標准化的數據建設來說，這遠遠不夠。標准的數據研發流程包括四個階段：需求階段、開發階段、交付階段和運維階段。每個階段中又涉及多個環節，如果你缺失了這些環節，就很容易出問題，數據也會因此沒辦法高效、高質量的交付。
需求階段
需求是數據開發的起點。如果想讓后面的流程高效運作，那需求的定義一定要清晰，這樣協作者（數據開發、應用開發、數據產品 / 分析師）對需求的理解才能一致。在數據中台中，數據需求通常是以指標的形式出現的，比如李天真提了個需求（計算每日黑卡會員的消費額），而承載這個場景的產品就是指標系統。那什么時候會提需求？又什么時候會頻繁用到指標系統呢？一般來說，分析師在制作新的報表，數據產品經理在策划新的數據產品時，會提一些新的指標需求，然后就會在指標系統登記指標（包括指標的業務口徑、可分析維度、關聯的應用、時間周期信息）。這個時候，指標的狀態就是待評審狀態。
然后，管理指標的數據產品（沒有這個角色的，分析師也行）會叫上相關的數據開發、應用開發、提出這個需求的分析師或者數據產品，對指標進行評審：
指標是新指標還是存在的指標；如果是新指標，那么是原子指標還是派生指標；確認指標業務口徑、計算邏輯和數據來源。那評審后的結果又是什么呢？如果是新指標，就在指標系統上錄入相關信息，指標狀態是待開發狀態；如果是存在的指標，應用開發可以直接找到這個指標所在的表，然后看這個表是否已經有現成的接口可以被直接使用，如果有，就直接申請授權，如果沒有，可以基於這張表發布一個新的接口。
研發階段
現在，新指標的狀態是待開發狀態，接下來就要進入開發階段。在這個階段，你要秉持“先設計，后開發”的理念。為啥這么說呢？因為很多開發都習慣邊開發、邊設計，想到哪里，代碼寫到哪里，這其實並不是一個好習慣。這會造成缺少整體的設計，開發過程中經常出現表結構頻繁修改、代碼返工、整體研發效率不高。所以說，我們要先做好模型的設計，而承載這個場景的工具產品就是模型設計中心。這里我再強調一下，數據開發在設計的過程中，可能要用到一些已經存在的數據，這時就要利用數據地圖發現已經存在的表，然后理解這些表中數據的准確含義。除此之外，在模型設計過程中，要對模型中每個字段關聯前面設計好的指標，以及可分析的維度。
這里你要注意一下，數據域的負責人一般是數據架構師，他需要檢查數據是不是重復建設，要保證自己管理的域下模型設計的相關復用性、完善度、規范性的相關指標。當然了，除了新建模型之外，已有模型也會存在變更的情況（比如增加一個字段或變更字段枚舉值）。這個時候，要根據數據血緣，通知所有依賴這個表的下游任務的負責人，在負責人確認以后，才能進行模型變更。
比如，甄可愛是一名數據開發，她接到需求完成模型設計之后，就要開始模型的開發了。首先她要把數據從業務系統導入數據中台中，那她第一步就要申請對應數據庫的權限，然后在數據傳輸中心建立數據傳輸任務，把數據同步過來。
接下來，要清洗和加工數據，那她要在數據開發中心開發數據的 ETL 任務，根據之前模型設計，編寫對應任務的代碼。任務代碼完成以后，甄可愛要在數據測試中心，驗證數據：一個是進行數據探查，確定新加工的數據是否符合預期；另外一類是對原有模型的重構，新增字段或者更新部分字段。此時不僅要驗證新加工數據的正確性，還要確保原有未修改數據與修改前是否有改變，我們管它叫數據的比對。數據測試中心還提供了靜態 SQL 代碼檢查的功能，主要是發現一些使用固定分區、使用測試環境的庫、使用笛卡爾積等代碼問題，我們把這個過程叫 SQL Scan。 在我們的開發規范中，只有通過 SQL Scan 的代碼才被允許發布上線。
在數據測試完成后，甄可愛還要在數據質量中心里配置稽核校驗規則。目的是對任務產出的數據進行校驗，在數據出現問題時第一時間發現問題，快速地恢復故障。在開發規范中，主鍵唯一性監控、表行數絕對值以及波動率監控等屬於基礎監控，是必須要添加的，另外還需要根據業務過程，添加一些業務規則，比如一個商品只能歸屬一個類目等。配置完稽核規則，甄可愛要任務發布上線了。任務發布上線，要設置調度周期，配置任務依賴，設置報警規則以及報警對象，選擇提交的隊列。任務發布與模型發布一樣，也需要進行審核。首先甄可愛需要發起任務發布上線的工單，然后工單會根據產出表所在域流轉到對應域負責人賈英俊審批，審批的主要內容：確認任務參數設置是否合理，比如 Spark Executor 分配內存和 CPU 資源；檢查任務依賴、報警設置是否正確，核心任務必須要開啟循環報警，同時要開啟報警上報；重點審核稽核規則是否完備，是否有缺失需要補充。
在審批通過以后，任務就會發布上線，每天就會有數據源源不斷的產生了。到這里，甄可愛就完成了所有模型研發的流程了。你看，雖然是一個模型研發的環節，可涉及這么多的工具產品，還包括了多個審批流程，但是這些工具和流程，都是標准化研發不可或缺的。例如如果不測試，就會導致大量的 BUG 上線，如果沒有稽核監控規則配置，就會導致出了 BUG 還不知道，等着被投訴。而數據研發完，接下來就是數據的交付了，如何讓數據快速接入到數據應用中呢？
交付階段
在數據中台之前，其實並不存在單獨的交付階段，因為數據開發加工好數據應用需要的表，他的工作就已經結束了，剩下的就是應用開發的事兒了。應用開發需要把數據導出到應用所屬的數據庫，然后開發 API 接口，供客戶端調用。數據中台，提出了數據服務化的思想，數據中台暴露的不再直接是數據，而是服務。數據開發不僅需要加工數據，還需要把數據發布成 API 接口或者其他服務形式，提供給業務系統或者數據產品調用，從而形成了單獨的數據交付階段。數據服務承載了數據交付的整個流程。數據開發，可以直接選擇一張數據中台的 Hive 表，然后在數據服務上創建一個數據抽取任務，把數據抽取到中間存儲中（中間存儲可以是 DB，KV，MPP 等）。這個過程，數據服務會自動根據中台數據的產出時間，在調度系統中創建數據導出任務，建立到產出任務的依賴。接下來，數據開發可以基於中間存儲發布 API 接口，定義輸入和輸出參數，測試 API 后發布上線。這個時候，數據開發的工作才算完成。最后，應用開發在數據服務上創建應用，然后申請對該接口的授權，等數據開發審批通過后，就可以直接調用該接口獲取數據了。數據交付完呢，還不算完，接下來數據開發的工作，還需要保證任務的正常運行，這就進入了第四個階段，運維階段。
運維階段
承載運維階段的工具產品主要是任務運維中心。在這個階段的第一責任人是任務負責人（一般是這個任務對應的數據開發）。這里有這樣幾個過程：數據開發接到報警后，要第一時間認領報警；任務運維中心提供了報警認領的功能，數據開發點擊認領，代表數據開發開始處理這個報警；如果報警遲遲沒有人認領，任務運維中心會每隔 5 分鍾會發起一次電話報警，直到報警認領；如果報警一直沒有認領，系統會在 3 次報警，15 分鍾后進行報警的上報，發送給模型所在域的負責人。這樣的機制設計，確保了報警能夠在第一時間被響應，我們在實施這項機制后，報警的平均響應時間從 2 個小時縮短到 15 分鍾內。那么當數據開發認領報警之后，需要開始排查，首先要確認上游依賴任務稽核規則是否有異常（也就是輸入數據是否存在異常）。如果沒有異常，數據開發要通過任務運行日志，排查當前任務的問題原因，並進行緊急修復，接下來再重跑該任務，任務重跑完，還要通過數據地圖，找到所有依賴該表的下游任務負責人，發送“下游任務需要進行重跑”的通知。
故障恢復完，還要進行復盤，其中重要的事情就是補充稽核規則，確保不再出現犯過的錯誤。通過這樣不斷沉淀和記錄，數據中台的數據質量就會越來越高，數據質量問題也會減少。
數據分析
根據我的經驗，我把數據分析過程划分五個步驟。接下來，我通過一個例子，為你呈現了一個典型的數據分析流程。
第一步：發現業務問題。數據分析的典型場景呢，起點都是業務出現了某個問題，我們需要基於數據找出業務問題背后的原因。電商平台 Q2 季度某個品類的商品銷售額下降了 30%，老板要求給出問題的原因，並進行整改。這個任務落到了她的身上。 要解釋這個問題，她必須要從現有的數據入手，看看到底是哪里出現問題。
第二步：理解數據。她首先要了解這樣幾點：要分析的業務過程；這些業務過程中涉及到了哪些關鍵指標；這些指標的業務口徑是什么；有哪些可以分析的維度。這些事兒比較瑣碎，為了提高效率，利用指標系統，將要分析的業務過程快速鎖定到交易域下的業務過程，然后找到交易域下有哪些指標。通過指標系統，了解了“渠道銷售額”這個指標的口徑定義、計算邏輯和數據來源。接下來，去查看指標對應的數據，借助指標系統，可以直接跳轉到指標關聯到數據報表上，接下來需要申請報表的權限，查看數據。報表負責人審批通過后，就可以看到數據了。
這個時候發現，淘寶渠道銷售額數據出現下降，拖累了整體品類銷售額的數據。可是當想進一步探查渠道下降的原因時，卻發現並沒有渠道級別的商品庫存和銷售指標。現在，靠現有的指標和數據已經沒辦法進一步解讀業務問題的原因了，需要進行探索式分析。
第三步：探索式分析。首先要找到當下有哪些數據可以用，借助數據地圖，可以快速了解當前主題域下有哪些表，這些表分別代表什么含義。這個時候，會存在兩種情況：如果現有的數據可以滿足分析的需求，可以直接在數據地圖表詳情頁上發起數據權限的申請流程；如果現有的數據沒辦法滿足需求，就要對數據開發提出數據研發的需求，會稍顯麻煩。幸運的是，發現，商品粒度的庫存和銷售表中有渠道的字段，按照渠道進行聚合、過濾，就可以滿足分析的需求了。所以，在數據地圖的相關表詳情頁里申請了這些表的權限。
接下來，權限申請流程會流轉到表對應的負責人上：對於核心表（比如交易數據），除了表負責人審批，還需要中台負責人審批；核心表中的一些核心 KPI 數據（比如平台全年銷售額），還需要 CTO 甚至 CEO 級別的審批。等了一段時間，權限審批終於通過，收到了來自權限中心的通知，於是馬不停蹄地在自助分析上，基於 SQL 對相關表進行了探查分析。對比分析后發現，淘寶渠道銷售數據下降的主要原因是：該品類下的部分暢銷商品經常庫存為 0，出現缺貨情況，導致整體品類銷售額下降。
第四步：可視化展現。現在，找到了問題原因，為了給老板講清楚分析過程，還要通過報表的方式，把分析過程呈現出來。所以，又在 BI 工具網易有數上進行了報表的制作，把報表授權給相關的管理層。看到了原因后，管理層制訂了供應鏈優化措施，加大了淘寶渠道的庫存供貨，整體品類銷售額數據出現回升，終於解決了問題。
第五步：分析過程產品化。解決了現有問題，並不是數據分析的終點。我們還要建立長久的問題發現和解決機制。為了持續地監控該問題，並對其進行智能預警，需要將分析過程固化到數據產品中。策划並研發了供應鏈決策協同系統，能夠自動檢測商品的庫存和銷售，智能生成補貨建議，然后推送給采購系統。到此，整個數據分析的全過程就完成了。
最后，我想再強調一個點，在這五個步驟中，你往往最容易忽略是最后一個步驟。當然，這也並不只是分析師的疏忽，本身數據產品的建設還需要有一定的研發資源的投入。為了解決大規模數據產品研發資源投入的問題，在網易，我們基於網易有數（BI 工具）實現了數據門戶的功能，它實現了一個低代碼構建數據產品的開發環境，允許分析師通過拖拉拽的方式構建企業數據門戶，從而為高效的大規模數據產品構建提供了基礎。基於數據門戶，企業可以構建商品運營系統、供應鏈協同決策系統、流量看板系統、會員運營管理系統等不同的數據產品，滿足不同場景下數據分析的需要。數據如何被使用講完，接下來，我還想來談談數據的精細化管理流程，因為這個流程或者環節的缺失，會導致很多成本、安全、以及穩定性的問題。
最佳實踐
而且建數據中台是一項系統性的工程，涉及人員組織架構的變動，需要研發大量的系統支撐工具，更要和業務部門達成密切的合作，形成雙贏，反之會有失敗的風險。還是分享一件我見過的事兒。甄英俊是某零售企業 IT 部門的老大，最近他也想在企業中建數據中台。設想一番后，他親自操刀，組建了新的數據中台部門，還親自規划了十個業務場景（包括會員看板、商品運營、供應鏈管理、售后管理、毛利分析、類目管理、門店管理、倉儲管理、渠道分析、輔助選品）。但數據中台團隊沒有和業務部門達成一致的 KPI，在具體工作推進過程中，中台團隊與業務部門脫節，業務部門也沒有資源支撐中台的推進（例如指標的梳理）。最后，雖然基於原先規划的十個場景，數據中台確實做出了一些報表，但很少有人查看。於是，尷尬的一幕發生了：在年終總結匯報中，甄英俊自信地向 CEO 匯報了數據建設的成果（輸出了多個報表，覆蓋了多少業務場景）。可當 CEO 問業務老大是否感覺到數據的作用？業務老大搖了搖頭，他們並沒有認可數據中台的成果。這是一個很典型的失敗項目，而問題的根源就在於數據中台團隊雖然獨立於業務，但是並不能脫離業務。 甄英俊最大的失誤就是沒有深入調研業務問題，也沒有和業務達成一致的 KPI，更沒有根據業務的反饋，不斷完善數據應用。所以，如果你要建中台，要做到這樣幾點：
問問自己為什么要建中台，與業務達成一致的目標；
把數據中台作為一個公司級別的頂級項目來推進，而不是一個數據部門自己的 KPI；
數據中台必須要有清晰的、可量化的價值來衡量（從主觀上也要得到業務部門的認可）。
立項數據中台項目
我認為，立項是建數據中台最關鍵的一步，因為它的核心就是挖掘業務的痛點，跟業務達成一致的建設目標。如果能達成一個一致的、可量化的目標，數據中台的項目就成功了一半。這里我多說幾句，對一些傳統企業來說，業務部門的數據思維能力比較薄弱，數據使用水平還比較初級，根本講不出什么痛點。如果遇到這種情況，你要多關注一下業績目標（比如，如何讓數據幫助企業達成 KPI）。 如果談論這種話題，業務部門的老大一定很感興趣。經過調研，我總結了這樣幾個痛點。
第一，指標業務口徑不一致。
第二，需求響應速度慢。
第三，取數效率低。我們問了很多的分析師、運營，他們集中認為取數效率太低，原因有兩個。一個是他們不知道有哪些數據，也不知道到哪里去找數據。當時整個電商團隊存在三個小數倉（供應鏈、市場和倉配客）加起來有近 4W 張表，對他們來說，找到並准確理解數據，其實是非常困難的事情。另一個是，基於 SQL 取數，對於非技術人員來說，門檻比較高。分析師經常遇到一個 SQL 異常就不知所措，更不要說不懂 SQL 的運營。
正是因為這兩個原因，取數要靠數據開發幫助完成，效率很低。有多低呢？平均取數需求從提出到交付，需要一周（數據來源於項目管理工具 JIRA）。而這也抑制了數據的大規模使用，與此同時，臨時取數的需求，占據了數據開發的大量時間（來自 JIRA 的數據統計，數據開發 50% 的時間都被臨時性的取數需求占據）。
第四，數據經常違反常識。糟糕的數據質量也是各個業務部門對數據最為不滿的地方，經過 POPO 群統計（網易內部辦公協作通訊工具），平均每周，我們就有 10 個數據質量問題被業務方投訴。更為可怕的是，這些問題中，90% 都是由業務方先於數據提供方發現的問題，然后 50% 都是因為數據研發的 BUG 導致。在當時，我們經常出現數據經常無法按時產出，數據修復需要花費一天的時間！
第五，數據成本指數級增長。2018 年，電商業務的大數據資源從一年 4000CU(1 CU = 1 Core + 4 memory) 增長到 12000CU，並且還在持續高速增長。當時正好是 2018 年底，公司對業務毛利這塊兒管控得非常嚴格，精簡成本作為了各個業務推進的優先級，大數據這塊也不例外。為了優化大數據的成本，我們排查后發現，至少有 20% 的數據在當時都屬於廢棄數據，這些數據每天仍在產生，卻沒有人訪問，浪費着資源。
除了現有數據是否用得好以外，我們也對各個部門的業務目標進行了調研，目的就是讓數據幫助解決更多的業務問題。
商品部門：主要目標是優化商品結構、降低滯銷商品比例、提高商品庫存周轉，從而達到控制毛利水平的目標。所以他們最緊急的就是監控平台上滯銷的商品。供應鏈部門：主要目標是盡可能保證商品的供貨充足，盡量避免缺貨商品出現。所以及時發現缺貨商品，制訂更精准的采購計划是最緊急的事兒。倉配客部門：最重要的業務目標是保障商品及時送達，優化物流成本。所以，基於各個倉庫的數據和物流公司的報價，制訂最合理的配送計划，是他們最重要的事兒。
推進數據中台項目落地
第一步，調整團隊組織架構，明確各個團隊的職責。在數據中台構建之前，電商業務主要存在 3 個獨立的數倉：市場、供應鏈和倉配客。這些業務部門中有數據開發、數據產品還有分析師。而我們首先要做的，就是成立數據中台團隊，這個團隊是在原有市場數倉（除了服務市場，還服務於管理層）的基礎上建起來的。而對供應鏈和倉配客，我們並沒有立即把他們的數據開發團隊並入中台團隊，而是調整了團隊職責，把他們的數據開發的職責調整成，基於數據中台數據，加工私有的集市層和應用層。這樣處理的話，各方比較容易接受，不然業務部門會覺得中台團隊在搶他們的人，對於員工個人，也可能因為團隊定位、福利等原因不願意轉部門。
第二步，數據整合。中台團隊成立后，首先面對的是混亂的指標業務口徑，所以團隊要先梳理指標，建立全局的指標管理規范（對應咱們的 05 講）。這項工作由 1 名數據產品牽頭，2 名數據產品輔助，對電商分布在各個業務線的 20 多個數據產品，800 多個指標進行了梳理，去除了冗余指標，對齊口徑不一致的指標。最后，我們把指標梳理成 400 個，其中，原子指標 127 個，這個過程花了 1 個月的時間，不過大部分時間都是在理解業務，和業務的分析師、數據產品對口徑。接下來，中台團隊還要對模型進行重構、整合和遷移（對應咱們的 06 講），而這部分工作可以分為設計階段和實施階段。設計階段，由一名數據架構師牽頭，根據梳理好的指標，構建主題域，然后在原有模型的基礎上進行重新設計，構建一致性維度。這里需要強調的是，中台團隊必須要完全接管 ODS 層數據，這可以強迫業務部門必須要基於中台數據進行再加工。當然，中台團隊會肩負着巨大的壓力，但是只有熬過最痛苦的時期，這種中台的機制才能建立起來，一旦原始數據沒有管住，那中台就會功虧一簣。
第三步，研發工具產品。在數據中台構建過程中，我們積累了很多規范和經驗，但數據中台如果要形成落地、長久的運行機制，就必須把這些規范和經驗沉淀到產品中，通過產品化的方式實現。所以在原有數據研發、數據產品團隊的基礎上，我們開始構思數據平台（工具產品）研發團隊。因為考慮到網易集團存在公共技術研發部門（杭州研究院），可以實現工具產品在集團內不同業務線之間復用，所以選擇了與公技合作的方式，由公技承擔數據中台支撐技術產品的研發。
第四，數據產品構建。最后，就是業務支撐。我們通過構建數據產品，幫助業務達成業績目標。我們的重點是商品和供應鏈。分別研發了商品運營系統和供應鏈輔助決策系統，大幅度提升了業務決策的效率。數據產品團隊，我們有 10 個人的團隊規模，主要負責數據產品研發。
總結數據中台項目成果
耗時一年半（實際執行一年的時間），我們完成了電商數據中台的搭建，並產出了一些階段性的成果，對於成果這部分，你可以重點參考一下，因為你也可以通過這種方式，說服你的老板啟動數據中台的建設。
數據中台從哪里來？
關於組織關系，我曾經說過，數據中台的團隊必須獨立於業務部門，同時又不能脫離業務。獨立於業務，是因為數據中台要實現多個業務之間數據的共享，如果在業務部門內部，單個業務部門沒有動力去做這個事情。那為什么不能脫離業務呢？ 這就與今天的話題密切相關了。因為數據中台必須要解決業務的問題，我記得之前在和嚴選數據部門負責人交流時，他有一句話讓我印象深刻，他說：“數據中台各項指標建設得再好，都比不上業務部門老大在管委會上，說一句數據有用，什么數據幫他們解決了什么問題。”我覺得，這其實反應了一個根本問題，那就是業務部門的口碑，是數據部門的生命線，如果沒辦法獲得業務的認可，數據做得再多，也是無用功。那么要解決業務的問題，得先搞清楚業務存在哪些問題。我把這些問題歸結為兩類：
第一類是數據用的好不好的問題；第二類是怎么讓數據幫助業務解決更多的問題。
據我所知，很多企業已經擁有了大數據研發的基礎，也有了不少數據應用的場景，但是數據到底用的好不好，這是他們面臨的最大的問題。從業務的視角看，需求響應速度慢、取數效率低、指標口徑不一致、數據經常無法按時產出，違反常識，甚至是高昂的大數據成本，種種原因讓很多想用數據，但是對成本比較敏感的業務望而卻步。這些問題最終導致數據在業務部門用的並不好。我清楚記得，在數據中台構建前，一個業務部門的負責人向我反饋說：“別看現在有 3000 多張報表，其實能用的不超過 10 張，因為指標口徑都不一致，根本無法用，不知道相信誰。“這個時候，數據中台要解決的核心問題就是效率、質量和成本的問題。只有解決好這些問題，才能讓數據用的好，業務部門用的爽，真正實現讓更多的人使用數據的目的。第二類問題，是如何讓數據幫業務解決更多的問題。對一些企業來說，尤其是傳統企業，如果連數據應用場景都還沒有，你去跟他談效率、質量和成本，他們根本就不會關心，因為他們還沒有到達這個階段。所以，對他們來說，數據到底能解決什么業務問題才是最重要的，因為他們還沒嘗到數據的甜頭。比如，某項業務指標出現下降，你能基於數據，幫他找到下降的原因，並解決，那業務就會很認可數據的價值。
數據中台到哪里去？
當然，數據中台的價值最終是要回到業務價值上來的。對數據部門的負責人來說，最尷尬的地方，就是數據中台並不能直接產生業務價值，他們需要前台（也就是數據應用）來接觸業務，所以數據中台的價值，最終還是要通過數據應用來體現。對應於前面兩類業務問題，我認為數據中台的價值，最終也是體現在數據用的好不好和數據解決了什么業務問題上。數據用的好不好，主要看這樣幾點：
數據需求的交付時間到底有沒有縮短；
還存不存在指標業務口徑不一致的問題；
數據質量是否有顯著的提升；數據成本是否增長變慢了。
其實我主要是想讓你明白一個基本的道理：數據中台和業務的關系，就是魚和水的關系，誰也離不開誰，不能把它們完全分開來看。業務想要獲得更大的增長，就必須依賴數據中台，數據中台想要存活下去，就必須依賴業務的口碑和認可。這也是我這十多年來，數據建設過程中最重要的一條經驗了。
總結
以后關於數據中台系列的總結大部分來自Geek Time的課件，大家可以自行關鍵字搜索。