大資料技術在當下時代，已經不算是什麼新鮮東西了。但絕大部分同學往往又是沒機會接觸大資料相關底層技術的，包括我自己。

不過，俗話說沒吃過豬肉還沒見過豬跑嗎？哈哈，今天就來說說我對大資料技術的思考吧，希望會給部分同學解開一些迷惑！

1.什麼是大資料？

我們不搞虛的：大資料就是資料量比較大的場景，比如上TB或者PB級別以上的，基本就要歸屬於大資料的範疇了。

所以，如果你用關係型資料庫處理以上級別的資料，做了很多最佳化，這又何嘗不是一種大資料處理技術呢？

所以，大資料只是一種場景而已。

2.大資料技術是什麼？

大資料技術就是處理超級大資料情況下使用到的一系列技術框架，手段。開源的或主流的方案目前就是hadoop生態技術，如mapreduce、spark、flink，儲存如hbase，hive，kylin，排程如yarn，oozie、azkaban，訊息中介軟體發中kafka；

為什麼有這麼多技術呢？實際上因為有這麼多的場景問題需要解決，而在大資料領域內，又沒辦法讓一個框架做完所有的事，所以就將這些場景進行了拆分，形成了各種獨立的技術。而已。

所以，大資料技術實際上是領域細分的結果。

3.為什麼會有大資料技術？

前面說了，大資料只是一個應用場景，只是當資料量超過一定量級之後的結果。它並沒有許多特別的業務訴求，所以理論上它的需求點不會多於業務前端。

那麼為什麼還必須要大資料技術？實際上是因為，資料量超過一定量級後，前端系統已經沒有辦法提供業務支援了，所以在這種場景下業務需求就沒辦法再往前端堆砌了。不是少堆砌，而是一點也不能了。這種情況持續了許多年，大家一直在保持資料儘量小的邊緣反覆試探，反覆刪庫跑路。

所以，有時候我們說，發現問題時就已離解決問題也不遠了，實際也不一定，你總有無能為力的時候。

所以，大資料雖只是一個場景，但大資料技術是必須的，因為只有它能處理這個場景。這就是宿命。

4.大資料技術的原理是什麼？

這個問題那是大得不能再大了，可以用無言以對來形容。

儘管如此，我還是想說兩句：大資料技術的核心原理是平行計算和分散式儲存。就問你大不大？哈哈。

我們可以用大白話翻譯一下：大資料技術的核心邏輯，第一：是使用了許多臺機器一起參與運算。從而使我們原來在一臺機器無法處理完成或需要幾天幾個月的時間才能完成的任務，被分攤到這多臺機器上，這是顯而易見的事情。第二：使用了多臺機器一起儲存資料，從而解決了原來一臺機器無法儲存的容量或要求超級計算機才能儲存的容量的問題。這也是顯而易見的，一臺機器儲存不了，那就兩臺，不行就再加。

以上，就是我認為的大資料技術的核心原理。而要達到上面兩個核心原理，又都必須有一個能力：任意橫向擴充套件；這些問題處理的複雜性，造就了大資料技術的龐大與複雜。

5.大資料系統構建的幾個核心問題？

很明顯，大資料技術解決問題的場景基本已定。如果能夠把這幾個問題解決好，那麼這就是一個好的技術系統。

但我還得重申幾個問題：

- 是否為前端提供服務？

- 資料來源是啥？

- 能夠對外輸出什麼？

- 目標使用者是誰？

- 核心功能是啥？

- 價效比如何？

上面幾個問題，有些是輕而易舉能就能問答的問題，比如：一般不會直接為前端提供服務，資料來源往往來自於各種各樣的儲存系統，訊息系統。但後面幾個問題比較難答了。如果這幾個問題想不清楚，那也許你的大資料據系統可能就是無謂地浪費而已。因為很明顯的，大資料系統的支出是不便宜的，平行計算和分散式儲存，至少需要的是大量頻寬和磁碟容量（而且可能要求SSD這種昂貴的盤），還有其他許多隱形支出。

6.大資料技術的幾個大變遷感受

讓整個大資料生態燃起希望的，是hadoop的出現，實際上，hadoop在出現之初就已經解決了兩大核心問題：平行計算與分散式儲存。它提供的hdfs分佈檔案檔案儲存系統，已經是不可憾動的基石（個人感覺，不一定準確）。而它提供的平行計算mapreduce，在出現之初也是非常牛逼的，但那是在沒得選的時候。可能是由於它用一套系統完成了所有的事，顯得統一的同時，恰好又顯得臃腫，於是又顯得不夠好。hadoop的出現是一個質的改變！

有了先驅者，後來者便蜂擁而上，不停地完善其中的不足，尤其是一眼就看到的分散式計算mr。而限制mr的一個重要原因則是基於磁碟的資料交換。

於是，spark出現了，它的核心或者初衷是解決了mr運算速度的問題，因為它是儘可能基於記憶體的資料交換，和磁碟速度相比自然有一個量級的提升。不要小看這一個量級，有的東西的前提就是基於這一個量級（比如超過一天就無效，而在幾小時內則是有效的）。而後又有了spark生態圈的繁榮昌盛，極大推動了大資料生態的發展。spark可以說也是一個質的改變。

但spark遇到了一個難以解決的問題，即它的架構是基於批處理的，批處理領域無可挑剔，挑剔的是人。人們要求大資料系統能夠實時反饋業務變化，於是spark尷尬了，於是storm出現了。（不瞭解）

flink找到了批處理與流處理的間隙，一把殺向市場，提出了批流合一，再加上各大廠商的鼎力相助，於是乎發展得如火如荼。但我只能給它打個中等分數，因為它只能算得量變而算不得質變。

花開兩朵，話分兩頭。在另一條線上，分散式儲存也發生了變化，如hive，pig，hbase，cassandra，presto，impala，sparksql，kylin, flinksql...

關於大資料技術的一點思考