大資料時代已經到來，社群最近組織了“大資料時代企業的精準化和個性化管理及服務實踐線上交流探討”，並邀請專家陳星星撰寫了《大資料時代背景教育企業的精準化和個性化管理及服務實踐》（點選標題可閱讀），為廣大會員提供大資料應用相關實踐借鑑，以下由陳星星將活動中提出的難點問題及解答進行總結，供更多讀者參考。

很多初學者，對大資料的概念都是模糊不清的，大資料是什麼，能做什麼，學的時候，該按照什麼線路去學習，學完往哪方面發展，想深入瞭解，想學習的同學歡迎加入大資料學習qq群：957205962，有大量乾貨（零基礎以及進階的經典實戰）分享給大家，並且有清華大學畢業的資深大資料講師給大家免費授課，給大家分享目前國內最完整的大資料高階實戰實用學習流程體系

Q1、傳統數倉轉向大資料平臺的必要性？

如題，或者什麼場景的的傳統數倉適合轉向大資料平臺。轉向大資料平臺後都解決了什麼樣的問題，暴露出什麼樣的問題？

A：

■ rein07 某證券 系統架構師：

大資料平臺採用分散式架構，用於解決海量資料的儲存和分析問題，傳統數倉無法解決上百TB及PB級的分析問題。大資料平臺由於架構新，使用模式也不盡相同，有的使用SQL，有的使用spark程式設計，有的使用mapreduce程式設計，所以存在一定的學習成本；大資料平臺還在逐步完善中，尤其是使用者管理、安全、元資料管理等方面還存在一定問題，使用時需要注意。

 

Q2、大資料底層保持資料強一致性是如何實現的？

A：

■ 陳星星 科技公司 技術經理：

大資料底層的資料強一致性是通過HDFS的分散式架構中的冗餘副本策略和心跳檢測機制實現的。

1、冗餘副本策略：HDFS處理節點失效的一個方法就是資料冗餘，即對資料做多個備份，在HDFS中可以通過配置檔案設定備份的數量,預設是3副本，只有資料在3個副本上均完成寫成功，才返回。

2、心跳機制：檢測節點失效使用“心跳機制”。每個 Datanode 節點週期性地向 Namenode 傳送心跳訊號。 Namenode 通過心跳訊號的缺失來檢測這一情況，並將這些近期不再發送心跳訊號 Datanode 標記為宕機，不會再將新的 IO 請求發給它們。

N： 3 (資料備份的數目)

W： 1 （資料寫入幾個節點返回成功），預設是1

R： 1 （讀取資料的時候需要讀取的節點數）

W + R < N

■ rein07 某證券 系統架構師：

Hadoop沒有辦法保證所有資料的強一致性，但是通過副本機制保證一定程度的一致性，如果某一個datanode宕機，將會在其他datanode上重建一個副本，從而達到副本一致性的目的，且在寫入的時候可以採用一次寫入多個副本的方式保證即使某個副本對應機器掛掉，也不影響整個資料。

 

Q3、大資料底層平臺對硬體的要求有哪些？

A：

■ rein07 某證券 系統架構師：

1、在企業內部，最好保證叢集中所有機器的配置保持一直，否則容易出現一臺機器執行較慢，從而拖慢整體任務執行速度的情況。

2、大資料平臺對網路要求較高，在幾十臺機器的叢集下，如果採用千兆網路，極其容易出現某一個大任務把頻寬佔滿的情況。

3、平臺對CPU、硬碟的需求相對網路要低點，但也不能太低，否則IO上不來，任務也會被拖慢。

4、平臺對記憶體的要求高，尤其在一個平臺內搭建Impala、Spark、MR、Hive、HBase等元件共享資源的情況下，更應該配備高記憶體。

■ michael1983 某證券 技術經理 ：

支援樓上，X86分散式部署即可。尤其注意系統IO效能，可配置SSD。

■ wuwenpin 軟體開發工程師：

大吞吐量、大容量，高頻寬。

■ 陳星星 科技公司 技術經理：

1、Hadoop現在已經是大資料的事實標準，而 Hadoop的出現就是執行在廉價商用伺服器上，以叢集之力，分而治之地解決先前傳統資料庫、傳統儲存、傳統計算模型束手無策的問題，讓大規模資料的處理成為了可能。

2、對於硬體沒有太高的要求，普通的PC伺服器即可，但是為了高更的效能，伺服器內可以增加SSD固態硬碟或是內容等資源。

 

Q4、使用者畫像用到了哪些大資料技術和工具，做的時候應該注意什麼？

A：

■ 陳星星 科技公司 技術經理：

所謂使用者畫像就是用多維度的資料來描述一個使用者的整體特徵，涉及到特徵工程的提取，打標籤的過程。

