導讀：本文將介紹分貝通在大數(shù)據(jù)領域的一些建設經(jīng)驗。分貝通在ToB領域是一個年輕的公司，成立六年多，大數(shù)據(jù)體系剛剛建立一年多，整個團隊不到二十人，整體的大數(shù)據(jù)建設處于初級和摸索的階段。本次將總結在大數(shù)據(jù)業(yè)務上的實踐和思考，希望給大家?guī)韱l(fā)。

主要內容包括以下幾方面：

公司介紹

大數(shù)據(jù)建設背景

大數(shù)據(jù)建設方案

大數(shù)據(jù)應用場景

01公司介紹

先簡單介紹一下分貝通。

我們平常公司中可能會遇到這種場景，比如出差時通過公司OA或郵件進行審批，然后去訂機票、火車票、酒店等，到了目的地之后很多費用還要自己墊付，回來再通過發(fā)票報銷，發(fā)票數(shù)量多且金額大，時間耗費多；同時對公司而言，因為要對接很多外部平臺，對企業(yè)和員工而言都是非常麻煩的。

分貝通致力于解決企業(yè)這方面的痛點，除了差旅這部分大的支出，我們也希望在所有的支出管理場景提供整體解決方案，實現(xiàn)企業(yè)在預算、審批、交易、報銷的全流程閉環(huán)。對員工而言，所有支出都在一個平臺，可以不用墊資和發(fā)票，使用非常便捷。對企業(yè)而言，可以做到事前預算管理，事中費用控制，事后自動報銷，極大地減輕了財務和行政的工作量。

前提是分貝通需要提前去對接不同的供應商，比如酒店供應商、用車供應商等。在某些場景，分貝通還在建立自己的供應商體系，包括自營的酒店、自營的商城。經(jīng)過六年多的發(fā)展，該模式得到了投資人和市場的認可，現(xiàn)在服務于數(shù)千家客戶，業(yè)務增長迅速，融資的規(guī)模也比較可觀，目前在企業(yè)服務領域算是獨角獸的存在。

02大數(shù)據(jù)建設背景

我們公司的大數(shù)據(jù)部門去年才成立，之前整個公司數(shù)據(jù)底層建設比較匱乏，所有數(shù)據(jù)都是通過業(yè)務研發(fā)團隊去支撐，業(yè)務研發(fā)除了很多自己的產品功能迭代以外，還要排期去做數(shù)據(jù)支持。整體體驗較差，一個業(yè)務上線需要一到兩個月。這可能是所有ToB公司必經(jīng)的一個階段，ToB公司一開始的數(shù)據(jù)量可能不是特別大，不像ToC公司一開始就有自己的大數(shù)據(jù)團隊，隨著ToB公司的發(fā)展，數(shù)據(jù)量變大后，對大數(shù)據(jù)團隊建設的需求是非常迫切的。

這是我們去年業(yè)務部門的需求，可以看到整個團隊在底層數(shù)據(jù)方面的需求處于井噴的狀態(tài)，未來可能有更多更細的需求。

對于一個ToB公司來說，基本上可以把客戶旅程分為六個階段：認知、教育、選擇、支付、使用、增購。這是我們基于硅谷藍圖的SaaS獲客模型優(yōu)化后的劃分，對整個國內ToB行業(yè)也有參考意義。

認知：當我們想談一個客戶，首先要讓客戶了解分貝通。我們通過廣告或者電銷團隊去做一個初步的接觸，這個叫做認知。

教育：當有一定需求，客戶想起分貝通這個公司，會聯(lián)系你做深度的交流和拜訪，這時是深度教育的階段，讓客戶了解我們能夠解決他的什么問題。

選擇：通過多家的對比選擇了分貝通。

使用：交付使用。

增購：發(fā)現(xiàn)有一些其他功能還不錯增加購買，或者到了使用年限后繼續(xù)購買。

分貝通整體可以歸為三類部門，第一是業(yè)務部門，包括銷售、渠道、市場、客戶成功等；第二是運產部門，即運營+產品的業(yè)務研發(fā)部門，包括商城、商旅、費控、支付；第三是職能部門，包括產研、人力、財務。這三大部門對數(shù)據(jù)的需求不太一樣，對各個階段的需求也會有區(qū)別。

