導讀：數據治理經過多年的沉淀，積累了比較完善的理論體系；但是落地時候，治理范圍如何聚焦，數據產品如何定位、具象設計和推廣運營，不同公司有著不同的設計實現。本文會結合貝殼找房近兩年的業務數據中心建設經驗，從產品視角來談談數據治理的問題。主要內容包括：

數據治理目的及內容

結合公司特點聚焦治理范圍

中臺側實踐的建設內容及思路

治理項目的目標管理

產品及運營落地經驗

01數據治理目的及內容

1. 貝殼找房介紹

貝殼的主要C端產品是貝殼找房app，圍繞居住領域，提供二手、新房、租賃、裝修等品質服務。

2. 數據治理目的

數據治理的終極目的，是提升數據的使用價值。數據是公司的重要資產。數據使用包括兩方面：一是通過數據為用戶提供更好的服務，如推薦算法；另一方面是利用數據，來為管理提供抓手，更高效地管控業務，在這種情況下，功能創新和管理提效，都依賴于數據被更好地利用，這也是數據治理要解決的核心問題。以下是提升數據使用價值的三個方向。

① 共享

共享性的提升，是指讓公司內部所有的要用到數據的同學，知道公司有哪些數據，找人找數更加便捷。首先從業務視角來看，在日常的需求對接中，通常會通過郵件、PRD、共享文檔等載體來管理和記錄數據，一旦發生人員調轉，或者業務組織架構調整，數據的背景前提就無法考證。很多情況下，數據邏輯只有相關產研了解，需要較高的溝通成本。另一方面，從公司視角去看共享性這個問題，公司的業務系統眾多，導致數據分散在各個部門管理，無法流通起來。在這種情況下，我們需要一系統平臺，對數據做統一的收口，使得高流通的數據可見、可查、可申請、可管理。

② 準確

第二個方向是基于準確性的考量。

在現實場景中，一個業務字段可能需要從多個維度去定義和描述，包括業務含義，圖文解釋說明等。但是數據提供方的記錄文檔，常常不夠清晰和完整。我們希望，業務方通過系統平臺看到相關數據后，可以判斷出它的業務含義，以及是否符合訴求，是否可用。數據治理想做的事，就包括通過工具約束，對字段進行維護和補全。

業務自身在迭代過程中，會產成多個版本；數據業務含義的歷史變更等，都需要進行維護。

不管是實時的業務系統數據還是接口數據，我們希望提高搜索的準確性，降低溝通成本。

業務迭代過程中，上游發生變化時，需要及時觸達到下游的關注方，這也是我們系統要解決的問題。

③ 可用

可用性主要是指做到讓數據可信賴。已經下線的數據，如果文檔沒有同步下線，可能造成下游使用方繼續調用數據，影響業務；此外，對數據健康狀態的監控預警，如事件類消息的消費積壓等，也需要及時觸達下游；然后，通過元數據的血緣關系，可以幫助業務方更快查找問題；最后，為降低下游消費方解析數據的成本，應該盡量保證流通性數據的數據格式統一。

3. 數據治理范圍

對于大量的用戶數據，我們會對相應的埋點數據進行管理；加工用戶數據的數倉表，需要進行元數據和數據血緣的管理；加工得到的指標，需要解決的問題包括指標合理化定義，指標認證，指標高效檢索等。除了上面介紹的離線數據，還有一些業務主體數據，如貝殼經紀人相關的作業數據等業務系統實時數據，會落到mysql表中，或是加工成流通的數據形式：如以kafka消息，或實時接口的形式提供。完善的數據治理需要多年的時間，公司可結合自身業務特點和系統交互模式，針對現階段問題對癥下藥進行治理，把小類問題做好，即可發揮數據治理的價值。02結合公司特點聚焦治理范圍下面介紹，我們在以往的經驗中，是如何結合公司業務的需求，確定數據治理的范圍的。

1. 系統特點

主要從兩個方面來看貝殼對數據治理的要求。首先，貝殼業務數據系統特點，更偏中臺屬性，許多前臺應用無法實現數據的自給自足，需要依賴中臺進行數據傳輸，如C端界面呈現的大多數信息等。同時，一些精細化的運營動作，風控、品質相關的智能算法，實時金額獎勵等都需要用到中臺側的實時數據，這部分需求的特點是高頻且強依賴。另一個視角看，中臺側自身也存在一些同質化問題，比如數據本身的黑盒化：數據都收口在中臺，沒有向用戶普及，就會影響數據的共享，造成溝通成本較高。另外，一些需求的開發成本較高，需要較多產品、研發、測試同學參與，需要進行提效。第三點是存在格式混亂、可讀性較差的問題，這些問題會導致中臺側對一些緊急的數據需求無法及時響應。基于以上問題，需要業務中心來對中心化的數據做統一的治理、收口和質量管控。主要包括兩個核心：數據收斂和提效建設。數據收斂主要解決數據不共享的問題，把一些高流通的接口和事件類數據做集中的發布，并做相應的質量管控。提效建設是為了讓更少的人力參與到高頻且復雜的數據流通過程中，把產研人力釋放出來，投入到對公司價值更高的業務開發和業務迭代中。

