9月27日，WOT技術門診第一期會診結束，本期特邀門診專家數果科技創始人王勁，針對在構建大數據應用平臺過程中遇到的典型問題開出了那些藥方？

[本期專家簡介：數果科技聯合創始人，曾任酷狗音樂大數據架構師，技術負責人，負責酷狗大數據技術規劃、建設、應用。12年IT從業經驗，2年分布式應用開發，1年移動互聯網廣告系統架構設計，4年大數據技術實踐經驗，多年的團隊管理經驗，主要研究方向流式計算、大數據存儲計算、分布式存儲系統、NoSQL、搜索引擎等～]

問題一：很多開發者在搭建大數據分析平臺時，都會遇到大數據內部的融合性、與傳統技術的融合性、運維負擔大等問題，您認為在搭建大數據分析平臺時應該遵循哪些設計準則?

大數據平臺架構設計的基本準則：實時、簡單、解耦、易維護、易定位。

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

簡單：大數據平臺架構盡量簡單，適應業務需求就可以，不要過度設計，不一定要全采用開源的，有些組件自己開發更快更簡單。解耦：整個大數據平臺由很多環節組件，每個環節是一個獨立系統，盡量讓環節與環節之間解耦，耦合太高，不便后續的維護升級。

易維護：由于大數據平臺，都是采用分布式架構，很多故障是不可預測的，所以需要可視化運維平臺來簡化我們后續的運維工作。易定位：在大數據平臺中，數據異常、數據波動也是經常發生的，所以需要對整個數據鏈路進行監控，我們叫數據質量監控。[[174086]]

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

針對在大數據系統架構的技術選型時，如何保持技術的互補與不造成架構臃腫間的平衡這個問題，根據公司的業務需求進行技術選型，夠用就行，不能為了架構而架構。

關于這方面的監測和應對方案

從兩方面處理：

1. 對使用的組件團隊需要成員深入了解，需要對使用的組件可控。
2. 對使用的每個組件進行指標監控，便于出問題后定位分析問題。

問題三：對于對實時性要求較強的業務來說，應該如何進行NoSQL的選型?比如HBase/Redis/ Cassandra,分別適用于哪些場景?請您簡述它們各自的優劣勢。

對于技術選型，沒有統一的標準與規范，而是要根據具體的業務需求進行量身定制，同一項技術，在A公司能很好的應用，而在B公司可能就會存在很多問題。一旦選型某項技術后，團隊一定要能消化此技術的核心問題，這樣在整個運營過程中才能扛得住各種奇葩的問題。

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

對于HBase / Cassandra / Redis來說

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

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

HBase / Cassandra更多適合TB或PB數據存儲及查詢等場景; Redis更多適合緩存或對GB級實時性要求高的場景。

問題四：在國家互聯網+，以及移動互聯網蓬勃發展的背景下，大數據的發展會有哪個更側重的趨勢呢?在這樣的背景下，大數據從業者又該如何強化自身適應潮流?

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

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

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

面對猛增的數據和數據種類，企業非常需要能夠收集和整合大數據的人才。ETL開發人員面臨企業數據的多種不同的來源，并想辦法從這些來源中提取數據、導入數據并調整數據以適應企業的需求，然后將其添加到數據庫中。

Hadoop開發人員

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

可視化工具開發人員

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

數據科學家

數據科學家之前被稱為數據架構師，他們能夠從數據中挖掘出商業價值。他們還必須具備良好的溝通能力，以向IT領導和業務領導解釋數據結果。這些數據科學家通常還有自己的沙箱，用于探索和檢查企業的數據，并幫助推動創新。

OLAP開發人員

聯機分析處理(On-Line Analytical Processing，OLAP)開發人員是數據分析專家。他們從關系型或非結構化數據來源獲取數據，并創建三維模型，然后構建用戶界面，通過高性能預定義查詢來訪問數據。

預測分析開發人員“在營銷公司中，預測分析被大量用于預測消費者行為和瞄準目標受眾。”有時候，這個職位似乎有點類似于數據科學家，這些IT人員非常擅長構建潛在商業情況、利用基于歷史數據的假設來預測未來表現。

問題五：同樣作為流處理模型，SparkStreaming與Storm目前各自的應用現狀如何?在進行技術選型時應該從哪些方面權衡?

從實際生產應用現狀來看：

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

storm與spark streaming的對比：

數據處理模型、數據延遲性

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

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

容錯能力

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

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

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

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

當然，如果你希望對每次實時處理的過程進行掌控，那么spark streaming提供的狀態記錄會清楚地描述出數據處理的過程，并且數據的錯榮能力也很不錯。

問題六：探索性大數據的意義何在?應該具備哪些技術基礎?

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

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

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

b、分析方法從實際出發，不以某種理論為依據

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

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

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

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

以下內容用心感受才能撲捉到更細膩的美好瞬間

WOT技術門診-認真“治病”互動花絮

一線業務人員和大數據技術人員“撕逼”大戰花絮

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

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

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

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

其實我真的想對你說

WOT技術門診第二期也要開始嘍～