業(yè)務部門對數(shù)據(jù)的需求非常強烈。在建立大數(shù)據(jù)團隊之前，銷售去挖目標線索的時候是非常散沒有體系的，大數(shù)據(jù)能夠提供市場上潛在客戶的信息，并刻畫出哪些客戶的購買意愿更高，這樣就能更好的進行營銷。另一個場景是客戶簽約，客戶購買了很多應用場景的模塊，有些模塊用得很好，有些模塊用得很差，客戶成功團隊希望知道哪些應用場景重點在用，哪些開通了也不用，還有哪些用戶在流失等，這些都是對數(shù)據(jù)的需求。

運產部門對數(shù)據(jù)的核心要求在整個業(yè)務過程中存在卡點，希望我們通過數(shù)據(jù)去告訴它。

對于職能部門，產研關心的是產品上線后是否有人在用，用的怎樣，是否能做ABtest。人力關心的是現(xiàn)在的員工關注的點是哪些，是薪酬還是福利。財務關注的是現(xiàn)在的財務報表，數(shù)據(jù)的準確性如何，跟流水是否對得上，需要很明確的被告知，以上這些都是公司對數(shù)據(jù)的需求，各種各樣且非常強烈。

基于以上業(yè)務背景，我們需要選擇合適的技術來滿足業(yè)務的需求，從業(yè)務和技術兩個角度來考慮。首先，從業(yè)務方面考慮，當時團隊剛剛組建，人手比較匱乏，創(chuàng)業(yè)公司對人才的吸引力有限，因此我們的架構的應用成本要特別低，功能盡量簡單，這樣才能更多地進行業(yè)務思考和數(shù)據(jù)賦能。同時，由于業(yè)務已經(jīng)發(fā)展到一定階段了，對數(shù)據(jù)的需求已經(jīng)比較迫切了，因此我們要快速的拿到結果。另外，從技術上考慮，原有技術數(shù)據(jù)已經(jīng)上云，因此我們必須選擇云端的解決方案，這樣有利于數(shù)據(jù)的傳輸。同時，我們有很多的數(shù)據(jù)來源表，但是數(shù)據(jù)量還比較小，數(shù)據(jù)量在TB規(guī)模，對實時的要求沒有那么高。

在不考慮自建IDC的前提下，當時擺在我們面前有三個選擇：

第一個是比較成熟的云端的組建，阿里的MaxCompute+Hologres+實時計算Flink版+大數(shù)據(jù)開發(fā)治理平臺DataWork，第二個是云上開源的組建EMR，第三個是什么都不用，在云上自建Hadoop集群。這三個方案各有優(yōu)缺點，第一個方案的好處是應用成本嫁接給阿里云，但應用成本較高。第二個方案是比較折中的方案，有一定的靈活性，但是在運維上也需要一定的專業(yè)性。第三個方案需要招聘非常專業(yè)的應用團隊來組建自己的Hadoop集群，這在當時來看不太可行。

最后綜合來看，我們選擇了方案一。

03大數(shù)據(jù)建設方案

技術架構選型結束后，我們開始從內部梳理大數(shù)據(jù)建設的整體體系，逐步進行大數(shù)據(jù)建設。與大多數(shù)大數(shù)據(jù)體系架構類似，底層是多源數(shù)據(jù)連接，往上做數(shù)據(jù)清洗，再往上進行離線和實時的數(shù)據(jù)存儲與計算，到數(shù)據(jù)倉庫的建設，再到上面的應用層的建設，左邊是組織流程規(guī)范的一些保障。

其中一些實踐方面的細節(jié)和總結值得分享。比如數(shù)據(jù)分析，對于ToB的公司來說是很大的一個模塊，這里的數(shù)據(jù)分析是指對外的數(shù)據(jù)分析，希望對現(xiàn)有的數(shù)據(jù)進行深入的分析。在組織架構上我們將數(shù)倉和數(shù)據(jù)分析分成兩個團隊，數(shù)倉團隊負責整個ODS和DWD層的建設，數(shù)據(jù)分析團隊負責上層的DWS層和ADS層的建設，這是橫向的切分。這樣做的好處是，數(shù)倉團隊可以更好地關注底層數(shù)據(jù)的質量，需要更多地跟研發(fā)打交道，數(shù)據(jù)分析團隊只需要對數(shù)據(jù)分析負責，而數(shù)據(jù)分析師可以更加關注整個數(shù)據(jù)的應用和業(yè)務的應用。這兩個團隊有著完全不一樣的技能，而且可以互相監(jiān)督。除此之外，實時和離線不分開的好處是對于大家的技術發(fā)展而言，技術棧比較完整。

