一、技術轉產品的思考

賀老師畢業于計算機軟件專業，曾接觸過軟件開發、圖像識別、數學挖掘等專業知識，畢業后成為了一名程序員。后經歷了團隊從業務的數據研發工作到中臺的數據平臺研發的轉型，積累了豐富的大數據研發經驗。由于個人興趣以及團隊角色的需求，在同一個項目內逐步轉型為數據平臺產品經理。

因此，技術到產品的轉型，需要結合內在性格、外部機遇和自我培養等多方因素才能實現。

產品與研發的區別主要體現在職能、思維和研發上，兩者需要相互配合共同實現價值。數據平臺屬于技術型平臺，對產品經理的要求更高，既要有產品經理的必備素養，又要有大數據領域的專業技術。

技術轉型產品需要做如下一些準備工作：

• 首先是判斷。從專業知識、好奇心、是否對負責任的事情操心、積極的心態、善于挑戰目標、溝通能力等角度判斷是否適合轉型。并判斷是否有足夠好的機會，比如在同一項目內部進行轉型就是一個比較好的機會。
• 第二嘗試。在轉型之前，是從產品的視角對需求進行思考，做一些思維上的簡單訓練和嘗試。從簡單的需求入手，進行原型圖繪制，需求文檔撰寫等。
• 第三是學習。培養自身產品經理所需要的一些素養，提升自身產品力，太過于技術的思維方式會阻礙產品力的發展，如果總是考慮實現的難度就可能會丟失一些好的想法。

二、深度理解數據工作者的需求

接下來分享如何由淺入深地理解數據平臺的用戶需求。

以內容類 APP 為例，它是通過內容連接用戶和平臺，即作者使用 APP 發布內容，APP 再通過推薦算法將合適的內容推薦給用戶。在算法推薦、用戶精細化運營、業務決策環節都需要用到數據生產資料，尤其對于算法模型而言，數據決定了一個算法的上界。由此可見，數據非常重要。

在這種背景下，數據層面卻仍然面臨著很多問題。面向數據開發的工具非常多，但是圍繞數據資產本身的工具缺乏，導致數據的管理和使用混亂。數據需要反復驗證，查詢速度非常慢導致數據分析師效率低。對于策略產品經理而言，只能查到基礎的表結構，沒有功能去了解表的更多數據信息。公司內的數據工具和平臺非常多，但沒有協同效應，連集群都是割裂的，這非常不利于數據工程師的工作。表名亂，沒有數據規范，數據質量差，出了問題新入職的數據工程師也不知道能找誰。

為了解決這些問題，我們以建設數據資產為目標，來搭建數據平臺能力。當一份數據較為規范、易于理解、質量可靠，我們可以稱之為數據資產。當數據資產能方便地被下游使用時，才可能發揮出數據中更大的價值。

因此早期歐拉平臺著力于打造一個數據資產管理平臺，用于沉淀出業務的核心數據資產，面向數據工程師提供數據管理、數據質量監控能力。歐拉先采集表的技術元數據并做一些加工，然后提供一些管理工具給用戶登記業務元數據來豐富表的描述，讓數據變得更易理解。數據科學家或數據分析師在充分了解數據后，再使用 Presto 這樣的高速查詢引擎來快速獲取分析結果。

平臺上線后運行效果并沒有完全達到預期，主要有以下問題。首先，問題產生后再解決比較棘手，例如開發一張表，表名已經建好甚至數據已經被下游使用，這時修改會很麻煩，只能做簡單的數據管理。其次，數據已經產生甚至已經交付后治理的動力明顯不足，導致最終業務的信息登記更少，無法形成一個有效的元數據管理氛圍，周期性運動式的治理難以持續。

那么 DE 到底需要什么呢？

• 通過 Presto 引擎將查詢速度提升了，但產品體驗也是決定工作效率的核心因素。
• 技術元數據更豐富，擁有了數據地圖的檢索能力，但業務元數據很難沉淀，找到表之后缺乏描述表業務信息的內容。
• 數據質量問題能被有效監控，但很難定位到根因。
• 數據管理、質量監控等能力在功能矩陣上新增了，但生產流程與管理流程依然割裂。

針對上述問題，有如下解法：

解法1：把一些治理動作提前到生產過程中，不僅規范了表名，也規范了整個開發流程，從而推動整個新表資產化的程度，舊表通過引入的方式進入到治理過程。

解法2：有機整合在整個生產過程中用到的平臺工具，來提升數據工程師的效率，元數據信息也因此不會被重復冗余登記。

解法3：構建數據資產化程度的評價指標，從規范、安全、成本、應用等角度設計此評價體系，持續驅動存量和新增數據的治理。

解法4：從上游提前規避數據質量問題。在上游開發階段充分進行數據測試，核心節點出現問題時能阻斷下游傳播，防止對下游數據的污染。對于報表延遲風險，在上游出現變慢或失敗等突發狀況時，評估下游的一些核心保障節點是否有延遲風險。

