讓我們一起走進(jìn)大數(shù)據(jù)開源項(xiàng)目--第2節(jié)

看了上一節(jié)，這節(jié)我們來講解一下：

數(shù)據(jù)可視化

在大數(shù)據(jù)的海洋中，如何更直觀對(duì)數(shù)據(jù)進(jìn)行探索和可視化也是目前最值得關(guān)注的方向，這類開源項(xiàng)目包括D3,Chart.js, Arbor, DC.js, Sigma.js, Zeppelin等，熟悉前端技術(shù)的攻城師可以分分鐘利用這些優(yōu)秀的library將大數(shù)據(jù)直接以圖表形式展示給人們。

================================================================================================

以下為個(gè)人評(píng)價(jià)：

1、當(dāng)前的數(shù)據(jù)倉庫產(chǎn)品，又發(fā)生了較大變化，kylin和durid的成熟，為OLAP提供了更好的解決方案，另外在數(shù)據(jù)分析中spark也愈發(fā)成熟

2、MADlib已經(jīng)成為apache的頂級(jí)項(xiàng)目，另外HAWQ也發(fā)布到了2.2.0.0，相信很快會(huì)成為頂級(jí)項(xiàng)目

3、GemFire是個(gè)不錯(cuò)的東東，抽空研究下，其版權(quán)屬于Pivotal(EMC與VMware/GE合資公司)，Redis的創(chuàng)始人Salvatore Sanfilippo 現(xiàn)在也供職于Pivotal。當(dāng)前主要應(yīng)用銀行、社保、12306等交易系統(tǒng)。

大數(shù)據(jù)開源框架

1. ElasticSearch

1.1 ElasticSearch的優(yōu)點(diǎn)：

高并發(fā)。實(shí)測(cè)es單機(jī)分配10g內(nèi)存單實(shí)例，寫入能力1200qps，60g內(nèi)存、12核CPU起3個(gè)實(shí)例預(yù)計(jì)可達(dá)到6000qps。
同機(jī)房單條數(shù)據(jù)寫入平均3ms（比mysql慢，mg不清楚）
容錯(cuò)能力比mg強(qiáng)。比如1主多從，主片掛了從片會(huì)自動(dòng)頂上
滿足大數(shù)據(jù)下實(shí)時(shí)讀寫需求，無需分庫（不存在庫的概念）。
易擴(kuò)展。實(shí)例間做下配置即可擴(kuò)展并發(fā)性和容積，自動(dòng)分配的寫入機(jī)制，無需操心傳統(tǒng)db中多主同步的詬病
支持較復(fù)雜的條件查詢，group by、排序都不是問題
具有一定的關(guān)系性，但不用擔(dān)心大字段的問題
1.2 ElasticSearch的缺點(diǎn)：

不支持事務(wù);
讀寫有一定延時(shí);
無權(quán)限管理.

2. Lucene

   Lucene 是一個(gè) JAVA 搜索類庫，它本身并不是一個(gè)完整的解決方案，需要額外的開發(fā)工作。

2.1 Lucene的優(yōu)點(diǎn)

   成熟的解決方案，有很多的成功案例。apache 頂級(jí)項(xiàng)目，正在持續(xù)快速的進(jìn)步。龐大而活躍的開發(fā)社區(qū)，大量的開發(fā)人員。它只是一個(gè)類庫，有足夠的定制和優(yōu)化空間：經(jīng)過簡(jiǎn)單定制，就可以滿足絕大部分常見的需求；經(jīng)過優(yōu)化，可以支持 10億+ 量級(jí)的搜索。

2.2 Lucene的缺點(diǎn)

   需要額外的開發(fā)工作。所有的擴(kuò)展，分布式，可靠性等都需要自己實(shí)現(xiàn)；非實(shí)時(shí)，從建索引到可以搜索中間有一個(gè)時(shí)間延遲，而當(dāng)前的“近實(shí)時(shí)”(Lucene Near Real Time search)搜索方案的可擴(kuò)展性有待進(jìn)一步完善。

3. Redis

3.1 Redis的優(yōu)點(diǎn)

讀寫性能優(yōu)異
支持?jǐn)?shù)據(jù)持久化，支持AOF和RDB兩種持久化方式
支持主從復(fù)制，主機(jī)會(huì)自動(dòng)將數(shù)據(jù)同步到從機(jī)，可以進(jìn)行讀寫分離。
數(shù)據(jù)結(jié)構(gòu)豐富：除了支持string類型的value外還支持string、hash、set、sortedset、list等數(shù)據(jù)結(jié)構(gòu)。
3.2 Redis的缺點(diǎn)