在流程和規(guī)范方面，我們當時面臨的挑戰(zhàn)是內部的業(yè)務線特別多，有十幾個業(yè)務線，不僅多，并且復雜，比如用車業(yè)務線，與滴滴的業(yè)務線相似。每個業(yè)務線的表很多，每個業(yè)務之間又是獨立開發(fā)的，規(guī)范需要統(tǒng)一，數(shù)據(jù)質量也有很大差異，是非常棘手的問題。但是同時我們也有先發(fā)優(yōu)勢——從零開始建設，所以我們當時確定一個原則，一定要邊建設邊治理而不是先建設后治理。我們摸索出了一套從業(yè)務需求到開發(fā)到上線的標準的動作，也就是所謂的SOP。比如將每周二、每周四作為固定的評審時間，評審的內容都是按照自己的內容自己的模板準備好，每次評審都有記錄，上線的時候根據(jù)評審記錄來看它是否完成是否需要修改，保證流程規(guī)范治理好。

一件事情做到60分很簡單，比如數(shù)倉的建立比較簡單，但是要做到極致，真正做出一個90分的好數(shù)倉其實是一件很難的事情。

有了對于大數(shù)據(jù)整體體系的流程與思路以后，落地就需要工具的支持，下面介紹一下數(shù)據(jù)建模的工具。

現(xiàn)在我們用的是阿里云的DataWorks智能數(shù)據(jù)建模，我們去年底參加了他們的公測，今年開始正式使用。DataWorks智能數(shù)據(jù)建模最大的好處是，我們會把整個數(shù)倉的規(guī)劃和最終模型的產出做一個強關聯(lián)，模型可以直接生成物理表，發(fā)布成功后也可以直接生成簡單的ETL代碼。之前我們在應用開發(fā)環(huán)境之前用SQL去建模，結果大家之間的標準不統(tǒng)一，就是一個人治的過程。有了DataWorks以后我們就變成了法治，通過工具實現(xiàn)了對整個數(shù)據(jù)的強治理，與原來相比，我們建模的便利性可能會差一些，比如想建一個數(shù)據(jù)匯總表，首先要建一個原始指標才能建立派生指標，然后搭建表模型，再關聯(lián)數(shù)據(jù)標準，這個流程相對而言會變長，剛開始的時候大家會不太習慣。雖然單個點的流程變長，但是整體效率提升了，數(shù)倉團隊都非常接受這種規(guī)范。對數(shù)據(jù)倉庫的長期建設而言，一些標準與規(guī)范的事前投入是非常有必要的，往往可以起到事半功倍的效果。

上圖是數(shù)倉整體架構。

在技術架構方面，現(xiàn)在仍然是非常典型的一個lambda架構，離線與實時是分開的，結果在Hologres做了一層匯聚，有用到一些輔助的數(shù)據(jù)庫如MySQL和ES來存儲業(yè)務和標簽的數(shù)據(jù)。這里有一些基于我們業(yè)務場景的使用建議，數(shù)據(jù)應用鏈Hologres與MaxCompute有離線實時一體化的能力，Hologres存在兩種表存儲的方法，一個是數(shù)據(jù)不導出，直接加載MaxCompute表作為外表，一個是數(shù)據(jù)導入Hologres成為內表。我們BI報表的業(yè)務場景是對外的，對我們來說是非常重要的，數(shù)據(jù)的穩(wěn)定性是需要首要保證的，所以我們更多地采用Hologres內表方式去訪問ODS的數(shù)據(jù)而不是外表方式，這樣做的好處是一旦不小心將表的結果變更，如果是外表，BI工具只有在客戶訪問的時候才暴露出這種問題，但是采用內表的方式在推數(shù)的時候就會發(fā)現(xiàn)問題，就可以避免線下穩(wěn)定性的問題。另外，我們每天都需要數(shù)據(jù)更新，我們不是每天都更新整個Hologres里面的表數(shù)據(jù)，因為這樣效率會比較低，可能引起服務中斷。我們的方案是建立一個臨時的外表，生成臨時的內表去替代線上表，這樣速度是非常快的，因為整個Hologres做了線路的優(yōu)化，效率非常高，直接去替代線上表，這樣對線上幾乎沒有影響。

再來介紹一下算法方面的經(jīng)驗。

先說一下Batch Mode的離線模型，我們目前使用的是阿里云的機器學習PAI來滿足日常的建模場景，這個圖是非常典型的數(shù)據(jù)流過程。首先樣本經(jīng)過實景化到ODS上面，在MaxCompute上進行清洗和加工，最后也會實景化到一些表，在模型訓練階段去開發(fā)、訓練整個模型，訓練完后有兩種選擇，一是不需要線上部署，只需要做一些離線的大表預測，可以通過Designer去做一些數(shù)據(jù)的部署數(shù)據(jù)湖到整個ODS的table里。第二是如果想做模型的線上服務，同樣可以把模型輸入到OSS層上面，通過EAS組件進行服務，這個是我們現(xiàn)在用的比較多的離線模型的數(shù)據(jù)流程。

