公司要開搞大資料了,針對大資料的一般姿勢做了個簡單調研。
hbase:非關係型分布式資料庫,基於hdfs,高容錯、高吞吐。hbase採用的是key/value的儲存方式,即使隨著資料量增大,也幾乎不會導致查詢的效能下降。
flume:最主要的作用就是,實時讀取伺服器本地磁碟的資料,將資料寫入到hdfs/kafka/hbase。
sqoop:用來在rdbms和hadoop之間進行資料傳輸的工具就是我們所說的sqoop。在這裡,rdbms指的是mysql,oracle sql等,而hadoop指的是hive,hdfs和hbase等。 我們使用sqoop將資料從rdbms匯入hadoop,也可用於將資料從hadoop匯出到rdbms
高併發的基石。吞吐量遠遠領先於同類別的mq。
linkedin團隊做了個實驗研究,對比kafka與apache activemq v5.4和rabbitmq v2.4的效能
生產者消費者
4.1、演變史
4.2、mapreduce 到 hive 到 sparksql的演變
4.3、mapreduce 、 spark 、flink
mapreduce
spark
mapreduce:
mapreduce 模型的抽象層次低,大量的底層邏輯都需要開發者手工完成。
只提供 map 和 reduce 兩個操作。比如兩個資料集的 join 是很基本而且常用的功能,但是在 mapreduce 的世界中,需要對這兩個資料集做一次 map 和 reduce 才能得到結果。
在 hadoop 中,每乙個 job 的計算結果都會儲存在 hdfs 檔案儲存系統中,所以每一步計算都要進行硬碟的讀取和寫入,大大增加了系統的延遲。
spark:
spark 最基本的資料抽象叫作彈性分布式資料集(resilient distributed dataset, rdd),它代表乙個可以被分割槽(partition)的唯讀資料集,它內部可以有很多分割槽,每個分割槽又有大量的資料記錄(record)。
rdd 是 spark 最基本的資料結構。spark 定義了很多對 rdd 的操作。如 map、filter、flatmap、groupbykey 和 union 等等,極大地提公升了對各種複雜場景的支援。
相對於 hadoop 的 mapreduce 會將中間資料存放到硬碟中,spark 會把中間資料快取在記憶體中,從而減少了很多由於硬碟讀寫而導致的延遲,大大加快了處理速度。
flink
在 flink 中,程式天生是並行和分布式的。乙個 stream 可以包含多個分割槽(stream partitions),乙個操作符可以被分成多個操作符子任務,每乙個子任務是在不同的執行緒或者不同的機器節點中獨立執行的。
效能對比
可以看出,hadoop 做每一次迭代運算的時間基本相同,而 spark 除了第一次載入資料到記憶體以外,別的迭代時間基本可以忽略。
4.4、幾種處理引擎對比
api
類sql
效能容錯性
實時性批處理
流處理exactly once語義
社群活躍度
mapreduce
複雜沒有低低
低中不支援無
低hive簡單有
低高低中
不支援無
中spark簡單有
高高中高(秒級)高中
支援高flink簡單有
高高高(微妙級)中高
支援中beam
或者代表著未來。目前在谷歌內部使用、生態還沒發展起來。拭目以待
附1:在流處理系統中,我們對應資料記錄的處理,有3種級別的語義定義,以此來衡量這個流處理系統的能力。
at most once(最多一次)。每條資料記錄最多被處理一次,潛台詞也表明資料會有丟失(沒被處理掉)的可能。
at least once(最少一次)。每條資料記錄至少被處理一次。這個比上一點強的地方在於這裡至少保證資料不會丟,至少被處理過,唯一不足之處在於資料可能會被重複處理。
exactly once(恰好一次)。每條資料記錄正好被處理一次。沒有資料丟失,也沒有重複的資料處理。這一點是3個語義裡要求最高的。
4.5、使用場景
mapreduce:僅僅用來學習,理解大資料的原理。
hive:類sql引擎,適合做報表分析
spark: spark 存在的乙個缺點——無法高效應對低延遲的流處理場景入手。對於以下場景,你可以選擇 spark。
資料量非常大而且邏輯複雜的批資料處理,並且對計算效率有較高要求(比如用大資料分析來構建推薦系統進行個性化推薦、廣告定點投放等);
基於歷史資料的互動式查詢,要求響應較快;
基於實時資料流的資料處理,延遲性要求在在數百毫秒到數秒之間。
spark 完美滿足這些場景的需求, 而且它可以一站式解決這些問題,無需用別的資料處理平台。
flink:由於 flink 是為了提公升流處理而建立的平台,所以它適用於各種需要非常低延遲(微秒到毫秒級)的實時資料處理場景,比如實時日誌報表分析。
而且 flink 用流處理去模擬批處理的思想,比 spark 用批處理去模擬流處理的思想擴充套件性更好,所以我相信將來 flink 會發展的越來越好,
生態和社群各方面追上 spark。比如,阿里巴巴就基於 flink 構建了公司範圍內全平台使用的資料處理平台 blink,美團、餓了麼等公司也都接受 flink 作為資料處理解決方案。
可以說,spark 和 flink 都在某種程度上統一了批處理和流處理。
大資料Spark與Storm技術選型
先做乙個對比 對比點storm spark streaming 實時計算模型 純實時,來一條資料,處理一條資料 準實時,對乙個時間段內的資料收集起來,作為乙個rdd,再處理 實時計算延遲度 毫秒級秒級 吞吐量低 高事務機制 支援完善 支援,但不夠完善 健壯性 容錯性 zookeeper,acker,...
大資料技術 kafka和flume的對比
摘要 1 kafka和flume都是日誌系統。kafka是分布式訊息中介軟體,自帶儲存,提供push和pull訪問資料功能。flume分為agent 資料採集器 collector 資料簡單處理和寫入 storage 儲存器 三部分,每一部分都是可以定製的。比如agent採用 rpc thrift ...
遠端呼叫選型對比
一般來說服務間遠端呼叫有兩種方式,http和rpc。http主要包括httpclient okhttp resttemplate feign 對resttemplate封裝可整合ribbon做負載均衡 等 rpc主要包括dubbo grpc brpc motan rpcx thrift等。本文主要對...