Redis不具備自動(dòng)容錯(cuò)和恢復(fù)功能，主機(jī)從機(jī)的宕機(jī)都會(huì)導(dǎo)致前端部分讀寫請(qǐng)求失敗，需要等待機(jī)器重啟或者手動(dòng)切換前端的IP才能恢復(fù)。
主機(jī)宕機(jī)，宕機(jī)前有部分?jǐn)?shù)據(jù)未能及時(shí)同步到從機(jī)，切換IP后還會(huì)引入數(shù)據(jù)不一致的問題，降低了系統(tǒng)的可用性。
Redis的主從復(fù)制采用全量復(fù)制，復(fù)制過程中主機(jī)會(huì)fork出一個(gè)子進(jìn)程對(duì)內(nèi)存做一份快照，并將子進(jìn)程的內(nèi)存快照保存為文件發(fā)送給從機(jī)，這一過程需要確保主機(jī)有足夠多的空余內(nèi)存。若快照文件較大，對(duì)集群的服務(wù)能力會(huì)產(chǎn)生較大的影響，而且復(fù)制過程是在從機(jī)新加入集群或者從機(jī)和主機(jī)網(wǎng)絡(luò)斷開重連時(shí)都會(huì)進(jìn)行，也就是網(wǎng)絡(luò)波動(dòng)都會(huì)造成主機(jī)和從機(jī)間的一次全量的數(shù)據(jù)復(fù)制，這對(duì)實(shí)際的系統(tǒng)運(yùn)營造成了不小的麻煩。
Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜。為避免這一問題，運(yùn)維人員在系統(tǒng)上線時(shí)必須確保有足夠的空間，這對(duì)資源造成了很大的浪費(fèi)。

4. HBase

4.1 HBase的優(yōu)點(diǎn)

列的可以動(dòng)態(tài)增加，并且列為空就不存儲(chǔ)數(shù)據(jù),節(jié)省存儲(chǔ)空間.

Hbase自動(dòng)切分?jǐn)?shù)據(jù)，使得數(shù)據(jù)存儲(chǔ)自動(dòng)具有水平scalability.

Hbase可以提供高并發(fā)讀寫操作的支持

4.2 HBase的缺點(diǎn)

不能支持條件查詢，只支持按照Row key來查詢。

暫時(shí)不能支持Master server的故障切換,當(dāng)Master宕機(jī)后,整個(gè)存儲(chǔ)系統(tǒng)就會(huì)掛掉。

5. Hadoop

5.1 Hadoop的優(yōu)點(diǎn)

Hadoop集群的擴(kuò)展性是其一大特點(diǎn)，Hadoop可以擴(kuò)展至數(shù)千個(gè)節(jié)點(diǎn)，對(duì)數(shù)據(jù)持續(xù)增長，數(shù)據(jù)量特別巨大的需求很合適。
Hadoop的成本是其另一大優(yōu)勢(shì)，由于Hadoop是開源項(xiàng)目，而且不僅從軟件上節(jié)約成本，硬件上的要求也不高。目前去IOE潮流風(fēng)行，低成本的Hadoop也是一大推手。
Hadoop生態(tài)群活躍，其周邊開源項(xiàng)目豐富，HBase, Hive，Impala等等基礎(chǔ)開源項(xiàng)目眾多。

6.5.2 Hadoop的缺點(diǎn)

全量場(chǎng)景，任務(wù)內(nèi)串行
重吞吐量，響應(yīng)時(shí)間完全沒有保證
中間結(jié)果不可見，不可分享
單輸入單輸出，鏈?zhǔn)嚼速M(fèi)嚴(yán)重
鏈?zhǔn)組R不能并行
粗粒度容錯(cuò)，可能會(huì)造成陷阱
圖計(jì)算不友好
迭代計(jì)算不友好
不能支持秒級(jí)計(jì)算，只適合做離線數(shù)據(jù)分析任務(wù)
這些只是本人的一些見解，如果有什么不對(duì)的隨時(shí)可以指出。
以后會(huì)更新一些其他的關(guān)于大數(shù)據(jù)的文章。

很多人都知道我有大數(shù)據(jù)培訓(xùn)資料，都天真的以為我有全套的大數(shù)據(jù)開發(fā)、hadoop、spark等視

頻學(xué)習(xí)資料。我想說你們是對(duì)的，我的確有大數(shù)據(jù)開發(fā)、hadoop、spark的全套視頻資料。
如果你對(duì)大數(shù)據(jù)開發(fā)感興趣可以加口群領(lǐng)取免費(fèi)學(xué)習(xí)資料： 763835121