2. 業務特點

以上是從公司業務系統交互模式上考慮，需要建設數據治理中心。下面從公司本身的業務特點來分析。

許多為傳統行業賦能的互聯網公司都有作業的主體，如貝殼找房的經紀人等，這就導致很多業務運營訴求的產生：需要利用數據，對業務進行正向牽引，對作業人員進行管控。比如對經紀人上傳房源的備件信息來保證房源質量等正向行為的激勵，對一些作弊行為的處罰等。這類需求的特點是對數據的實時性要求非常高，獎勵要及時發放，關黑等處罰要及時處理。而上述這些正向牽引和管控，依賴對實時數據源的監聽，要求數據中心本身要收口足夠豐富的數據。以“共享”和“業務語義可讀”舉例來說，業務運營的同學需要配置一些運營規則時，能夠通過數據源，快速判斷如何使用數據，來輔助運營策略。許多公司都會遇到運營規則演變一段時間后，策略規則需要優化和提升。這就需要數據準確且可回溯，能夠找回依賴的數據源，完成策略優化工作。結合貝殼的業務特點，我們的業務數據中心主要對業務主體關聯的明細信息接口，和業務節點的kafka消息做重點治理。以上從系統特點和公司業務特點，介紹了數據治理的背景環境。下面展開介紹數據收斂和提效建設的必要性。

3. 數據收斂必要性

首先，由于中臺維護的數據不夠全面，有大量的高成本單次取數需求，需要業務方來支持，且這些數據往往缺少文檔記錄，完成需求需要較高的溝通成本。這類需求量級大，頻率高，管理者可能會采用增加人力的方式來解決。造成人力成本較高。公司在做數據賦能過程中，包括AI、品質風控、精細化運營等團隊，需要來自不同業務方的大批量數據，取數效率低會成為卡點，影響核心項目的展開。所以有必要通過業務中臺對數據進行治理。

4. 提效建設必要性

提效建設方面，如果通過管理層從上向下推動，往往不夠高效。建議結合數據流通中產研的痛點問題，將提效做到平臺產品中，釋放人力，這樣執行層就會更通暢地接入。03中臺側實踐的建設內容及思路

1. 建設內容

提效建設圍繞從生產到發布測試的整個流程，包括自助測試、查詢訂閱等功能，方便整個公司更高效地訪問數據。數據從生產、測試、查詢使用、權限申請的閉環都通過平臺來管控。

2. 產品框架

在產品架構上，根據治理的數據主體分為不同類，如接口、事件、指標、數據表等。每個類下面有多個領域模塊。比如生產環節提效方面，支持配置化開發；發布時統一格式規范和查詢入口；支持用戶根據需求，自主訂閱查詢；測試時支持自助聯調測試；以及通過監控和預警模塊，對數據質量進行管控等。

3. 建設思路

建設思路首先要建能力。我們有很多的數據生產方，所以針對生產環節進行了一系列功能性建設，支持數據更便捷的加工、發布、關聯業務屬性，以及從生產者視角查看下游鏈路、訂閱方，數據變更的觸達等。平臺對消費方的支持，包括支持統一的查詢、自助訂閱、對已授權數據的管理、變更觸達等。生產和消費功能具備后，就可以啟動推廣。推廣過程中的問題怎么解決，后面會有具體的例子來說明。當數據都收斂到平臺上之后，才知道有哪些數據可以治理。首先要識別有哪些問題數據；另外要完善數據認證的功能，來提高取數的便捷性；在質量維護方面，通過線上的反饋和觸達機制，結合問題報告等管理方法，來代替運營走查的方式，形成良性循環。數據治理工作依賴很多組織的配合。比如公司通常有治理委員會，還需要跟安全、法務部門有協作，以及會有一些自上而下的數據規范標準等，這些組織依賴會影響數據治理的設計。能力依賴方面，數據有非常多的應用，以數據請求為例，就需要基礎且統一的服務標識；還可以通過鏈路日志的分析，來輔助識別問題；鑒權方面也需要相應的能力等。04治理項目的目標管理

目標管理第一是能找到數據。許多核心業務項目的數據，都通過平臺來獲取，可以通過平臺對業務數據需求的滿足率來評價。第二要求在業務方使用數據過程中，數據清晰可理解，量化為核心指標字段信息的完備率、以及平臺中心化認證數據的占比。第三要提高數據使用中的質量，減少badcase數量，這方面可以和公司的工作流系統、故障組等配合，來量化這個指標。05產品及運營落地經驗

