9月27日，WOT技術(shù)門診第一期會診結(jié)束，本期特邀門診專家數(shù)果科技創(chuàng)始人王勁，針對在構(gòu)建大數(shù)據(jù)應(yīng)用平臺過程中遇到的典型問題開出了那些藥方？

[本期專家簡介：數(shù)果科技聯(lián)合創(chuàng)始人，曾任酷狗音樂大數(shù)據(jù)架構(gòu)師，技術(shù)負(fù)責(zé)人，負(fù)責(zé)酷狗大數(shù)據(jù)技術(shù)規(guī)劃、建設(shè)、應(yīng)用。12年IT從業(yè)經(jīng)驗，2年分布式應(yīng)用開發(fā)，1年移動互聯(lián)網(wǎng)廣告系統(tǒng)架構(gòu)設(shè)計，4年大數(shù)據(jù)技術(shù)實踐經(jīng)驗，多年的團(tuán)隊管理經(jīng)驗，主要研究方向流式計算、大數(shù)據(jù)存儲計算、分布式存儲系統(tǒng)、NoSQL、搜索引擎等～]

問題一：很多開發(fā)者在搭建大數(shù)據(jù)分析平臺時，都會遇到大數(shù)據(jù)內(nèi)部的融合性、與傳統(tǒng)技術(shù)的融合性、運(yùn)維負(fù)擔(dān)大等問題，您認(rèn)為在搭建大數(shù)據(jù)分析平臺時應(yīng)該遵循哪些設(shè)計準(zhǔn)則?

大數(shù)據(jù)平臺架構(gòu)設(shè)計的基本準(zhǔn)則：實時、簡單、解耦、易維護(hù)、易定位。

實時：由于大數(shù)據(jù)的時效性越高，數(shù)據(jù)價值就越大，所以設(shè)計時盡量讓數(shù)據(jù)實時。

簡單：大數(shù)據(jù)平臺架構(gòu)盡量簡單，適應(yīng)業(yè)務(wù)需求就可以，不要過度設(shè)計，不一定要全采用開源的，有些組件自己開發(fā)更快更簡單。解耦：整個大數(shù)據(jù)平臺由很多環(huán)節(jié)組件，每個環(huán)節(jié)是一個獨立系統(tǒng)，盡量讓環(huán)節(jié)與環(huán)節(jié)之間解耦，耦合太高，不便后續(xù)的維護(hù)升級。

易維護(hù)：由于大數(shù)據(jù)平臺，都是采用分布式架構(gòu)，很多故障是不可預(yù)測的，所以需要可視化運(yùn)維平臺來簡化我們后續(xù)的運(yùn)維工作。易定位：在大數(shù)據(jù)平臺中，數(shù)據(jù)異常、數(shù)據(jù)波動也是經(jīng)常發(fā)生的，所以需要對整個數(shù)據(jù)鏈路進(jìn)行監(jiān)控，我們叫數(shù)據(jù)質(zhì)量監(jiān)控。[[174086]]

問題二：在大數(shù)據(jù)系統(tǒng)架構(gòu)的技術(shù)選型時，如何保持技術(shù)的互補(bǔ)與不造成架構(gòu)臃腫間的平衡?還有就是我們都知道這些工具都是有自身的缺陷，而且缺陷的暴露基本上不可預(yù)測的，像spark在數(shù)據(jù)量過大的時穩(wěn)定性經(jīng)常沒法保證，能否請您說一下關(guān)于這方面的監(jiān)測和應(yīng)對方案呢?

針對在大數(shù)據(jù)系統(tǒng)架構(gòu)的技術(shù)選型時，如何保持技術(shù)的互補(bǔ)與不造成架構(gòu)臃腫間的平衡這個問題，根據(jù)公司的業(yè)務(wù)需求進(jìn)行技術(shù)選型，夠用就行，不能為了架構(gòu)而架構(gòu)。

關(guān)于這方面的監(jiān)測和應(yīng)對方案

從兩方面處理：

1. 對使用的組件團(tuán)隊需要成員深入了解，需要對使用的組件可控。
2. 對使用的每個組件進(jìn)行指標(biāo)監(jiān)控，便于出問題后定位分析問題。

問題三：對于對實時性要求較強(qiáng)的業(yè)務(wù)來說，應(yīng)該如何進(jìn)行NoSQL的選型?比如HBase/Redis/ Cassandra,分別適用于哪些場景?請您簡述它們各自的優(yōu)劣勢。

