一、大數(shù)據(jù)中的數(shù)據(jù)倉(cāng)庫(kù)和Mpp數(shù)據(jù)庫(kù)如何選型?

在Hadoop平臺(tái)中，一般大家都把hive當(dāng)做數(shù)據(jù)倉(cāng)庫(kù)的一種選擇，而Mpp數(shù)據(jù)庫(kù)的典型代表就是impala，presto。Mpp架構(gòu)的數(shù)據(jù)庫(kù)主要用于即席查詢場(chǎng)景，暨對(duì)數(shù)據(jù)查詢效率有較高要求的場(chǎng)景，而對(duì)數(shù)據(jù)倉(cāng)庫(kù)的查詢效率要求無(wú)法做大MPP那樣，所以更多地適用與離線分析場(chǎng)景。

Hadoop已經(jīng)是大數(shù)據(jù)平臺(tái)的實(shí)時(shí)標(biāo)準(zhǔn)，其中Hadoop生態(tài)中有數(shù)據(jù)倉(cāng)庫(kù)Hive，可以作為大數(shù)據(jù)平臺(tái)的標(biāo)準(zhǔn)數(shù)據(jù)倉(cāng)庫(kù)，

對(duì)于面向應(yīng)用的MPP數(shù)據(jù)庫(kù)，可以選擇MYCAT(mySql的分布式架構(gòu))或是impala(基于Hive和Hbase)，包括對(duì)稱式和非對(duì)稱式兩種分布式模式

二、大數(shù)據(jù)分析中的實(shí)時(shí)推薦是如何實(shí)現(xiàn)的?

實(shí)時(shí)推薦需要使用實(shí)時(shí)處理框架結(jié)合推薦算法，從而做到對(duì)數(shù)據(jù)的實(shí)時(shí)處理和推薦。實(shí)時(shí)處理框架有Storm、Flink、SparkStreaming，組件可以對(duì)接Kafka，獲取實(shí)時(shí)流數(shù)據(jù)，在實(shí)時(shí)框架內(nèi)部實(shí)現(xiàn)對(duì)數(shù)據(jù)的處理過(guò)程。

1、實(shí)時(shí)推薦需要借助實(shí)時(shí)計(jì)算框架例如Spark或是Strom技術(shù)，

2、數(shù)據(jù)采集采用Flume+Kafka作為數(shù)據(jù)緩存和分發(fā)作用

3、同時(shí)還需要有非常適合的實(shí)時(shí)推薦算法，例如基于用戶畫(huà)像的實(shí)時(shí)推薦，或是基于用戶行為的實(shí)施推薦、或是對(duì)商品相識(shí)度的實(shí)施推薦等不同的算法

三、數(shù)據(jù)治理有何高效的處理方法或工具?

數(shù)據(jù)治理沒(méi)有具體的工具和方法，這是一項(xiàng)浩大的工程，可能牽扯到每個(gè)部門(mén)，既有技術(shù)人員參與，又要有業(yè)務(wù)人員參與，關(guān)鍵時(shí)刻還要有領(lǐng)導(dǎo)進(jìn)行決策。每個(gè)公司的數(shù)據(jù)情況不同，處理方法也不盡相同，基本的方法是有的，暨通過(guò)對(duì)數(shù)據(jù)的梳理(元數(shù)據(jù)、主數(shù)據(jù))，發(fā)現(xiàn)數(shù)據(jù)質(zhì)量問(wèn)題，再通過(guò)質(zhì)量標(biāo)準(zhǔn)或組織協(xié)調(diào)的方式，對(duì)數(shù)據(jù)進(jìn)行標(biāo)準(zhǔn)化處理的。

數(shù)據(jù)治理是一項(xiàng)人力和辛苦活，沒(méi)有捷徑和什么有效的工具，而且在一個(gè)大數(shù)據(jù)項(xiàng)目中，數(shù)據(jù)治理是非常重要的一個(gè)環(huán)節(jié)，因?yàn)橹挥袛?shù)據(jù)質(zhì)量滿足前端應(yīng)用需求，才有可能挖掘和分析出準(zhǔn)確的結(jié)果。

具體數(shù)據(jù)處理方法還需要看實(shí)際業(yè)務(wù)情況，例如數(shù)據(jù)庫(kù)、數(shù)據(jù)類型、數(shù)據(jù)規(guī)模等

