2018年第21周-以我角度看大數據

以我角度看大數據

最近公司開啓了大數據項目，有幸的，我可以有個平臺學習和實踐大數據。研究和實驗了兩個月，雖然都是屬於我的研究，但仍是有所體會。在此分享給你們。既然要從個人角度說大數據，那我得說下個人背景，我寫Java已有不少不少年了，工做也快有6年了。專業是軟件工程，因此代碼經驗和功底仍是有一些的，能夠評一評所謂的大數據。因爲見識沒有廣大網友這麼廣大(有次看黑客帝國的影評，發現本身電影白看了)，因此個人評論可能稍微有點偏見，歡迎拍磚交流。

大數據由來

根據百度百科，大數據是在2008年提出的，到如今已經有10年了。
個人印象中，「大數據」概念好像是2014年到2015年火起來的。當時以爲大數據是一個很神祕的東西，就算是如今，在不懂大數據的人面前，依然能夠很神祕（懂大數據的你故做神祕是能夠忽悠到他們）。
以我不嚴謹地猜測大數據的由來，簡單的說就是MySQL趕上瓶頸了（哈哈，夠簡單直白吧）。世界上的IT公司，互聯網公司，並非各個都是谷歌。不少公司都是沒有自主研發創造能力的，這或許是沒有資金，沒有合適的生產關係，也或者是這社會過於浮躁（只有掙錢的就是好公司，也確實是，只不過別忘記「有趣」也很重要的）。因而不少公司都是隻是使用開源產品，做爲Java開發人員，估計無人不曉得Spring這些開源框架吧。這些開源框架已經被驗證過無數次，已是很成熟，因此對於初創公司來講，能節省大量的成本，不管是開發時間仍是人才成本（培訓機構批量生產）。因而我以爲在數據層面，普通公司的基本同一顏色都是MySQL等關係型數據庫，其便利性和可靠性等我就不展開說了，應該都知道。然而在時間這個天使或惡魔的驅使下，數據慢慢地累積，時間讓不管大小的公司（只要還活着的公司）都會趕上數據問題，MySQL等關係型數據庫的問題開始凸顯，準確來講是達到了其邊界。這時候，迫切須要一個可能處理大量數據的工具。因而開源框架Hadoop的承擔了這歷史責任。

MySQL等關係型數據庫的痛點

MySQL等關係型數據庫是屬於OLTP(On Line Transcation Processing)。也稱爲面向交易的處理過程，其基本特徵是前臺接收的用戶數據能夠當即傳送到計算中心進行處理，並在很短的時間內給出處理結果，是對用戶操做快速響應的方式之一。注重的響應，而不是高吞吐。用過MySQL都是指有insert、update、select和delete，其用了大量的硬盤隨機讀寫，這才讓數據原地更新。在這種機制下，想要高吞吐量，那勢必極大地加大響應時間。
可擴展性也是關係型數據庫的痛點，你們對於其擴展，基本也就是讀寫分離，分庫分表分區。每次數據庫擴展，有經歷的人，都是心有餘悸的。一是須要停機維護，二是須要時間好長，並且懼怕恢復不起來。簡單地說就是要熬夜加班。三是成本增加會非線性增加，擴展硬盤和CPU都是很花錢呢。

從MySQL等關係型數據庫的痛點思考

咱們發現其痛點能夠歸於兩類：一是硬盤的隨機讀，二是擴展性。
Hadoop基本上能夠很好的解決這兩個問題，一是引入線性讀寫的概念，這樣就重塑了update的概念，update不只僅包括讓數據原地更新，以追加的形式保存歷史記錄的狀態也是屬於update概念範疇。二是其使用的都是普通PC，因此須要將其連起來使用，因此天生就是具備擴展性。
雖然Hadoop可以很好的解決關係型數據庫的兩大痛點，它就能夠替代關係型數據庫。這裏就要引入吞吐量(Throughtput)和響應時間(RT)，可參考。
吞吐量是對單位時間內完成的工做量的量度。示例包括：

每分鐘的數據庫事務
每秒傳送的文件千字節數
每秒讀或寫的文件千字節數
每分鐘的 Web服務器命中數

響應時間是提交請求和返回該請求的響應之間使用的時間。示例包括：

數據庫查詢花費的時間
將字符回顯到終端上花費的時間
訪問 Web 頁面花費的時間

一般，在資源必定的狀況下，平均響應時間越長，系統吞吐量較大；平均響應時間越短，系統吞吐量越小。
因此在Hadoop處理全量數據的狀況下，目標就是高吞吐量，因此其響應速度可能就沒法和傳統的關係型數據庫媲美了。

大數據概念火的緣由

1.時勢
2.是其帶來的價值，可以全量的分析數據，讓全量分析成爲可能，從而延伸出人功能智能什麼的（我猜的）。若是你實踐一下大數據的全量分析，那感受，真的很爽。
3.Hadoop開源框架的出現，讓不懂寫代碼，或者說是沒有多少年寫代碼經驗或對計算機理論不熟悉的人，讓這些人按照其官網教程或本身拼接組件，從而很輕易的使用上大數據，並且方案還算很成熟，如離線方案：Flume->Kafka->Flume->HDFS->Hive。這方案能夠說基本不用本身寫代碼。（或許說得有點過，要成爲商業級產品，仍是須要些計算機理論和代碼的功底滴）

觀點總結

數量隨着時間的增加，數據量以達到傳統關係型數據庫的邊界。其關鍵邊界，一是硬盤的隨機度，二是擴展性。而Hadoop以線性讀寫和高擴展性解決這兩個痛點，成爲大數據的代名詞，但依然沒法代替傳統關係型數據庫。那是由於資源必定的狀況下，響應時間和吞吐量成反比（響應時間越長，系統吞吐量較大，響應時間越短，系統吞吐量越小）。一項技術誕生，每每需經歷，發明創造、優化和普及等三個階段。而Hadoop帶來普及，Hadoop也成爲大數據的代名詞。
以上觀點純屬我的觀點，算是屬於實驗結論，非邏輯推理。可能不嚴謹不全面。但我以爲適合用於入門鋪墊，下降人的心理門檻。