對于技術(shù)選型，沒有統(tǒng)一的標(biāo)準(zhǔn)與規(guī)范，而是要根據(jù)具體的業(yè)務(wù)需求進(jìn)行量身定制，同一項技術(shù)，在A公司能很好的應(yīng)用，而在B公司可能就會存在很多問題。一旦選型某項技術(shù)后，團(tuán)隊一定要能消化此技術(shù)的核心問題，這樣在整個運(yùn)營過程中才能扛得住各種奇葩的問題。

而且具體的技術(shù)，在業(yè)務(wù)不同的階段會拋出不同的問題。有時會隨著數(shù)據(jù)量的增加，性能成為瓶頸;有時會隨著業(yè)務(wù)的復(fù)雜度增加，對某些特性要求更高等等。所以不敢選型哪項技術(shù)，團(tuán)隊一定要慢慢深入吃透，才能扛住業(yè)務(wù)不斷變化的需求。

對于HBase / Cassandra / Redis來說

HBase，Cassandra屬于列式數(shù)據(jù)庫，HBase提供了Cassandra沒有的行鎖機(jī)制，Cassandra要想使用鎖需要配合其他系統(tǒng)，如Hadoop Zookeeper; HBase提供更好的MapReduce并行計算支持，Cassandra在0.6版本也提供了這個功能; Cassandra的讀寫性能和可擴(kuò)展性更好，但不擅長區(qū)間掃描。

Redis屬于一個key-value存儲系統(tǒng)。和Memcached類似，它支持存儲的value類型相對更多，包括string(字符串)、list(鏈表)、set(集合)和zset(有序集合)。這些數(shù)據(jù)類型都支持push/pop、add/remove及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎(chǔ)上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數(shù)據(jù)都是緩存在內(nèi)存中。區(qū)別的是redis會周期性的把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎(chǔ)上實現(xiàn)了master-slave(主從)同步Redis一個分布式緩存。

HBase / Cassandra更多適合TB或PB數(shù)據(jù)存儲及查詢等場景; Redis更多適合緩存或?qū)B級實時性要求高的場景。

問題四：在國家互聯(lián)網(wǎng)+，以及移動互聯(lián)網(wǎng)蓬勃發(fā)展的背景下，大數(shù)據(jù)的發(fā)展會有哪個更側(cè)重的趨勢呢?在這樣的背景下，大數(shù)據(jù)從業(yè)者又該如何強(qiáng)化自身適應(yīng)潮流?

1. 大數(shù)據(jù)計算提高數(shù)據(jù)處理效率，增加人類認(rèn)知盈余
2. 大數(shù)據(jù)通過全局的數(shù)據(jù)讓人類了解事物背后的真相
3. 大數(shù)據(jù)有助于了解事物發(fā)展的客觀規(guī)律，利于科學(xué)決策
4. 大數(shù)據(jù)提供了同事物的連接，客觀了解人類行為
5. 大數(shù)據(jù)改變過去的經(jīng)驗思維，幫助人們建立數(shù)據(jù)思維

大數(shù)據(jù)從業(yè)者，面臨很多崗位，針對不同崗位，要求不一樣，下面介紹幾種崗位，有興趣的可以了解下。

ETL(提取、傳輸和加載)開發(fā)人員

面對猛增的數(shù)據(jù)和數(shù)據(jù)種類，企業(yè)非常需要能夠收集和整合大數(shù)據(jù)的人才。ETL開發(fā)人員面臨企業(yè)數(shù)據(jù)的多種不同的來源，并想辦法從這些來源中提取數(shù)據(jù)、導(dǎo)入數(shù)據(jù)并調(diào)整數(shù)據(jù)以適應(yīng)企業(yè)的需求，然后將其添加到數(shù)據(jù)庫中。

Hadoop開發(fā)人員

Hadoop是基于Java的開源框架，它支持對大數(shù)據(jù)集的處理。根據(jù)Kforce表示，企業(yè)對Hadoop框架中的數(shù)據(jù)，以及不同種類的技術(shù)，如Hive、HBase、MapReduce、Pig等有著很高的需求，這主要是對數(shù)據(jù)量的需求。并且，如果沒有大規(guī)模分布式處理，使用傳統(tǒng)商業(yè)智能工具處理TB級/PB級的成本很高而且很費(fèi)時間。 “具有Hadoo框架經(jīng)驗的人員最受追捧，隨著企業(yè)確定其長期的大數(shù)據(jù)戰(zhàn)略，這些職位將會更緊俏。

可視化工具開發(fā)人員

