數(shù)據(jù)凌亂，埋點差，難以歸因？數(shù)據(jù)治理有妙招！
導讀：大數(shù)據(jù)時代的到來，讓很多企業(yè)看到了數(shù)據(jù)資產(chǎn)的價值，開始探索應用場景和商業(yè)模式，并建設(shè)相關(guān)技術(shù)平臺。因此，數(shù)據(jù)治理成為了挖掘數(shù)據(jù)價值的重要手段和工具。但數(shù)據(jù)治理不僅需要完善的保障機制，還需要理解具體的治理內(nèi)容，比如數(shù)據(jù)該怎么規(guī)范，元數(shù)據(jù)該怎么管理等。這些問題是數(shù)據(jù)治理過程中最實際也是最復雜的問題，今天我將從數(shù)據(jù)治理的各個核心領(lǐng)域來和大家分享一下云音樂在數(shù)據(jù)治理中的探索與實踐。
本文會圍繞以下四個方面展開：
音樂數(shù)倉概況
數(shù)據(jù)規(guī)范
埋點治理
資產(chǎn)治理
首先介紹一下云音樂目前所面臨的一些問題與挑戰(zhàn)，也就是為什么要做數(shù)據(jù)治理。
1.?整體情況
數(shù)據(jù)體量大。
業(yè)務場景復雜。
歷史包袱重。
以上幾方面導致了數(shù)據(jù)倉庫在保障數(shù)據(jù)質(zhì)量、控制計算與成本等方面面臨了越來越大的挑戰(zhàn)。
2.?問題與挑戰(zhàn)
問題主要有三個方面：
數(shù)據(jù)規(guī)范：因為早期數(shù)倉建設(shè)的時候迭代速度快，沒有一個標準的設(shè)計模式，導致數(shù)據(jù)非常凌亂。
數(shù)據(jù)生產(chǎn)：云音樂是個內(nèi)容流量產(chǎn)品，目前在數(shù)據(jù)埋點這方面存在埋點定義混亂，埋點質(zhì)量問題多，以及埋點信息不夠全面等問題。埋點信息不夠全面也導致我們無法支持要求越來越高的精細化運營場景。
數(shù)據(jù)資產(chǎn)：大數(shù)據(jù)開發(fā)經(jīng)常面臨開發(fā)周期長、交付質(zhì)量差的問題；另外計算和存儲的成本迅速增長也是我們目前急需解決的問題。
接下來就針對上述三方面來展開介紹一下云音樂的數(shù)據(jù)治理工作。
數(shù)據(jù)規(guī)范是數(shù)據(jù)治理建章立制的一個基礎(chǔ)。在音樂數(shù)據(jù)倉庫這一塊，我將從設(shè)計規(guī)范和開發(fā)規(guī)范這兩方面來介紹我們云音樂標準化改造的過程。
1.?設(shè)計規(guī)范-問題和痛點
在設(shè)計規(guī)范方面遇到的主要問題和痛點：
缺乏頂層設(shè)計：早期數(shù)據(jù)開發(fā)以需求為導向，跟隨業(yè)務的變化而快速迭代，因此數(shù)據(jù)模型復用率低，造成了大量的跨層引用。比如大量的數(shù)據(jù)報告表都是直接從原始日志或者業(yè)務表中提取數(shù)據(jù)來做分析的。
數(shù)據(jù)孤島：數(shù)據(jù)開發(fā)的模式主要是按照業(yè)務來劃分的，開發(fā)相對獨立，信息也相對獨立，所以缺少公共數(shù)據(jù)資產(chǎn)的沉淀，從而導致難以應對跨業(yè)務的需求。
數(shù)據(jù)質(zhì)量：數(shù)據(jù)異常，如空值、缺失、臟數(shù)據(jù)；數(shù)據(jù)的一致性問題，如活躍，留存，CRT等在不同的報表里面結(jié)果可能是不一樣的。
這塊我們需要從數(shù)據(jù)的穩(wěn)定、效率和質(zhì)量方面來解決。
2. 設(shè)計規(guī)范-數(shù)據(jù)域
從整體架構(gòu)上來講，我們將云音樂的整個數(shù)據(jù)進行了一個數(shù)據(jù)域的劃分，用來確定一個高穩(wěn)定性的數(shù)據(jù)倉庫。主題域是一個要保持穩(wěn)定不變的高度抽象的概念。我們將整個云音樂劃分為參與者、服務及產(chǎn)品、事實、協(xié)議，以及公共數(shù)據(jù)這五個主題域?；谶@五個主題域，我們又對業(yè)務場景做了進一步的子主題的劃分，子主題的劃分也是相對穩(wěn)定的。數(shù)據(jù)劃分后，當業(yè)務發(fā)生迭代時，新的數(shù)據(jù)也能夠有一個相對明確的數(shù)據(jù)域的歸屬。
數(shù)據(jù)的劃分主要是為了實現(xiàn)業(yè)務形態(tài)和實體關(guān)系的表達。我們按照以上五個主題域來進行劃分是因為我們的數(shù)據(jù)核心其實就是參與者和服務及產(chǎn)品這兩個方面。參與者就是用戶，服務及產(chǎn)品主要是內(nèi)容。
參與者和服務及產(chǎn)品之間會達成一些協(xié)議，比如直播協(xié)議，版權(quán)協(xié)議等。另外，參與者和服務及產(chǎn)品之間會產(chǎn)生各種各樣的業(yè)務過程，這就是事實。其中主要包括流量數(shù)據(jù)，互動數(shù)據(jù)，支付數(shù)據(jù)。
在人、坑位和資源的不同粒度中，我們的分層模型設(shè)計就是針對這樣的核心數(shù)據(jù)來進行的。
3. 設(shè)計規(guī)范-模型分層
上圖是云音樂數(shù)據(jù)倉庫分層的一個基本情況。跟大部分流量型產(chǎn)品的數(shù)據(jù)分層一樣，我們也分為ODS貼源層，DIM的維度，以及DWD的明細，DWS的匯總層。另外我們在應用層支持了非常多的產(chǎn)品，比如活動跟蹤、用戶歌曲畫像、流量羅盤，以及各種to C和to B的數(shù)據(jù)產(chǎn)品。
我們模型設(shè)計的核心是對DWS這個匯總層進行了進一步的拆分，比如在這個圖里我們可以看到有橫向拆分和縱向拆分。
橫向是對不同的匯總粒度和方式進行的拆分。匯總粒度既包括明細/輕度/高度，又區(qū)分多維度/雙實體/單實體。匯總方式包含周期快照以及累積快照。
縱向區(qū)分主要針對的是維度和業(yè)務過程的一個拆分。維度主要是一些核心的實體，就是人、資源、坑位。業(yè)務過程主要包括交易營收、社交互動，以及場景流量。
我們最終的設(shè)計目標是，通過這樣一個模型設(shè)計來達到高效率高質(zhì)量的數(shù)據(jù)生產(chǎn)和使用。
4. 設(shè)計規(guī)范-平臺管控
我們通過網(wǎng)易數(shù)帆開發(fā)平臺對設(shè)計規(guī)范的落地進行管控。上圖是平臺提供的一個工單機制，對我們的數(shù)據(jù)域、分層結(jié)構(gòu)進行設(shè)置和規(guī)范，也對表和字段的命名也進行規(guī)范，幫助我們將設(shè)計思想真正落到實際的生產(chǎn)過程中去。
5. 數(shù)據(jù)規(guī)范-開發(fā)規(guī)范
開發(fā)規(guī)范造成的問題也是屢見不鮮，我們也在新的體系下對開發(fā)工作進行調(diào)整和改進：
很多任務會直接讀寫文件，導致數(shù)據(jù)血緣缺失。為達到一個完備的數(shù)據(jù)血緣，新的規(guī)范會強制要求所有人要在讀寫表的基礎(chǔ)上進行。
任務會有純SQL，或者是SQL和API結(jié)合的方式。為了統(tǒng)一開發(fā)規(guī)范和流程，降低運維成本，新規(guī)范要求公共層模型必須用純SQL來執(zhí)行，并且我們定義了一個SQL規(guī)范來去執(zhí)行。
多表和多任務可能會合并到一個workflow里面去，導致一個workflow里可能有幾十個甚至上百個任務節(jié)點，對任務管理造成了比較大的影響，也不利于性能和資源分析，因此我們要求一個workflow只能輸出一個正式表，額外的好處是任務的查找也變得更加方便。
多workflow間通過數(shù)據(jù)檢查依賴去執(zhí)行的方式，對運維也造成了一定影響。比如任務出現(xiàn)了失敗或者異常如何快速做數(shù)據(jù)恢復。在新的規(guī)范里，我們基于開發(fā)平臺做跨流任務依賴，以此構(gòu)建任務血緣，進而有效地進行基線診斷和運維。
6. 數(shù)據(jù)規(guī)范-DQC
另外我們的數(shù)據(jù)開發(fā)平臺提供了一個數(shù)據(jù)質(zhì)量控制的功能，上圖是一個規(guī)則配置的頁面。這個功能除了可以支持標準化表組件的唯一性檢測，表行數(shù)檢查，字段空值檢查，字段枚舉值檢查等模板規(guī)則，還可以支持一些我們自定義的規(guī)則。這樣我們能夠在任務上線之后，對數(shù)據(jù)質(zhì)量進行監(jiān)控，及時發(fā)現(xiàn)并阻塞異常向下游擴散。
數(shù)據(jù)治理中解決數(shù)據(jù)源頭問題是關(guān)鍵，下面將從技術(shù)方案和流程管理兩方面來介紹埋點治理工作。
1.?埋點治理-問題和痛點
云音樂目前在埋點這方面遇到的問題和痛點，主要分為四個方面。
格式凌亂：埋點字段含義不統(tǒng)一，規(guī)則定義不精確，管理平臺功能單一，埋點查找困難。
數(shù)據(jù)質(zhì)量低下：上線較為隨意，埋點的多錯漏難以檢查。另外我們數(shù)據(jù)方面的設(shè)計，以及客戶端都是面向單次需求開發(fā)的，導致新老埋點容易相互影響，造成數(shù)據(jù)異常頻出。
開發(fā)效率低：人工進行埋點編碼和開發(fā)ETL任務占據(jù)了大量工作，數(shù)據(jù)需求也是直接從原始日志來進行解析的。另外業(yè)務數(shù)據(jù)，比如說像歸因分析這樣的需求還是依賴數(shù)據(jù)層面的復雜邏輯加工來實現(xiàn)的。
看數(shù)困難：目前的埋點無法支持自動化的取數(shù)看數(shù)以及精細化的指標產(chǎn)出。雖然我們也去落地了一些取數(shù)平臺以及流量羅盤，但是這些產(chǎn)品基于老的埋點體系更新十分繁瑣，更新周期也特別長。
為此云音樂啟動了一套全新的埋點改造方案。
2.?技術(shù)方案-SDK
技術(shù)方案是聯(lián)合客戶端來進行設(shè)計和實施的?？蛻舳藢崿F(xiàn)了一個埋點的SDK來對埋點生產(chǎn)進行標準化，其中有以下幾個重點：
對SPM和SCM進行一個對象化，對像化的核心就是對象能夠復用，大大降低了設(shè)計和開發(fā)的成本。
復用的意思如右圖，每個節(jié)點每個位置都是一個對象，不同的對象組裝成一個對象邏輯樹。如果對象發(fā)生了位置的修改，只需要修改它所在的父節(jié)點的位置，這樣就能夠大大簡化設(shè)計和開發(fā)的效率。
點擊和播放事件埋點，每個埋點會帶上它的Refer信息。Refer信息包含了跳轉(zhuǎn)到某個頁面或坑位的多級行為鏈路及其關(guān)聯(lián)的資源和策略。
埋點生產(chǎn)標準化的結(jié)果是埋點格式的變化。埋點格式，我們以往是用扁平的JSON方式，里面就是key/value。但在新的標準下，我們會生成一套嵌套的JSON，里面攜帶全局公參、事件公參、對象標準參數(shù)、對象業(yè)務參數(shù)。
3.?技術(shù)方案-數(shù)據(jù)倉庫
數(shù)據(jù)倉庫我們也會重新接入新的埋點數(shù)據(jù)，使我們能夠?qū)崿F(xiàn)離線和實時統(tǒng)一數(shù)據(jù)源接入和模型設(shè)計。
離線和實時都將具備精確的歸因分析能力。
在數(shù)據(jù)倉庫的數(shù)據(jù)易用性角度，我們對改造之后的嵌套JSON做了適當?shù)谋馄交?/span>
針對這樣一個標準的埋點范式進行自動的ETL，使得能夠更高效地支持Ad-hoc查詢以及敏捷的數(shù)據(jù)探索。
右邊是我們基于新的埋點方案的數(shù)據(jù)流示意圖。通過這次埋點治理，我們會同步推進歷史任務的治理。以前很多任務都是直接從ODS上提取和解析數(shù)據(jù)的，希望這次通過對埋點格式的修改，能夠切斷以往ODS直接訪問的方式，將我們之前的分層模型設(shè)計實實在在地落地到整個數(shù)據(jù)生產(chǎn)的環(huán)節(jié)當中去。
4.?技術(shù)方案-歸因設(shè)計
我們的歸因大致分為以下幾方面：渠道歸因、內(nèi)容歸因、搜索歸因、策略歸因。
渠道歸因，主要指內(nèi)容在App中分發(fā)的資源位，如首頁不同模塊。
內(nèi)容歸因，主要指內(nèi)容的包裝形式，如歌單、相關(guān)資源推薦。
搜索歸因，根據(jù)一次搜索請求產(chǎn)生的后續(xù)整個鏈路的流向，去分析這個搜索的效果。
策略歸因，主要指推薦或算法模型的歸因，我們通過這個策略歸因來支持算法模型的離線或者實時的模型訓練。
右邊展示了我們目前設(shè)計的幾個refer的形式，refer同時包含了SPM和SCM的信息。比如：
_psrefer是頁面對象創(chuàng)建，就是首次曝光時生成的來源對象；
_pgrefer是頁面?每一次曝光時生成的來源對象；
_hsrefer是App內(nèi)整個消費起始鏈路的來源；
_multirefers是行為鏈路上的5級頁面的_psrefer順序拼接；
_addrefer和_playrefer主要是針對云音樂的播放場景，_addrefer是觸發(fā)內(nèi)容添加到播放列表的對象，_playrefer是觸發(fā)內(nèi)容播放的對象；
_rqrefer主要是針對一些互動行為，比如評論，收藏，點贊等行為，由客戶端觸發(fā)服務端請求對象來記錄并傳給服務端來打點。
5.?埋點治理-流程管理
埋點治理的另一個重點是流程管理，因為整個埋點流程會涉及到很多團隊，決定了技術(shù)方案能否高效率高質(zhì)量的應用到生產(chǎn)流程當中。
第一步，策劃、BI以及數(shù)倉的開發(fā)會錄入埋點需求以及參與方案的設(shè)計；
第二步，大前端開發(fā)會根據(jù)埋點設(shè)計來設(shè)置剛剛說的一些對象參數(shù)；
第三步是SDK，根據(jù)業(yè)務設(shè)置的一些對象信息來自動構(gòu)建對象邏輯樹，并自動進行曝光和點擊的埋點，同時會帶入歸因相關(guān)的refer的信息。
接下來一步，依據(jù)選擇的需求中對象和樹的規(guī)則進行埋點上報，上報到系統(tǒng)里，由QA進行實時的埋點驗證和測試。
當整套流程都測試通過之后，埋點才能最終上線接入到數(shù)據(jù)倉庫，進入到后續(xù)的數(shù)據(jù)分析中去。其中有兩個關(guān)鍵的環(huán)節(jié)，就是埋點設(shè)計和數(shù)據(jù)測試，這兩塊會接入到我們新的埋點平臺來進行管控。
6.?埋點治理-埋點平臺
上圖是我們埋點平臺大致的頁面情況。
埋點平臺主要面向的是上述埋點流程中會涉及到的團隊和角色：產(chǎn)品策劃、數(shù)據(jù)開發(fā)、大前端開發(fā)以及QA。
埋點平臺承載的功能是一些元數(shù)據(jù)管理，包含一些對象管理，版本管理等，以及整個需求工作流的管理和實時埋點測試。未來還會規(guī)劃更多功能，比如說質(zhì)量監(jiān)控，BI分析等
7.?埋點治理-預期成效
埋點治理的改造項目是一項正在進行的工作，我們希望能夠通過流程管控和技術(shù)支撐來提高開發(fā)效率，實現(xiàn)數(shù)據(jù)質(zhì)量和數(shù)據(jù)價值的提升，主要包含以下三個方面：
不需要再人工進行坑位標準化，所見即所得，埋點上線后直接用于數(shù)據(jù)分析、數(shù)據(jù)產(chǎn)品等；
歸因鏈路不需要再人工梳理和單點開發(fā)，埋點上線后攜帶多種歸因字段，精確的位置和資源信息，支持實時歸因；
埋點質(zhì)量提升，埋點時機口徑標準化，多端一致，上線流程優(yōu)化。
降本提效是資產(chǎn)治理的一個核心，這一塊將從數(shù)據(jù)流治理和生命周期治理兩方面來介紹我們的工作。
1.?資產(chǎn)治理-問題和痛點
資產(chǎn)核心就兩個部分：計算資源和存儲資源。
計算資源：目前整個集群CPU內(nèi)存的使用率絕大多數(shù)時間都在80%以上，我們的任務在半年內(nèi)增長了15%，接下來我們可能就會遇到一個數(shù)據(jù)開發(fā)團隊普遍會遇到的問題，就是核心任務延遲。
存儲資源：整個集群存儲量的日均增長近0.4%，在整個量級是PB級的存儲情況下，這個增量也是非?？捎^的；另外還有90%的表可能都是無引用的表。
從計算和存儲兩方面來看，也有很多歷史包袱的問題。比如可能存在大量的無人瀏覽的報表，大量的歷史遺留任務等，這些都是我們在資產(chǎn)治理方面需要解決的問題。
2.?資產(chǎn)治理-數(shù)據(jù)流治理
數(shù)據(jù)流治理又分兩個小點：分層模型數(shù)據(jù)和治理、單任務內(nèi)數(shù)據(jù)流治理。
分層模型治理，本質(zhì)上是數(shù)據(jù)標準、數(shù)據(jù)規(guī)范的一個落地。
當我們遇到一個數(shù)據(jù)產(chǎn)品各項指標需求的時候，需要去分析什么樣的指標是可以沉淀到公共模型去的，什么樣的指標是需要在ADS才完成的。比如我們ADS處理的是一些不可加指標、自定義規(guī)則標簽以及自定義的多維分析。
我們也需要去分析什么樣的指標是需要沉淀到我們的公共資產(chǎn)里面去的。比如說客觀事實的派生指標可能需要的團隊不同，可能時間周期要求不一樣，可能有的要求看1日的指標，有的想看7日的，有的30日，有的3日。這些可能在我們的整個DWS層處于同一個加工流程只是一個不同時間周期的處理。另外多團隊一致復雜指標的典型案例就是我們對一些資源或者用戶會進行一個綜合評分，綜合評分會用到多種多樣的場景。
一些缺失的原子指標必然需要從我們的DWD層去重新加工。
單任務內(nèi)數(shù)據(jù)流治理這塊主要講一下我們在做單任務優(yōu)化的時候的大任務拆解策略。
大任務內(nèi)部邏輯是否需要拆解我們從兩個方面來考慮：
拆解執(zhí)行過程，降低任務的失敗或者延遲恢復的成本。因為某一個節(jié)點失敗之后，可能我們只需要從這個節(jié)點重新進行恢復，不需要重新執(zhí)行整個任務，因為有時候重新執(zhí)行整個任務需要好幾個小時。
避免做過度拆解，因為可能多余的任務啟動和IO的過程反而會導致效率的下降。
這邊簡要總結(jié)幾個我們在優(yōu)化過程中的經(jīng)驗：
需要緩存的中間結(jié)果拆解。要考慮先做子節(jié)點的拆解，避免重復計算。
盡量避免拆解為串行任務。拆為串行任務并沒有優(yōu)化整個執(zhí)行過程，反而導致了多余任務啟動還有IO過程的問題。
依賴產(chǎn)出不穩(wěn)定的多個部分拆解。比如將上游產(chǎn)出不穩(wěn)定的部分拆分為多個節(jié)點，這樣就能夠降低上游任務的影響，分散計算資源占用的時間。
案例：我們有一款數(shù)據(jù)產(chǎn)品是一個推歌的產(chǎn)品，核心是生產(chǎn)歌曲畫像標簽。歌曲畫像我們總共做了400多個標簽，之前隨著產(chǎn)品快速迭代和煙囪式開發(fā)，產(chǎn)生了大量ADS表，其中包含許多重復的數(shù)據(jù)加工邏輯。在落地我們的模型設(shè)計規(guī)范之后，減少了十個ADS表，沉淀了50多個指標到CDM，讓我們整個數(shù)據(jù)的產(chǎn)出時間提早了兩個多小時。有的任務里面可能會加工特別多的數(shù)據(jù)，我們通過對單任務數(shù)據(jù)流的優(yōu)化，實現(xiàn)了單表耗時減少30%以上。
3.?資產(chǎn)治理-生命周期治理
資產(chǎn)治理的另外一部分就是生命周期治理，生命周期治理主要考慮三個部分：
業(yè)務場景分析：在模型設(shè)計的時候，需要我們綜合業(yè)務場景、應用場景去規(guī)范設(shè)置表的生命周期，并對過期的任務和數(shù)據(jù)進行清理；同時對于一些新老模型更替的情況，即使對老任務和相關(guān)依賴進行遷移和下線。
數(shù)據(jù)血緣分析：數(shù)據(jù)血緣能夠幫助我們?nèi)プR別表被引用和訪問的情況，做自動的生命周期診斷，基于分析結(jié)果進行針對性清理。
成本分析：成本分析是幫助我們針對一些高計算、高存儲成本的任務和數(shù)據(jù)進行重點排查和治理，針對不同的情況做優(yōu)化、改造或下線。
這塊我們也借助網(wǎng)易數(shù)帆開發(fā)平臺中的數(shù)據(jù)資產(chǎn)中心，支持我們做存儲分析、計算分析、報表分析，來幫助我們?nèi)ジ玫毓芾砣蝿蘸捅淼纳芷?。通過這個平臺我們已經(jīng)下線了100多個報表和相關(guān)的任務，節(jié)省存儲超過1PB。
最后對我們云音樂未來數(shù)據(jù)治理做一些規(guī)劃和展望，我們希望做到的是自動化的數(shù)據(jù)治理方案。主要有幾個方面：
數(shù)據(jù)資產(chǎn)的可視化。將我們整個數(shù)據(jù)倉庫的標準做一個可視化，讓更多的數(shù)據(jù)使用方明確地知道倉庫里面有什么樣的數(shù)據(jù)，怎樣使用倉庫中的數(shù)據(jù)。
SQL靜態(tài)代碼檢查以及性能監(jiān)測與告警。目前數(shù)倉開發(fā)需要同時完成開發(fā)和測試工作，而且數(shù)倉團隊的規(guī)模也在不斷擴大，光靠人工保障開發(fā)質(zhì)量是不可控，還是需要結(jié)合平臺能力來對我們的代碼進行管控。
制定健康度評分。這個是希望從數(shù)據(jù)生產(chǎn)和使用的多個方面，對數(shù)據(jù)本身或者數(shù)據(jù)工作者進行一個綜合的判斷，并反過來去指導我們更高效更合理地做數(shù)據(jù)生產(chǎn)和分析。
精彩問答
Q：數(shù)據(jù)治理之后的顯著成果有哪些？
A：第一個是數(shù)據(jù)規(guī)范的落地。之前整個數(shù)倉是沒有一個明確的分層定義的，現(xiàn)在我們會將整個數(shù)據(jù)資產(chǎn)搬到我們的數(shù)據(jù)平臺去，重新定義好分類，重新構(gòu)建DWD、DWS、DIM?，F(xiàn)在有一百多個已經(jīng)分好數(shù)據(jù)域數(shù)據(jù)分層的模型。第二個是新的埋點正在逐步上線。因為涉及到歷史埋點和新埋點的兼容問題，所以目前正在做上線前的測試以及新老數(shù)據(jù)的對比工作。資產(chǎn)治理方面，通過數(shù)據(jù)平臺管理任務，我們下線了100多個報表，使得線上的一些核心任務能夠能有更好的計算資源的保證。?
Q：數(shù)據(jù)治理的成果如何來通過指標來量化？
A：基于我們網(wǎng)易的開發(fā)平臺，有一些資產(chǎn)大盤。我們現(xiàn)在目前整個存儲增長是一個什么樣的情況，表的生命周期管理是什么樣的情況，有多少推薦下線的表以及我們真的下線了多少，這些具體指標我們平臺里面都會有。
Q：能詳細說一下技術(shù)架構(gòu)嗎？
A：這個架構(gòu)圖DIM層、DWD層可能各個公司都一樣，主要講一下DWS層。比如從社交互動這一塊，因為我們是個內(nèi)容平臺，除了有消費者之外還有生產(chǎn)者。所以我們根據(jù)內(nèi)容、生產(chǎn)者、消費者這三個核心，以及坑位來去設(shè)計這一塊。這里總共分了兩條線，一個是我們區(qū)分多個維度的一個聚合的快照；另外一個是我們在做一些活動、報告或者總結(jié)的時候，經(jīng)常會用到的比如用戶的首次行為是什么樣子的，歌曲的首次行為樣子的這種信息。我們會針對這類需求再做一些公共模型，比如落到每種資源的首末次詳情。除此之外，我們還會做比如播放或者互動行為的留存情況。這一塊的設(shè)計是，在流量這塊我們也會有一個簡單的多維分析的聚合，也會有針對用戶和坑位的首末次情況，以及用戶和坑位的留存情況。其實在整體設(shè)計上來說，思路都是一樣的，只不過我們從橫向和縱向再進一步做了一個拆解。然后頂層這一塊，因為我們經(jīng)常會用到，比如歌曲畫像里面，歌曲什么時候達到了它的播放峰值，還有其他類似相關(guān)的時間點級對應數(shù)據(jù)的記錄，我們針對這類需求場景做了一些的累計實時的快照表，這樣方便我們?nèi)Y源或者對用戶進行整個生命周期的分析。
Q：可以聊一下數(shù)據(jù)和業(yè)務之間的關(guān)系嗎？哪一個更重要？
A：數(shù)據(jù)和業(yè)務應該不存在說哪個更重要，因為我們數(shù)據(jù)需要根據(jù)業(yè)務來做迭代，業(yè)務需要用數(shù)據(jù)來做支撐。比如說怎樣合理的分配我們的流量，怎樣合理的分發(fā)歌曲，怎樣合理的設(shè)計產(chǎn)品，這些東西都需要我們數(shù)據(jù)去做支撐。另外一個就是數(shù)據(jù)的價值，音樂版權(quán)的采買情況或者是ROI的分析，需要我們從數(shù)據(jù)層面來進行支撐。通過這一套數(shù)據(jù)我們做了一個版權(quán)評估系統(tǒng)去支持我們的業(yè)務做相關(guān)決策。