數(shù)據(jù)治理的過(guò)程是一個(gè)對(duì)業(yè)務(wù)系統(tǒng)數(shù)據(jù)梳理的過(guò)程，過(guò)程中發(fā)現(xiàn)的問(wèn)題會(huì)反饋給業(yè)務(wù)部門(mén)，同時(shí)還要制定統(tǒng)一的質(zhì)量和稽核標(biāo)準(zhǔn)，就好比給每個(gè)業(yè)務(wù)系統(tǒng)數(shù)據(jù)生成線上增加一個(gè)質(zhì)量監(jiān)管員。

對(duì)大數(shù)據(jù)以及人工智能概念都是模糊不清的，該按照什么線路去學(xué)習(xí)，學(xué)完往哪方面發(fā)展，想深入了解，想學(xué)習(xí)的同學(xué)歡迎加入大數(shù)據(jù)學(xué)習(xí)qq群：458345782，有大量干貨（零基礎(chǔ)以及進(jìn)階的經(jīng)典實(shí)戰(zhàn)）分享給大家，并且有清華大學(xué)畢業(yè)的資深大數(shù)據(jù)講師給大家免費(fèi)授課，給大家分享目前國(guó)內(nèi)最完整的大數(shù)據(jù)高端實(shí)戰(zhàn)實(shí)用學(xué)習(xí)流程體系 。

四、大數(shù)據(jù)分析中針對(duì)日志分析的框架如何選型?

elk 常用組件, 上層業(yè)務(wù)封裝還需要求其他組件完成

日志分析 elk + redis + mysql 熱點(diǎn)數(shù)據(jù) , 熱點(diǎn)分析

等等, 看你的業(yè)務(wù)是什么模式和 開(kāi)發(fā)人員偏好

現(xiàn)在免費(fèi)且主流的均已采用Elastic公司的ELK框架，均為輕量級(jí)組件，且簡(jiǎn)單易用，從采集到界面展示幾乎用不了多少時(shí)間即可搭建完畢，Kibana界面效果優(yōu)異，包含地圖、報(bào)表、檢索、報(bào)警、監(jiān)控等眾多功能。

五、請(qǐng)問(wèn)在大數(shù)據(jù)平臺(tái)搭建過(guò)后，大數(shù)據(jù)平臺(tái)的運(yùn)維監(jiān)控主要關(guān)注哪些?

大數(shù)據(jù)平臺(tái)的運(yùn)維監(jiān)控主要包括硬件和軟件層面，具體如下：

1、主機(jī)、網(wǎng)絡(luò)、硬盤(pán)、內(nèi)存、CPU等資源。

在擁有幾十臺(tái)以上的集群環(huán)境中，大量的數(shù)據(jù)計(jì)算對(duì)硬件尤其是硬盤(pán)的損耗是較大的，在大量計(jì)算中，網(wǎng)絡(luò)也往往會(huì)成為一個(gè)瓶頸，這些都需要時(shí)刻關(guān)注。

2、平臺(tái)層面

主要監(jiān)控平臺(tái)各個(gè)組件的狀態(tài)、負(fù)載情況，有異常及時(shí)報(bào)警。

3、用戶層面

大數(shù)據(jù)平臺(tái)建設(shè)是為了服務(wù)公司內(nèi)部廣大用戶的，所以資源既是共享的，又需要是隔離的，所以需要對(duì)用戶對(duì)平臺(tái)資源的使用情況做好監(jiān)控，及時(shí)發(fā)現(xiàn)異常使用情況，防止對(duì)其他用戶產(chǎn)生不良影響，影響正常業(yè)務(wù)開(kāi)展。

大數(shù)據(jù)平臺(tái)搭建后，運(yùn)維監(jiān)控的主要內(nèi)容包括

1、分布式架構(gòu)的底層虛擬機(jī)的運(yùn)行情況(CPU、內(nèi)存、網(wǎng)絡(luò)、硬盤(pán)等)

2、各個(gè)組件(HDFS 、MR、 SPark 、Hive 、Hbase、 IMpla、FLume、 Spooq等)的運(yùn)行狀態(tài)和告警信息

六、數(shù)據(jù)量大，數(shù)據(jù)類型繁雜的情況下，如何做性能保障?