大規(guī)模的數(shù)據(jù)給數(shù)據(jù)分析帶來巨大挑戰(zhàn)。新類型的可視化工具集(例如Spotifre、Qlikview和Tableau)允許直觀的快速的數(shù)據(jù)探測。雖然這些職位可能類似于通常的商業(yè)智能開發(fā)人員，但Hadoop現(xiàn)在仍然很熱門，而且是一種新類型的專門技能。

數(shù)據(jù)科學(xué)家

數(shù)據(jù)科學(xué)家之前被稱為數(shù)據(jù)架構(gòu)師，他們能夠從數(shù)據(jù)中挖掘出商業(yè)價值。他們還必須具備良好的溝通能力，以向IT領(lǐng)導(dǎo)和業(yè)務(wù)領(lǐng)導(dǎo)解釋數(shù)據(jù)結(jié)果。這些數(shù)據(jù)科學(xué)家通常還有自己的沙箱，用于探索和檢查企業(yè)的數(shù)據(jù)，并幫助推動創(chuàng)新。

OLAP開發(fā)人員

聯(lián)機(jī)分析處理(On-Line Analytical Processing，OLAP)開發(fā)人員是數(shù)據(jù)分析專家。他們從關(guān)系型或非結(jié)構(gòu)化數(shù)據(jù)來源獲取數(shù)據(jù)，并創(chuàng)建三維模型，然后構(gòu)建用戶界面，通過高性能預(yù)定義查詢來訪問數(shù)據(jù)。

預(yù)測分析開發(fā)人員“在營銷公司中，預(yù)測分析被大量用于預(yù)測消費(fèi)者行為和瞄準(zhǔn)目標(biāo)受眾。”有時候，這個職位似乎有點類似于數(shù)據(jù)科學(xué)家，這些IT人員非常擅長構(gòu)建潛在商業(yè)情況、利用基于歷史數(shù)據(jù)的假設(shè)來預(yù)測未來表現(xiàn)。

問題五：同樣作為流處理模型，SparkStreaming與Storm目前各自的應(yīng)用現(xiàn)狀如何?在進(jìn)行技術(shù)選型時應(yīng)該從哪些方面權(quán)衡?

從實際生產(chǎn)應(yīng)用現(xiàn)狀來看：

Storm開源的比較早，自2011年起，推特就在使用storm了，大部分公司的實時計算環(huán)境使用的storm。而spark streaming是一個比較新的項目，在2013年的時候，僅僅被Sharethrough使用。Storm是Hortonworks Hadoop數(shù)據(jù)平臺中的數(shù)據(jù)流式處理的解決方案，而Spark Streaming出現(xiàn)在MapR的分布式平臺和Cloudera的企業(yè)數(shù)據(jù)平臺中。

storm與spark streaming的對比：

數(shù)據(jù)處理模型、數(shù)據(jù)延遲性

雖然兩種框架都提供了系統(tǒng)的可擴(kuò)展性和可容錯性，但是它們的數(shù)據(jù)處理模型從根本上說是不一樣的，而處理模型則決定了他們的實時性。

Storm可以實現(xiàn)正真流式實時的處理數(shù)據(jù)，例如每次處理一條消息，這樣，延遲就可以控制在秒級以下，實時性很高。而Spark Streaming的本質(zhì)其實還是批量處理，只是這個批量是微批量，在短的時間窗口內(nèi)進(jìn)行數(shù)據(jù)實時處理，通常延遲在秒級左右，實時性相對較弱。

容錯能力

在數(shù)據(jù)容錯能力方面，spark streaming做的比storm好一些，它的容錯是通過狀態(tài)記錄去實現(xiàn)的。而storm則不一樣，storm對每一條數(shù)據(jù)進(jìn)行處理標(biāo)記，從而進(jìn)行跟蹤數(shù)據(jù)的處理情況，它只能保證每條數(shù)據(jù)被處理一次，但實際情況是，在發(fā)生錯誤的時候，這條數(shù)據(jù)是被處理多次的。這意味著，更新多次的時候可能會導(dǎo)致數(shù)據(jù)不正確。

而spark的批處理特點，能夠保證每個批處理的所有數(shù)據(jù)只處理一次，保證數(shù)據(jù)不會在恢復(fù)的時候錯亂(批處理重新執(zhí)行)。

storm提供的Trident庫雖然能夠保證在數(shù)據(jù)容錯時只被處理一次，但它很大程度上依賴于事務(wù)的狀態(tài)更新，并且這個過程相對較慢，更甚者，這個過程是需要用戶自己去實現(xiàn)。

