建站
咨詢
售后
建站咨詢
新聞中心
本次分享主要從以下部分展開：
創(chuàng)新互聯(lián)建站是一家專注于成都做網(wǎng)站、網(wǎng)站設(shè)計、外貿(mào)營銷網(wǎng)站建設(shè)與策劃設(shè)計,東洲網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)建站做網(wǎng)站,專注于網(wǎng)站建設(shè)十年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:東洲等地區(qū)。東洲做網(wǎng)站價格咨詢:18982081108
- 數(shù)據(jù)中臺的產(chǎn)生：數(shù)據(jù)工作的痛點、數(shù)據(jù)中臺的產(chǎn)生、中臺的實質(zhì);
- 愛奇藝數(shù)據(jù)中臺的定義：理解數(shù)據(jù)中臺、數(shù)據(jù)中臺的發(fā)展歷程、輸出和定位;
- 愛奇藝數(shù)據(jù)中臺的建設(shè)：中臺建設(shè)、Pingback體系、數(shù)倉體系、數(shù)倉平臺、離線數(shù)倉架構(gòu)、大數(shù)據(jù)平臺、數(shù)據(jù)平臺架構(gòu);
- 數(shù)據(jù)中臺的應(yīng)用場景：統(tǒng)一化、個性化、定制化。
一、數(shù)據(jù)中臺的產(chǎn)生
1、數(shù)據(jù)工作的痛點
說到數(shù)據(jù)中臺的產(chǎn)生，我們不得不從數(shù)據(jù)工作的痛點來切入。我總結(jié)了八個方向，這八個方向可能不足以覆蓋數(shù)據(jù)工作中的所有痛點，但肯定是數(shù)據(jù)工作中最痛的八個點。
- 使用門檻高：數(shù)據(jù)工作是一個專業(yè)性特別強的一個工作，對于人員的要求比較高。在一些數(shù)據(jù)的工作當(dāng)中需要人員有專業(yè)的數(shù)據(jù)基礎(chǔ)能力，這樣就導(dǎo)致了數(shù)據(jù)人力的缺失，可能會影響業(yè)務(wù)的數(shù)據(jù)支持力度;
- 口徑不一致：在使用數(shù)據(jù)過程當(dāng)中，口徑不一致是特別常見的一種問題，這種問題可能會導(dǎo)致一種數(shù)據(jù)使用和分析的差異，而且會降低業(yè)務(wù)的數(shù)據(jù)分析效率，最終對業(yè)務(wù)決策造成嚴(yán)重影響;
- 數(shù)據(jù)可靠性低：在生產(chǎn)過程中，降低業(yè)務(wù)的數(shù)據(jù)分析效率，最終會對業(yè)務(wù)決策造成嚴(yán)重的影響，不僅數(shù)據(jù)鏈路過程很長，其中還會引入很多數(shù)據(jù)質(zhì)量問題。并且，由于環(huán)節(jié)過多，也帶來了生產(chǎn)時間延遲的問題，可能直接影響到后續(xù)核心報表，推薦、模型的優(yōu)化;
- 跨業(yè)務(wù)難度大：因為我們?nèi)鄙僖粋€統(tǒng)一的數(shù)據(jù)建設(shè)的規(guī)劃、標(biāo)準(zhǔn)和規(guī)范，所以難以指導(dǎo)各個業(yè)務(wù)或者整個生產(chǎn)鏈路的各個環(huán)節(jié)，以擁有一個標(biāo)準(zhǔn)化的生產(chǎn)和處理過程，就導(dǎo)致了多個業(yè)務(wù)的數(shù)據(jù)難以融合，難以發(fā)揮更大的數(shù)據(jù)價值;
- 接入成本高：這主要應(yīng)用在一個新的業(yè)務(wù)場景下，也就是說，如果我們有新的業(yè)務(wù)接入或者新的場景需要使用數(shù)據(jù)，很多工作都需要人工處理。去申請各種資源、權(quán)限、找數(shù)據(jù)并且串聯(lián)整個數(shù)據(jù)的采集、生產(chǎn)、計算、同步和展示等各個環(huán)節(jié)，這是一個耗時長、效率低，最終還是很容易出錯的過程;
- 投遞質(zhì)量低：因為說到數(shù)據(jù)的話肯定離不開投遞，投遞是我們用來記錄用戶行為的一連串的數(shù)據(jù)信息。如果投遞過程缺少標(biāo)準(zhǔn)化或者流程管控的話，都會導(dǎo)致投遞質(zhì)量比較差;
- 獲取數(shù)據(jù)難：可能在大家日常工作中會發(fā)現(xiàn)，我們數(shù)據(jù)的生產(chǎn)到最終使用，中間可能要經(jīng)歷一個比較長的時間周期或者一個比較寬的團隊跨度，用戶可能無法很快地找到想要的數(shù)據(jù)，或者數(shù)據(jù)團隊生產(chǎn)出來的數(shù)據(jù)并沒有真正觸達(dá)到業(yè)務(wù)，來達(dá)到它的數(shù)據(jù)價值;
- 數(shù)據(jù)資產(chǎn)模糊：這個點可能和獲取數(shù)據(jù)難有一點點關(guān)聯(lián)，數(shù)據(jù)資產(chǎn)模糊的話更多的是在說我們需要對公司的數(shù)據(jù)資產(chǎn)做一個整體的管理，如果沒有這個整體的管理，就會導(dǎo)致對數(shù)據(jù)資產(chǎn)的級別和我們自己擁有什么數(shù)據(jù)資產(chǎn)都很模糊。最終就是導(dǎo)致數(shù)據(jù)的優(yōu)勢難以發(fā)揮出來，而且雖然我們耗費了很多計算資源、人力資源、存儲資源，但沒有帶來相應(yīng)的價值，最終導(dǎo)致資源效率極低。
基于這些數(shù)據(jù)工作的一些痛點，我們就會引入“數(shù)據(jù)中臺”的概念。
2、數(shù)據(jù)中臺的產(chǎn)生
數(shù)據(jù)中臺的產(chǎn)生，在國內(nèi)其實是阿里巴巴首先在2015年首先提出來的。提出這個概念指的是，我們通用能力的落地通過大中臺加小前臺的方式來實現(xiàn)。
但是，中臺并不適合所有的公司。數(shù)據(jù)中臺和其他中臺可能適用的場景，也就是一個公司或者一個集團有多個業(yè)務(wù)并行發(fā)展且需要不斷地沉淀通用能力的時候。
下面列舉愛奇藝數(shù)據(jù)的中臺化的轉(zhuǎn)變過程：
左邊是剛開始的狀態(tài)。我們每一個團隊都負(fù)責(zé)一個業(yè)務(wù)線的數(shù)據(jù)處理、報表開發(fā)，最終輸出的數(shù)據(jù)也要提供給一些橫向的團隊使用，比如說推薦、運營和用戶畫像的工作。
但是，每個團隊或者每條業(yè)務(wù)線所覆蓋的數(shù)據(jù)場景可能都不一樣，每個團隊的能力或者標(biāo)準(zhǔn)也不一樣，這樣輸出數(shù)據(jù)的質(zhì)量或者口徑就會參差不齊。最終導(dǎo)致在下游使用的時候，成本會急劇增加。特別是在這個業(yè)務(wù)快速發(fā)展了一段時間之后，這個問題就會越發(fā)地突現(xiàn)出來。
通過中臺化建設(shè)，組織架構(gòu)上靠一個團隊去支撐，把數(shù)據(jù)的通用能力抽象出來，并且統(tǒng)一維護這套通用的能力。再將這一套通用的能力附加到每條業(yè)務(wù)線上，把每一條業(yè)務(wù)線或者說把每一個業(yè)務(wù)線輸出的數(shù)據(jù)，做成一個標(biāo)準(zhǔn)化、流程化的數(shù)據(jù)體系，最終輸出給下游方使用。下游方就是我們的業(yè)務(wù)，包括推薦、運營，都是整個公司運轉(zhuǎn)起來的各個支持方向。
做完這個中臺化之后，從下游應(yīng)用的角度來說，它的口徑和效率都得到了一個很明顯的提升。
所以對于中臺化建設(shè)，我們的目標(biāo)就是避免煙囪式和重復(fù)建設(shè)，要實現(xiàn)抽象公共的通用能力，而且這個通用能力需要不斷沉淀和更新，并不是一成不變的。同時，需要提供相關(guān)的標(biāo)準(zhǔn)和規(guī)范來指導(dǎo)用戶共同打造和使用中臺，因為單靠一個團隊去支持所有標(biāo)準(zhǔn)化的事情是不太現(xiàn)實的。
在此背景下，中臺團隊有一項特別重要的工作就是提供標(biāo)準(zhǔn)和規(guī)范，讓大家能以一個統(tǒng)一的標(biāo)準(zhǔn)去開展工作。這樣按照標(biāo)準(zhǔn)化流程生產(chǎn)出來的數(shù)據(jù)或者是其他的技術(shù)能力都可以快速復(fù)用。
最終，其實我們還是希望能夠打造一個數(shù)據(jù)生態(tài)的閉環(huán)，覆蓋生產(chǎn)、處理、存儲、治理、服務(wù)整個過程。
3、數(shù)據(jù)中臺的實質(zhì)
數(shù)據(jù)中臺更像一種企業(yè)架構(gòu)，是一套結(jié)合互聯(lián)網(wǎng)技術(shù)和行業(yè)特性，在企業(yè)發(fā)展的不確定性中，尋找確定性，并且持續(xù)沉淀和抽象企業(yè)核心能力，最終支持企業(yè)快速、高效、低成本進行業(yè)務(wù)創(chuàng)新和增強的企業(yè)架構(gòu)。
進一步，數(shù)據(jù)中臺的實質(zhì)就是抽象通用的數(shù)據(jù)能力，解決公司業(yè)務(wù)發(fā)展遇到的一些實際問題，降低數(shù)據(jù)的使用成本，通過數(shù)據(jù)促進業(yè)務(wù)的發(fā)展。
二、愛奇藝數(shù)據(jù)中臺的定義
說了很多關(guān)于數(shù)據(jù)中臺的概念，下面我們結(jié)合愛奇藝的數(shù)據(jù)中臺來討論下數(shù)據(jù)中臺的定義。
1、理解數(shù)據(jù)中臺
這個圖其實是一個很簡略的圖，但是能比較清晰地劃分出后臺、中臺、前臺的分界線。
數(shù)據(jù)后臺：
我們大家平時更多用到了大數(shù)據(jù)集群，也就是說Hadoop、Spark、Flink以及其他OLAP工具。但是這些只是數(shù)據(jù)后臺的一個概念，并沒有做成一個標(biāo)準(zhǔn)化、通用化、門檻相對來說比較低的中臺化的概念。
數(shù)據(jù)中臺：
數(shù)據(jù)中臺其實是一個數(shù)據(jù)即服務(wù)的產(chǎn)品概念，它包括了數(shù)據(jù)服務(wù)、數(shù)據(jù)平臺、數(shù)據(jù)中臺產(chǎn)生的數(shù)據(jù)以及在所有的數(shù)據(jù)工作中產(chǎn)生的標(biāo)準(zhǔn)和規(guī)范，這一些組成了我們所謂的數(shù)據(jù)中臺。
數(shù)據(jù)前臺：
數(shù)據(jù)前臺就是我們實際的產(chǎn)品落地的具體例子，主要包括了幾個大的方向：
- 分析體系，比如說用戶分析、內(nèi)容分析、業(yè)務(wù)報表等;
- 數(shù)據(jù)應(yīng)用，比如說即席查詢、可視化查詢工具;
- 數(shù)據(jù)產(chǎn)品，類似于畫像和推薦業(yè)務(wù)，可能都是一些數(shù)據(jù)最終形成的產(chǎn)品，直接面向用戶服務(wù)。
所以數(shù)據(jù)中臺抽象出來，就是指“平臺+服務(wù)+數(shù)據(jù)+標(biāo)準(zhǔn)化”的概念，它是將數(shù)據(jù)的生產(chǎn)、收集、處理、存儲和服務(wù)進行封裝，并且面向不同層級的用戶提供不同的服務(wù)形式。
在數(shù)據(jù)標(biāo)準(zhǔn)化過程中，數(shù)據(jù)中臺可以防止數(shù)據(jù)重復(fù)建設(shè)，避免口徑問題，提高數(shù)據(jù)的使用效率。
在我們的數(shù)據(jù)的生產(chǎn)使用過程中，可能會因為歷史的原因，或者業(yè)務(wù)快速發(fā)展所帶來的弊端，導(dǎo)致數(shù)據(jù)生產(chǎn)出來，并沒有得到有效的使用或者生產(chǎn)出來的數(shù)據(jù)不夠穩(wěn)定、質(zhì)量不夠高。這個時候我們就需要對數(shù)據(jù)進行有效的治理，以提升數(shù)據(jù)傳輸?shù)姆€(wěn)定性和準(zhǔn)確性，同時提升資源的利用率。
從另外一個角度看，數(shù)據(jù)中臺最終的目的是為了屏蔽數(shù)據(jù)工作的復(fù)雜性，讓用戶能夠更方便、更高效地發(fā)現(xiàn)和使用數(shù)據(jù)，以此來滿足快速發(fā)業(yè)務(wù)快速發(fā)展的需求。
2、數(shù)據(jù)中臺的發(fā)展歷程
下圖是愛奇藝數(shù)據(jù)中臺的一個發(fā)展歷程，雖然相對粗粒度了一些，但是基本上能代表業(yè)界數(shù)據(jù)工作的一個發(fā)展歷程。
2017年及以前：
- 2017年及以前大家的數(shù)據(jù)工作都是一個相對零散化的狀態(tài)，用Hadoop client或者是其他的客戶端進行數(shù)據(jù)工作的開發(fā)，并且通過腳本化對數(shù)據(jù)任務(wù)進行管理和運維。
但是數(shù)據(jù)生產(chǎn)更多是需求導(dǎo)向的，來一個需求，我們就可以做一個數(shù)據(jù)。而不是，我們根據(jù)業(yè)務(wù)的發(fā)展的方向去擴展數(shù)據(jù)的需求并且提前把擴展性做好，這樣會導(dǎo)致數(shù)據(jù)比較零散，缺少統(tǒng)一的規(guī)劃。而缺少這種標(biāo)準(zhǔn)化的建設(shè)過程也符合當(dāng)時業(yè)務(wù)快速發(fā)展的需要。
2018年：
2018年愛奇藝開始推進平臺化建設(shè)的事情，也就是數(shù)據(jù)平臺的建設(shè)。
平臺化的過程中，我們主要是完成了以下幾項工作：
- 離線計算的任務(wù)的開發(fā)和運維管理;
- 對應(yīng)的流式計算的開發(fā)和運維管理;
- 為了高效穩(wěn)定地把外部的數(shù)據(jù)同步到我們的數(shù)據(jù)中臺，或者把數(shù)據(jù)產(chǎn)出同步到其他的業(yè)務(wù)系統(tǒng)下，我們開發(fā)了自己的數(shù)據(jù)集成模塊，用于實現(xiàn)不同存儲數(shù)據(jù)之間的數(shù)據(jù)同步功能;
我們對數(shù)據(jù)進行了一些簡單的管理，即數(shù)據(jù)表的創(chuàng)建到、維護、管理，都通過平臺化的形式去進行的。
2019年：
- 在平臺化初步建成之后，我們開始著手做一些標(biāo)準(zhǔn)化的工作。
- 標(biāo)準(zhǔn)化工作幾乎覆蓋了整個數(shù)據(jù)生命周期，從日志投遞環(huán)節(jié)開始實施，針對Pingback2.0的規(guī)范，做了相應(yīng)的工具來支持這個規(guī)范落地。同時結(jié)合公司業(yè)務(wù)制定了數(shù)據(jù)倉庫規(guī)范，用于指導(dǎo)整個的建模流程，也對指標(biāo)和維度體系都做了一個明確的定義和規(guī)范。
- 進一步，把數(shù)據(jù)的生產(chǎn)流程進行了流程化的管理，最終給下游提供了統(tǒng)一的數(shù)據(jù)接口能力。這個數(shù)據(jù)接口能力更多偏向應(yīng)用層，我們通過前面一系列的數(shù)據(jù)開發(fā)工作，在平臺上定義數(shù)據(jù)接口和數(shù)據(jù)服務(wù)，最終通過REST API的形式，對下游提供數(shù)據(jù)查詢或接入能力。
2020年：
- 完成了上述的平臺化和標(biāo)準(zhǔn)化工作之后，其實已經(jīng)初步達(dá)到了中臺化建設(shè)的要求。
- 前面提到的平臺化和標(biāo)準(zhǔn)化更多的是給中臺團隊定義了一套統(tǒng)一的流程，讓使用方按照這套流程做操作和處理。而中臺化，其實是完成了一個從統(tǒng)一化到定制化的一個轉(zhuǎn)變。也就是說，中臺可以提供各種各樣在不同環(huán)節(jié)的工具或者平臺，業(yè)務(wù)方根據(jù)自己的需要進行靈活組裝，把這種模塊化的數(shù)據(jù)能力，定制化地輸出到業(yè)務(wù)當(dāng)中。
- 同時，我們開始了數(shù)據(jù)治理的體系。數(shù)據(jù)治理包括制定數(shù)據(jù)資產(chǎn)的定級標(biāo)準(zhǔn)、梳理整個數(shù)據(jù)鏈路、數(shù)據(jù)存儲形式和數(shù)據(jù)使用審計等環(huán)節(jié)。所以可以認(rèn)為，數(shù)據(jù)治理是一個持續(xù)性的工作，不像項目制工作有結(jié)項的節(jié)點和計劃，這和平臺化、標(biāo)準(zhǔn)化的事情還是有一定差異的。
還有就是我們在基于平臺化、標(biāo)準(zhǔn)化的過程中，對新的業(yè)務(wù)抽象出一套通用的處理模板，幫助業(yè)務(wù)快速、自動化地完成接入，這種方式適合公司內(nèi)部孵化的一些新業(yè)務(wù)快速接入我們的數(shù)據(jù)能力。
最后，是一個持續(xù)化的過程，即通用能力的不斷沉淀。因為數(shù)據(jù)工作，或者其他技術(shù)類工作都是類似的，在實際的發(fā)展過程中技術(shù)和理念的升級，都會帶來一些通用能力的抽象沉淀，所以這個不斷沉淀的過程也是一個發(fā)展的過程。
3、數(shù)據(jù)中臺的輸出
數(shù)據(jù)中臺面向不同的用戶和場景，它的呈現(xiàn)形式是都不一樣。因為中臺的目的是服務(wù)業(yè)務(wù)和用戶，它區(qū)別于平臺一個特別關(guān)鍵的點就是它可以滿足不同場景和不同用戶，通過數(shù)據(jù)中臺的模塊化能力構(gòu)建一套定制化的數(shù)據(jù)處理流程，以此來滿足不同業(yè)務(wù)的個性化的數(shù)據(jù)解決方案。
數(shù)據(jù)中臺輸出形式分為以下幾個：
- 服務(wù)：指可以提供對外信息查詢、可視化查詢、數(shù)據(jù)接口、元數(shù)據(jù)接口等服務(wù)形式，用戶可以直接訪問或者通過協(xié)議對接到自己的平臺或者服務(wù)當(dāng)中;
- 數(shù)據(jù)：指數(shù)據(jù)工作中一個核心的產(chǎn)出，最終以一個統(tǒng)一數(shù)倉的形式呈現(xiàn)出來。統(tǒng)一數(shù)倉完成一些標(biāo)準(zhǔn)化的工作，把業(yè)務(wù)都需要的一些通用邏輯進行抽象處理，避免下游使用方在使用過程中的重復(fù)處理。因為在重復(fù)的處理過程中，可能會引入不一致的口徑或者維度，造成資源的浪費。而且，因為數(shù)據(jù)發(fā)展可能要經(jīng)歷業(yè)務(wù)的很多階段，所以我們在做統(tǒng)一數(shù)倉的時候，需要把這些歷史的演進過程，幫用戶屏蔽掉，讓大家在用數(shù)據(jù)時，不需要再去考慮歷史的演進問題。而且我們在對于不同業(yè)務(wù)之間也做了一個標(biāo)準(zhǔn)化的處理，方便用戶跨業(yè)務(wù)地去使用數(shù)據(jù);
- 平臺：更多面向數(shù)據(jù)開發(fā)人員，對整個的大數(shù)據(jù)的能力進行了平臺化的封裝。提供界面化的數(shù)據(jù)開發(fā)能力，并且數(shù)據(jù)任務(wù)的運維和管理更加高效，同時也會把工作中常用到的信息以更好的組織形式展現(xiàn)出來。除了這些能力之外，還有其他便于用戶使用和加工數(shù)據(jù)的能力，比如HA、補跑數(shù)據(jù)等;
- 投遞：數(shù)據(jù)來源中比較重要的一塊。在形成了一套投遞標(biāo)準(zhǔn)之后，去建立一些對應(yīng)的投遞工具用于進行投遞管理。進一步，在測試和灰度階段也增加了兩個平臺用于保證投遞質(zhì)量，分別是統(tǒng)計測試平臺和灰度監(jiān)測平臺。在這兩個階段對質(zhì)量進行監(jiān)控，最終保證數(shù)據(jù)在真正投遞出來之前穩(wěn)定可靠且質(zhì)量比較高;
- 標(biāo)準(zhǔn)/規(guī)范：是數(shù)據(jù)中臺能力最基礎(chǔ)的組成部分。也就是說，中臺要輸出標(biāo)準(zhǔn)流程和規(guī)范來讓大家可以快速按照流程和規(guī)范去開展工作，而且這個流程和規(guī)范一定是方便用戶接受的。如果一些標(biāo)準(zhǔn)流程過于復(fù)雜，就要盡可能地通過平臺化、工具化的方式協(xié)助用戶理解。
4、數(shù)據(jù)中臺的定位
說到數(shù)據(jù)中臺定位，因為數(shù)據(jù)中臺和前臺、后臺都需要有一個明確的劃分，數(shù)據(jù)中臺定位提供了這種抽象通用的能力來支持前臺團隊在此基礎(chǔ)之上進行定制化，最終在復(fù)用通用能力的同時，能夠滿足業(yè)務(wù)快速發(fā)展的個性化的需求，達(dá)到一個全局最優(yōu)化的狀態(tài)。
三、愛奇藝數(shù)據(jù)中臺建設(shè)
下面給大家介紹一下愛奇藝數(shù)據(jù)中臺的建設(shè)過程。
1、建設(shè)
我們主要是從五個角度去輸出中臺能力，分別是服務(wù)、數(shù)據(jù)、平臺、投遞、標(biāo)準(zhǔn)/規(guī)范。在愛奇藝數(shù)據(jù)中臺的實施過程中，我們劃分出了三個大方向：
- 生產(chǎn)，也就是我們所說的投遞體系;
- 數(shù)據(jù)，也就是統(tǒng)一數(shù)倉的體系，是數(shù)據(jù)的核心;
- 大數(shù)據(jù)平臺能力：包括開發(fā)、治理、服務(wù)。
日志投遞：
- 這部分我們輸出了投遞規(guī)范，進一步針對投遞規(guī)范，我們需要對公司的相關(guān)員工進行培訓(xùn)，讓大家深刻地理解投遞是為了做什么，并且怎樣才能達(dá)到我們對于用戶的行為足夠深入的分析要求。
在平臺和工具這個角度，我們封裝了Pingback SDK來滿足不同端的投遞工作，比如安卓、iPhone等;通過Pingback SDK去幫助業(yè)務(wù)實現(xiàn)通用化的工作。同時我們幫助投遞管理的同學(xué)提供了一個管理平臺，并且在數(shù)據(jù)的使用當(dāng)中提供統(tǒng)計測試平臺和灰度監(jiān)測平臺。
大數(shù)據(jù)平臺：
- 我們有一線開發(fā)、對應(yīng)的運維管理、實時開發(fā)對應(yīng)的運維管理，以及數(shù)據(jù)治理、數(shù)據(jù)圖譜、數(shù)據(jù)服務(wù)和即席查詢。即席查詢是我們數(shù)據(jù)服務(wù)里的一個子項，但是因為應(yīng)用面比較廣，就單獨拎出來了。
統(tǒng)一數(shù)倉：
- 最后一塊是統(tǒng)一數(shù)倉的能力，也就是為下游提供離線和實時的兩種數(shù)倉能力。為了方便大家實現(xiàn)跨離線和實時混合使用的場景，需要進行標(biāo)準(zhǔn)化的工作，也就是離線輸出的字段、定義、口徑、格式和實時數(shù)據(jù)要盡可能一致，即實時數(shù)據(jù)向離線數(shù)據(jù)看齊。
同時，數(shù)倉在提供數(shù)據(jù)本身的能力之外，我們還要維護整個公司級別的指標(biāo)體系和統(tǒng)一維度，讓所有的數(shù)據(jù)系統(tǒng)平臺和都會對接到統(tǒng)一的維度指標(biāo)體系。而且，為了幫助數(shù)倉建設(shè)過程中的數(shù)據(jù)建模和統(tǒng)計指標(biāo)的管理，我們建設(shè)了一個對應(yīng)的數(shù)據(jù)平臺，也是按照數(shù)據(jù)規(guī)范的標(biāo)準(zhǔn)建設(shè)，以此來支持使用方使用平臺依照規(guī)范去建設(shè)數(shù)倉的流程化工作。
2、Pingback體系
Pingback的體系就是投遞體系，那么具體為什么要做這個事情呢?
投遞工作面臨的問題主要有以下幾個點：
- 缺乏整體的規(guī)劃，投遞數(shù)據(jù)使用難度大。就是大家可能在使用的過程中說，在不同業(yè)務(wù)當(dāng)中同樣的字段不一樣，或者不一樣的還以同樣的字段，或者在同一個業(yè)務(wù)因為時間的前后性，在一年前做的字段還有用但一年之后它就代表了另外一種含義，又或者產(chǎn)生了一個相同含義的另一個字段，這就造成了后續(xù)使用數(shù)據(jù)的難度特別大;
- 管理力度不足，后期維護成本極高。這其實也是一個雙刃劍，如果管理力度過高的話，業(yè)務(wù)在使用起來就會覺得約束性比較強，效率就會有所降低。但如果管理力度不夠的話，就會造成一種隨用隨投的過程，最終導(dǎo)致了歷史延續(xù)性很差，維護成本極高。同時，如果沒有工具和平臺去統(tǒng)一維護和管理的話，大家會以各種形式來傳遞這些信息，導(dǎo)致溝通成本也相當(dāng)高;
- 缺少共用的約束和校驗環(huán)節(jié)，投遞質(zhì)量難以保證。由于沒有一個統(tǒng)一的規(guī)范，導(dǎo)致后續(xù)對投遞質(zhì)量校驗和監(jiān)測的過程中，也就沒有統(tǒng)一的標(biāo)準(zhǔn)，最終導(dǎo)致投遞質(zhì)量難以保障;
- 字段等定義不一致，跨業(yè)務(wù)數(shù)據(jù)打通很難。作為一個公司，不同業(yè)務(wù)線的數(shù)據(jù)在各自業(yè)務(wù)線發(fā)揮的價值要遠(yuǎn)遠(yuǎn)小于數(shù)據(jù)能跨業(yè)務(wù)向打通的這種價值。所以，當(dāng)字段的這種跨業(yè)務(wù)線定義產(chǎn)生很大的差異，或者完全不一致的情況下，這種跨業(yè)務(wù)數(shù)據(jù)難打通造成的數(shù)據(jù)的價值流失特別嚴(yán)重。
3、數(shù)倉體系
下圖右側(cè)是一個簡化流程，依據(jù)Pingback規(guī)范建設(shè)Pingback管理平臺，同時開發(fā)了一整套的Pingback SDK。業(yè)務(wù)在使用SDK的時候，把這些用戶行為投遞出來并進行收集，通過ETL輸出到測試統(tǒng)計和灰度監(jiān)測這兩個平臺上，通過兩個環(huán)節(jié)對數(shù)據(jù)質(zhì)量進行校驗，盡可能地把投遞問題堵截在全量發(fā)布之前。
數(shù)倉體系幾個要解決的痛點：
- 數(shù)據(jù)重復(fù)建設(shè)和資源浪費。這個資源浪費不是簡簡單單的存儲和計算資源，人力資源的浪費可能更為明顯;
- 維度和指標(biāo)定義混亂。能描述同一個統(tǒng)計口徑指標(biāo)，名稱完全不一樣，或者名稱完全一樣，但是口徑是完全不一致的，維度也會有類似的問題;
- 口徑不統(tǒng)一。比如說我們在算轉(zhuǎn)化率的時候，跨業(yè)務(wù)線的統(tǒng)一口徑，或者同一個業(yè)務(wù)不同的需求下口徑也不一致，導(dǎo)致后續(xù)的數(shù)據(jù)使用過程中，經(jīng)常出現(xiàn)數(shù)據(jù)撞車的情況，這就需要花大量人力和精力去排查解決;
- 業(yè)務(wù)處理邏輯復(fù)雜。因為每一個業(yè)務(wù)都有自己特有的業(yè)務(wù)邏輯，并且在投遞過程中可能會產(chǎn)生一些投遞問題，所以需要在數(shù)據(jù)處理過程中把這些問題修復(fù)掉。但是，修復(fù)的過程如果沒有一個統(tǒng)一的處理節(jié)點，就會造成每一處下游使用時都要做額外的處理，大大提高了業(yè)務(wù)處理的邏輯復(fù)雜度;
- 數(shù)據(jù)質(zhì)量參差不齊。因為大家各自去構(gòu)建自己的數(shù)據(jù)產(chǎn)出流程，數(shù)據(jù)質(zhì)量參差不齊，越底層數(shù)據(jù)的質(zhì)量問題對下游的影響度就越大;
- 數(shù)據(jù)使用的溝通成本高。在缺少規(guī)劃的背景下，接收到一個或一批數(shù)據(jù)需求時，都會輸出一些新的數(shù)據(jù)表或者數(shù)據(jù)產(chǎn)出。在后續(xù)復(fù)用的情況下，沒有一個統(tǒng)一標(biāo)準(zhǔn)去維護和管理，或者我們在建設(shè)數(shù)據(jù)的過程中也沒有統(tǒng)一標(biāo)準(zhǔn)，就會造成使用過程中也需要去反復(fù)地溝通和確認(rèn)，才能真正找到對應(yīng)的數(shù)據(jù)，而且找到的數(shù)據(jù)也不見得口徑一定一致。
4、數(shù)倉平臺
數(shù)倉平臺主要是為了做業(yè)務(wù)建模、數(shù)據(jù)建模、物理建模、維度管理、指標(biāo)管理和數(shù)倉管理。
數(shù)倉平臺的特性：
- 數(shù)據(jù)表創(chuàng)建的約束性：比如我們需要對表有的命名規(guī)范要求，如果沒有一個工具去管理，可能會因為大家對規(guī)范的理解不一致，最終導(dǎo)致落地過程中依然存在各種各樣的差異性;
- 數(shù)據(jù)信息的可描述性：指在創(chuàng)建表的過程中，為了快速地滿足業(yè)務(wù)，很少去添加一些相關(guān)的描述信息，導(dǎo)致數(shù)據(jù)缺少描述性。所以需要通過平臺，要求用戶在數(shù)據(jù)創(chuàng)建的過程中把信息描述的足夠精細(xì)，方便后續(xù)的數(shù)據(jù)使用過程;
- 數(shù)據(jù)建模體系的完整性：指我們需要一個三步的建模過程，即業(yè)務(wù)建模后，有對應(yīng)的數(shù)據(jù)建模;數(shù)據(jù)建模之后，針對這個數(shù)據(jù)建模，有不同的物理建模的形式。整體是一個流程化的工作，避免用戶為了快速地滿足業(yè)務(wù)需求跳過某些過程，最終導(dǎo)致建模的擴展性較差;
- 數(shù)據(jù)關(guān)系的維度與指標(biāo)管理的系統(tǒng)性：通過提供一套統(tǒng)一的維度和指標(biāo)管理體系來作為一個中心，對外輸出統(tǒng)一的指標(biāo)和維度，讓大家在使用的過程中，可以使用這些標(biāo)準(zhǔn)化后的并且集中管理的元數(shù)據(jù);
- 數(shù)據(jù)關(guān)系的可追溯性：是指通過數(shù)倉建設(shè)、建模的過程，促使我們后續(xù)數(shù)據(jù)表和字段的相互關(guān)系是有記錄可查詢的，也就是我們所說的數(shù)據(jù)血緣關(guān)系。
5、離線數(shù)倉架構(gòu)
下面是數(shù)倉的簡化架構(gòu)，主要是體現(xiàn)了離線數(shù)倉部分。其中帶顏色的一部分是統(tǒng)一數(shù)倉，其他的淺顏色的就是一些數(shù)據(jù)應(yīng)用，包括數(shù)據(jù)集市和主題數(shù)倉。
6、大數(shù)據(jù)平臺
最后一個大方向就是大數(shù)據(jù)平臺：
我們大數(shù)據(jù)平臺經(jīng)歷了五個階段，第一個階段和第二個階段聯(lián)系更加緊密：
開發(fā)：我們在第一階段完成了整個數(shù)據(jù)開發(fā)的平臺化、可視化能力，降低了開發(fā)門檻，并提升開發(fā)標(biāo)準(zhǔn)化。
運維：在開發(fā)之后，需要提升任務(wù)的管理和運維能力。通過建設(shè)運維管理模塊的建設(shè)，保證用戶更方便地對任務(wù)進行管理，并且對任務(wù)產(chǎn)出的穩(wěn)定性和數(shù)據(jù)產(chǎn)出的時效性實現(xiàn)了有效的監(jiān)控。
質(zhì)量：在提供了數(shù)據(jù)開發(fā)和管理相關(guān)能力之后，需要進一步對數(shù)據(jù)產(chǎn)出進行質(zhì)量校驗，避免生產(chǎn)出的數(shù)據(jù)在未關(guān)注數(shù)據(jù)質(zhì)量的情況下直接被使用，造成數(shù)據(jù)問題的快速擴散。
數(shù)據(jù)質(zhì)量這一部分主要是為了及早地發(fā)現(xiàn)質(zhì)量問題，盡可能地把問題解決在數(shù)據(jù)鏈路的更上游的階段，避免造成數(shù)據(jù)的生產(chǎn)延遲和資源浪費。
使用：數(shù)據(jù)使用也是一個數(shù)據(jù)發(fā)現(xiàn)的過程。比如生產(chǎn)了很多數(shù)據(jù)，如何讓用戶看到這些數(shù)據(jù)，并將其更好地應(yīng)用在業(yè)務(wù)需求當(dāng)中。
針對這個痛點，我們完成數(shù)據(jù)圖譜模塊的發(fā)布，把各種的數(shù)據(jù)元信息進行收集、加工、管理，最終把完整的數(shù)據(jù)信息以一種更友好的形式提供出來，幫助大家快速地發(fā)現(xiàn)數(shù)據(jù)，進一步去了解數(shù)據(jù)元信息、快速準(zhǔn)確地使用數(shù)據(jù)。
治理：是數(shù)據(jù)生態(tài)的最后一個環(huán)節(jié)，也是打造健康生態(tài)閉環(huán)的重要部分。有的公司可能是把治理放到比較靠前的環(huán)節(jié)，但是在一些場景下，比如說業(yè)務(wù)快速發(fā)展的過程中，治理往往是跟不上業(yè)務(wù)需求的。
所以我們采取的方式是，等業(yè)務(wù)發(fā)展到一定程度，再去補充數(shù)據(jù)治理的能力，對存量去治理，對增量去管控。治理工作的內(nèi)容主要包括對數(shù)據(jù)和任務(wù)進行日常審計，然后通過數(shù)據(jù)血緣和使用情況，對數(shù)據(jù)的冗余度進行有效評估，并進行相應(yīng)的優(yōu)化，以減少資源和人力的浪費。同時在生產(chǎn)過程中，如果出現(xiàn)生產(chǎn)不穩(wěn)定的情況，我們也可以快速地發(fā)現(xiàn)問題，進而優(yōu)化整個的生產(chǎn)鏈路，提高整個數(shù)據(jù)生態(tài)的健康度。
7、數(shù)據(jù)平臺架構(gòu)
這就是數(shù)據(jù)平臺的一個大體的架構(gòu)：
最底層是一個數(shù)據(jù)層，比如說我們的投遞服務(wù)器的日志，包括業(yè)務(wù)的數(shù)據(jù)或者其他數(shù)據(jù)來源，通過我們的采集層和傳輸層達(dá)到我們的計算層。計算層的話，更多的是大數(shù)據(jù)集群服務(wù)，也包括一些任務(wù)調(diào)度能力;再上層是我們所提到的平臺層，包括離線和流式任務(wù)的開發(fā)管理、機器學(xué)習(xí)平臺、數(shù)倉平臺，然后下面是對于整個的數(shù)據(jù)的ETL的一個平臺化的處理，還有外部數(shù)據(jù)的一個同步能力的模塊，稱為數(shù)據(jù)集成。在擁有這些開發(fā)能力或管理能力的同時，我們還需要對投遞管理、數(shù)據(jù)安全、數(shù)據(jù)質(zhì)量、數(shù)據(jù)圖譜做一些有效的建設(shè)，并且在整個數(shù)據(jù)體系中去做數(shù)據(jù)治理工作。最終是以即席查詢、實時分析，數(shù)據(jù)服務(wù)、元數(shù)據(jù)服務(wù)多種形式對下游提供服務(wù)能力。
四、應(yīng)用場景
數(shù)據(jù)中臺的應(yīng)用場景，其實面向不同階段來提供不同的接入方式：
- 第一個階段是統(tǒng)一化的形式。我們有一套通用的模板，它的優(yōu)點和缺點都很明顯，優(yōu)點是接入起來很簡單，缺點就是不夠個性化和定制化，只能支持這種通用的數(shù)據(jù)能力。所以它比較適合于業(yè)務(wù)初期，能夠進行快速接入，并且自動化地完成這種數(shù)據(jù)的處理和服務(wù);
- 第二個階段是個性化的能力。也就是說，我們把整個流程確定下來，業(yè)務(wù)在使用過程中可以針對某些環(huán)節(jié)做定制化的開發(fā)，拓展現(xiàn)存數(shù)據(jù)模塊的能力來滿足一些個性化需求，所以它更適用于業(yè)務(wù)的成長期的階段;
- 第三個階段是定制化的能力。定制化更多面向一些特別成熟的業(yè)務(wù)，也就是對于數(shù)據(jù)這一塊的需求有多方面的、深層次的使用場景，并且通用的和個性化的架構(gòu)已經(jīng)不足以滿足數(shù)據(jù)需求的情況下，可以采用定制化的能力。定制化能力也就是我們提供數(shù)據(jù)模塊化的能力，然后業(yè)務(wù)再根據(jù)自己的需求去對應(yīng)選取這些模塊化能力，并進行組裝和擴展，來滿足自己定制化的需求。
以下是一個自動化接入流程：
新業(yè)務(wù)接入，做出一個產(chǎn)品，然后使用我們投遞的SDK去進行投遞，通過平臺的工具進行投遞的管理，最終數(shù)據(jù)采集、存儲、監(jiān)控，到統(tǒng)一數(shù)倉的加工，數(shù)據(jù)結(jié)果的輸出，這整一個流程都是有統(tǒng)一的模板去執(zhí)行的。比如我們常見的DAU、留存、新增、轉(zhuǎn)化率、點擊率，其實靠通用模板就能達(dá)到。
最終輸出的形式，比如用戶行為分析或者我們提供不同層級的數(shù)據(jù)產(chǎn)出物，像是MID層的聚合數(shù)據(jù)或者DWD層的明細(xì)數(shù)據(jù)等。用戶可以通過自主查詢的能力對數(shù)據(jù)進行查詢和使用，同時業(yè)務(wù)線也會有自己的核心報表或者通用報表，可以通過這套自動化的流程產(chǎn)出，最終反哺到新業(yè)務(wù)當(dāng)中。
這是一個快速，并且成本極其低的一個過程，更適用于業(yè)務(wù)的初期階段。
以下是一個定制化的接入過程：
定制化的用戶更多的可以參與到數(shù)據(jù)的整個處理過程當(dāng)中。比如說生產(chǎn)和定制化的開發(fā)、業(yè)務(wù)基于統(tǒng)一數(shù)倉建設(shè)自己的數(shù)倉、關(guān)注自己的數(shù)據(jù)質(zhì)量、輸出數(shù)據(jù)結(jié)果、數(shù)據(jù)業(yè)務(wù)集市，最終能輸出成自助查詢的一些數(shù)據(jù)元。
然后，一些定制化的報表、用戶行為的分析，都也可以去定制化自己的元數(shù)據(jù)服務(wù)和數(shù)據(jù)服務(wù)能力來對接到自己的平臺或者服務(wù)上，這是一個相對來說比較定制化的過程。大家可以在某一個環(huán)節(jié)或者是某些環(huán)節(jié)去接入，更多地把自己的一個業(yè)務(wù)的特點應(yīng)用到數(shù)據(jù)的整個處理過程當(dāng)中。
Q & A
Q1：請問沒有做過數(shù)據(jù)倉庫，可以一步到位建設(shè)數(shù)據(jù)中臺嗎?
不建議這么做，數(shù)據(jù)工作的核心是數(shù)據(jù)，而數(shù)據(jù)倉庫是數(shù)據(jù)的主要組織形式，是應(yīng)該最早建設(shè)起來的，可以脫離數(shù)據(jù)中臺的其他部分發(fā)揮數(shù)據(jù)價值;同時建設(shè)數(shù)據(jù)中臺工作是一個長期迭代的過程，也不會是一步到位的。
Q2：數(shù)倉到數(shù)據(jù)中臺，和大數(shù)據(jù)平臺到數(shù)據(jù)中臺，哪種路徑會更好些?
這兩個方向并不沖突，數(shù)據(jù)中臺更著重的是數(shù)據(jù)的通用能力輸出，無論是數(shù)倉還是大數(shù)據(jù)平臺都是數(shù)據(jù)中臺不可或缺的重要組成部分;如果非要選擇一個的話，我建議先建數(shù)倉，因為大數(shù)據(jù)平臺是可以通過直接使用大數(shù)據(jù)集群完成相關(guān)數(shù)據(jù)工作的能力。
Q3：建設(shè)數(shù)據(jù)倉庫的方法論是什么?主要用到什么系統(tǒng)?
主要是依賴Kimball的多維建模方法論，但是針對一些實體分析的場景，如用戶數(shù)倉、內(nèi)容數(shù)倉等等，則需要引入Anchor建模方式，這兩種建模方式是目前我們主要采用的;我們目前是自建的數(shù)倉平臺，是依賴自身制定的數(shù)倉規(guī)范進行建設(shè)的，主要有建模流程、模型管理、維度管理和指標(biāo)管理等子模塊。
Q4：數(shù)據(jù)倉庫里，拉鏈表多嗎?
目前拉鏈表較少，拉鏈表的生產(chǎn)和使用成本相對較高，而使用的場景又相對有限;如果確實有這方面的需求，可以考慮在特定的場景對快照表進行相應(yīng)的處理，以實現(xiàn)拉鏈表所提供的能力。
Q5：請問投遞怎么理解?是埋點或者訂閱嗎?主要涉及到哪些工作?
投遞可以理解為用戶行為的記錄，包括用戶啟動APP、播放視頻、瀏覽頁面和點擊內(nèi)容等，可以記錄用戶在APP內(nèi)的操作行為;主要涉及投遞設(shè)計和管理，投遞出的日志收集和ETL，包括用于監(jiān)控投遞質(zhì)量的統(tǒng)計平臺等。
Q6：請問什么是埋點呢?埋點丟失時預(yù)警有做嗎?
埋點可以理解為用戶行為的記錄，即在用戶的某種行為下會觸發(fā)行為日志的投遞;埋點丟失的預(yù)警可以有兩個角度，一個是功能角度，即用戶級別的監(jiān)測，這依賴前端的投遞SDK，用于記錄投遞失敗的次數(shù)和信息;另一個是統(tǒng)計角度，即從相對粗的粒度進行行為統(tǒng)計，根據(jù)其他事件或者歷史情況進行對比，確認(rèn)數(shù)據(jù)是否有丟失。
Q7：數(shù)據(jù)重跑是怎樣的?
數(shù)據(jù)重跑的場景可以分為幾種情況，數(shù)據(jù)修復(fù)、口徑變化、新增指標(biāo)等;我們會通過數(shù)據(jù)平臺的任務(wù)管理來創(chuàng)建重跑任務(wù)，指定重跑時間段、相關(guān)參數(shù)和并行度等，然后執(zhí)行重跑任務(wù)，最后在數(shù)據(jù)重跑后進行數(shù)據(jù)的驗證。
Q8：數(shù)據(jù)質(zhì)量平臺稽核任務(wù)的執(zhí)行，對接的數(shù)據(jù)存儲一般用哪些?關(guān)系型數(shù)據(jù)庫還是Hive?
數(shù)據(jù)中臺的數(shù)據(jù)主要是離線和實時兩種形式，離線數(shù)據(jù)主要以Hive為載體，其中包括從關(guān)系型數(shù)據(jù)庫接入的業(yè)務(wù)數(shù)據(jù);實時數(shù)據(jù)主要以Kafka為載體;數(shù)據(jù)質(zhì)量平臺主要針對這兩種形式的數(shù)據(jù)進行數(shù)據(jù)稽核。
Q9：在中臺上如何開放目錄或者地圖，讓業(yè)務(wù)方或者其他應(yīng)用開發(fā)者快速獲取所需數(shù)據(jù)?
數(shù)據(jù)中臺中有數(shù)據(jù)圖譜模塊，以搜索和地圖等形式將元數(shù)據(jù)以更為合理的形式輸出，方便用戶發(fā)現(xiàn)數(shù)據(jù)，并在平臺一站式的完成數(shù)據(jù)的權(quán)限申請和使用。
Q10：數(shù)據(jù)治理是放到數(shù)據(jù)服務(wù)之后嗎?數(shù)據(jù)治理主要是治理哪塊?數(shù)據(jù)質(zhì)量?數(shù)據(jù)標(biāo)準(zhǔn)?
數(shù)據(jù)治理是貫穿整個數(shù)據(jù)生命周期的，和數(shù)據(jù)服務(wù)沒有前后關(guān)系，可以認(rèn)為數(shù)據(jù)服務(wù)也是在數(shù)據(jù)治理的范疇之內(nèi);數(shù)據(jù)治理主要包括數(shù)據(jù)質(zhì)量的分析、生產(chǎn)鏈路穩(wěn)定性的分析、資源利用分析、數(shù)據(jù)標(biāo)準(zhǔn)化分析和使用審計等，數(shù)據(jù)治理的目的是為了保障數(shù)據(jù)穩(wěn)定高質(zhì)的進行生產(chǎn)，并推進整體的資源優(yōu)化，同時防止數(shù)據(jù)的泄露等。
Q11：對于數(shù)據(jù)生命周期怎么處理?有做冷熱備份嗎?
數(shù)據(jù)有不同的資產(chǎn)等級，需要根據(jù)不同的資產(chǎn)等級制定TTL的設(shè)定;同時可以對數(shù)據(jù)進行垂直裁剪，將時效性要求較高的部分進行裁剪，以降低數(shù)據(jù)存儲的成本;另外，為了滿足對歷史數(shù)據(jù)的追溯，可以將使用頻率極低的數(shù)據(jù)存儲到冷備，但需要考慮冷備的成本，包括恢復(fù)數(shù)據(jù)的經(jīng)濟成本和時間成本。
Q12：請問支持為多租戶分配平臺資源、工具、開發(fā)嗎?
支持，這是數(shù)據(jù)平臺必須的能力。
Q13：愛奇藝用到的大數(shù)據(jù)集群是開源的還是CDH?
主要是基于CDH的，并在此基礎(chǔ)上進行了定制化的開發(fā)，包括內(nèi)外部的各種補丁。
Q14：任務(wù)調(diào)度系統(tǒng)是自研的嗎?還是用的開源的，哪個會比較好呢?
目前任務(wù)調(diào)度系統(tǒng)是基于oozie進行二次開發(fā)的，主要是增加了一些參數(shù)和打通其他的數(shù)據(jù)中臺組件;目前主流的調(diào)度主要是oozie、airflow和azkaban等，各有優(yōu)勢，主要還是得看具體的使用場景和取舍，進而選擇合適的調(diào)度系統(tǒng)。
Q15：請問下老師，大數(shù)據(jù)平臺目前對外輸出嗎?
暫時還沒有對外輸出，由于每個公司的具體場景存在差異性，數(shù)據(jù)中臺的體現(xiàn)形式也會稍有不同，不過后期可能會通過文章或者書籍的方式對外輸出我們的想法和建設(shè)感受。
馬金韜
愛奇藝數(shù)據(jù)中臺負(fù)責(zé)人
目前主要負(fù)責(zé)愛奇藝數(shù)據(jù)中臺的規(guī)劃和建設(shè)，對廣告業(yè)務(wù)和大數(shù)據(jù)體系都有一定的了解;
北郵本碩畢業(yè)，先后在百度、阿里巴巴、墨跡和愛奇藝等多家公司從事廣告和大數(shù)據(jù)方向的工作。
網(wǎng)站標(biāo)題：愛奇藝數(shù)據(jù)中臺建設(shè)組合拳：日志投遞、統(tǒng)一數(shù)倉、大數(shù)據(jù)平臺
文章分享：http://www.fisionsoft.com.cn/article/dhsdshh.html
