//
數(shù)據(jù)倉(cāng)庫(kù)技術(shù)在大眾點(diǎn)評(píng)網(wǎng)的實(shí)踐之路和案例分享
http://www.infoq.com/cn/presentations/practice-and-case-sharing-of-data-warehouse-technology-in-dianping
//概要
隨著O2O概念在互聯(lián)網(wǎng)業(yè)務(wù)中的深度應(yīng)用，相關(guān)業(yè)務(wù)發(fā)展趨于細(xì)化、市場(chǎng)競(jìng)爭(zhēng)趨于白熱。作為在消費(fèi)領(lǐng)域同時(shí)提供信息和交易的互聯(lián)網(wǎng)公司，大眾點(diǎn)評(píng)在用戶(hù)流量和交易兩方面的業(yè)務(wù)都趨向精細(xì)化開(kāi)發(fā)和運(yùn)營(yíng)，這些都對(duì)大數(shù)據(jù)平臺(tái)提出很高的要求，具體表現(xiàn)在大數(shù)據(jù)存儲(chǔ)/計(jì)算平臺(tái)、數(shù)據(jù)倉(cāng)庫(kù)技術(shù)和數(shù)據(jù)產(chǎn)品設(shè)計(jì)上的各種Trade-off，本討論將深度分析點(diǎn)評(píng)數(shù)據(jù)平臺(tái)在以上三個(gè)方面的業(yè)務(wù)積累和各種取舍。
//
閆劍鋒, 博士，大眾點(diǎn)評(píng)網(wǎng)數(shù)據(jù)中心負(fù)責(zé)人 具有15年數(shù)據(jù)相關(guān)研究和工作經(jīng)歷，專(zhuān)業(yè)領(lǐng)域在數(shù)據(jù)平臺(tái)構(gòu)建和數(shù)據(jù)建模，互聯(lián)網(wǎng)數(shù)據(jù)產(chǎn)品設(shè)計(jì)，基于數(shù)據(jù)倉(cāng)庫(kù)和商務(wù)智能的知識(shí)發(fā)現(xiàn)，以及數(shù)據(jù)挖掘和并行/分布式數(shù)據(jù)管理系統(tǒng)開(kāi)發(fā)。 曾就職于多家IT和互聯(lián)網(wǎng)企業(yè)，參與高性能數(shù)據(jù)處理和In-Database分析的相關(guān)研發(fā)工作，并搭建典型互聯(lián)網(wǎng)公司的用戶(hù)行為數(shù)據(jù)倉(cāng)庫(kù)。 目前負(fù)責(zé)大眾點(diǎn)評(píng)網(wǎng)數(shù)據(jù)中心，負(fù)責(zé)從大數(shù)據(jù)分布式平臺(tái)到數(shù)據(jù)展示產(chǎn)品的技術(shù)研發(fā)工作，負(fù)責(zé)從基礎(chǔ)數(shù)據(jù)規(guī)范到倉(cāng)庫(kù)建模，再到公司指標(biāo)體系的構(gòu)建。
//80-90年代: 數(shù)據(jù)庫(kù)行業(yè)的四大金剛(IBM/DB2/Infosys/sybase): 管好,查好(建立索引), 事務(wù)(),
異構(gòu)數(shù)據(jù)--整合起來(lái),
//6分:21秒
90--2000年: SAP, Teredata最風(fēng)光,Oracle,
Oracle開(kāi)始向上做?(對(duì)底層的貢獻(xiàn)開(kāi)始沒(méi)那么大了)---做buiness, 對(duì)業(yè)務(wù)的回答.
OLTP技術(shù)(80-90年代的)已經(jīng)奠定了底層基礎(chǔ).
//8:17 2000-2010年:
mysql散布非常廣泛---
facebook的kernel很多都是在mysql之中.
阿里云ADS都是以mysql為基礎(chǔ)的
hadoop和cassandra都是解決底層的大數(shù)據(jù)的存儲(chǔ)/計(jì)算問(wèn)題, 歷史驚人相似.
客戶(hù)還是要回答業(yè)務(wù)問(wèn)題--sql(HiveQL/SparkSQL)也不想寫(xiě).
有些公司開(kāi)始做---數(shù)據(jù)整合, kafka/flume等等.把數(shù)據(jù)傳進(jìn)來(lái).
業(yè)務(wù)和大數(shù)據(jù)結(jié)合的公司產(chǎn)品現(xiàn)在還很少, 比如salesForce
下一個(gè)十年會(huì)是bigdata warehouse的十年
//13:20
現(xiàn)在互聯(lián)網(wǎng)創(chuàng)業(yè)最火的是o2o(演講時(shí)間為2015年),
互聯(lián)網(wǎng)是一個(gè)方法,會(huì)引領(lǐng)各個(gè)行業(yè),
京東/旅游/汽車(chē)等等都是一個(gè)線(xiàn)上和線(xiàn)下的過(guò)程.
對(duì)大數(shù)據(jù)處理就是一種比較通用的技術(shù)(就像現(xiàn)在的sql技術(shù)一樣).
缺的就是對(duì)業(yè)務(wù)的理解,
缺的就是數(shù)據(jù)倉(cāng)庫(kù)這樣一套思路和體系.
//15:40, 數(shù)據(jù)集中/一致
大眾點(diǎn)評(píng)的整個(gè)的數(shù)據(jù)會(huì)非常集中, 會(huì)在基礎(chǔ)平臺(tái)之上以數(shù)據(jù)倉(cāng)庫(kù)的概念一層一層的去建設(shè),最終釋放出來(lái)一些比較一致的數(shù)據(jù)和結(jié)果.
//16:10 互聯(lián)網(wǎng)的一些本質(zhì), 互聯(lián)網(wǎng)方法的三個(gè)特點(diǎn):
//1)水平擴(kuò)展---數(shù)據(jù)一定要規(guī)范化
(規(guī)?；?商業(yè)模式可以復(fù)制) 規(guī)模化代表太多東西,對(duì)于數(shù)據(jù)領(lǐng)域意味著--數(shù)據(jù)一定要規(guī)范化.
規(guī)范化之后,大眾點(diǎn)評(píng)網(wǎng)對(duì)于每一個(gè)商戶(hù)的日志/訪(fǎng)問(wèn)情況,都是一份code就能全部看的清清楚楚, 對(duì)于一個(gè)非常小的面館,或者大的小南國(guó)店,最終看到的東西是一樣的,可以用同一套code簡(jiǎn)單的水平擴(kuò)展出來(lái), 大眾點(diǎn)評(píng)可能有2000萬(wàn)家商戶(hù),單個(gè)去做定制會(huì)是非?？膳碌氖虑? 數(shù)據(jù)領(lǐng)域是有一個(gè)規(guī)范化的要求.
//2)用戶(hù)觸達(dá)---數(shù)據(jù)可閉環(huán)
能夠通過(guò)終端知道用戶(hù)在干什么, 對(duì)于數(shù)據(jù)領(lǐng)域的要求是: 數(shù)據(jù)可閉環(huán), 對(duì)于數(shù)據(jù)倉(cāng)庫(kù)的挑戰(zhàn)性上帶來(lái)了很多內(nèi)容,
SAP有財(cái)務(wù)系統(tǒng), CRM系統(tǒng),各種系統(tǒng),ERP,
SAP財(cái)務(wù)系統(tǒng)說(shuō)你收了多少錢(qián),花了多少錢(qián),成本/收益是多少,
在點(diǎn)評(píng)網(wǎng)如果加上用戶(hù)可觸達(dá)就復(fù)雜了很多,用戶(hù)花了一千塊錢(qián),那這個(gè)用戶(hù)的留存怎么樣?第二次來(lái)了沒(méi)有,二個(gè)月以后來(lái)了沒(méi)有,花完這筆錢(qián)就永遠(yuǎn)不來(lái)了
//3)馬太效應(yīng)---數(shù)據(jù)精細(xì)化/數(shù)據(jù)驅(qū)動(dòng)
一個(gè)行業(yè)如果做透的話(huà),只有老大沒(méi)有老二,
做互聯(lián)網(wǎng)業(yè)務(wù)是非常難的一件事,
美國(guó)十年前提過(guò)一個(gè)概念---數(shù)據(jù)驅(qū)動(dòng)
//22:10
ETL(PB,得到數(shù)據(jù),多搜集)->HQL(TB,HQL快查詢(xún),得到信息)->DM數(shù)據(jù)集市/DM->(GB, 得到知識(shí), 回答業(yè)務(wù)問(wèn)題)
去統(tǒng)計(jì)/學(xué)習(xí),看看什么原因?qū)е聵I(yè)務(wù)問(wèn)題.
從底層的數(shù)據(jù) 變成 可以理解的知識(shí)(業(yè)務(wù)/決策層可以理解的)
//23:10
自上而下,自下而上去做的兩波人.
一個(gè)人說(shuō)想看看昨天團(tuán)購(gòu)銷(xiāo)售額,往下去查,
另一個(gè)人說(shuō)他也查了,發(fā)現(xiàn)對(duì)不上,開(kāi)始找錯(cuò),不停滴找,
最后發(fā)現(xiàn)有一個(gè)去退款了,有一個(gè)沒(méi)去退款
兩撥人的方法轉(zhuǎn)換到技術(shù)上來(lái)看,需要什么?
報(bào)表分析/臨時(shí)查詢(xún),很多數(shù)據(jù)獲取的結(jié)果,從結(jié)果的角度出發(fā),把他們一路演化
目前看很多都是MapReduce的job,通過(guò)HQL的方法,通過(guò)一些編程的方法,DataMining通過(guò)Spark的MLlib等等, 一直向下--傳到下去,變成一些(底層的)技術(shù)問(wèn)題, 在這些過(guò)程之中需要一些工具---調(diào)度,對(duì)大量的任務(wù)去做調(diào)度.
//24:40
血緣,數(shù)據(jù)的血緣
//架構(gòu)
血緣也在調(diào)度之中,權(quán)限/主數(shù)據(jù)/數(shù)據(jù)質(zhì)量/數(shù)據(jù)整合等很多東西--這些都是技術(shù)上要實(shí)現(xiàn)的東西,
在目前的所有開(kāi)源基礎(chǔ)之上,怎么樣去完善這樣一個(gè)數(shù)據(jù)倉(cāng)庫(kù)體系,
//點(diǎn)評(píng)的數(shù)據(jù)平臺(tái)的發(fā)展過(guò)程.
技術(shù)部同學(xué)做了很多mysql表,實(shí)現(xiàn)他們的業(yè)務(wù),
老板或者產(chǎn)品要什么,各種臨時(shí)抓取,從mysql里抓取,只要DBA看不見(jiàn)就行,
會(huì)遇到很多很多問(wèn)題,
2012年, 存儲(chǔ)計(jì)算/通用展示平臺(tái), 開(kāi)始基于開(kāi)源產(chǎn)品之上構(gòu)建自己的存儲(chǔ)和計(jì)算體系和數(shù)據(jù)展示體系.
2013年,規(guī)范/數(shù)據(jù)倉(cāng)庫(kù),開(kāi)始定規(guī)范,(數(shù)據(jù)要規(guī)范--互聯(lián)網(wǎng)三個(gè)方法論其中之一),在規(guī)范的基礎(chǔ)之上做數(shù)據(jù)倉(cāng)庫(kù),日志的規(guī)范(每個(gè)業(yè)務(wù)都要打日志),商務(wù)的規(guī)范(預(yù)定的業(yè)務(wù)和團(tuán)購(gòu)的業(yè)務(wù)都有交易數(shù)據(jù),數(shù)據(jù)間的關(guān)聯(lián)關(guān)系是什么?)
2014年, 數(shù)據(jù)產(chǎn)品, 我們認(rèn)為差不多了,通過(guò)數(shù)據(jù)產(chǎn)品來(lái)約束和統(tǒng)一用戶(hù)對(duì)于數(shù)據(jù)的使用, 內(nèi)部會(huì)類(lèi)似于google analitick,去做整個(gè)流量的大盤(pán),做運(yùn)營(yíng)的dashboard(運(yùn)營(yíng)活動(dòng)效果好壞的dashboard),
2015年, 流式計(jì)算,實(shí)時(shí)的價(jià)值開(kāi)始越來(lái)越高, 這是平臺(tái)級(jí)
//27:40
做具體架構(gòu)之前,先看看你的用戶(hù)是哪些?
全是內(nèi)部用戶(hù),這些用戶(hù)有不同特點(diǎn),
1)有些用戶(hù),是技術(shù)部門(mén)的,拿到用戶(hù)的feture來(lái)做事,需要什么?--需要高可用HA(系統(tǒng)一定要非常穩(wěn)健),需要編程接口,需要一個(gè)service,需要一個(gè)開(kāi)發(fā)平臺(tái)來(lái)幫他做事,
2)銷(xiāo)售市場(chǎng)部門(mén)會(huì)要數(shù)據(jù)質(zhì)量, 數(shù)據(jù)質(zhì)量要求很高(指的是一致性--數(shù)據(jù)閉環(huán),一定要準(zhǔn)確),因?yàn)橐N(xiāo)售提成,達(dá)到一定數(shù)值后---向上11%提成,向下8%提成,
3)產(chǎn)品經(jīng)理,他們對(duì)數(shù)據(jù)產(chǎn)品的要求是什么?--他們是需要一些指標(biāo)/指標(biāo)體系,大的產(chǎn)品經(jīng)理看DAU/GMV,小的產(chǎn)品經(jīng)理要看很多細(xì)節(jié)的東西,他要看這個(gè)按鈕到那個(gè)按鈕的click到底是怎么樣的,他要看這個(gè)顏色換成藍(lán)色和白色之間的區(qū)別是什么--A/B test這樣的東西,很多細(xì)節(jié)的指標(biāo),
4)運(yùn)營(yíng)的人: 運(yùn)營(yíng)的人要的東西就更多了, 經(jīng)常會(huì)根本搞不清楚他自己的,這次運(yùn)營(yíng)活動(dòng)對(duì)什么的提升會(huì)更好,他得有一個(gè)預(yù)測(cè), 他就去看,他發(fā)現(xiàn)這個(gè)東西不是我想象的, 無(wú)法和老板交代,看看別的指標(biāo)是否會(huì)提升. 本來(lái)我要拉新用戶(hù)的,新用戶(hù)沒(méi)拉上來(lái), 那再看看對(duì)老用戶(hù)留存是否有幫助?---他會(huì)不停的Ad hoc(即席查詢(xún)),
//29:50 針對(duì)以上的用戶(hù)群體, 我們整個(gè)平臺(tái)的設(shè)計(jì)
//1)基礎(chǔ)架構(gòu)
首先一大塊,是屬于基礎(chǔ)架構(gòu),基礎(chǔ)的運(yùn)行,存儲(chǔ)和計(jì)算的架構(gòu).核心的基礎(chǔ)架構(gòu)采用的是hadoop/hive/storm/spark. 在展示層面會(huì)用到redis/hbase等等.
在此之上我們主要自己研發(fā)去做,有很多調(diào)度/質(zhì)量監(jiān)控/傳輸/測(cè)試/OLAP引擎等等很多這樣的工具在做. 有了這些東西之后,用戶(hù)就可以在平臺(tái)上看,在平臺(tái)基礎(chǔ)去做,
目標(biāo)只有一個(gè)--快. 用戶(hù)能寫(xiě)東西寫(xiě)的/實(shí)現(xiàn)的很快, 運(yùn)行的也不錯(cuò)--對(duì)性能的要求可能沒(méi)有那么高 ,相比之下,能拿到正確的數(shù)據(jù)比快更重要,.
//2.1)數(shù)據(jù)倉(cāng)庫(kù)(ETL:數(shù)據(jù)的規(guī)范/收集/整理/集中存儲(chǔ))
另外一大塊體系是數(shù)據(jù)--即數(shù)據(jù)倉(cāng)庫(kù), 對(duì)基礎(chǔ)數(shù)據(jù)做各種清理,對(duì)這些日志做規(guī)范/做清理.
在頁(yè)面要定義規(guī)范,比如說(shuō) 現(xiàn)在的app里會(huì)有很多的H5頁(yè)面,H5頁(yè)面的日志收集方法和APP是不一樣的,只要是頁(yè)面它收集的東西一定是用js來(lái)收集,這兩者之間定義什么樣的規(guī)范/命名規(guī)范/調(diào)用規(guī)范,總之要把他們連接在一起,因?yàn)閺挠脩?hù)的角度它是一個(gè)個(gè)的APP和H5是沒(méi)有區(qū)別的.--我們要看用戶(hù)的體驗(yàn).
//2.2)數(shù)據(jù)主題(數(shù)據(jù)的主題)
在這上面, 我們從用戶(hù)/商戶(hù)/交易這樣的角度做基礎(chǔ)的數(shù)據(jù)主題,
在此基礎(chǔ)上去做, 運(yùn)營(yíng)/基礎(chǔ)畫(huà)像/KPI等各種各樣的東西,
以上是整個(gè)數(shù)據(jù)倉(cāng)庫(kù)的建設(shè)過(guò)程,
//3)數(shù)據(jù)產(chǎn)品(數(shù)據(jù)的價(jià)值)
3.1)價(jià)值: 我們要對(duì)數(shù)據(jù)的價(jià)值有一些判斷,那些數(shù)據(jù)是非常重要的,全公司的KPI指標(biāo)是非常重要的,某個(gè)部門(mén)的小指標(biāo)可能并不重要,
3.2)安全:
3.3)組織和維度: 這些數(shù)據(jù)是歸屬于哪個(gè)組織的,指標(biāo)是歸屬于誰(shuí)的/哪個(gè)部門(mén)的,
維度是各種各樣的東西,城市是統(tǒng)一的/品類(lèi)是統(tǒng)一的,等等很多工作,
有了這些,我們就可以應(yīng)對(duì)很多基礎(chǔ)性工作,
//4) 數(shù)據(jù)產(chǎn)品(數(shù)據(jù)展示/收攏)
2014年,我們開(kāi)始通過(guò)產(chǎn)品的方法收攏,收攏整個(gè)的展示,讓用戶(hù)能更快速的看得到, 展示數(shù)據(jù),展示最終的結(jié)果,包括email發(fā)送/微信之類(lèi)的,
還有開(kāi)發(fā),我們的客戶(hù),很多要處理自己數(shù)據(jù),要在此之上做開(kāi)發(fā),屏蔽底下所有的東西,只在這邊做一些開(kāi)發(fā)上線(xiàn)就可以.
運(yùn)營(yíng)效果好壞,包括留存,回訪(fǎng)如何,交易拉回來(lái)的GMV--拉回來(lái)的交易額有多少,還有流量,
點(diǎn)評(píng)整個(gè)數(shù)據(jù)平臺(tái)的架構(gòu)就是如上,大概有一個(gè)概念了.
//33:40 案例
//平臺(tái)中的取舍
建設(shè)整個(gè)平臺(tái)過(guò)程中,有以下幾點(diǎn)是非常值得小心和注意的,
1)首先, 在基礎(chǔ)平臺(tái)這一塊,平臺(tái)中我們是有一些取舍, 最重要一點(diǎn)是 實(shí)時(shí)和離線(xiàn)的統(tǒng)計(jì),
老板總是很可恨的 ,問(wèn)你這個(gè)數(shù)據(jù)出出來(lái)沒(méi)有, 我隨時(shí)都想看到,可不可以做到, one size not fit all, 做不到怎么辦--我們就做一些取舍,
1/2)實(shí)時(shí)數(shù)據(jù): 時(shí)效性強(qiáng)/一致性弱, 比如算時(shí)效獎(jiǎng)金,錯(cuò)10塊錢(qián)都不行,某種意義上叫一致性,
2/2)離線(xiàn)數(shù)據(jù): 用戶(hù)畫(huà)像舉例,這個(gè)人的用戶(hù)行為在過(guò)去很長(zhǎng)時(shí)間積累里面,已經(jīng)有了自己的特性,實(shí)時(shí)只能對(duì)它有增強(qiáng)效果,沒(méi)有決定性效果,至少男女年齡不會(huì)改變, 離線(xiàn)統(tǒng)計(jì)部分的價(jià)值會(huì)很高
我們以這樣的原則(CAP)來(lái)和需求/和我們的客戶(hù)來(lái)談,
客戶(hù)說(shuō)我們想看DAU數(shù)據(jù),我們會(huì)說(shuō)沒(méi)問(wèn)題,但是對(duì)不起,它一定會(huì)和batch的計(jì)算差5%左右,否則你會(huì)給自己挖坑,
//36:00 實(shí)時(shí)架構(gòu)
1/3) APP手機(jī)前端日志,
2/3)app server收集后端日志,
3/3)mysql收集的是業(yè)務(wù)數(shù)據(jù),多少交易/多少單子
傳輸數(shù)據(jù)到-->自研系統(tǒng)(Blackhole/puma<binlog>)-->最后灌入到storm-->持久化(one size not fit all,通過(guò)不同系統(tǒng)做持久化,通過(guò)不同特點(diǎn)來(lái)走) --> data service向外提供服務(wù)
//data service
異構(gòu)數(shù)據(jù)源,不同系統(tǒng)之中的數(shù)據(jù)應(yīng)該怎么辦,對(duì)用戶(hù)來(lái)講,希望通過(guò)一個(gè)data service來(lái)搞定--內(nèi)部的事情我們自己去做(封裝在服務(wù)內(nèi)部去).
//37:00 建模中的取舍
建模中,我們的取舍是最嚴(yán)重的,
有三個(gè)取舍,
1/3)業(yè)務(wù)變化 VS 基礎(chǔ)穩(wěn)定:
業(yè)務(wù)經(jīng)常會(huì)發(fā)生變化,基礎(chǔ)又要非常穩(wěn)定,基礎(chǔ)數(shù)據(jù)要非常穩(wěn)定, 兩者之間怎么辦
2/3)維度多樣 VS 口徑一致
維度非常多樣,口徑要一致, 去退款的例子,
3/3) 運(yùn)營(yíng)精細(xì) VS指標(biāo)全面,
//1/3)業(yè)務(wù)變化 VS 基礎(chǔ)穩(wěn)定:
自上而下或自下而上方式建模型,可能是星型模型/雪花模型,
//1)變動(dòng)小: 對(duì)流量這樣的體系,采用自底而上方式,
寫(xiě)代碼/做業(yè)務(wù)的人不care日志, 我可以在日志基礎(chǔ)上盡情做我想做的事情,定義好這樣的日志,在此基礎(chǔ)上做,
2)變動(dòng)大: 比如銷(xiāo)售的獎(jiǎng)金計(jì)算規(guī)則(有可能一個(gè)禮拜就變一次), 運(yùn)營(yíng)活動(dòng)里的分析,
我們只能采用自頂向下的方式來(lái)建設(shè), 要非常清楚地知道他到底需要知道什么樣的東西,
比如在銷(xiāo)售計(jì)算里,最開(kāi)始可能只是簽單多少,賣(mài)了多少,到后來(lái)要看新客有多少在用,后面可能還有流量,多少人訪(fǎng)問(wèn)了你這個(gè)單子---必須要自頂向下的來(lái)走,
3)還有些線(xiàn)上線(xiàn)下串聯(lián)的工作,
比如: 運(yùn)營(yíng)活動(dòng)里,運(yùn)營(yíng)活動(dòng)總是最后要看效果的,下單下了多少,10單還是20單,可是會(huì)有一個(gè)現(xiàn)象,我們?cè)赼pp上先點(diǎn)了第一個(gè)運(yùn)營(yíng)活動(dòng),再點(diǎn)了第二個(gè)運(yùn)營(yíng)活動(dòng),然后我們下的單, 單算的話(huà),
0元看電影:這是一個(gè)線(xiàn)上線(xiàn)下串接的很好例子,
第一個(gè)活動(dòng)有可能幫助你留住了用戶(hù)也說(shuō)不準(zhǔn),
---我們要自底向上的設(shè)計(jì)流量模型,設(shè)計(jì)流量的樹(shù)狀模型,每一個(gè)運(yùn)營(yíng)活動(dòng)的頁(yè)面都放好,用戶(hù)都瀏覽過(guò)哪些頁(yè)面...然后我們自上而下地去看,怎么樣去分配利潤(rùn),
//維度多樣 VS 口徑一致
核心數(shù)據(jù)一定和CFO/CEO討論清楚,到底應(yīng)該怎么定義,我們?yōu)榇顺赃^(guò)很多很多的虧,
數(shù)據(jù)中心自身的強(qiáng)大來(lái)定義所謂的規(guī)則/規(guī)范,使得上面的工作非常的簡(jiǎn)潔/容易,
//運(yùn)營(yíng)精細(xì)化 VS 指標(biāo)全面
兩者之間也是有很多矛盾,
1)用戶(hù)在大規(guī)模的,高級(jí)用戶(hù)在指標(biāo)的全面性上有很高要求,要看DAU/訂單的效率/訂單金額/,
2)小級(jí)別用戶(hù)會(huì)有N多的需求,
//產(chǎn)品設(shè)計(jì)
通過(guò)產(chǎn)品來(lái)約束用戶(hù),設(shè)計(jì)真正的數(shù)據(jù)產(chǎn)品過(guò)程之中,也會(huì)有一些坑,坑分成兩大類(lèi),
//1/2) 業(yè)務(wù)閉環(huán) VS 數(shù)據(jù)閉環(huán)
產(chǎn)品經(jīng)理/運(yùn)營(yíng)/開(kāi)發(fā)是個(gè)小閉環(huán)--業(yè)務(wù)閉環(huán),
而對(duì)于轉(zhuǎn)化率/點(diǎn)擊率/CPM展示率/好評(píng)率--這些東西是由自己來(lái)負(fù)責(zé),數(shù)據(jù)會(huì)在縱向的閉環(huán)--從最高的指標(biāo)一直到一直落到最下面的日志規(guī)范,這中間起到一個(gè)閉環(huán)作用, 由我們?nèi)ザx...業(yè)務(wù)自身去做一個(gè)橫向的閉環(huán).
//2/2)產(chǎn)品的矛盾,
每個(gè)部門(mén),都有自己運(yùn)營(yíng)活動(dòng)的平臺(tái),工程師會(huì)做一個(gè)平臺(tái),讓運(yùn)營(yíng)人員在上面自己去做事--就相當(dāng)于自助
但是平臺(tái)只針對(duì)于電影,運(yùn)營(yíng)自然會(huì)提需求,去幫我把運(yùn)營(yíng)效果分析下...而數(shù)據(jù)部門(mén)會(huì)看公司所有的數(shù)據(jù)結(jié)果,這兩者之間是有矛盾的,從產(chǎn)品的角度會(huì)不同,
DAU有各種各樣不同的產(chǎn)品,那之間怎么做,
交互的方式上可以做嵌入,
//44:45
點(diǎn)評(píng)網(wǎng)對(duì)于數(shù)據(jù)倉(cāng)庫(kù)技術(shù)在互聯(lián)網(wǎng)領(lǐng)域的應(yīng)用,有這樣一個(gè)未來(lái)的規(guī)劃,
分成兩撥來(lái)看,一波是硬技術(shù)--平臺(tái)技術(shù)/工具技術(shù)/產(chǎn)品技術(shù),
另外一波是軟技術(shù),是數(shù)據(jù)倉(cāng)庫(kù)技術(shù)
1)基礎(chǔ)模型,基礎(chǔ)框架,基礎(chǔ)報(bào)表,
2)在此基礎(chǔ)上,做維度統(tǒng)一,主題定義上面做一些事情
3)第三階段, 流式計(jì)算,性能優(yōu)化, 數(shù)據(jù)模型上要在一致性和數(shù)據(jù)驅(qū)動(dòng)性上做事, 目前我們剛剛爬上第三個(gè)階段,
-- End --
