777米奇色狠狠888俺也去,激情亚洲一区国产精品

這是彭文華的第117篇原創(chuàng)

上周在PMTalk分享了如何建設(shè)一個好的數(shù)據(jù)中臺產(chǎn)品，今天把現(xiàn)場實(shí)錄給大家，文末有ppt下載方式。

今天分享的內(nèi)容就是這樣一個節(jié)奏，先拋出一個問題，然后再看幾個例子，最后總結(jié)一下。

一個好的產(chǎn)品是能系統(tǒng)性的解決問題的，能給整個鏈條帶來超量增值。所以應(yīng)該是一個完整的解決方案，能連接所有利益相關(guān)方，共同參與進(jìn)來，讓各方都收益。比如說集裝箱。在集裝箱出來之前，貨物都是混裝的，裝的少不說，還得倒騰。所以碼頭通常會聚集大量的搬運(yùn)工。

集裝箱出來之后，一個集裝箱內(nèi)裝一種貨物，一艘船可以隨便裝。而且集裝箱非常標(biāo)準(zhǔn)化，可以隨便裝。

除了集裝箱，罐頭也是一樣。美軍稱霸全球，罐頭功不可沒。

總結(jié)一下：一個好的產(chǎn)品應(yīng)該具有的兩個品質(zhì)：1、屏蔽復(fù)雜業(yè)務(wù)邏輯；2、提供簡單有價值的服務(wù)。

所以數(shù)據(jù)中臺當(dāng)然是一種好的產(chǎn)品。他能屏蔽復(fù)雜的取數(shù)邏輯，降低數(shù)據(jù)的使用成本，然后提供托拉拽、接口、高價值的簡單可行的數(shù)據(jù)應(yīng)用。

阿里數(shù)據(jù)中臺建設(shè)邏輯

那一個好的數(shù)據(jù)中臺產(chǎn)品應(yīng)該怎么打造出來？我選取了阿里、宜信和貝殼三種模式給大家分享一下。

首先我們看看阿里數(shù)據(jù)中臺。

這個是阿里數(shù)據(jù)中臺產(chǎn)品的全景圖，包括Data Phin、Quick Bi、Quick Stock、Quick A+、Quick Audience、Quick Decision等組件。

Data Phin搞定底層數(shù)據(jù)，Quick Bi搞定圖表可視化，Quick A+搞定用戶行為分析，Quick Stock搞定人貨場運(yùn)營，Quick Audience搞定用戶運(yùn)營，Quick Decision提供全面精細(xì)化運(yùn)營和決策。

如圖所示，Data Phin解決的就是底層數(shù)據(jù)的處理。

實(shí)時和離線兩條通道，將不同數(shù)據(jù)源的數(shù)據(jù)采集過來，然后分層建設(shè)數(shù)據(jù)倉庫，然后再進(jìn)行數(shù)據(jù)管理，對前端提供相關(guān)服務(wù)。

其實(shí)就是絕大多數(shù)大數(shù)據(jù)平臺的功能。只不過阿**據(jù)自己的經(jīng)驗(yàn)進(jìn)行了優(yōu)化而已。類似的產(chǎn)品很多，星環(huán)、華為、新華三等等，小廠就更多了。

這里除了產(chǎn)品，還需要用到阿里數(shù)據(jù)中臺的One ID、One Model、One Service的3One方法論。最終實(shí)現(xiàn)One Data的目標(biāo)。

這是Quick Bi的功能，很清晰，跟其他的BI產(chǎn)品沒啥太大的區(qū)別。

Quick搭建在Data Phin之上，直接讀取Data Phin處理好的數(shù)據(jù)，直接做展現(xiàn)和分發(fā)就行了。對標(biāo)的產(chǎn)品就是各種BI產(chǎn)品，PowerBI、FineBI、SmartBi等等。

這是Quick A+解決的是日志埋點(diǎn)、采集、流量指標(biāo)分析的需求。對標(biāo)的就是各種日志分析起家的產(chǎn)品，神策、GIO、諸葛IO等等。

Data Phin還很技術(shù)，Quick BI和Quick A+也是大數(shù)據(jù)平臺范圍內(nèi)必備的項(xiàng)目，Quick Stock就開始偏業(yè)務(wù)了。這張圖上基本看不到技術(shù)的影子，全部都是在解決業(yè)務(wù)問題。這就偏流通環(huán)節(jié)的解決方案了。

這是Quick Audience，其實(shí)就是阿里數(shù)據(jù)中臺的用戶中心，大廠的標(biāo)配。也是阿里One ID最廣為人知的應(yīng)用案例。

這是Quick Decision，就是各種策略運(yùn)營手段的數(shù)據(jù)服務(wù)化。這是各大廠的運(yùn)營策略的實(shí)驗(yàn)平臺。

