一、大數據中的數據倉庫和Mpp數據庫如何選型?
在Hadoop平臺中，一般大家都把hive當做數據倉庫的一種選擇，而Mpp數據庫的典型代表就是impala，presto。Mpp架構的數據庫主要用於即席查詢場景，暨對數據查詢效率有較高要求的場景，而對數據倉庫的查詢效率要求無法做大MPP那樣，所以更多地適用與離線分析場景。
Hadoop已經是大數據平臺的實時標準，其中Hadoop生態中有數據倉庫Hive，可以作為大數據平臺的標準數據倉庫，
對於面向應用的MPP數據庫，可以選擇MYCAT(mySql的分佈式架構)或是impala(基於Hive和Hbase)，包括對稱式和非對稱式兩種分佈式模式
二、大數據分析中的實時推薦是如何實現的?
實時推薦需要使用實時處理框架結合推薦算法，從而做到對數據的實時處理和推薦。實時處理框架有Storm、Flink、SparkStreaming，組件可以對接Kafka，獲取實時流數據，在實時框架內部實現對數據的處理過程。
1、實時推薦需要藉助實時計算框架例如Spark或是Strom技術，
2、數據採集採用Flume+Kafka作為數據緩存和分發作用
3、同時還需要有非常適合的實時推薦算法，例如基於用戶畫像的實時推薦，或是基於用戶行為的實施推薦、或是對商品相識度的實施推薦等不同的算法
三、數據治理有何高效的處理方法或工具?
數據治理沒有具體的工具和方法，這是一項浩大的工程，可能牽扯到每個部門，既有技術人員參與，又要有業務人員參與，關鍵時刻還要有領導進行決策。每個公司的數據情況不同，處理方法也不盡相同，基本的方法是有的，暨通過對數據的梳理(元數據、主數據)，發現數據質量問題，再通過質量標準或組織協調的方式，對數據進行標準化處理的。
數據治理是一項人力和辛苦活，沒有捷徑和什麼有效的工具，而且在一個大數據項目中，數據治理是非常重要的一個環節，因為只有數據質量滿足前端應用需求，才有可能挖掘和分析出準確的結果。
具體數據處理方法還需要看實際業務情況，例如數據庫、數據類型、數據規模等
數據治理的過程是一個對業務系統數據梳理的過程，過程中發現的問題會反饋給業務部門，同時還要制定統一的質量和稽核標準，就好比給每個業務系統數據生成線上增加一個質量監管員。
四、大數據分析中針對日誌分析的框架如何選型?
elk 常用組件, 上層業務封裝還需要求其他組件完成
日誌分析 elk + redis + mysql 熱點數據 , 熱點分析
等等, 看你的業務是什麼模式和 開發人員偏好
現在免費且主流的均已採用Elastic公司的ELK框架，均為輕量級組件，且簡單易用，從採集到界面展示幾乎用不了多少時間即可搭建完畢，Kibana界面效果優異，包含地圖、報表、檢索、報警、監控等眾多功能。
五、請問在大數據平臺搭建過後，大數據平臺的運維監控主要關注哪些?
大數據平臺的運維監控主要包括硬件和軟件層面，具體如下：
1、主機、網絡、硬盤、內存、CPU等資源。
在擁有幾十臺以上的集群環境中，大量的數據計算對硬件尤其是硬盤的損耗是較大的，在大量計算中，網絡也往往會成為一個瓶頸，這些都需要時刻關注。
主要監控平臺各個組件的狀態、負載情況，有異常及時報警。
3、用戶層面
大數據平臺建設是為了服務公司內部廣大用戶的，所以資源既是共享的，又需要是隔離的，所以需要對用戶對平臺資源的使用情況做好監控，及時發現異常使用情況，防止對其他用戶產生不良影響，影響正常業務開展。
大數據平臺搭建後，運維監控的主要內容包括
1、分佈式架構的底層虛擬機的運行情況(CPU、內存、網絡、硬盤等)
2、各個組件(HDFS 、MR、 SPark 、Hive 、Hbase、 IMpla、FLume、 Spooq等)的運行狀態和告警信息
六、數據量大，數據類型繁雜的情況下，如何做性能保障?
如何保障大數據平臺的處理性能，關鍵還是看應用場景和業務需求，不是每種業務都需要高性能。
1、在類OLTP場景下，大數據平臺有像HBase一樣的組件，保證數據讀寫具有極高的性能和吞吐量。
2、在OLAP場景下，大數據平臺有像Impala、Kudu、Kylin、Druid這樣引擎，通過內存或預計算的方式保證查詢性能。
3、在離線分析場景，有像Hive、Spark、Mapreduce這樣的引擎，分佈式處理海量數據，在這種場景下，性能和響應時間已無法做到保證。
1、大數據的底層全部都是分佈式架構，分佈式架構具有很強的橫向擴展能力，而且是使用廉價的PC服務器即可組件分佈式架構，只有增加服務器數據，性能也可以橫向擴展，
2、另外大數據平臺在數據處理方面也均是採用分佈式處理技術(例如 MR、 Hive、 Hbase 、 HDFS)
3、另外還有一些是基於內存的數據計算和處理架構Spark技術，大數據平臺下對性能的要求沒有和傳統的交互式的響應不太一樣，大數據分為實時和離線計算，實時計算要求響應時間，離線計算對於響應時間沒有太高的要求。
七、數據預處理問題?
鋼鐵行業的數據比較複雜，對於對生產工藝不是特別瞭解的IT人員如何進行數據處理，或是應該由誰來進行數據處理?
數據預處理的過程包括數據的清洗、集成、整合、標準化等過程。
1、數據預處理的過程是由承建大數據項目的供應商來處理，或是專門做數據治理的公司來負責這項工作。
2、大數據項目中，數據的預處理會花費大量的時間，而且是手工工作量較多，如果對業務部太數據，勢必會有很多問題，最好是由對業務相對了解的人員來參與數據的預處理的工作。
只有高質量的數據才會有分析的價值，所以預處理過程顯得尤為重要。數據是業務的數字化形式，對於比較複雜的行業數據，技術人員是不會知道怎麼處理才能滿足業務分析的需求的，必須要業務分析人員提出具體的數據處理需求，技術人員才能設計滿足相應需求。
八、從傳統數倉向大數據平臺遷移的規劃?
傳統數倉很多用oracle做的，現在想轉入大數據平臺，有什麼好的遷移規劃方案，以及遷移可能遇到的問題，謝謝!
1、數據倉庫無論是用oracle，還是其他數據庫，此類型的數據轉入大數據平臺都有個ETL的過程，將數據統一存放在HDFS分佈式文件系統中，上層則藉助於Hive構建數據倉庫，用於離線數據跑批計算，Hbase，用於支持數據高併發在線查詢和非結構化數據的對象存儲來滿足前段的應用分析需求
2、可以利用數據倉庫中原有的數據共享交換平臺，實時將數據推送到共享平臺，例如Sqoop數據導入結構化數據，利用Flume和Kafka對非結構化類數據進行採集並將之轉為結構化數據落地HDFS進行存儲
九、傳統數倉轉向大數據平臺的必要性?
如題，或者什麼場景的的傳統數倉適合轉向大數據平臺。轉向大數據平臺後都解決了什麼樣的問題，暴露出什麼樣的問題?
大數據平臺採用分佈式架構，用於解決海量數據的存儲和分析問題，傳統數倉無法解決上百TB及PB級的分析問題。大數據平臺由於架構新，使用模式也不盡相同，有的使用sql，有的使用spark編程，有的使用mapreduce編程，所以存在一定的學習成本;大數據平臺還在逐步完善中，尤其是用戶管理、安全、元數據管理等方面還存在一定問題，使用時需要注意。
十、大數據底層保持數據強一致性是如何實現的?
大數據底層的數據強一致性是通過HDFS的分佈式架構中的冗餘副本策略和心跳檢測機制實現的。
1、冗餘副本策略：HDFS處理節點失效的一個方法就是數據冗餘，即對數據做多個備份，在HDFS中可以通過配置文件設置備份的數量,默認是3副本，只有數據在3個副本上均完成寫成功，才返回。
2、心跳機制：檢測節點失效使用“心跳機制”。每個 Datanode 節點週期性地向 Namenode 發送心跳信號。 Namenode 通過心跳信號的缺失來檢測這一情況，並將這些近期不再發送心跳信號 Datanode 標記為宕機，不會再將新的 IO 請求發給它們。
N： 3 (數據備份的數目)
W： 1 (數據寫入幾個節點返回成功)，默認是1
R： 1 (讀取數據的時候需要讀取的節點數)
W + R < N
Hadoop沒有辦法保證所有數據的強一致性，但是通過副本機制保證一定程度的一致性，如果某一個datanode宕機，將會在其他datanode上重建一個副本，從而達到副本一致性的目的，且在寫入的時候可以採用一次寫入多個副本的方式保證即使某個副本對應機器掛掉，也不影響整個數據。
十一、大數據平臺加入到災備怎麼做?有成熟的思路或者方案嗎?
1、災備解決的是業務連續性的問題，大數據平臺本身提供多副本機制是保障業務的穩定和可靠運行的
2、目前大數據平臺基本是都是部署在虛擬機或是容器之上，很少有直接部署在物理服務器+存儲架構之上
3、這樣虛擬化和容器本身就帶來很強的業務連續性的功能，例如虛擬機的熱遷移、HA、DRS等功能
十二、大數據底層平臺對硬件的要求有哪些?
1、在企業內部，最好保證集群中所有機器的配置保持一直，否則容易出現一臺機器運行較慢，從而拖慢整體任務運行速度的情況。
2、大數據平臺對網絡要求較高，在幾十臺機器的集群下，如果採用千兆網絡，極其容易出現某一個大任務把帶寬佔滿的情況。
3、平臺對CPU、硬盤的需求相對網絡要低點，但也不能太低，否則IO上不來，任務也會被拖慢。
4、平臺對內存的要求高，尤其在一個平臺內搭建Impala、Spark、MR、Hive、HBase等組件共享資源的情況下，更應該配備高內存。
支持樓上，X86分佈式部署即可。尤其注意系統IO性能，可配置SSD。
大吞吐量、大容量，高帶寬。
1、Hadoop現在已經是大數據的事實標準，而 Hadoop的出現就是運行在廉價商用服務器上，以集群之力，分而治之地解決先前傳統數據庫、傳統存儲、傳統計算模型束手無策的問題，讓大規模數據的處理成為了可能。
2、對於硬件沒有太高的要求，普通的PC服務器即可，但是為了高更的性能，服務器內可以增加SSD固態硬盤或是內容等資源。
十三、大數據人才培養?
向大數據平臺轉型成功的關鍵，人才佔了很大的比例，如何有效平滑的推動人才隊伍的建設?
大數據涉及數據採集、數據的清洗集成、治理、大數據平臺的安裝調試和運維、大數據的開發、大數據的算法工程師、大數據的挖掘工程師等。
大數據人才需求是一種金字塔架構，最底層需求量最大的是數據採集、清洗和治理的人員(基本上以人工為主)，在上層就是數據平臺的安裝調試(必須有linux基礎)，往上就是大數據的開放、算法和挖掘工程師了。
如果是用戶單位，需要提前培養大數據的意識，要認識到大數據的重要性和可行性，培養可以為項目後期提供運維的人員為主。
十四、用戶畫像用到了哪些大數據技術和工具，做的時候應該注意什麼?
所謂用戶畫像就是用多維度的數據來描述一個用戶的整體特徵，涉及到特徵工程的提取，打標籤的過程。
例如用戶的屬性、偏好、生活習慣、行為、運動、作息等信息，抽象出來的標籤化用戶模型。通俗來講就是給用戶打標籤，而標籤是通過對用戶信息分析而來的高度精煉的特徵標識。
涉及到數據採集、數據建模、挖掘分析等，需要注意一下幾點：
1、在畫像創建之前需要知道用戶關心的的特徵維度和用戶的行為等因素，從而從總體上掌握對用戶需求需求。
2、創建用戶畫像不是抽離出典型進行單獨標籤化的過程，而是要融合邊緣環境的相關信息來進行討論。
3、用戶畫像有時候需要變化、分為短期內的畫像、或是長期的畫像等。
十五、一般一個大數據項目實施過程中應該注意什麼?
這個過程與一般的項目沒有本質區別，基本的需求、分析、設計、開發、測試都是要有的。不同的地方是大數據項目採用的技術不像傳統的基於數據庫的SQL開發那麼簡單，對編程能力的要求較高，同時對遇到問題的排查能力要求也較高，因為是分佈式運行，導致問題排查變得非常複雜。
1、大數據項目實施過程中涉及到和客戶的眾多業務系統進行對接的，也就是數據的採集，到數據的清洗、集成、標準、數據治理、數據的建模、挖掘分析和最後的可視化等過程。
2、在和業務系統對接的過程中需要注意的必須拿到業務系統的數據字典(如果沒有，拿到數據對數據的識別和分析非常困難)。
3、數據業務分析維度，需要項目經理進場需要客戶明確的需求後確定系統的範圍和邊界(否則需求和範圍不停的變，開發週期遙遙無期)。
4、準備好大數據平臺要求的底層環境和資源(CPU、內存、硬盤、網絡等)，大數據項目對於這些資源的要求還是相對比較高的，例如硬盤容量，例如要分析日誌類的數據或是流水數據。
十六、企業級大數據平臺如何選型?
現在，大數據平臺基本特指Hadoop平臺了，選型主要還是指Haoop管理平臺。現在主流的廠商有cloudera和Hortonworks,國內有華為的fusion insight和星環科技的產品。相對來說，cloudera具有較大優勢，市場佔有率也較高，管理平臺非常實用，對與平臺管理人員來說是不可多得的好幫手
Hadoop現在已經是大數據的事實標準了，企業級大數據平臺建議選擇基於Hadoop開源的生態，目前對於Hadoop開源商業推廣最大的兩個場景及cloudera(CDH版本，適合於linux系統上運行)和Hortonworks(HDP版本，支持運行在windows系統上運行)，目前是一家公司了，可以選擇其中一家產品即可
十七、大數據中的實時計算SPark和Storm優缺點是什麼?分別適合於哪些場景?
SparkStreaming和Strom都屬於實時計算框架，有點都是可以做到對數據的實時處理。SparkStreaming是基於Spark Core實現的，所以對數據的處理要形成RDD，暨要形成數據窗口，所以其處理過程可以稱之為微批處理，而storm是可以做到實時處理每一條數據的，所以相對來說，實時性比sparkstreaming更高。所以storm更適合處理實時性要求極高的場景。
SPark體系中的 Spark Streaming嚴格意義上屬於批處理計算框架，準實時，基於內存的計算框架，性能可以達到秒級，大數據除了實時計算之外，還包括了離線批處理、交互式查詢等業務功能，而且實時計算中，可能還會牽扯到高延遲批處理、交互式查詢等功能，就應該首選Spark生態，用Spark Core開發離線批處理，用Spark SQL開發交互式查詢，用Spark Streaming開發實時計算，三者可以無縫整合，給系統提供非常高的可擴展性。
Storm是純實時計算框架，來一條數據，處理一條數據，可以達到毫秒級，適合於要求可靠的事務機制和可靠性機制，即數據的處理完全精準，一條也不能多，一條也不能少，也可以考慮使用Storm。
形象點比喻，SPark就好比商城的直梯，Storm就好比商場的扶梯。
閱讀更多 微笑數據工程師 的文章