以下是一些想要共享的建議。治理團隊最好不要做只負責建設工具的獨立團隊，在設計之初，承接一段時間業務需求，才會了解業務方真實的訴求。“治理團隊要長在業務的土壤中”。在需求場景中發現的問題，是只通過調研訪談用戶無法發現的。我們在做治理中心的時候，會承接業務方的數據需求。通過對整個流程中，產品、研發、測試的具體工作有比較深刻的體驗，才能設計好產品。

1. 數據收斂經驗——目標用戶觸達

產品設計完成后，一般結合幾個試點用戶的反饋來建設能力。之后就需要進行推廣。首先要明確平臺服務的用戶，如果用戶是整個公司的產研，可以利用公司內的電子屏、海報機等展位，以及公司的內網來對用戶進行觸達。

2. 數據收斂經驗——深度需求挖掘

即便進行了大量的宣傳和推廣，可能收效仍然有限。這種情況下，可以到各個業務線進行深度訪談和宣講，使得產品功能與用戶訴求相匹配。通過宣講，也可以發現一些產品還欠缺的關鍵的能力點，幫助我們完善產品建設。此外，可以通過集思廣益，廣泛收集反饋，以及與行業內同類產品對標，通過需求驅動產品的進一步規劃。

3. 數據收斂經驗——良性牽引

除了前期的推廣，產品更重要的是要通過核心的價值點，來吸引目標用戶。以下是結合貝殼自身特點的舉例，并不一定適用于所有業務線。我們做的比較好的一點是對數據格式進行來收斂。因為格式不統一是數據使用方很大的痛點，平臺實現了這個功能，使用方就會驅動生產方將數據生產遷移到平臺上。推動格式統一的過程中，如果生產高流通數據的業務方不愿意遵守格式規范，中臺會通過產研支持的方式，幫助完成中間層的開發和轉化。

另外一點比較好的經驗是與公司核心數據獲取方建立合作機制，讓相關系統的規則引擎、運營產品等，使用業務數據中心平臺的數據，借此驅動更多數據的生產方將數據發布到業務數據中心，使得平臺的數據源更加豐富和全面。建設初期，中心主動跟進一些數據需求，并將需求發布到平臺上，由數據中心平臺來做統一的收斂和治理，沉淀出新的功能點、管理手段、規則標準等，來推動工具建設。平臺能力建設好之后，再通過自上而下的推動，平臺產品的價值會得到越來越多的接受和認可。

4. 治理難點及舉措

最后介紹一下我們遇到的一些問題，以及解決這些問題的舉措。首先，數據治理涉及生產提效、數據統一、標準收口、數據共享、內容治理、質量、穩定性等很多方面，需要公司給予戰略層級的支持，需要相關的架構負責人共同討論和設計，自上而下去推動。產品設計方面，要結合公司自己的業務形態去摸索、迭代和沉淀。這個過程中，首先要尊重用戶，不能只調研少量業務方后，就設計產品功能。而應制定標準，做好迭代。最初可以從文檔管理開始，逐步進行系統化收口。此外還要大膽創新。一些產品功能，比如業務詞典，依賴對業務的深刻理解。業務本身產生的數據，如核心SOP流程、名詞解釋、測試鏈接、賬號等，都需要系統化梳理，才能保障更好地使用數據。此外我們也會做一些前沿的探索，感興趣的同學可以一起交流。能力依賴方面，需要和公司的基礎設施、業務系統都有好的聯動，所以合作共贏的意識非常重要。推廣運營需要擅長借力，一方面通過自上而下的驅動，另一方面產品要有核心的競爭力。此外，推動數據收口和治理，流通管控過程中，可以與安全、法務團隊緊密合作，一起推動。

06精彩問答

Q：數據收斂與數據治理的區別

A：這里所說的數據收斂，是指把管控的高流通數據都統一收口到平臺。數據治理首先要讓數據透明化，將獵物關在籃子里，才能對質量進行管控。

?Q：如何解決不同業務之間模糊地帶的權責劃分？

A：中臺工具搭建之后，數據治理更多是依賴工具的使用者來推動。

Q：中臺部門是成本部門，在貝殼的實踐中，中臺提升數據價值是如何體現的？如何讓中臺部門的同學有好的收益，對團隊更有信心？

A：舉個例子，比如業務新增加一個上報的動作，如果業務方自己開發，功能開發之后需要等待測試同學排期，以及后續一系列上線流程都比較耗時。但是如果是中臺來做，我們會監控原始數據的變動，然后根據業務事件定義的規則，對新增加的事件進行定義和自助測試。這個過程不需要測試同學介入即可完成上線發布。如果后續有同學需要用這些新增加的數據進行聯調，我們可以提供測試樣例，并把這部分數據發到對方的kafka topic里。