這些產(chǎn)品當(dāng)然不是一下就做起來的。我?guī)痛蠹覙?biāo)注了一下各自的發(fā)布時間。Data phin 最底層，是2017年做的。光有個底層數(shù)據(jù)平臺沒法體現(xiàn)任何價值。所以還得有一個數(shù)據(jù)可視化和分析系統(tǒng)，于是同年推出了Quick BI。后來再逐步推出用戶行為分析和用戶運(yùn)營平臺，畢竟用戶是最重要的。

最后推出的是人貨場運(yùn)營平臺和策略運(yùn)營中心。這就精準(zhǔn)命中使用場景了。

所以從阿里的玩法，我們可以總結(jié)出這幾點(diǎn)：

全面規(guī)劃，平臺級建設(shè)。

自下而上，先技術(shù)后應(yīng)用，最后解決方案。

這明顯是產(chǎn)品主導(dǎo)的邏輯，我們產(chǎn)品人最喜歡這么建設(shè)，但是這種機(jī)會可遇不可求。阿里能這么做，是因?yàn)榍懊婊?0年時間摸索，最近才產(chǎn)品化。

宜信數(shù)據(jù)中臺建設(shè)邏輯

我們現(xiàn)在再看看宜信數(shù)據(jù)中臺的建設(shè)邏輯。

我跟宜信盧山巍盧總請教過，他在19年也分享過“宜信敏捷數(shù)據(jù)中臺建設(shè)實(shí)踐分享實(shí)錄”，感觸很多。給大家選幾頁觀察一下宜信是怎么做的。

這是宜信的中臺定位。宜信的組織架構(gòu)有很像阿里，一個數(shù)據(jù)中臺團(tuán)隊(duì)+N個業(yè)務(wù)數(shù)據(jù)團(tuán)隊(duì)。外掛數(shù)據(jù)管理、安全、運(yùn)維團(tuán)隊(duì)予以保障。宜信的業(yè)務(wù)線非常多，這種組織結(jié)構(gòu)是必然的產(chǎn)物，因此數(shù)據(jù)中臺也只能平臺化。

這是ADX（敏捷數(shù)據(jù)中臺縮寫）的菜單，從這這里可以看到它的主要功能，非常全面。

從這張圖可以看到各個環(huán)節(jié)所使用的技術(shù)。其中采集、流處理、展示（藍(lán)色部分）都是自研的。存儲形式很豐富：”結(jié)構(gòu)化、kudu、Hbase、cass、hdfs、hive、ck、druid、kylin、es、mongodb，后面還加了一個…，基本上當(dāng)時主流的數(shù)據(jù)存儲方案都用到了。

圖中藍(lán)色的都是自研的。他當(dāng)時的情況比較尷尬，處在底層數(shù)據(jù)和業(yè)務(wù)之間，逼得他只能進(jìn)行平臺級的開發(fā)。他把數(shù)據(jù)流向圖梳理了一下，發(fā)現(xiàn)也只有這幾個地方有機(jī)會。數(shù)據(jù)源那邊沒辦法，總不能自己做一個數(shù)據(jù)庫吧。MQ這邊有Kafka、RocketMQ，已經(jīng)足夠好了。存儲這邊也非常全，那就只有數(shù)據(jù)集成、數(shù)據(jù)加工、數(shù)據(jù)計(jì)算和展示這幾個環(huán)節(jié)了。于是他們就把這幾個地方分別自研了一個工具，并且開源出來。

這個是數(shù)據(jù)中臺的核心Wormhold（流處理平臺）架構(gòu)，從kafka獲取數(shù)據(jù)，經(jīng)過spark和flink的計(jì)算，sink到N種庫中。然后一堆的管理、安全、運(yùn)維保障組件?？梢酝ㄟ^api和web進(jìn)行訪問平臺。

盧總對敏捷數(shù)據(jù)中臺定位很準(zhǔn)，就是快、精、準(zhǔn)。

盧總是平臺層技術(shù)，這些建設(shè)全部都是他們自己主導(dǎo)的，對于業(yè)務(wù)線來說，貌似感官不太大。所以總結(jié)一下他的建設(shè)邏輯：

圍繞數(shù)據(jù)流向，集成優(yōu)秀產(chǎn)品，抽象公共需求，自研平臺化產(chǎn)品。

盧總透露，其實(shí)這么做也是無奈之舉。他也想做一些更有價值的事情，比如商業(yè)化的內(nèi)容，但是組織架構(gòu)在這里擺著，手伸不過去啊。這也是技術(shù)主導(dǎo)的煩惱。

貝殼數(shù)據(jù)中臺建設(shè)邏輯

我們轉(zhuǎn)過頭看看貝殼哈。