解法5：將軟件工程領域有效的經驗進行轉換吸收應用到數據工程領域。比如 DataOps 是從敏捷、Devops、精益制造吸收的靈感。通過落地 DataOps 可以提升整體協同效率，保障數據質量，減少開發工作量。

按照“組合創新&錯位競爭”的思路，將解決用戶需求的方向，從數據資產管理平臺，最終轉向成了打造一站式數據資產開發平臺（資產工場），把管理過程前置到開發，借鑒軟件工程思想，目標群體也更專注在數倉工程師、而不是所有的數據研發。

三、騰訊歐拉資產工場實踐

接下來介紹騰訊歐拉資產工場的落地實踐。

騰訊歐拉資產工場是基于 DataOps 的一站式數據開發平臺。通過提前制定流程規范、設定數倉配置，大大增強了整個數據倉庫的規范性，并同時兼顧開發效率。

功能矩陣如下圖所示：

首先是數據規劃。對包括業務域、主題域在內的數倉架構進行設計，對 Hive 以外的數據源進行統一管理。

第二是數據開發。開發階段支持表與任務同時開發，提供豐富的數據同步組件與上下游外部數據進行對接，還擁有智能解析依賴的能力。

第三是數據調試與發布。提供測試模式這樣的方式隔離線上環境，在發布階段走代碼評審，在發布上線時同時發布到任務調度平臺以及 GIT 代碼倉庫。

最后是數據運維與質量。數據上線后，提供運維大盤、DAG 圖等功能對數據運維提供基線預警與質量監控等功能，從而觀測和提升整個數據倉庫的健康狀況。

在敏捷、標準化、自動化程度高的數據開發流程下，

• 角色得到進一步細分。比如有數據規劃者由此能夠把數據當作產品一樣進行精益化生產，從而構建規范、更高質量的數據倉庫，使得下游數據使用者更加滿意。

• 重點打磨數據開發面板。增強團隊內部協同效率，實現了配置化開發；強化了數據版本控制，把所有影響生產的內容，包括表結構任務的代碼、調度配置、以及依賴了什么上游任務等等都當作代碼，并對版本內容進行可視化；實現自動化上線，發布后同時上線 Hive 集群、調度平臺和 Git 倉庫；構建出正式環境與測試環境的簡單隔離，智能解析上游依賴，自動抓取 Python 中的 SQL 等自動化能力。

• 隨著時間的推移，業務數倉規模不斷膨脹，運維壓力加大，采取分層保障來提升數據質量，降低運維起夜率。對于大部分日常任務數據可以自動監控，保證基本正常運維。對于重點數據的內容進行質量監控，必要時設定強規則，在告警后可以阻斷下游執行，避免污染下游更多數據。對更核心的數據，還提供及時性方面的基線保障，支持追蹤監控整個上游任務鏈路，提前預測產出延遲風險。

• 除了平臺上的設計落地外，還搭配與資產工場相關的課程體系。比如在數據工程職位上開設了《DataOps》，《SQL 代碼規范》，《數倉設計》還有《數據測試》等四門必修課。策略產品職位則開設了《SQL 實操應用》，從而使提數據需求的產品經理對數倉和 SQL 的認識更深刻，從而方便他與 DE/DS 更好地溝通。通過這些課程，提升用戶對資產工場的使用效果。

意識、平臺工具、組織保障等多方面的疊加，使得在各個業務線實現了生產及治理的效果。生產前，通過規范標準來系統化預約束，增強數倉整體規范性。生產中，通過數倉屬性和業務元數據的登記，增強數據可理解性。生產后，關注數倉的質量和即時性，提升數據內容質量和任務產出時效。最后將數據在各種數據應用中進行呈現，發揮數據的價值。

在落地整套方案的過程中，一站式的功能的不斷補齊，在具體應用場景上也下了不少功夫，從某種程度上來說降低了數據開發的門檻，使得潛在客戶群體不斷擴大，目前非DE的用戶占比達到 1/3。

四、數據平臺產品方法論

1、平臺創新方法論

無論是從 0 到 1 做一個新的平臺，還是對已有平臺進行自我革命，作為產品經理首先要關注行業前沿，與研發、技術用戶始終保持在基本相同的技術認知上，才有可能一起找到一個新興技術方向，沿著方向做強，打造出新的核心競爭力。

在設計方案時，要嘗試把要素拆解得足夠細，例如從需求角度重新理解當下的平臺已經提供了哪些功能，把這些功能及用戶需求拆解得足夠細，再進行有機組合，達到人無我有，人有我優的境地。找準一個方向，著力于打造一個核心競爭力，錯位競爭。比如我們找準了 DE 這一方向，在數倉領域做大做強。在一開始功能的質量比用戶規模更重要。另外，做平臺不是做工具，功能不能靠簡單的堆疊，而是有機地進行整合。

2、規范和效率如何兼顧？

首先，可以在日常大功能需求的迭代中，插入一些小而美的需求，這些需求可能是日常不斷和用戶溝通反饋收集而來的。這些需求還需要足夠通用，才會有更多用戶受益。