如何保障大數(shù)據(jù)平臺(tái)的處理性能，關(guān)鍵還是看應(yīng)用場(chǎng)景和業(yè)務(wù)需求，不是每種業(yè)務(wù)都需要高性能。

1、在類OLTP場(chǎng)景下，大數(shù)據(jù)平臺(tái)有像HBase一樣的組件，保證數(shù)據(jù)讀寫(xiě)具有極高的性能和吞吐量。

2、在OLAP場(chǎng)景下，大數(shù)據(jù)平臺(tái)有像Impala、Kudu、Kylin、Druid這樣引擎，通過(guò)內(nèi)存或預(yù)計(jì)算的方式保證查詢性能。

3、在離線分析場(chǎng)景，有像Hive、Spark、Mapreduce這樣的引擎，分布式處理海量數(shù)據(jù)，在這種場(chǎng)景下，性能和響應(yīng)時(shí)間已無(wú)法做到保證。

1、大數(shù)據(jù)的底層全部都是分布式架構(gòu)，分布式架構(gòu)具有很強(qiáng)的橫向擴(kuò)展能力，而且是使用廉價(jià)的PC服務(wù)器即可組件分布式架構(gòu)，只有增加服務(wù)器數(shù)據(jù)，性能也可以橫向擴(kuò)展，

2、另外大數(shù)據(jù)平臺(tái)在數(shù)據(jù)處理方面也均是采用分布式處理技術(shù)(例如 MR、 Hive、 Hbase 、 HDFS)

3、另外還有一些是基于內(nèi)存的數(shù)據(jù)計(jì)算和處理架構(gòu)Spark技術(shù)，大數(shù)據(jù)平臺(tái)下對(duì)性能的要求沒(méi)有和傳統(tǒng)的交互式的響應(yīng)不太一樣，大數(shù)據(jù)分為實(shí)時(shí)和離線計(jì)算，實(shí)時(shí)計(jì)算要求響應(yīng)時(shí)間，離線計(jì)算對(duì)于響應(yīng)時(shí)間沒(méi)有太高的要求。

七、數(shù)據(jù)預(yù)處理問(wèn)題?

鋼鐵行業(yè)的數(shù)據(jù)比較復(fù)雜，對(duì)于對(duì)生產(chǎn)工藝不是特別了解的IT人員如何進(jìn)行數(shù)據(jù)處理，或是應(yīng)該由誰(shuí)來(lái)進(jìn)行數(shù)據(jù)處理?

數(shù)據(jù)預(yù)處理的過(guò)程包括數(shù)據(jù)的清洗、集成、整合、標(biāo)準(zhǔn)化等過(guò)程。

1、數(shù)據(jù)預(yù)處理的過(guò)程是由承建大數(shù)據(jù)項(xiàng)目的供應(yīng)商來(lái)處理，或是專門(mén)做數(shù)據(jù)治理的公司來(lái)負(fù)責(zé)這項(xiàng)工作。

2、大數(shù)據(jù)項(xiàng)目中，數(shù)據(jù)的預(yù)處理會(huì)花費(fèi)大量的時(shí)間，而且是手工工作量較多，如果對(duì)業(yè)務(wù)部太數(shù)據(jù)，勢(shì)必會(huì)有很多問(wèn)題，最好是由對(duì)業(yè)務(wù)相對(duì)了解的人員來(lái)參與數(shù)據(jù)的預(yù)處理的工作。

只有高質(zhì)量的數(shù)據(jù)才會(huì)有分析的價(jià)值，所以預(yù)處理過(guò)程顯得尤為重要。數(shù)據(jù)是業(yè)務(wù)的數(shù)字化形式，對(duì)于比較復(fù)雜的行業(yè)數(shù)據(jù)，技術(shù)人員是不會(huì)知道怎么處理才能滿足業(yè)務(wù)分析的需求的，必須要業(yè)務(wù)分析人員提出具體的數(shù)據(jù)處理需求，技術(shù)人員才能設(shè)計(jì)滿足相應(yīng)需求。

八、從傳統(tǒng)數(shù)倉(cāng)向大數(shù)據(jù)平臺(tái)遷移的規(guī)劃?

