本文根據神策數據聯合創始人 & CTO 曹犟發表的《數據治理中的一些挑戰與應用》主題演講整理而成。
本文將為你重點介紹：
- 數據治理的概念與重要性
- 數據治理面臨的挑戰
- 數據治理與組織架構
- 數據治理中的應對
許多大數據公司在過去一段時間都得到了較好的發展，究其原因是因為恰逢專注於業務流的信息化建設正在向數據化轉型。
但在很多時候，數據其實還只是 IT 化的“副產品”，早期的工作思路仍然圍繞如何將業務 IT 化，而數據只是這個過程中自然而然產生的結果，即所謂的“副產品”。
由於在數據生產的過程中並未做到足夠重視，數據質量與可靠性則很難得到保證，這也是數據治理在現在得以被重視的重要原因。
在業務 IT 化的過程中，企業通過第三方廠商、自研等方式構建多種數據系統，採用多種系統中的數據化治理，是實現數據效能、數據驅動業務的關鍵步驟。
早期，企業用信息技術去構建業務流，而現在，我們試圖用信息技術，特別是互聯網行業中的一些大數據處理以及分佈式處理技術構建數據流，但在構建過程中，過多強調技術本身而忽視了對數據的治理。
數據治理是整體性問題，並非僅是技術問題，市面上數不勝數的商業組件可以解決如何對數據進行存儲、查詢等問題，但是在實際的業務情況下對於數據治理這樣一個系統性工程，目前卻並無現成的產品或技術可以直接解決。
我們可以嘗試用數據治理的角度來解讀上圖。
構建數據流的過程，很大意義上是為了解決分佈在 IT 系統裡各個不同子系統之間的數據孤島問題，用一條完整的數據流將不同子系統之間的數據孤島打通，同時應用於不同的應用場景，這個打通的過程，就是某種意義上的數據治理。這也反映了我之前尤為推崇的一個觀點——構建數據倉庫本身就是一個數據治理的過程。
另外，對於數據的本質，我一直推崇如下兩個定義：第一“信息是用來消除不確定性的”，第二“大數據的本質，就是用信息來消除不確定性”。
同樣，對於數據驅動在業務決策和產品智能兩大方面的應用，也都將建立在數據治理的基礎上才有意義。
一、什麼是數據治理？
數據治理的本質是組織對數據的可用性、完整性和安全性的整體管理。
1. 數據治理的本質
可用性指數據可用、可信且有質量保證，不會因為分析結果的準確性造成偏差，從業者可以放心地根據數據結果做業務決策；完整性分為兩個方面，一方面指數據需覆蓋各類數據應用的需要，另一方面指不會因為數據治理沒有到位而造成數據資產的流失，也即影響數據資產的積累，這也是神策數據在創業伊始便開展私有化部署的原因；安全性指治理和分享過程需安全可控，不侵犯用戶隱私，且不會給組織留下安全隱患。
2. 數據治理的重要性
數據治理是所有數據應用的根基，數據治理的好壞直接影響所有數據應用的價值。
無論是基於數據看報表，還是做交互式的多維分析，還是做更復雜的個性化推薦，所有的數據應用都需要有一個良好的數據治理結果。
神策本身就擁有一款推薦產品——神策智能推薦，通過這款產品的實踐，我們發現，它的實施週期相比其它幾個產品普遍偏長，這也是因為個性化推薦對於數據的質量和準確性要求相對更高。
簡而言之，數據應用做得越深入，所需數據就會更多，對數據質量也會有更高的要求。
數據治理是組織數據資產沉澱的基礎，數據治理的好壞直接決定了組織的數據資產能否得到沉澱，能否充分地發揮價值。
經常會有客戶主動來詢問：
“領導說我們要做一個數據中臺沉澱數據，但不知具體原因，亦不清楚搭建中臺的具體目的，可能要等搭建之後尋找數據價值時，再去探索具體應用。”
個人認為，在經費條件允許的情況下，當然可以將企業的所有數據整合在一起，通過良好的權限管控，充分的共享，聚合所有的業務部門一起去探索數據的應用，因為數據中臺本身就承載著組織內部所有數據的整合分享角色。
二、數據治理面臨的挑戰
本部分的內容將數據治理面臨的挑戰分為兩類，一類因“技術”而起，一類因“人”而起。
由客觀的技術問題對數據治理帶來的挑戰普遍較好解決，比如如何採集數據、如何存儲數據等，都可通過更先進的工具、更新的技術等方式解決。
而由人或組織架構帶來的問題相對複雜，它的背後包含的是企業在文化、流程上的問題，可以通過以下實例說明。
1. 多業務系統多數據源的整合挑戰
企業想要做的數據應用越多，所需的數據就會越多，所要去獲取的數據源也會增多，而相應的數據處理也會越多，這是一個極為顯而易見的問題。
對於神策數據而言，我們在數據應用方面相對“單純”，主要針對用戶行為領域，採集用戶行為數據，從客戶端、服務端、數據庫等做對接。
但即使是這樣一個限定特殊領域的應用，我們在整合多方面數據源上也會碰到非常多的挑戰，可想而知在面對多業務系統多數據源的情況下將更加困難。
2. 數據採集技術上的挑戰
近年來，許多公司都在嘗試將自己的業務線上化，都需要通過數據對用戶進行分析與運營，如何精準採集可用的用戶數據以及其他相關數據，都將是數據採集在技術層面上面臨的挑戰。
3. 用戶隱私與安全挑戰
用戶隱私與安全不僅是對技術挑戰，更多的是一種意識上的挑戰。企業需要準確把控數據採集的紅線，比如針對歐盟範圍內的國際業務，就需要參考 GDPR 的相關規範。
在國內，很多銀行券商等企業也同樣擁有一套完善的數據合規要求，甚至已經細化到“某個特定字段對於某一個特定人可看但不可下載”的程度，這些都是需要在進行數據治理時考慮的因素。另外，如果需要在公網傳輸交換數據，也同樣需要思考數據如何防止竊取和偽造的問題
4. 組織架構與部門隔閡帶來的配合
部分組織在數據治理的過程中速度過慢，成效不好，其中一個很重要的原因是權責、部門配合等方面存在問題。很多情況下，生產數據、使用數據、分析數據的工作人員分佈在不同的職能線與部門，角色不同，立場也不同，這些客觀存在的影響因素都會影響整個數據治理的最終結果。
5.業務持續迭代中帶來的挑戰
在互聯網行業中，尤其是業務迭代較為迅速的團隊裡，通常存在“1.0 版本的數據質量最優，1.1 版本不行，2.0 版本完全不可用”的說法，說明第一次做數據治理時，極重視數據質量，會有完善的流程來保證埋點的準確性，本身也沒有太多的包袱；而在後續的產品迭代中，如果流程和標準的迭代相對滯後，整個數據治理的結果也會隨著受影響，最終導致整個數據質量低劣，直至所謂的“完全不可用”。
下面舉兩個具體實例說明。
實例 1.
某公司的業務部門向第三方數據分析平臺提出數據需求，該公司內部有多個 App 頻道，每個頻道隸屬於一個單獨的部門，而第三方數據分析平臺在埋點採集階段需要不同部門的團隊相互配合。由於缺乏統一各部門需求與任務的統籌角色，實施過程中很難清楚劃分相關責任，再加上管理、測試等工具的缺失，最終導致每次發版都會發生埋點丟失和報錯。
實例 2.
某企業的所有用戶相關數據分散在不同的系統裡面，試圖通過第三方數據分析平臺整合統一的用戶標籤數據系統。然而在收集數據的過程中，每跨一次部門就需要提一次全套的審批流程，好不容易收集齊各部門各系統中的數據之後，卻發現數據統計口徑不一致，無法得到一個公司統一的用戶標籤數據。
三、數據治理與組織架構
上述內容已經提到關於組織架構的內容，因其重要性將在本部分單獨說明。
1. 數據治理是一個動態的過程
數據治理實際反映的是組織問題、文化問題，這也是許多公司為了明確權責劃分而建立數據治理委員會的原因。同時，還需要明確的程序與執行程序的計劃，明確的程序指對數據進行治理所需經歷的階段、問題有明細的瞭解，執行程序的計劃指每一步需要解決哪些問題。當公司的主流業務發生變化時，組織架構會隨之改變，接而帶來數據治理層面的變更，所以，數據治理是一個動態的過程，伴隨整個業務變更與組織架構變更。
2. 數據治理中的兩個核心角色
- 第一，數據使用者，通常集中在產品經理、數據分析師、營銷經理、運營經理等崗位，有查看報表、數據分析、用戶畫像、用戶運營等需求，他們屬於數據治理的受益者。
- 第二，數據生產者，通常集中在前端開發、後端開發、數據工程師、ETL 工程師，有埋點、打日誌、做數據 ETL 的需求，他們屬於數據治理的付出者，可能看不到直接收益，反而增加工作負擔。
由於數據使用者屬於數據治理中受益的一方，多數情況下需由其來推動數據治理任務進行。
在神策數據的具體實踐中，我們非常強調對客戶接口人，通常情況下也就是數據使用者的培訓，由他去推動整個流程，去了解數據生產者的實際情況，從而讓數據治理工作更好地進行。
四、數據治理中的應對
首先，數據治理的核心認識是，數據治理是一個持續並且長久的一個過程，不同的產品可以解決比如採集、傳輸等數據治理層面上的不同問題，但並不存在一款所謂的“數據治理產品”，可以用來解決所有問題。
其次，數據治理的整體方法論是“從應用倒推”。先確定數據應用、數據資產的需求，接著確定需要哪些數據，之後確定需要從哪種數據源獲取數據，最終確定具體的數據治理方案。
神策憑藉近年在實際業務中的經驗，圍繞用戶行為分析領域，總結出一套數據治理方法論。
- 第一步，確定分析需求。通過了解數據使用者需要看哪些指標、用在哪些場景、使用哪些分析模型等方面來了解具體的數據使用需求，完成需求梳理。
- 第二步，映射數據模型。在該步驟需確定採集的事件和屬性，並完成事件設計。
- 第三步，確定數據採集技術方案。根據要採的事件和屬性，結合現有實際業務系統，去確定到底要從何種系統裡以何種技術方案採集數據。
- 第四步，數據採集與集成。這一步就是指具體的開發、集成工作，包括完成相應的 SDK 集成、數據採集工具的開發、數據 ETL 開發等。
- 第五步，數據校驗和上線。這一步中需要使用必要的測試工具、利用埋點管理平臺做數據對比等。
下面，舉例說明數據治理的三大原則：
數據治理原則 1：不要先汙染後治理，要從源頭控制
在創立神策數據之前，我們曾長期參與百度的日誌數據相關的工作。在最開始的階段，所謂的日誌處理就是通過中控機器，從不同的業務系統裡下載文本日誌，跑完腳本後生成報表，再通過郵件的形式分發。
2008 年，團隊解決了之前方案中的技術架構的問題，把以前的單機系統變成了分佈式系統，提高了整體性能與計算效率，用分佈式的方式下載日誌，用分佈式的方式來計算報表。但是，我們本質上只提供了一個計算的調度平臺。就數據本身而言，沒有人知道這些海量數據其中的細節，數據沒有得到充分的複用，造成了許多計算資源的浪費。所以，這部分的工作其實只是解決了一個技術問題，但並沒有解決任何數據治理方面的問題。
意識到數據治理的問題之後，團隊中開始了百度用戶數據倉庫的構建工作。有工程師每天將文本日誌用程序轉成結構化日誌，並在進行必要的數據清洗、Union、Join 等 ETL 的工作之後，將這些結構化日誌統一映射到一張大表（今天 event 模型前身），並對外提供集中訪問。
但隨著產品線不斷增多，入庫週期變得更長，到後期，每增加一條產品線，都需要付出至少一週時間去解決。同時，由於數據在產生後需要做 ETL，從產生到傳輸到統一的 Hadoop 集群需要時間， ETL 的計算也同樣需要時間，即使在最佳情況下也只能保證半小時的時效性。
這是一個典型的數據“先汙染後治理”的例子，不僅在治理上需要付出更多的代價和成本，數據本身的可用性和時效性也會受到影響。
之後，我們嘗試通過推行全百度統一的 Logging 平臺，從打日誌開始就保證數據的正確性，並且直接將數據傳輸到分佈式集群上以保證數據的可用，這就是從源頭來治理數據的思路。
在創立神策之後，我們就充分吸取了這些教訓，通過 SDK 或者其他工具去嚴格控制數據埋點格式及數據模型，盡最大努力減少 ETL 的代價，從而保證查詢時效性與導入時效性。所以，數據治理要從源頭開始，不要先汙染後治理。
數據治理原則 2：數據治理的過程要貫穿到整個業務迭代的過程中
以軟件開發流程為例。
首先，在產品需求階段，同樣需要去明確數據需求。在具體設計階段，完成產品交互系統架構變更的同時，去確定要加哪些日誌、字段等。
在實際開發階段，完成相應的代碼開發、日誌變更，單元測試應包括相應的日誌變更部分，並進行日誌審計，不要將埋點當成一個單獨的開發任務，而是伴隨的過程。在
測試階段，當測試整體性能的正確性的同時，測試數據、日誌的正確性，確保功能符合預期、日誌打印正確，可以滿足分需求。
在上線階段，要實際查看上線的埋點、日誌是否正確，並對功能進行確認。
最後，在項目總結階段，用數據說明轉化率變化、流程優化情況，對功能完成程度的總結，嘗試真正地用數據說話。
數據治理原則 3：以產品化、組件化的思路來解決，不能依賴於人工
以產品的方式解決客戶端數據採集問題。
神策的開源 SDK 被許多業界同仁參考學習，究其原因是因為它用產品的方式解決客戶端數據採集問題的思維，無論是電商、社交、金融、遊戲，還是哪一種產品，都會在客戶端採集用戶數據時面臨匿名 ID 生成、基礎屬性採集、數據打包壓縮加密、本地緩存、網絡傳輸、時間校準、根據數據模型限定了採集數據的 Schema、通過全埋點等方式提供了對常見數據的自動採集功能、結合後端提供了對於採集端調試功能等場景，所以，可以用產品思維來解決的問題，不依賴人工。
作者：曹犟，神策數據聯合創始人 & CTO
本文由 @神策數據 發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