這是我之前整理的貝殼6層堡壘。貝殼從鏈家繼承了太多資產(chǎn)了。其中樓盤字典從08年就開始建設(shè)了。是一個單獨(dú)的團(tuán)隊(duì)在做，網(wǎng)傳最多的時候有500多號人。貝殼融合其他品牌的時候，都會不斷擴(kuò)充這個樓盤字典。

這個樓盤字典還從技術(shù)層保障了住建部嚴(yán)禁“虛假房源”的要求。

而基于信任和合作的ACN，則從人性和規(guī)則層保障了房源的真實(shí)性。

我們從四因說的角度上來看，樓盤字典就是一個技術(shù)含量算高，同時非常費(fèi)時費(fèi)力，但是建好之后可以成為公司超級護(hù)城河的核心資產(chǎn)。這與阿里的One ID的思路是一致的。

從貝殼的大數(shù)據(jù)平臺的三個階段可以看出他們的建設(shè)邏輯：夠用，然后優(yōu)化。貝殼大數(shù)據(jù)平臺到現(xiàn)在都是Lambda的架構(gòu)，沒有上批流一體。原則都是為業(yè)務(wù)服務(wù)，技術(shù)夠用就行。

OLAP平臺也是這樣，先夠用。然后不斷發(fā)展。貝殼是kylin的深度用戶，給kylin做了很多貢獻(xiàn)。注意我這里圈出來的地方。他們在前臺的指標(biāo)API和Kylin之間，加了一層查詢接口層，對查詢進(jìn)行轉(zhuǎn)換，在架構(gòu)層面做了服務(wù)降級、熔斷等保障性的服務(wù)管理。

有了這個查詢接口層，等于有了一個萬能轉(zhuǎn)換器，底層的OLAP引擎就可以隨便換了。所有現(xiàn)在的架構(gòu)就可以支持druid、ck、doris等產(chǎn)品。

肖博士在分享的時候也曾透露參考了阿里的One Data邏輯。但是在貝殼這邊不太好弄。貝殼的業(yè)務(wù)太復(fù)雜了，很多地方?jīng)]法進(jìn)行統(tǒng)一業(yè)務(wù)建模。所以O(shè)ne Model建的不夠好。不過這也與貝殼的組織架構(gòu)有關(guān)系。每個平臺一個團(tuán)隊(duì)，必然導(dǎo)致團(tuán)隊(duì)內(nèi)外部的構(gòu)成成本高企。其實(shí)很多問題都是因?yàn)榻M織、業(yè)務(wù)形態(tài)導(dǎo)致的。

這是DMP架構(gòu)。是為精準(zhǔn)營銷、人群分析、個性化推薦等服務(wù)提供基礎(chǔ)數(shù)據(jù)。

DMP建設(shè)的時候使用的就是ID Mapping的思路，使用Spark + graph X進(jìn)行 id之間的圖計(jì)算，識別相同的用戶。

為了提升圈人的效率，DMP大量使用位圖技術(shù)，億級別用戶的圈人可以秒出。

這是貝殼推薦平臺，一樣是價值優(yōu)先，兩個場景，一個是用戶購房推薦，一個是經(jīng)紀(jì)人維護(hù)營銷。

也是快速搭建、慢慢發(fā)展的邏輯建設(shè)的。

這是最新的推薦平臺架構(gòu)圖，已經(jīng)是3.0版本了。之前還有兩版，最早那版很粗糙的。

這個是算法中臺。為商業(yè)化服務(wù)。你看他的業(yè)務(wù)場景很有意思，是給經(jīng)紀(jì)人用的。按照我們業(yè)外人士的理解，貝殼是一個賣房的平臺，真正的用戶不是購房者嗎？這就是貝殼的業(yè)務(wù)理解。也是我認(rèn)為貝殼中臺的成功之處：所有的技術(shù)都是為了業(yè)務(wù)核心價值服務(wù)。

金貝平臺是給經(jīng)紀(jì)人用來獲得客源的平臺。經(jīng)紀(jì)人通過做各種任務(wù)獲得貝幣，通過消耗貝幣，獲得曝光和IM潛客溝通。這就形成了一個內(nèi)部的經(jīng)濟(jì)循環(huán)。用金貝為抓手，驅(qū)動經(jīng)紀(jì)人完成眾包任務(wù)，同時給予潛客獎勵。

貝殼的商業(yè)化是在經(jīng)紀(jì)人身上上的，而不是真正的用戶身上。這對我這個業(yè)外人士來說，是很驚訝的。這個洞察很值錢，把算法資源投入到這里更值錢。

貝殼現(xiàn)在也在繼續(xù)優(yōu)化。Python實(shí)在是不太夠用，數(shù)據(jù)量一大，速度就沒法保障了。所以現(xiàn)在基本都在往java方向轉(zhuǎn)了。