例如使用者的屬性、偏好、生活習慣、行為、運動、作息等資訊，抽象出來的標籤化使用者模型。通俗來講就是給使用者打標籤，而標籤是通過對使用者資訊分析而來的高度精煉的特徵標識。

涉及到資料採集、資料建模、挖掘分析等，需要注意一下幾點：

1、在畫像建立之前需要知道使用者關心的的特徵維度和使用者的行為等因素，從而從總體上掌握對使用者需求需求。

2、建立使用者畫像不是抽離出典型進行單獨標籤化的過程，而是要融合邊緣環境的相關資訊來進行討論。

3、使用者畫像有時候需要變化、分為短期內的畫像、或是長期的畫像等。

 

Q5、一般一個大資料專案實施過程中應該注意什麼？

A：

■ rein07 某證券 系統架構師：

這個過程與一般的專案沒有本質區別，基本的需求、分析、設計、開發、測試都是要有的。不同的地方是大資料專案採用的技術不像傳統的基於資料庫的SQL開發那麼簡單，對程式設計能力的要求較高，同時對遇到問題的排查能力要求也較高，因為是分散式執行，導致問題排查變得非常複雜。

■ 陳星星 科技公司 技術經理：

1、大資料專案實施過程中涉及到和客戶的眾多業務系統進行對接的，也就是資料的採集，到資料的清洗、整合、標準、資料治理、資料的建模、挖掘分析和最後的視覺化等過程。

2、在和業務系統對接的過程中需要注意的必須拿到業務系統的資料字典（如果沒有，拿到資料對資料的識別和分析非常困難）。

3、資料業務分析維度，需要專案經理進場需要客戶明確的需求後確定系統的範圍和邊界（否則需求和範圍不停的變，開發週期遙遙無期）。

4、準備好大資料平臺要求的底層環境和資源（CPU、記憶體、硬碟、網路等），大資料專案對於這些資源的要求還是相對比較高的，例如硬碟容量，例如要分析日誌類的資料或是流水資料。

很多初學者，對大資料的概念都是模糊不清的，大資料是什麼，能做什麼，學的時候，該按照什麼線路去學習，學完往哪方面發展，想深入瞭解，想學習的同學歡迎加入大資料學習qq群：957205962，有大量乾貨（零基礎以及進階的經典實戰）分享給大家，並且有清華大學畢業的資深大資料講師給大家免費授課，給大家分享目前國內最完整的大資料高階實戰實用學習流程體系

Q6、企業級大資料平臺如何選型？

A：

■ rein07 某證券 系統架構師：

現在，大資料平臺基本特指Hadoop平臺了，選型主要還是指Haoop管理平臺。現在主流的廠商有cloudera和Hortonworks,國內有華為的fusion insight和星環科技的產品。相對來說，cloudera具有較大優勢，市場佔有率也較高，管理平臺非常實用，對與平臺管理人員來說是不可多得的好幫手

■ 陳星星 科技公司 技術經理：

Hadoop現在已經是大資料的事實標準了，企業級大資料平臺建議選擇基於Hadoop開源的生態，目前對於Hadoop開源商業推廣最大的兩個場景及cloudera（CDH版本，適合於linux系統上執行）和Hortonworks（HDP版本，支援執行在windows系統上執行），目前是一家公司了，可以選擇其中一家產品即可

 

Q7、大資料中的實時計算SPark和Storm優缺點是什麼？分別適合於哪些場景？

A：

■ rein07 某證券 系統架構師：

SparkStreaming和Strom都屬於實時計算框架，有點都是可以做到對資料的實時處理。SparkStreaming是基於Spark Core實現的，所以對資料的處理要形成RDD，暨要形成資料視窗，所以其處理過程可以稱之為微批處理，而storm是可以做到實時處理每一條資料的，所以相對來說，實時性比sparkstreaming更高。所以storm更適合處理實時性要求極高的場景。

■ 陳星星 科技公司 技術經理：

SPark體系中的 Spark Streaming嚴格意義上屬於批處理計算框架，準實時，基於記憶體的計算框架，效能可以達到秒級，大資料除了實時計算之外，還包括了離線批處理、互動式查詢等業務功能，而且實時計算中，可能還會牽扯到高延遲批處理、互動式查詢等功能，就應該首選Spark生態，用Spark Core開發離線批處理，用Spark SQL開發互動式查詢，用Spark Streaming開發實時計算，三者可以無縫整合，給系統提供非常高的可擴充套件性。

Storm是純實時計算框架，來一條資料，處理一條資料，可以達到毫秒級，適合於要求可靠的事務機制和可靠性機制，即資料的處理完全精準，一條也不能多，一條也不能少，也可以考慮使用Storm。

形象點比喻，SPark就好比商城的直梯，Storm就好比商場的扶梯。

 

Q8、大資料分析中的實時推薦是如何實現的？

A：