傳統(tǒng)數(shù)倉(cāng)很多用oracle做的，現(xiàn)在想轉(zhuǎn)入大數(shù)據(jù)平臺(tái)，有什么好的遷移規(guī)劃方案，以及遷移可能遇到的問(wèn)題，謝謝!

1、數(shù)據(jù)倉(cāng)庫(kù)無(wú)論是用oracle，還是其他數(shù)據(jù)庫(kù)，此類型的數(shù)據(jù)轉(zhuǎn)入大數(shù)據(jù)平臺(tái)都有個(gè)ETL的過(guò)程，將數(shù)據(jù)統(tǒng)一存放在HDFS分布式文件系統(tǒng)中，上層則借助于Hive構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)，用于離線數(shù)據(jù)跑批計(jì)算，Hbase，用于支持?jǐn)?shù)據(jù)高并發(fā)在線查詢和非結(jié)構(gòu)化數(shù)據(jù)的對(duì)象存儲(chǔ)來(lái)滿足前段的應(yīng)用分析需求

2、可以利用數(shù)據(jù)倉(cāng)庫(kù)中原有的數(shù)據(jù)共享交換平臺(tái)，實(shí)時(shí)將數(shù)據(jù)推送到共享平臺(tái)，例如Sqoop數(shù)據(jù)導(dǎo)入結(jié)構(gòu)化數(shù)據(jù)，利用Flume和Kafka對(duì)非結(jié)構(gòu)化類數(shù)據(jù)進(jìn)行采集并將之轉(zhuǎn)為結(jié)構(gòu)化數(shù)據(jù)落地HDFS進(jìn)行存儲(chǔ)

九、傳統(tǒng)數(shù)倉(cāng)轉(zhuǎn)向大數(shù)據(jù)平臺(tái)的必要性?

如題，或者什么場(chǎng)景的的傳統(tǒng)數(shù)倉(cāng)適合轉(zhuǎn)向大數(shù)據(jù)平臺(tái)。轉(zhuǎn)向大數(shù)據(jù)平臺(tái)后都解決了什么樣的問(wèn)題，暴露出什么樣的問(wèn)題?

大數(shù)據(jù)平臺(tái)采用分布式架構(gòu)，用于解決海量數(shù)據(jù)的存儲(chǔ)和分析問(wèn)題，傳統(tǒng)數(shù)倉(cāng)無(wú)法解決上百TB及PB級(jí)的分析問(wèn)題。大數(shù)據(jù)平臺(tái)由于架構(gòu)新，使用模式也不盡相同，有的使用SQL，有的使用spark編程，有的使用mapreduce編程，所以存在一定的學(xué)習(xí)成本;大數(shù)據(jù)平臺(tái)還在逐步完善中，尤其是用戶管理、安全、元數(shù)據(jù)管理等方面還存在一定問(wèn)題，使用時(shí)需要注意。

十、大數(shù)據(jù)底層保持?jǐn)?shù)據(jù)強(qiáng)一致性是如何實(shí)現(xiàn)的?

大數(shù)據(jù)底層的數(shù)據(jù)強(qiáng)一致性是通過(guò)HDFS的分布式架構(gòu)中的冗余副本策略和心跳檢測(cè)機(jī)制實(shí)現(xiàn)的。

1、冗余副本策略：HDFS處理節(jié)點(diǎn)失效的一個(gè)方法就是數(shù)據(jù)冗余，即對(duì)數(shù)據(jù)做多個(gè)備份，在HDFS中可以通過(guò)配置文件設(shè)置備份的數(shù)量,默認(rèn)是3副本，只有數(shù)據(jù)在3個(gè)副本上均完成寫(xiě)成功，才返回。

2、心跳機(jī)制：檢測(cè)節(jié)點(diǎn)失效使用“心跳機(jī)制”。每個(gè) Datanode 節(jié)點(diǎn)周期性地向 Namenode 發(fā)送心跳信號(hào)。 Namenode 通過(guò)心跳信號(hào)的缺失來(lái)檢測(cè)這一情況，并將這些近期不再發(fā)送心跳信號(hào) Datanode 標(biāo)記為宕機(jī)，不會(huì)再將新的 IO 請(qǐng)求發(fā)給它們。

N： 3 (數(shù)據(jù)備份的數(shù)目)