另外，在規范上約束用戶行為時，需要考慮是否已提供給用戶足夠多的輔助工具。比如強制代碼評審，那么需要考慮代碼的對比能力是否將改動前后的差異清晰呈現，從而加速整個 CR 流程提高整個開發效率。

3、目標驅動

平臺的驅動力：首先定義幾個核心目標，然后考慮如何度量。平臺對效率的提升起初沒有找到很好的辦法直接定量度量，但用戶可以直觀感受到。我們可以從用戶規模、用戶留存對效率進行定性，反映出平臺的吸引力。對于剛接入的新用戶可以詢問原因，提煉吸引點來拉動更多新用戶。

用戶的驅動力：一為推力驅動，通過拉通各個業務團隊共同制定一個評價機制，來評價整個資產化過程，形成平臺分資產分評價體系。如果有規則沒有達標，則會呈現為待治理狀態。二為拉力驅動，把一些工作成果直觀地統計出來，例如近 7 天開發了多少表、處理了多少任務異常情況等等，對用戶進行激勵。

4、用戶運營層面講究策略

首先，用戶運營需要與業務同學建立有效連接，可以搭建一套數倉對用戶進行細粒度分析，通過對用戶的分析來充分了解用戶。用自己的平臺搭建數倉，也能從用戶角度思考平臺還有什么不完善的地方。第二，與用戶溝通時，要建立信任感，做到事事有回音。第三，抓住比較主動的新用戶，耐心地與用戶溝通，解答平臺內部一些細節問題，使得新用戶認可平臺，從而帶他們整個團隊更多人來使用。最后，運營要有節奏感，合適的產品推薦給合適的用戶。此外，平臺的 PRD 方案可以拉上一些用戶進行預評審，在實際溝通中我會發現用戶非常樂于參與到方案的制定當中。

5、個人產品力的提升

首先多實踐，在實踐中思考。通過數據分析、研究競品、研究用戶和自己的直覺來發現問題。提出問題，界定要解決的問題邊界，論證問題的一些限制條件，問題解決后會有怎樣的價值。運用產品工具來解決問題，把功能上線后，定期對平臺運行情況復盤。多看成功案例實踐，有些看似有用的功能通過數據監控發現用戶量非常少，需要多反思。最后，從微觀到宏觀、從局部到整體多思考。另外，最重要的一點的是，熱愛自己所負責的事情，這是做好它的動力源泉。

五、問答環節

Q1：數據模型如何迭代？市面上有什么工具可以使用？

A1：數倉工程師應該更適合來回答這個問題。我對于該問題的理解是，首先在做一套生產及治理流程時，很多業務團隊會趁機復盤整個數據倉庫存在的問題，重新對數倉的主題域、業務域劃分，制定標準。舊的數倉中核心根據數據這套標準直接掛到更合適的業務域或主題域節點上，本身設計不合理的數據表進行重新設計，達到對整個數倉模型的迭代目的。其次，我們會通過資產分的度量方式關注數倉內部整體的狀況，給數據模型迭代提供指導。:

Q2：您提到的治理方法的基本歸納為先定規范再按規范執行，對于介入治理時已經存在的質量問題如何處理？

A2：如果重新定義一套新的數倉規范，舊表會產生沖突，因此導入的時候提供選分層，業務域、主題域直接掛載上去，不對表名重新命名，因為下游已經很多任務在使用。

Q3：查詢引擎從 Hive 切換到了 Presto 效率提升了，但成品也是呈量級增長，這是否真的產生了價值？

A3：關于成本這一塊，我們后面打造出一個治理引擎的模塊，把日常開發的表建立的任務以及查詢記錄的具體成本明細通過各種方法統計出來，幫助用戶結合自身考慮是否要優化使用。

Q4：日常經常用到的表或數據只占業務所有數據量的 10% 以內，有些業務數據因為業務邏輯變更已經失效，這方面在治理上有什么辦法？

A4：由于每個人的精力有限，通過像基線監控，阻斷的這些能力應用在核心數據上，相當于對數據的重要程度打上標記，在運維的模塊會看到整個基建的安全產出率，即核心數據產出狀況，針對這些數據來更好的治理。

Q5：軟件工程思想的核心及工作中帶來的幫助有哪些？

A5：軟件工程領域有整體像 DevOps 流程的，應用在 DataOps 領域希望整個環節從規劃生產到交付，有一些自動化的處理，另外更希望有一些協同的能力，比如有公共 python 的管理，可以在 python sql 開發時通過公共 python 進行代碼復用，提升協同效率。另外軟件工程注重整體的質量，在數據工程領域利用落地一些數據，測試數據質量來提升整體質量。

Q6：政務相關的業務相對成熟，有必要建數據平臺嗎？

A6：我們分析用戶需求，了解業務里面的數據平臺工具是否已經解決這些問題，沒有解決的話嘗試能否在已有的系統上重新把功能，比如通過 API 的方式重新組合，代價會相對比較小。