■ rein07 某證券 系統架構師：

實時推薦需要使用實時處理框架結合推薦演算法，從而做到對資料的實時處理和推薦。實時處理框架有Storm、Flink、SparkStreaming，元件可以對接Kafka，獲取實時流資料，在實時框架內部實現對資料的處理過程。

■ 陳星星 科技公司 技術經理：

1、實時推薦需要藉助實時計算框架例如Spark或是Strom技術

2、資料採集採用Flume+Kafka作為資料快取和分發作用

3、同時還需要有非常適合的實時推薦演算法，例如基於使用者畫像的實時推薦，或是基於使用者行為的實施推薦、或是對商品相識度的實施推薦等不同的演算法

 

Q9、資料治理有何高效的處理方法或工具？

A：

■ rein07 某證券 系統架構師：

資料治理沒有具體的工具和方法，這是一項浩大的工程，可能牽扯到每個部門，既有技術人員參與，又要有業務人員參與，關鍵時刻還要有領導進行決策。每個公司的資料情況不同，處理方法也不盡相同，基本的方法是有的，暨通過對資料的梳理（元資料、主資料），發現數據質量問題，再通過質量標準或組織協調的方式，對資料進行標準化處理的。

■ 陳星星 科技公司 技術經理：

資料治理是一項人力和辛苦活，沒有捷徑和什麼有效的工具，而且在一個大資料專案中，資料治理是非常重要的一個環節，因為只有資料質量滿足前端應用需求，才有可能挖掘和分析出準確的結果

具體資料處理方法還需要看實際業務情況，例如資料庫、資料型別、資料規模等

資料治理的過程是一個對業務系統資料梳理的過程，過程中發現的問題會反饋給業務部門，同時還要制定統一的質量和稽核標準，就好比給每個業務系統資料生成線上增加一個質量監管員

 

Q10、資料量大，資料型別繁雜的情況下，如何做效能保障？

在資料處理層是關注處理能力，還是要做業層的效能與傳統效能一樣關注響應的時間嗎？

A：

■ rein07 某證券 系統架構師：

如何保障大資料平臺的處理效能，關鍵還是看應用場景和業務需求，不是每種業務都需要高效能。

1、在類OLTP場景下，大資料平臺有像HBase一樣的元件，保證資料讀寫具有極高的效能和吞吐量。

2、在OLAP場景下，大資料平臺有像Impala、Kudu、Kylin、Druid這樣引擎，通過記憶體或預計算的方式保證查詢效能。

3、在離線分析場景，有像Hive、Spark、Mapreduce這樣的引擎，分散式處理海量資料，在這種場景下，效能和響應時間已無法做到保證。

■ 陳星星 科技公司 技術經理：

1、大資料的底層全部都是分散式架構，分散式架構具有很強的橫向擴充套件能力，而且是使用廉價的PC伺服器即可元件分散式架構，只有增加伺服器資料，效能也可以橫向擴充套件，

2、另外大資料平臺在資料處理方面也均是採用分散式處理技術（例如 MR、 Hive、 Hbase 、 HDFS）

3、另外還有一些是基於記憶體的資料計算和處理架構Spark技術，大資料平臺下對效能的要求沒有和傳統的互動式的響應不太一樣，大資料分為實時和離線計算，實時計算要求響應時間，離線計算對於響應時間沒有太高的要求

 

Q11、資料預處理問題？

鋼鐵行業的資料比較複雜，對於對生產工藝不是特別瞭解的IT人員如何進行資料處理，或是應該由誰來進行資料處理？

A：

■ 陳星星 科技公司 技術經理：

資料預處理的過程包括資料的清洗、整合、整合、標準化等過程。

1、資料預處理的過程是由承建大資料專案的供應商來處理，或是專門做資料治理的公司來負責這項工作。

2、大資料專案中，資料的預處理會花費大量的時間，而且是手工工作量較多，如果對業務部太資料，勢必會有很多問題，最好是由對業務相對了解的人員來參與資料的預處理的工作。

■ rein07 某證券 系統架構師：

只有高質量的資料才會有分析的價值，所以預處理過程顯得尤為重要。資料是業務的數字化形式，對於比較複雜的行業資料，技術人員是不會知道怎麼處理才能滿足業務分析的需求的，必須要業務分析人員提出具體的資料處理需求，技術人員才能設計滿足相應需求。

很多初學者，對大資料的概念都是模糊不清的，大資料是什麼，能做什麼，學的時候，該按照什麼線路去學習，學完往哪方面發展，想深入瞭解，想學習的同學歡迎加入大資料學習qq群：957205962，有大量乾貨（零基礎以及進階的經典實戰）分享給大家，並且有清華大學畢業的資深大資料講師給大家免費授課，給大家分享目前國內最完整的大資料高階實戰實用學習流程體系