總結(jié)：如果你的業(yè)務(wù)場景對實時性要求比較高，同樣對數(shù)據(jù)容錯也有所要求，那么storm將是一個很好的選擇。

當(dāng)然，如果你希望對每次實時處理的過程進(jìn)行掌控，那么spark streaming提供的狀態(tài)記錄會清楚地描述出數(shù)據(jù)處理的過程，并且數(shù)據(jù)的錯榮能力也很不錯。

問題六：探索性大數(shù)據(jù)的意義何在?應(yīng)該具備哪些技術(shù)基礎(chǔ)?

談探索性大數(shù)據(jù)的意義，我們得從探索性數(shù)據(jù)分析的特點講起。

a、研究從原始數(shù)據(jù)入手，完全以實際數(shù)據(jù)為依據(jù)。

傳統(tǒng)的統(tǒng)計分析方法是先假定數(shù)據(jù)服從某種分布，如多數(shù)情況下假定數(shù)據(jù)服從正態(tài)分布，然后用適應(yīng)這種分布的模型進(jìn)行分析和預(yù)測。但客觀實際的多數(shù)數(shù)據(jù)并不滿足假定的理論分布(如正態(tài)分布)，這樣實際場合就會偏離嚴(yán)格假定所描述的理論模型，傳統(tǒng)統(tǒng)計方法就可能表現(xiàn)很差，從而使其應(yīng)用具有極大的局限性。EDA則不是從某種假定出發(fā)，而是完全從客觀數(shù)據(jù)出發(fā)，從實際數(shù)據(jù)中去探索其內(nèi)在的數(shù)據(jù)規(guī)律性。

b、分析方法從實際出發(fā)，不以某種理論為依據(jù)

傳統(tǒng)的統(tǒng)計分析方法是以概率論為理論基礎(chǔ)，對各種參數(shù)的估計、檢驗和預(yù)測給出具有一定精度的度量方法和度量值。EDA則以不完全正式的方法處理數(shù)據(jù)。在探索數(shù)據(jù)內(nèi)在的數(shù)量特征、數(shù)量關(guān)系和數(shù)量變化時，什么方法可以達(dá)到這一目的就采用什么方法，靈活對待，靈活處理。方法的選擇完全服從于數(shù)據(jù)的特點和研究的目的，并且更重視數(shù)據(jù)特征值的穩(wěn)健耐抗性，而相對放松對概率理論和精確度的刻意追求。

c、分析工具簡單直觀，更易于普及

傳統(tǒng)的統(tǒng)計分析方法應(yīng)用的數(shù)學(xué)工具越來越深奧，統(tǒng)計研究也越來越理論化，這樣就使應(yīng)用的人越來越害怕統(tǒng)計。EDA提供多種多樣豐富多彩的詳細(xì)考察數(shù)據(jù)的方法。例如，它運(yùn)用簡單直觀的莖葉圖、箱線圖、殘差圖、字母值、數(shù)據(jù)變換、中位數(shù)平滑等與傳統(tǒng)統(tǒng)計方法截然不同的方法，使得具有一般數(shù)學(xué)知識的人就可以進(jìn)行復(fù)雜的數(shù)據(jù)分析。這不僅極大地擴(kuò)大了統(tǒng)計分析的用戶群體，而且為統(tǒng)計思想注入了新的活力。

探索性大數(shù)據(jù)分析需要具備哪些技術(shù)基礎(chǔ)，從它的特點可以看出，需要具體原始數(shù)據(jù)存儲功能，所以在大數(shù)據(jù)中做探索性分析，需要具備TB/PB級原始數(shù)據(jù)的快速查詢與存儲等技術(shù)能力。具體到技術(shù)點，大家有興趣的可以私聊～

以下內(nèi)容用心感受才能撲捉到更細(xì)膩的美好瞬間

WOT技術(shù)門診-認(rèn)真“治病”互動花絮

一線業(yè)務(wù)人員和大數(shù)據(jù)技術(shù)人員“撕逼”大戰(zhàn)花絮

WOT技術(shù)門診第一期已經(jīng)落幕。在這次線上互動交流活動中，各個行業(yè)不同崗位人群發(fā)表了自己最真實的想法。因為交流，我們從未孤獨孤獨，不是沒人聽你說話而是你不想說給別人聽。

所以，你孤獨，你活該。你的孤獨雖敗猶恥!!!

那個，別!別!不要!不要!扔磚啊!!

其實，我是想說，我不希望你孤獨。因為，我心疼......

其實我真的想對你說

WOT技術(shù)門診第二期也要開始嘍～