W： 1 (數(shù)據(jù)寫(xiě)入幾個(gè)節(jié)點(diǎn)返回成功)，默認(rèn)是1

R： 1 (讀取數(shù)據(jù)的時(shí)候需要讀取的節(jié)點(diǎn)數(shù))

W + R < N

Hadoop沒(méi)有辦法保證所有數(shù)據(jù)的強(qiáng)一致性，但是通過(guò)副本機(jī)制保證一定程度的一致性，如果某一個(gè)datanode宕機(jī)，將會(huì)在其他datanode上重建一個(gè)副本，從而達(dá)到副本一致性的目的，且在寫(xiě)入的時(shí)候可以采用一次寫(xiě)入多個(gè)副本的方式保證即使某個(gè)副本對(duì)應(yīng)機(jī)器掛掉，也不影響整個(gè)數(shù)據(jù)。

十一、大數(shù)據(jù)平臺(tái)加入到災(zāi)備怎么做?有成熟的思路或者方案嗎?

1、災(zāi)備解決的是業(yè)務(wù)連續(xù)性的問(wèn)題，大數(shù)據(jù)平臺(tái)本身提供多副本機(jī)制是保障業(yè)務(wù)的穩(wěn)定和可靠運(yùn)行的

2、目前大數(shù)據(jù)平臺(tái)基本是都是部署在虛擬機(jī)或是容器之上，很少有直接部署在物理服務(wù)器+存儲(chǔ)架構(gòu)之上

3、這樣虛擬化和容器本身就帶來(lái)很強(qiáng)的業(yè)務(wù)連續(xù)性的功能，例如虛擬機(jī)的熱遷移、HA、DRS等功能

十二、大數(shù)據(jù)底層平臺(tái)對(duì)硬件的要求有哪些?

1、在企業(yè)內(nèi)部，最好保證集群中所有機(jī)器的配置保持一直，否則容易出現(xiàn)一臺(tái)機(jī)器運(yùn)行較慢，從而拖慢整體任務(wù)運(yùn)行速度的情況。

2、大數(shù)據(jù)平臺(tái)對(duì)網(wǎng)絡(luò)要求較高，在幾十臺(tái)機(jī)器的集群下，如果采用千兆網(wǎng)絡(luò)，極其容易出現(xiàn)某一個(gè)大任務(wù)把帶寬占滿的情況。

3、平臺(tái)對(duì)CPU、硬盤(pán)的需求相對(duì)網(wǎng)絡(luò)要低點(diǎn)，但也不能太低，否則IO上不來(lái)，任務(wù)也會(huì)被拖慢。

4、平臺(tái)對(duì)內(nèi)存的要求高，尤其在一個(gè)平臺(tái)內(nèi)搭建Impala、Spark、MR、Hive、HBase等組件共享資源的情況下，更應(yīng)該配備高內(nèi)存。

支持樓上，X86分布式部署即可。尤其注意系統(tǒng)IO性能，可配置SSD。

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

1、Hadoop現(xiàn)在已經(jīng)是大數(shù)據(jù)的事實(shí)標(biāo)準(zhǔn)，而 Hadoop的出現(xiàn)就是運(yùn)行在廉價(jià)商用服務(wù)器上，以集群之力，分而治之地解決先前傳統(tǒng)數(shù)據(jù)庫(kù)、傳統(tǒng)存儲(chǔ)、傳統(tǒng)計(jì)算模型束手無(wú)策的問(wèn)題，讓大規(guī)模數(shù)據(jù)的處理成為了可能。

2、對(duì)于硬件沒(méi)有太高的要求，普通的PC服務(wù)器即可，但是為了高更的性能，服務(wù)器內(nèi)可以增加SSD固態(tài)硬盤(pán)或是內(nèi)容等資源。

十三、大數(shù)據(jù)人才培養(yǎng)?

向大數(shù)據(jù)平臺(tái)轉(zhuǎn)型成功的關(guān)鍵，人才占了很大的比例，如何有效平滑的推動(dòng)人才隊(duì)伍的建設(shè)?

大數(shù)據(jù)涉及數(shù)據(jù)采集、數(shù)據(jù)的清洗集成、治理、大數(shù)據(jù)平臺(tái)的安裝調(diào)試和運(yùn)維、大數(shù)據(jù)的開(kāi)發(fā)、大數(shù)據(jù)的算法工程師、大數(shù)據(jù)的挖掘工程師等。