貝殼的建設(shè)邏輯其實(shí)也很簡單，跟著業(yè)務(wù)走。左暉總的業(yè)務(wù)理解太深了，對人性理解的太透了。產(chǎn)品和技術(shù)完全為業(yè)務(wù)服務(wù)，構(gòu)建了一個又一個的護(hù)城河。

OK，大家可以看出，貝殼完全是業(yè)務(wù)主導(dǎo)。我們絕大多數(shù)企業(yè)都是這種建設(shè)邏輯。這種邏輯下，技術(shù)和產(chǎn)品每天都是雞飛狗跳，日夜加班。

但是好處是很明顯的，能夠抓住核心商業(yè)價值，小步快跑，快速迭代。

三種模式的對比

產(chǎn)品主導(dǎo)呢，基本上都是有中臺團(tuán)隊(duì)的。在一開始都是有頂層規(guī)劃的，商業(yè)價值不用說，是能掙錢的。但是難度是相當(dāng)?shù)拇?，需要前期投入太多?，F(xiàn)在市面上數(shù)據(jù)中臺產(chǎn)品基本上都是從阿里出來的。

技術(shù)主導(dǎo)基本都是獨(dú)立平臺部門，在平臺層進(jìn)行規(guī)劃和建設(shè)，一般來說不太會直接解決業(yè)務(wù)問題，因此商業(yè)價值較低，也比較難以量化。

業(yè)務(wù)主導(dǎo)一般都是要啥平臺就建一個小部門開干，直接解決業(yè)務(wù)需求，商業(yè)價值也很高，但問題在于缺乏總體規(guī)劃，通常是做著做著，平臺就不行了，要推到重來。

打造一個完美的產(chǎn)品，大多數(shù)產(chǎn)品人或許會認(rèn)為產(chǎn)品主導(dǎo)肯定是最好的。其實(shí)不然。

這里分享一個迪斯尼設(shè)計(jì)小路的故事。迪斯尼樂園中各個經(jīng)典相距較遠(yuǎn)，設(shè)計(jì)師羅培斯想了很久都沒有好的方案。于是他就出了一個絕招，在空地上撒草籽，變成草坪，路人自行踐踏形成小路。最后這個設(shè)計(jì)獲得了大獎。

迪斯尼的案例與貝殼的發(fā)展路線異曲同工，需要大數(shù)據(jù)平臺了，就先成立一個小組弄一個湊合用著，然后慢慢進(jìn)化。需要OLAP分析了，就成立一個小組快速搭一個用著，日拱一卒。需要樓盤主數(shù)據(jù)了，成立一個團(tuán)隊(duì)，死磕，一條一條數(shù)據(jù)清洗。

這跟產(chǎn)品的MVP邏輯是一致的。

所以大家有沒有發(fā)現(xiàn)這三種模式都遵循一個什么規(guī)律？

人月神話中有提到一個“康威定律”，用人話說也就是說組織形態(tài)決定了產(chǎn)品形態(tài)。產(chǎn)品主導(dǎo)就是上帝視角進(jìn)行建設(shè)，技術(shù)主導(dǎo)是在業(yè)務(wù)邏輯基礎(chǔ)上，因勢導(dǎo)利，建設(shè)平臺，業(yè)務(wù)主導(dǎo)最野蠻，河流往哪走，地形就得跟著變。

所以如果咱的公司是產(chǎn)品主導(dǎo)，那就直接抄阿里的作業(yè)。

如果是技術(shù)主導(dǎo)，那就幫技術(shù)好好策劃一下平臺產(chǎn)品。

如果咱是業(yè)務(wù)主導(dǎo)，那咱就加班硬抗吧，這個沒辦法。

以史為鏡-數(shù)倉發(fā)展歷史啟示

最后呢，再花幾分鐘給大家過一下數(shù)據(jù)倉庫的發(fā)展歷史，希望給大家?guī)硪恍﹩l(fā)。

其實(shí)數(shù)據(jù)中臺和數(shù)據(jù)倉庫非常像的。Inmon最早提出了數(shù)倉的概念，并且提出了完整的建設(shè)方案。方案是從數(shù)據(jù)上游向數(shù)據(jù)下游的方向全面建設(shè)，這很像產(chǎn)品主導(dǎo)的模式。但是這種模式遭遇到了前所未有的大敗局：幾乎所有的數(shù)倉項(xiàng)目都失敗了。

自上而下的數(shù)倉建設(shè)模式失敗之后，kimball提出了數(shù)據(jù)集市的概念。他的理念是從數(shù)據(jù)下游向數(shù)據(jù)上游逐步設(shè)計(jì)，跟Inmon恰好相反。但是正是因?yàn)檫@樣，以終為始，縮小范圍，成功率大大增加，這跟MVP的邏輯是一致的。