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

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

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

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... 

　　更多。。。  太多。。。

不要害怕今日的苦，你要相信明天，更苦！