大數(shù)據(jù)人才需求是一種金字塔架構(gòu)，最底層需求量最大的是數(shù)據(jù)采集、清洗和治理的人員(基本上以人工為主)，在上層就是數(shù)據(jù)平臺(tái)的安裝調(diào)試(必須有l(wèi)inux基礎(chǔ))，往上就是大數(shù)據(jù)的開(kāi)放、算法和挖掘工程師了。

如果是用戶單位，需要提前培養(yǎng)大數(shù)據(jù)的意識(shí)，要認(rèn)識(shí)到大數(shù)據(jù)的重要性和可行性，培養(yǎng)可以為項(xiàng)目后期提供運(yùn)維的人員為主。

十四、用戶畫(huà)像用到了哪些大數(shù)據(jù)技術(shù)和工具，做的時(shí)候應(yīng)該注意什么?

所謂用戶畫(huà)像就是用多維度的數(shù)據(jù)來(lái)描述一個(gè)用戶的整體特征，涉及到特征工程的提取，打標(biāo)簽的過(guò)程。

例如用戶的屬性、偏好、生活習(xí)慣、行為、運(yùn)動(dòng)、作息等信息，抽象出來(lái)的標(biāo)簽化用戶模型。通俗來(lái)講就是給用戶打標(biāo)簽，而標(biāo)簽是通過(guò)對(duì)用戶信息分析而來(lái)的高度精煉的特征標(biāo)識(shí)。

涉及到數(shù)據(jù)采集、數(shù)據(jù)建模、挖掘分析等，需要注意一下幾點(diǎn)：

1、在畫(huà)像創(chuàng)建之前需要知道用戶關(guān)心的的特征維度和用戶的行為等因素，從而從總體上掌握對(duì)用戶需求需求。

2、創(chuàng)建用戶畫(huà)像不是抽離出典型進(jìn)行單獨(dú)標(biāo)簽化的過(guò)程，而是要融合邊緣環(huán)境的相關(guān)信息來(lái)進(jìn)行討論。

3、用戶畫(huà)像有時(shí)候需要變化、分為短期內(nèi)的畫(huà)像、或是長(zhǎng)期的畫(huà)像等。

十五、一般一個(gè)大數(shù)據(jù)項(xiàng)目實(shí)施過(guò)程中應(yīng)該注意什么?

這個(gè)過(guò)程與一般的項(xiàng)目沒(méi)有本質(zhì)區(qū)別，基本的需求、分析、設(shè)計(jì)、開(kāi)發(fā)、測(cè)試都是要有的。不同的地方是大數(shù)據(jù)項(xiàng)目采用的技術(shù)不像傳統(tǒng)的基于數(shù)據(jù)庫(kù)的SQL開(kāi)發(fā)那么簡(jiǎn)單，對(duì)編程能力的要求較高，同時(shí)對(duì)遇到問(wèn)題的排查能力要求也較高，因?yàn)槭欠植际竭\(yùn)行，導(dǎo)致問(wèn)題排查變得非常復(fù)雜。

1、大數(shù)據(jù)項(xiàng)目實(shí)施過(guò)程中涉及到和客戶的眾多業(yè)務(wù)系統(tǒng)進(jìn)行對(duì)接的，也就是數(shù)據(jù)的采集，到數(shù)據(jù)的清洗、集成、標(biāo)準(zhǔn)、數(shù)據(jù)治理、數(shù)據(jù)的建模、挖掘分析和最后的可視化等過(guò)程。

2、在和業(yè)務(wù)系統(tǒng)對(duì)接的過(guò)程中需要注意的必須拿到業(yè)務(wù)系統(tǒng)的數(shù)據(jù)字典(如果沒(méi)有，拿到數(shù)據(jù)對(duì)數(shù)據(jù)的識(shí)別和分析非常困難)。

3、數(shù)據(jù)業(yè)務(wù)分析維度，需要項(xiàng)目經(jīng)理進(jìn)場(chǎng)需要客戶明確的需求后確定系統(tǒng)的范圍和邊界(否則需求和范圍不停的變，開(kāi)發(fā)周期遙遙無(wú)期)。