接下來是實時模型的流程，比如推薦等模型場景，對模型的實時性要求比較高。有一些比較通用的組件，比如Flink、kafka等進行數(shù)據(jù)的處理、特征的處理。模型的訓練階段先做一個模型的轉化，離線的模型轉化成實時的模型，然后進行訓練評估，最后掛到線上去訓練和替換，這里跟剛才的離線是不太一樣的。

04大數(shù)據(jù)應用場景

隨著大數(shù)據(jù)平臺的搭建，大數(shù)據(jù)在整個公司中逐漸開始驅動業(yè)務創(chuàng)新，這里選取了兩個特別好的數(shù)據(jù)創(chuàng)新的例子。

第一個是很多人了解的CDP（customer data platform，中文稱客戶數(shù)據(jù)平臺），這個平臺的重要性體現(xiàn)在它是整個公司的大腦，有了它以后可以指導很多業(yè)務的活動和創(chuàng)新。

在分貝通我們有一些公開的公域數(shù)據(jù)，以及一些私域的線上和線下處理的數(shù)據(jù)，通常這些數(shù)據(jù)會以數(shù)據(jù)孤島的形式存在，格式完全不一樣，使用起來非常不方便，我們每次統(tǒng)計市場部一次活動的效果都非常麻煩，因為會在不同的渠道投放，最后要求指標的匯總。

第一步就是要把所有數(shù)據(jù)放在數(shù)倉里做清洗與構建，去構建我們的CDP，從這個邏輯上我們把它分為了四個層次。統(tǒng)一ID的建設非常關鍵，一旦ID合并錯了那上面所有的信息基本上都是錯誤的。

有了統(tǒng)一的ID后（有統(tǒng)一的客戶標識ToB、統(tǒng)一的用戶標識ToC），就可以得到客戶的基本信息，我們可以把客戶的相關信息都匯總在一起。客戶信息可以分為三類，第一類是靜態(tài)信息，比如客戶名稱、所屬的行業(yè)類型、性別等；第二類是半動態(tài)信息，比如企業(yè)融資的狀態(tài)，相對來說變化沒那么快，或者用戶的喜好等；第三類是用戶的行為信息，比如用戶的瀏覽等。

信息層上面為標簽層，標簽層可以分為三類：基礎、規(guī)則、挖掘。基礎標簽比較簡單，不需要過多的邏輯就可以得到，比如用戶的性別。規(guī)則標簽需要一些統(tǒng)計規(guī)則去匯總出來，比如該用戶是否富有。挖掘標簽則需要一些算法，包括深度學習的算法去挖掘出來，最后根據(jù)標簽產生簇群，再對簇群做一些運算和分析。

CDP是一個偏數(shù)據(jù)中臺的平臺，與業(yè)務松耦合。有了CDP，下游就是連接的各種業(yè)務平臺，可以是智能化、精細化的營銷或運營的平臺，我們可以根據(jù)運營做廣告的投放、互動、內容推薦等，可以很方便調用個體信息，再做個性化的工作，因此CDP是非常重要的。

第二個場景是我們在做的CEM，客戶體驗管理，內部叫VOC（voice of customer）。CEM分為三個階段，首先是收集客戶的反饋，反饋渠道很多，包括客戶的投訴、工單、CRM、CSM、交付群等，所有用戶的數(shù)據(jù)都可以收集起來，與以前不一樣的是很多非結構化的數(shù)據(jù)，包括語音文本，需要去做處理。第二階段，有了這些數(shù)據(jù)之后，我們需要通過一些AI的手段，包括ASR、NLP等，對這些數(shù)據(jù)做分析，來判斷公司的產品服務的哪些環(huán)節(jié)存在問題，問題的嚴重程度如何。第三階段是有了量化的標準后我們會對每個環(huán)節(jié)進行評分，來衡量各部門各環(huán)節(jié)的表現(xiàn)，有了這些評分后我們可以為一線產品經(jīng)理、客服人員、運營等提供自動化的分析工具、CTA等。

