公司要開搞大資料了，針對大資料的一般姿勢做了個簡單調研。
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等。本文主要對...