4、準(zhǔn)備好大數(shù)據(jù)平臺(tái)要求的底層環(huán)境和資源(CPU、內(nèi)存、硬盤(pán)、網(wǎng)絡(luò)等)，大數(shù)據(jù)項(xiàng)目對(duì)于這些資源的要求還是相對(duì)比較高的，例如硬盤(pán)容量，例如要分析日志類的數(shù)據(jù)或是流水?dāng)?shù)據(jù)。

十六、企業(yè)級(jí)大數(shù)據(jù)平臺(tái)如何選型?

現(xiàn)在，大數(shù)據(jù)平臺(tái)基本特指Hadoop平臺(tái)了，選型主要還是指Haoop管理平臺(tái)?，F(xiàn)在主流的廠商有cloudera和Hortonworks,國(guó)內(nèi)有華為的fusion insight和星環(huán)科技的產(chǎn)品。相對(duì)來(lái)說(shuō)，cloudera具有較大優(yōu)勢(shì)，市場(chǎng)占有率也較高，管理平臺(tái)非常實(shí)用，對(duì)與平臺(tái)管理人員來(lái)說(shuō)是不可多得的好幫手

Hadoop現(xiàn)在已經(jīng)是大數(shù)據(jù)的事實(shí)標(biāo)準(zhǔn)了，企業(yè)級(jí)大數(shù)據(jù)平臺(tái)建議選擇基于Hadoop開(kāi)源的生態(tài)，目前對(duì)于Hadoop開(kāi)源商業(yè)推廣最大的兩個(gè)場(chǎng)景及cloudera(CDH版本，適合于linux系統(tǒng)上運(yùn)行)和Hortonworks(HDP版本，支持運(yùn)行在windows系統(tǒng)上運(yùn)行)，目前是一家公司了，可以選擇其中一家產(chǎn)品即可

十七、大數(shù)據(jù)中的實(shí)時(shí)計(jì)算SPark和Storm優(yōu)缺點(diǎn)是什么?分別適合于哪些場(chǎng)景?

SparkStreaming和Strom都屬于實(shí)時(shí)計(jì)算框架，有點(diǎn)都是可以做到對(duì)數(shù)據(jù)的實(shí)時(shí)處理。SparkStreaming是基于Spark Core實(shí)現(xiàn)的，所以對(duì)數(shù)據(jù)的處理要形成RDD，暨要形成數(shù)據(jù)窗口，所以其處理過(guò)程可以稱之為微批處理，而storm是可以做到實(shí)時(shí)處理每一條數(shù)據(jù)的，所以相對(duì)來(lái)說(shuō)，實(shí)時(shí)性比sparkstreaming更高。所以storm更適合處理實(shí)時(shí)性要求極高的場(chǎng)景。

SPark體系中的 Spark Streaming嚴(yán)格意義上屬于批處理計(jì)算框架，準(zhǔn)實(shí)時(shí)，基于內(nèi)存的計(jì)算框架，性能可以達(dá)到秒級(jí)，大數(shù)據(jù)除了實(shí)時(shí)計(jì)算之外，還包括了離線批處理、交互式查詢等業(yè)務(wù)功能，而且實(shí)時(shí)計(jì)算中，可能還會(huì)牽扯到高延遲批處理、交互式查詢等功能，就應(yīng)該首選Spark生態(tài)，用Spark Core開(kāi)發(fā)離線批處理，用Spark SQL開(kāi)發(fā)交互式查詢，用Spark Streaming開(kāi)發(fā)實(shí)時(shí)計(jì)算，三者可以無(wú)縫整合，給系統(tǒng)提供非常高的可擴(kuò)展性。

Storm是純實(shí)時(shí)計(jì)算框架，來(lái)一條數(shù)據(jù)，處理一條數(shù)據(jù)，可以達(dá)到毫秒級(jí)，適合于要求可靠的事務(wù)機(jī)制和可靠性機(jī)制，即數(shù)據(jù)的處理完全精準(zhǔn)，一條也不能多，一條也不能少，也可以考慮使用Storm。

形象點(diǎn)比喻，SPark就好比商城的直梯，Storm就好比商場(chǎng)的扶梯。

總結(jié)

以上是生活随笔為你收集整理的大数据平台应用 17 个知识点汇总的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。