這與我們之前做產品很不一樣，之前做產品的設計產品經(jīng)理去抽樣、調研客戶的需求，很主觀認為這些需求就是所有客戶的需求，這是很典型的小數(shù)據(jù)時代的思維，以樣本來代替全量的思維，CEM是典型的大數(shù)據(jù)時代的思維，跟大家比較熟悉的數(shù)據(jù)埋點一樣，我們不需要知道他們的爽點在哪、痛點在哪，他們在埋點里面可能會告訴我們一些答案。CEM跟埋點不一樣的地方在于搜集的范圍更加廣泛，埋點思維是一些結構化的數(shù)據(jù)，CEM包括非結構化的語言、文本，對技術的要求越來越高，它是AI時代的產品。目前分貝通按照這個流程去落地，但是需要人工投入的地方還有很多，我們希望有更多AI的手段去支持整個CEM的過程。

分貝通是典型的ToB企業(yè)。ToB和ToC企業(yè)存在一些差異，可以從三個方面來了解。首先是用戶群體，對于ToB來說，購買決策和使用性都是不一樣的，買一個軟件可能是財務的決策、KP的決策，但是員工在用。ToB企業(yè)的用戶粘性更高，一般按年簽約，公司已購買員工必須使用，同時對用戶有很強的專業(yè)性要求，針對不同的企業(yè)、角色，整個系統(tǒng)的設計是完全不同的，甚至相同行業(yè)相同崗位的需求也是完全不同的。ToC的采購決策者是個人，用戶不滿意可以放棄使用，粘性相對較低，用戶群體相對公眾化，用戶對軟件的需求有非常多的共性。

在應用場景方面，ToB的場景非常豐富，我們做的只能解決客戶在生產過程當中某一個環(huán)節(jié)的問題，無法覆蓋它所有方面的問題，因為專業(yè)性太強，一個問題的處理流程往往會很長，ToB在國內還沒有千億美金的互聯(lián)網(wǎng)公司。ToC比較簡單，滿足大家日常生活中的需求，例如吃、穿、住、行、玩，很容易在這一領域誕生千億美金的獨角獸互聯(lián)網(wǎng)公司，這決定了這兩個企業(yè)的企業(yè)規(guī)模。

在業(yè)務流程方面， ToB領域業(yè)務流程都很長，通常申請審批交易結算等，一次交易涉及到很多環(huán)節(jié)，但是ToC相對簡單，例如網(wǎng)購下單僅需幾秒鐘，非常簡單。

以上就是ToB和ToC企業(yè)的區(qū)別，也就決定了以下的技術特點：

ToB的數(shù)據(jù)量相對較小，在做數(shù)字化轉型的時候，包括我們自己，數(shù)據(jù)量還是TB級別，處于中小規(guī)模，但是業(yè)務相對復雜，對數(shù)倉的建模能力要求較高，需要了解業(yè)務后才能更好地去建模。整個作業(yè)的處理時間會比較短，我們現(xiàn)在的作業(yè)基本在分鐘級別，因此我們的容錯恢復很快，對于技術框架的選型要求會低一些，選錯了后面還有翻盤的機會。但對于ToC來說，基礎架構完全不一樣，一旦選錯了或版本需要升級，代價會非常高昂，這是在做數(shù)倉這兩種模型的區(qū)別。

未來展望可以分為兩個方面，一個是業(yè)務方面，希望可以識別公司更多的數(shù)字化轉型場景，我們希望通過產品化和平臺化更好地幫助公司去做業(yè)務化、智能化的事情；同時推進業(yè)務的BP機制，推動業(yè)務的緊密合作，數(shù)據(jù)中臺也要深入到業(yè)務中去，去了解業(yè)務內在的東西而不是等著業(yè)務提需求。現(xiàn)在更多的是報表類的支撐，希望未來發(fā)展為報告、智能化產品的支撐。雖然分貝通是企業(yè)支付的場景，但更多的是差旅方面，差旅是很復雜的過程，比如說出一次差，要做很多的決策，我們希望探索更加智能的用戶體驗，降低決策成本。

在技術層面，隨著技術和數(shù)據(jù)的不斷積累，對實時的數(shù)據(jù)要求越來越高，我們在實時與HTAP這塊，會做一些深度的探索。現(xiàn)在的業(yè)務比較流行湖倉一體化，之前沒有這種需求，現(xiàn)在我們需要管理語音、文本等大量數(shù)據(jù)，需要去解決非結構化數(shù)據(jù)儲存和管理。第三是批流一體化，我們使用的是lambda架構，應用比較精簡但是存在開發(fā)和運維上成本的重復，我們希望在這些方面繼續(xù)探索來統(tǒng)一整個數(shù)倉，真正實現(xiàn)存儲和數(shù)倉統(tǒng)一的架構，減少額外的成本，這將是我們未來探索的幾個方向。