大數(shù)據(jù)火起來之后揭糕，推大數(shù)據(jù)幾乎成為了政治正確，不管什么項目都要把大數(shù)據(jù)的架構(gòu)搭建起來比原，再利用數(shù)據(jù)分析來做出正確的產(chǎn)品決策插佛。政治正確的意思就是太對了杠巡，一點(diǎn)毛病都沒有量窘，但是實(shí)踐起來不是這么一回事，或者要付出巨大的代價氢拥。
這里不談那些把一張Excel表格當(dāng)大數(shù)據(jù)的蚌铜，對于大部分10M
DAU的應(yīng)用來說，平均每個用戶100個行為記錄嫩海，加上必要信息冬殃，每天日志不會超過1TB的數(shù)據(jù)量，以龜速10MBPS的處理速度叁怪，也不過一整天的運(yùn)算時間审葬，這應(yīng)該算應(yīng)不應(yīng)該加上大數(shù)據(jù)架構(gòu)的一個臨界點(diǎn)了。如果對于一個快速增長的產(chǎn)品來說，早做準(zhǔn)備把大數(shù)據(jù)架構(gòu)搭建起來總是沒有錯的涣觉。
但事情的真相沒那么簡單
首先每天寫滿一個硬盤的日志真的帶來了應(yīng)有的價值嗎痴荐？
一般數(shù)據(jù)處理會產(chǎn)生一些時間切片的數(shù)據(jù)，一般是某個衡量對象的量官册，包括用戶總量生兆，活躍用戶量，發(fā)帖數(shù)膝宁，添加朋友數(shù)鸦难，閱讀時間等指標(biāo) ，然后根據(jù)用戶性別员淫、年齡合蔽、地區(qū)進(jìn)行進(jìn)一步細(xì)分。但這些似乎并不需要從海量的日志中去獲得介返，產(chǎn)品數(shù)據(jù)庫里已經(jīng)有了更加完整的信息辈末。
數(shù)據(jù)處理還會進(jìn)行一些時序有關(guān)的分析，比如用戶在做了動作A之后會做什么映皆。有多少用戶在注冊第X步的時候退出了挤聘。這當(dāng)然是有用的，但是你上一次看這個數(shù)據(jù)是多久之前呢捅彻？而一次性的對當(dāng)天日志進(jìn)行分析组去，無論技術(shù)難度還是時間還是成本都會低非常多。
此外數(shù)據(jù)處理會提供一些性能的數(shù)據(jù)步淹，比如多久載入頁面从隆，上傳頭像成功率多少，但很難講這個信息真的能價值一塊硬盤缭裆，如果真的重要的性能數(shù)據(jù)键闺，恐怕每天分析一次是不太夠的。
當(dāng)然澈驼，永遠(yuǎn)可以有這樣的反駁：“多存點(diǎn)東西總歸是好的辛燥，萬一哪天用得到呢？”
對此我會亮出奧卡姆剃刀：如非必要缝其，勿增實(shí)體挎塌。
具體到這個問題就是：現(xiàn)在用不到的就是沒必要有的，以后用到了以后再加也來得及内边，而如果是臨時的數(shù)據(jù)就讓它用完就扔榴都。
舉個例子，有一天知乎的產(chǎn)品經(jīng)理想要看看每個用戶平均換幾次頭像漠其，然后根據(jù)這個數(shù)據(jù)來提供產(chǎn)品決策怎么提高換頭像的用戶體驗(yàn)嘴高。所以他要求一個碼農(nóng)把這個數(shù)字拿出來竿音，由于記錄一個按鈕的點(diǎn)擊很容易，所以之前就有了拴驮，碼農(nóng)寫了一個SQL把數(shù)據(jù)給產(chǎn)品經(jīng)理看谍失。很顯然，不死心的產(chǎn)品經(jīng)理會提出一個新的要求莹汤，比如換頭像多的用戶和換頭像少的用戶的活躍性相關(guān)分析快鱼，這就不是一個簡單的SQL能夠解決的了。這個故事告訴我們纲岭，即便你現(xiàn)在想的很完美抹竹，把各種需求都考慮到的日志記錄，也是不能滿足真實(shí)環(huán)境中的數(shù)據(jù)分析需求的止潮。
而知乎可能會很關(guān)注每篇文章閱讀時間這樣的數(shù)據(jù)窃判，在早期的時候這個日志很可能沒有記錄過，而隨著構(gòu)架的改變喇闸，這個日志記錄方式也可能會發(fā)生變化袄琳，但是這個當(dāng)需要的時候再收集并沒有任何問題，可能延誤一兩周甚至一兩個月的時間燃乍，但之前已經(jīng)延誤了一兩年時間也沒有任何問題唆樊。
其次真的有必要上Hadoop之類的計算方式嗎？
且不提有人用Hadoop來數(shù)總共有多少用戶這種事情刻蟹，大數(shù)據(jù)計算框架的本質(zhì)在于用大量的計算能力來解決以前用統(tǒng)計方法來解決的問題逗旁。
再也不用Bootstrap這樣的統(tǒng)計方式來計算了，直接全部數(shù)一遍就可以了舆瘪∑В看上去真的很美好，但是也真的很貴啊英古。除了搭建大數(shù)據(jù)計算的人力淀衣，機(jī)器的運(yùn)維，數(shù)據(jù)的處理和分析召调，都引入了大量的人力膨桥。而你得到的是，更精確的數(shù)據(jù)某残，根據(jù)你數(shù)據(jù)分布和統(tǒng)計對象的不同国撵，大概比抽樣5%的精確度高10-20%吧陵吸。
如果是計算用戶數(shù)量這樣的數(shù)據(jù)玻墅，由于用戶ID本身是均勻分布的，所以抽樣統(tǒng)計的結(jié)果可能相差無幾壮虫。對于用戶閱讀時間這樣非常差異的分布澳厢，誤差可能會大一些环础。但這種誤差并沒有讓你獲得更錯誤的數(shù)據(jù)，比如你希望知道的是用戶在A設(shè)計中閱讀時間和B設(shè)計中閱讀時間的比較剩拢，而不是在這個設(shè)計中具體需要多少秒時間线得。如果真的需要這么精確的程度，更改產(chǎn)品需求其實(shí)是更加合適的選擇徐伐，而不是大數(shù)據(jù)框架就能夠解決的問題贯钩。
因?yàn)橐粋€殘酷的事實(shí)是，即便日志里的時間戳办素，都有5%是完全不精確的角雷。比如最簡單的問題，很多用戶晚上11點(diǎn)半開始閱讀性穿，讀到12點(diǎn)半熄燈睡覺勺三，這一段是算昨天的還是今天的。當(dāng)然這個可以把時間分割到凌晨兩點(diǎn)或者三點(diǎn)來一定程度避免需曾，但如果你的應(yīng)用是全球市場的吗坚，那么這個問題就繼續(xù)產(chǎn)生了。
如果是一個手機(jī)應(yīng)用呆万，那么就更慘烈了商源，由于網(wǎng)絡(luò)的問題，可能客戶端收集的數(shù)據(jù)和上傳的時間相差了非常久谋减。更不用提因?yàn)榭蛻舳舜a沒寫好炊汹，處理上傳失敗或者重復(fù)上傳的情況不正確，上傳的時間戳不正確等等逃顶。
所以精確度不高是系統(tǒng)性的讨便，不是說單純在處理數(shù)據(jù)的部分提高一下就能夠完善解決的。更重要的是以政，你根本不需要這個精確度霸褒。
最后你真的需要需要專門的數(shù)據(jù)處理團(tuán)隊和機(jī)器嗎？
首先這個真的很貴，貴的不是人力镐侯，是每個人本心的持續(xù)增長的需要差油。雇來的不是數(shù)據(jù)處理團(tuán)隊，而是更加復(fù)雜的辦公室政治殊轴。
因?yàn)橛辛藬?shù)據(jù)處理團(tuán)隊，所以大家默認(rèn)他們是數(shù)據(jù)分析團(tuán)隊袒炉，本來自己隨手可以寫的SQL也不寫了旁理，甚至于收集數(shù)據(jù)也不管了。但是由于要做產(chǎn)品決定我磁，所以數(shù)據(jù)處理團(tuán)隊就變成了數(shù)據(jù)分析團(tuán)隊孽文。這給數(shù)據(jù)處理團(tuán)隊帶了非常多不能產(chǎn)生效益但是很繁瑣的日常工作驻襟，而他們并不能從產(chǎn)品成功里分享到成果。
由于數(shù)據(jù)處理團(tuán)隊站在數(shù)據(jù)處理的立場上芋哭，為了證明自己的價值沉衣，會做出更加復(fù)雜的數(shù)據(jù)處理系統(tǒng)，這些并沒有讓公司變得更有效减牺，也沒有對產(chǎn)品產(chǎn)生任何直接的作用豌习，但是卻需要更多的人手來保持系統(tǒng)的正確運(yùn)作，解決更多來自產(chǎn)品部門的需要拔疚，以及建立更加復(fù)雜的系統(tǒng)和實(shí)驗(yàn)斑鸦。
而這種架構(gòu)應(yīng)該是低效的，因?yàn)閿?shù)據(jù)處理團(tuán)隊并不清楚產(chǎn)品的邏輯草雕，寫的數(shù)據(jù)收集的邏輯最后還是需要產(chǎn)品團(tuán)隊來驗(yàn)證巷屿。即便是簡單的數(shù)據(jù)分析，也可能因?yàn)楫a(chǎn)品越來越復(fù)雜而必須要產(chǎn)品團(tuán)隊來驗(yàn)證墩虹，比如統(tǒng)計一個用戶多久修改一次主頁嘱巾，可能就包含點(diǎn)開主頁的記錄和點(diǎn)擊修改，以及點(diǎn)擊保存的記錄诫钓。在早期但仍然有50%占有率的應(yīng)用版本上旬昭，點(diǎn)開主頁就是修改；在最新的但是40%占有率的應(yīng)用版本上菌湃，需要點(diǎn)擊修改并保存才算问拘。
如果一個資源是免費(fèi)但有限的時候，大家會傾向于更加大量的索取惧所。比如讓數(shù)據(jù)團(tuán)隊給個數(shù)據(jù)這個行為對于產(chǎn)品團(tuán)隊來說是免費(fèi)的骤坐，但是由于數(shù)據(jù)團(tuán)隊人少，所以可能要等很久甚至得不到回復(fù)下愈，那么逮到機(jī)會就不管需不需要都會讓他們統(tǒng)統(tǒng)給你纽绍。
如果一個任務(wù)對于自己是得不到提升的，或者沒有好處的势似，那么傾向于不做或者搗漿糊拌夏。比如數(shù)據(jù)分析這種事情，如果自己出報告履因，預(yù)見性的提出了什么什么障簿，可能還對升職有點(diǎn)幫助；但如果是為了回答別人問題而做的分析栅迄，可能過一個月問你的人自己都不記得有這回事了站故。
而只有這個事情對自己是必要的，才會用最合適的資源和最積極的態(tài)度去完成霞篡。比如讓產(chǎn)品團(tuán)隊自己去做數(shù)據(jù)分析世蔗，他們就會知道什么問題是該問的端逼，什么問題是沒必要問的朗兵，也會知道拿一個數(shù)字需要怎樣的過程污淋，這個學(xué)習(xí)經(jīng)驗(yàn)應(yīng)該是一次性的，而成本也是最低的余掖。
所以該怎么辦寸爆？
一般中小型的應(yīng)用可能并不需要一個專職的做數(shù)據(jù)處理的工程師，一個框架搭好之后盐欺，可以用非常久赁豆。只需要讓所有人都能夠非常容易往里面加記錄，進(jìn)行分析就可以了冗美。
我覺得在100M用戶之前永遠(yuǎn)有繞開大數(shù)據(jù)的解決方案魔种。
當(dāng)然如果分析數(shù)據(jù)帶來的價值遠(yuǎn)高于多雇傭5%的工程師，一個良好的大數(shù)據(jù)架構(gòu)成本是值得付出的粉洼。
至于連SQL都不愿意學(xué)的產(chǎn)品經(jīng)理节预，我就不知道你為什么還要留著他了。
