學(xué)習(xí)，是一個循序，漸進(jìn)的過程。很意外我能接觸到如此有高度的大數(shù)據(jù)教程，也很意外我終于親自接觸到了如此優(yōu)秀的軟件工程師。
1、引子
我已經(jīng)記不太清我是從哪里得到李智慧老師在極客時間上的這門課程的信息的了。反正我平時是幾乎不上這個網(wǎng)站去找學(xué)習(xí)資料的，但現(xiàn)在，這個網(wǎng)站將是我未來很長一段時間里的知識寶庫！李智慧老師開設(shè)的這門《從零開始學(xué)大數(shù)據(jù)》刷新了我的認(rèn)知，包括技術(shù)上的、學(xué)習(xí)上的、職業(yè)規(guī)劃上的甚至有些是人生價值上的?；艘恢軙r間粗略地學(xué)習(xí)了一下這套教材，現(xiàn)簡單做個總結(jié)。
1.1、為什么要學(xué)習(xí)大數(shù)據(jù)技術(shù)
大數(shù)據(jù)技術(shù)說白了就是用于大量數(shù)據(jù)場景下的一種數(shù)據(jù)處理或分析的工具或手段。
計算機的出現(xiàn)在本質(zhì)上是將人類現(xiàn)實世界中的業(yè)務(wù)操作轉(zhuǎn)移到另一種場景來處理，利用計算機快速的計算性能以及便捷的網(wǎng)絡(luò)通信特性來提升我們處理業(yè)務(wù)的效率。但，時至今日，單臺計算機的性能提升已經(jīng)越來越困難了，并且提升單機性能所花費的成本也越來越大。而大數(shù)據(jù)技術(shù)在本質(zhì)上是協(xié)調(diào)多臺計算機的性能來處理一個需求，就是分布式計算模式。俗話說：三個臭皮匠，賽個諸葛亮。分布式是人類進(jìn)一步提升計算機性能的最佳手段。在計算機性能的提升之路上，縱向發(fā)展雖然受阻，橫向發(fā)展卻方興未艾。
數(shù)據(jù)中所蘊含著的價值是巨大的，甚至數(shù)據(jù)于某些企業(yè)就是護城河一般的存在。隨著時間的推移，各大企業(yè)所積累的數(shù)據(jù)規(guī)模也愈發(fā)龐大。隨之而來的各種大數(shù)據(jù)處理技術(shù)也越來越成熟。由大數(shù)據(jù)處理技術(shù)衍生的各種智能推薦、數(shù)據(jù)挖掘甚至是人工智能技術(shù)等都備受矚目。在未來，大數(shù)據(jù)編程技術(shù)將會越來越簡單，軟件工程師只需要花很少的時間在編寫代碼與調(diào)試上，剩余的精力將會花費在設(shè)計架構(gòu)以及梳理業(yè)務(wù)上。甚至于在未來相關(guān)行業(yè)的非軟件開發(fā)人員都需要懂點大數(shù)據(jù)編程技術(shù)，因為它是如此的易上手。如今的大數(shù)據(jù)技術(shù)已經(jīng)相當(dāng)成熟了，而大數(shù)據(jù)技術(shù)的應(yīng)用場景卻仍處于起步階段。未來將會有越來越多的行業(yè)搭上大數(shù)據(jù)技術(shù)的快車。毫無疑問下一個互聯(lián)網(wǎng)主題就是大數(shù)據(jù)。
1.2、大數(shù)據(jù)技術(shù)的前世今生
大數(shù)據(jù)技術(shù)公認(rèn)的開山始祖是 Google 在十幾年前先后發(fā)表的三篇論文
- 分布式文件系統(tǒng) GFS
- 大數(shù)據(jù)分布式計算框架 MapReduce
- NoSQL 數(shù)據(jù)庫系統(tǒng) BigTable
這三篇論文說白了就一個是文件系統(tǒng)，一個是計算引擎，還有一個是數(shù)據(jù)庫。這三套系統(tǒng)合并起來正好可以構(gòu)建一個完整的大數(shù)據(jù)技術(shù)生態(tài)。
當(dāng)年 Google 在發(fā)表這三篇論文時，其內(nèi)部就已經(jīng)在應(yīng)用著他們論文中論述的軟件框架了，但遺憾的是這三套 Google 自研的軟件是閉源的。但很快，對應(yīng)著這三篇論文的開源軟件框架就發(fā)布了。GFS 對應(yīng)的開源框架是 Hadoop ，Google MapReduce 對應(yīng)的開源框架是 Hadoop MapReduce ，BigTable 對應(yīng)的開源框架是 HBase。
這三套開源框架問世的時間并不一致，并且老實說，這三套框架的問世并沒有立即讓業(yè)界 “陷入瘋狂”，對于 Hadoop 的 HDFS 和 HBase 還好，就是這個 MapReduce 并不是很方便。不過也正是因為 MapReduce 的這個不足，才導(dǎo)致后續(xù)衍生出一系列簡化其編程模型的框架出來，諸如 Pig、Impala、Hive、YARN 等。其實大數(shù)據(jù)技術(shù)軟件框架之間 “爭奪天下” 的歷史還是挺復(fù)雜的，很不幸我們錯過了這個早期階段，同時又很幸運，我們剛好錯開了這段混沌歷史時期。
百度和阿里早在 2007 年的時候就用上了 Hadoop 了。有的時候你不得不承認(rèn)，大公司就是大公司，不僅技術(shù)一流，思想還很開放包容與前衛(wèi)。
在 2012 年的時候，也有一個大數(shù)據(jù)計算引擎逐漸進(jìn)入到人們的視野 -- Spark。Spark 與 MapReduce 的功能是一樣的，所不同的是，它充分發(fā)揮了計算機內(nèi)存的特性，相較于對硬盤依賴程度很高的 MapReduce ，同樣繁重的計算任務(wù)，Spark 的速度要遠(yuǎn)高于 MapReduce 。于是，Spark 很快就成為了大數(shù)據(jù)界的 “網(wǎng)紅”，并在很多場景下替代了 MapReduce 。但替代并不代表著取代，只是二者各有應(yīng)用場景而已。既是是現(xiàn)如今 MapReduce 在大數(shù)據(jù)計算領(lǐng)域也還發(fā)揮著至關(guān)重要的作用。
MapReduce、Spark 這類計算引擎主要用于處理離線數(shù)據(jù)，被稱為 “批處理”。而與之相對的又有專門處理實時數(shù)據(jù)的計算引擎，這類計算引擎被稱為 “流處理”。目前的代表計算引擎有 Spark Streaming、Storm、Flink。就目前而言，Storm 已經(jīng)逐漸被淘汰了。Flink 正變的越來越重要。
目前而言，我們所討論的大數(shù)據(jù)技術(shù)主要有以下三個應(yīng)用場景
- 數(shù)據(jù)分析
- 數(shù)據(jù)挖掘
- 機器學(xué)習(xí)
數(shù)據(jù)分析門檻較低，需要掌握 SQL、數(shù)倉建模等知識。數(shù)據(jù)挖掘?qū)?shù)學(xué)與算法要求較高。機器學(xué)習(xí)這塊我了解的很少，但它是人工智能的基礎(chǔ)。
2、技術(shù)篇
2.1、Hadoop
Hadoop 可以細(xì)分為 HDFS 和 MapReduce 兩套框架。其中 HDFS 專門負(fù)責(zé)存儲文件，它就是一個分布式版的文件系統(tǒng)。Google 在 2004 年的時候發(fā)布了大數(shù)據(jù)分布式存儲 GFS 論文，Hadoop 于 2006 年推出，歷經(jīng) 13 年，HDFS 憑借著它的特性仍然能夠穩(wěn)坐大數(shù)據(jù)存儲技術(shù)的交椅。
HDFS 是一個可靠的、可擴展的、容錯的分布式文件系統(tǒng)，它的全稱是 Hadoop distributed file system。HDFS 的模式是串聯(lián)多臺計算機的內(nèi)存、磁盤與 CPU 資源。對于終端用戶而言，它就是一臺計算機，不管你背后的集群規(guī)模有多么龐大。
2.1.1、HDFS 如何保證可靠性？
可靠性就是 HDFS 可以確保存儲在其中的文件不會丟失。同時，個人還認(rèn)為系統(tǒng)的高可用性也要算在可靠性的范疇以內(nèi)。什么是高可用性呢？就是 HDFS 的能讓終端用戶在任意時刻都能獲取到 HDFS 的正常服務(wù)的能力。
首先，HDFS 確保文件不丟失的機制很簡單，就是 “分布式存儲”。
HDFS 允許你設(shè)定一個 “副本因子”，副本因子就是同一個文件在這個集群中要保存多少份。默認(rèn)是 3 份。HDFS 分布式存儲文件也是有規(guī)則的。一份副本會被保存在寫入數(shù)據(jù)的那臺機器上，另一份副本會被保存在本機架內(nèi)的另一臺機器上，最后一份副本則保存在另一個機架的任意一臺機器上。
關(guān)于第一份副本會被保存在寫入數(shù)據(jù)的那臺機器上，這是什么意思呢？這是在我們的 HDFS 上，終端用戶可以連接任意一臺數(shù)據(jù)節(jié)點來讀寫數(shù)據(jù)，所以我們要存儲一個文件時，連接的是哪一臺數(shù)據(jù)節(jié)點，那就在哪個數(shù)據(jù)節(jié)點中存儲一份副本，畢竟本地存儲的成本是最低廉的。那第二、第三份副本存儲時提到的機架是什么呢？在分布式集群中，每臺計算機都被稱為是一個 “節(jié)點”。當(dāng)節(jié)點數(shù)量較多時，為了防止網(wǎng)絡(luò)服務(wù)中斷導(dǎo)致的 HDFS 服務(wù)中斷，通常會將這些節(jié)點劃分為不同的機架，簡單說，就是一批電腦接這個路由器，另一批電腦接那個路由器。當(dāng)然在生產(chǎn)環(huán)境中，這個 “不同的路由器” 一般是指不同的網(wǎng)絡(luò)服務(wù)提供商。
HDFS 分布式存儲文件副本的形式能夠極大地保證存儲在其上的文件不會丟失。畢竟同一個文件我有多個備份，一臺機器宕機了，我還可以從另一臺機器上得到這個文件完整備份。但這種副本機制所帶來的代價也是巨大的，這份代價主要就體現(xiàn)在磁盤空間與網(wǎng)絡(luò) IO 上，不過對于數(shù)據(jù)的可靠性而言，這種代價也顯得不是那么重要了。
其次，HDFS 確保高可用的方式是將管理節(jié)點設(shè)置為 “雙機熱備” 模式。雙機熱備是指同時運行兩臺計算機來扮演同一種功能的節(jié)點，但在集群中同一時刻只能有一個節(jié)點提供服務(wù)，另一臺節(jié)點以備份節(jié)點的形式實時同步主節(jié)點中的數(shù)據(jù)。當(dāng)主節(jié)點宕機時，能夠迅速接替工作對外提供服務(wù)，從而保證集群的服務(wù)不至于中斷。在 HDFS 中，這個 “工作接替” 的過程是很短暫的，通常在數(shù)秒至數(shù)分鐘的時間里就能完成。
2.1.2、HDFS 如何實現(xiàn)可擴展性？
HDFS 的擴展性指的是我們可以在不停服的情況下給我們的集群新增、刪減節(jié)點的特性。
這種特性可牛 X 了，當(dāng)市場上出現(xiàn)更強更廉價的設(shè)備以后，我們可以通過這種擴展性，逐步為我們的集群換上新硬件，退下老舊設(shè)備來，這一過程對用終端用戶來說是完全 “無感” 的。這種特性可以讓我們的集群 “永葆青春”。
HDFS 在配置文件中有兩種配置項：白名單與黑名單。通過將對應(yīng)節(jié)點的機器名稱添加到這兩份名單中，就可以達(dá)到 “優(yōu)雅地” 服、退役節(jié)點目的。新節(jié)點服役時，集群會做一個 “負(fù)載均衡” 操作以保證集群整體性能被均衡發(fā)揮。
2.1.3、HDFS 如何保證容錯性？
硬件設(shè)備總是會老化的，沒有任何一個存儲介質(zhì)敢聲稱自己所保存的數(shù)據(jù)不會出現(xiàn)差錯。HDFS 實現(xiàn)容錯性的方式是通過校驗機制與其副本機制。
文件在首次存入 DataNode 時會計算出校驗和（checksum）一并存儲。在有客戶端讀取數(shù)據(jù)時，讀取完成后會再次計算校驗和，并與已存儲起來的校驗和作對比，當(dāng)結(jié)果不一致時，則認(rèn)為該數(shù)據(jù)塊已損壞。這時，會從其它節(jié)點中嘗試讀取這份數(shù)據(jù)，直到讀到正確的數(shù)據(jù)為止。
2.1.4、HDFS 的系統(tǒng)架構(gòu)
HDFS 的系統(tǒng)架構(gòu)中主要有兩種角色
- NameNode
- DataNode
NameNode
很多教材將 NameNode 直譯為 “名稱節(jié)點”。雖然這種翻譯各種沒毛病，但我就是不怎么喜歡，我更喜歡稱它為 “管理節(jié)點”。
既然 HDFS 是一個文件系統(tǒng)，那么它就必然涉及到要管理每一個文件的 “名稱與路徑” 以及 “實際數(shù)據(jù)塊”，當(dāng)然還有最重要的 “每個文件名與其對應(yīng)數(shù)據(jù)塊的映射關(guān)系”。NameNode 負(fù)責(zé)除了 “實際數(shù)據(jù)塊” 以外的所有數(shù)據(jù)的管理工作。
DataNode
毫無疑問 DataNode 就是負(fù)責(zé)管理 “實際數(shù)據(jù)塊” 的咯。
?
在 HDFS 中，NameNode 只有少數(shù)幾臺，通常的生產(chǎn)環(huán)境中會有兩臺 NameNode 以構(gòu)建一個高可用的 HDFS 集群服務(wù)。Hadoop 目前還提供了一種被稱為 “HDFS 聯(lián)邦” 的機制，允許在一個集群中有多個 NameNode 的存在，不過這種場景不在本篇文章的討論范圍之內(nèi)。DataNode 的數(shù)量通常都很多。
在 HDFS 集群中，NameNode 是至關(guān)重要的，只有 NameNode 知道我們的集群中有哪些文件，以及這些文件分別保存在哪臺機器的哪個硬盤地址上，這也是我更喜歡將 NameNode 翻譯成管理節(jié)點的重要因素。
2.1.5、MapReduce
MapReduce 既是編程模型又是計算框架。
說 MapReduce 是編程模型，是因為它的核心思想是將數(shù)據(jù)的處理拆分為 map 階段和 reduce 階段。map 階段可以簡單理解為將數(shù)據(jù)從外部文件或流中讀取進(jìn)來，并將它們處理成 Key-Value 對的形式以作進(jìn)一步處理。reduce 階段可以簡單翻譯成 “歸并” 處理，但其實，歸不歸并，還得看你怎么編寫的程序，我們甚至可以取消 reduce 階段只執(zhí)行 map 階段。
從編程的角度看，MapReduce 就是一套 “編程協(xié)議”，只要我們遵循這套協(xié)議，就能從頭到尾一條龍的客制化我們的大數(shù)據(jù)處理程序。因此，我們說 MapReduce 是一種編程模型。
說 MapReduce 是計算框架，是因為它不僅能編寫大數(shù)據(jù)處理模型程序。還能運行我們寫好的程序。我們在寫好程序以后，將它編譯打包，然后再通過命令提交到 MapReduce 中去就可以執(zhí)行了。所以我們也說 MapReduce 是一種計算框架。
總得來說，MapReduce 是一種既簡單又強大的框架。說它簡單，是因為任何計算需求在它這里只有 map 和 reduce 兩個階段，甚至有些作業(yè)僅有一個 map 階段。說它強大，是因為它幾乎可以實現(xiàn)大數(shù)據(jù)領(lǐng)域所有的計算需求。
2.2、Hive
MapReduce 的功能雖然強大，但是它的開發(fā)過程確實是有點繁瑣了。當(dāng)年在 Hadoop 剛發(fā)布的時候，多數(shù)互聯(lián)網(wǎng)企業(yè)的大數(shù)據(jù)處理需求都是用于數(shù)據(jù)分析。而分析師們都對 SQL 很熟，但卻鮮有也熟悉 Java 開發(fā)的。為了解決這個問題，F(xiàn)acebook 推出了 Hive。Hive 支持使用一種類 SQL 的語言來開發(fā) MapReduce 程序，這種語言被稱為 Hive QL，簡稱 HQL。
HQL 與 SQL 大體上來說是一樣的，只是有部分的 SQL 語法在 HQL 上沒有而已，但總體來說，影響不大，畢竟 Hive 一經(jīng)推薦，就迅速得到追捧。
Hive 的工作模式就是將 HDFS 上的數(shù)據(jù)以特定的數(shù)據(jù)庫表的形式映射在 Hive 上，然后通過 SQL 語句操作這些數(shù)據(jù)表，Hive 的 HQL 解析引擎會將這些 HQL 語句自動轉(zhuǎn)化成 MapReduce 作業(yè)并提交給 MapReduce 運行。說白了就是 Hive 是一個中介，我告訴你相關(guān)的 SQL 語句，你幫我把它翻譯成 MapReduce 程序來幫我執(zhí)行運算而已。
2.3、Spark
Spark 也是一種大數(shù)據(jù)處理框架，它的作用與 MapReduce 是一樣的。不過，Spark 的速度可比 MapReduce 要快多了。因為 MapReduce 在作業(yè)運行過程中的中間產(chǎn)物都是保存在磁盤上的，而 Spark 則將中間產(chǎn)物直接保存在內(nèi)存中。磁盤的 IO 速度和內(nèi)存的 IO 速度豈是有可比性的？于是，在 Spark 推出以后，就立即得到了業(yè)界的青睞。
Spark 所使用的編程語言是 Scala，相對于 Java 來說，這是一門比較小眾的語言，所以其學(xué)習(xí)成本會高一點。不過，Scala 真的是一門很簡潔的編程語言。當(dāng)你熟悉了 Scala 的語法以后，你會發(fā)現(xiàn)使用 Scala 編程簡直就像在和計算機聊天一樣。實現(xiàn)同樣的功能，Scala 的代碼量要遠(yuǎn)少于 Java。
Spark 的 “野心” 遠(yuǎn)不止于做一個優(yōu)秀的批處理框架。在 Spark 的生態(tài)系統(tǒng)中，還有Spark SQL、Spark Streaming、Machine Learning、GraphX。Spark SQL 是直接對標(biāo) Hive 的。Spark Streaming 則定位于流處理，不過 Spark Streaming 的流處理模式是通過 “微批處理” 的形式來模擬實時流處理的，這在根本上還不是真正的實時流處理，但對于很多企業(yè)來說，也已經(jīng)夠了，至少在當(dāng)下，它夠了。Machine Learning 就是機器學(xué)習(xí)咯，關(guān)于這個和 GraphX ，我就不再說什么了。
2.4、HBase
HBase 是當(dāng)年 Google 三篇論文中的最后一篇 BigTable 的開源實現(xiàn)。它是一種 NoSQL，Not only SQL。它的出現(xiàn)是為了解決傳統(tǒng)關(guān)系型數(shù)據(jù)庫解決不了的海量數(shù)據(jù)存儲問題的。
HBase 與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫最大的區(qū)別在于它完全不管 “業(yè)務(wù)”。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫或多或少都會將一部分業(yè)務(wù)邏輯包含在內(nèi)，而 HBase 則是做到了完全不管業(yè)務(wù)邏輯的地步，數(shù)據(jù)庫就只是用來存儲數(shù)據(jù)的。
HBase 依賴于 HDFS，就本質(zhì)上來說，HBase 中的數(shù)據(jù)最終還是要存儲在 HDFS 上，HBase 僅僅管理一個數(shù)據(jù)庫中的元數(shù)據(jù)信息而已。什么是元數(shù)據(jù)信息？就是名稱啊、路徑啊、存儲位置啊等等等等。是不是感覺和 HDFS 本身很像？是的！
HBase 是按列存儲的數(shù)據(jù)庫。就是在一張表中，同一列的數(shù)據(jù)會被保存在一起。而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫則是按行存儲的。HBase 還有一個優(yōu)點就是如果某個字段的值為空時，它不會占用存儲空間。這個特性就厲害了，因為在很多數(shù)據(jù)庫中，經(jīng)常會遇到字段值為空的情況，RDBMS 對于空值，也會占用空間來存儲 “空值”。在大數(shù)據(jù)時代，HBase 這一特性可以為企業(yè)大大降低存儲成本。
HBase 中的數(shù)據(jù)表可以動態(tài)地增加列。HBase 對于列唯一的限定就是必須在建表時指定 “列族”。列族可以創(chuàng)建任意多個，一旦指定，便不可再更改。而列則可以在任意時刻進(jìn)行增減。這種動態(tài)增減列的方式是 HBase 實現(xiàn)其擴展性的重要依據(jù)。
HBase 還有一個很重要的特性就是不管你當(dāng)前操作的表中有多少數(shù)據(jù)，它總是能做到快速的讀寫操作。讀我們暫且不去討論，HBase 是如何實現(xiàn)海量數(shù)據(jù)下機械磁盤的高速寫操作的呢？這得歸功于它特殊的存儲機制，HBase 內(nèi)部維護了一個 WAL 文件，寫請求產(chǎn)生時，首先將數(shù)據(jù)保存到這個小文件的日志里，然后再將數(shù)據(jù)放到內(nèi)存中，在這個時候，HBase 就會告訴發(fā)起寫請求的客戶端：我已經(jīng)將你發(fā)過來的數(shù)據(jù)保存好了。對于一個小文件的寫操作以及內(nèi)存中的寫操作，其速度當(dāng)然快了，而且還完全不受現(xiàn)有數(shù)據(jù)規(guī)模的影響。HBase 在后面會通過異步的方式將內(nèi)存中的數(shù)據(jù)保存到磁盤中，真正實現(xiàn)數(shù)據(jù)的持久化存儲。這就是它寫入速度如此快速的原因。
2.5、Zookeeper
Zookeeper 在分布式系統(tǒng)中很常用。它專用于對分布式系統(tǒng)中的各節(jié)點做協(xié)同服務(wù)，說人話就是用于在各計算機之間同步數(shù)據(jù)用的。
那么，Zookeeper 是如何為分布式集群提供協(xié)同服務(wù)的呢？其實答案非常簡單，集群中各有需要的節(jié)點都統(tǒng)一向 Zookeeper 匯報自己的狀態(tài)，由 Zookeeper 來 “仲裁”。最終集群中各個有需要的節(jié)點以 Zookeeper 公布的結(jié)果為準(zhǔn)來執(zhí)行各自應(yīng)該做的任務(wù)。
Zookeeper 既然是要提供這種協(xié)同服務(wù)的，那么就必須要求它的反應(yīng)速度要非?？?，至少要快到不能讓 Zookeeper 成為制約集群性能的因素的地步。關(guān)于這個要求，Zookeeper 的解決方案就兩點：1、限量；2、基于內(nèi)存。限量是指每個 Zookeeper 的節(jié)點只能保存極其有限的數(shù)據(jù)量，小數(shù)據(jù)量的 IO 將會非常輕松，同時也由于數(shù)據(jù)量非常有限，也迫使集群只能將最重要的信息交由 Zookeeper 托管。第 2 點基于內(nèi)存想必就沒什么好說的。
同時，Zookeeper 還必須也得是高可用的，不然，它的協(xié)同服務(wù)會讓人非常沒有安全感。Zookeeper 實現(xiàn)高可用的方式是通過 ZAB 算法來實現(xiàn)的，即 Zookeeper atomic broadcast。這里不對 ZAB 算法展開討論，我們知道 ZAB 算法能夠有效保證 Zookeeper 集群的高可用就行了。
2.6、流處理
以 MapReduce、Spark 為代表的大數(shù)據(jù)處理技術(shù)被稱為批處理技術(shù)，即離線處理。一般常見的場景是在凌晨的時候執(zhí)行大數(shù)據(jù)分析作業(yè)，在早上分析師、高管們上班后，就可以看到關(guān)于昨天的情況分析報告了。
但離線處理終究只能是人類社會發(fā)展進(jìn)程中的一個小階段，實時數(shù)據(jù)處理才是人類追逐的目標(biāo)，也只有實時數(shù)據(jù)處理才能跟上人類社會發(fā)展的進(jìn)程。畢竟誰也不希望我要到明天才能知道我的錢包在今天掉了。
目前的實時流處理框架主要有三種
- Spark Streaming
- Storm
- Flink
Storm 已經(jīng)被淘汰。Spark Streaming 本身的模式注定它不適用于未來的場景需求。Flink 才是大勢所趨。如果你對實時流處理有興趣，那一定要著重學(xué)習(xí) Flink。畢竟現(xiàn)在已經(jīng)有越來越多互聯(lián)網(wǎng)巨頭往 Flink 上遷移了。跟著大部隊走，雖然不敢保證你也能成功，但至少不會錯。
3、職場篇
3.1、如何獲取大數(shù)據(jù)？
技術(shù)是通用的，算法也是公開的，唯有數(shù)據(jù)需要自行采集。業(yè)界比較常見的幾種采集數(shù)據(jù)的手段主要有以下幾種
- 外部數(shù)據(jù)庫導(dǎo)入
- 日志文件
- 前端埋點
- 爬蟲
外部數(shù)據(jù)庫是一個重要的數(shù)據(jù)來源。尤其電商平臺對這種數(shù)據(jù)來源渠道非常常用。用于 HDFS 和外部數(shù)據(jù)庫中導(dǎo)入導(dǎo)出數(shù)據(jù)的工具比較常用的是 Sqoop。
日志文件也是一個非常常用的數(shù)據(jù)來源。而用于自動化遷移日志文件到 HDFS 上的工具是 Flume。
前端埋點是指在前端系統(tǒng)中將用戶的一些動作行為部分或者全部上傳到后臺以供分析使用的。用戶在前端的某些操作是不會被記錄到傳統(tǒng)日志中，更不會被保存到后臺數(shù)據(jù)庫中的。但這些動作行為往往又代表著用戶的心理狀態(tài)，對于分析用戶行為與刻畫用戶畫像而言還是非常有參考價值的。為了得到這些數(shù)據(jù)，就有了前端埋點的操作。
爬蟲獲取數(shù)據(jù)的方式通常只會出現(xiàn)在某些特定性質(zhì)的企業(yè)里。
另外，社會上其實還有一些企業(yè)他們本身就擁有大量數(shù)據(jù)，并且他們會將部分?jǐn)?shù)據(jù)開放出來，供全社會使用。這就是所謂的 “大數(shù)據(jù)開放平臺”。
3.2、如何搭建大數(shù)據(jù)平臺？
大數(shù)據(jù)平臺通常是指一整套用于大數(shù)據(jù)分析的軟件系統(tǒng)。它通常包含以下 3 個模塊
- 數(shù)據(jù)采集系統(tǒng)
- 數(shù)據(jù)處理系統(tǒng)
- 數(shù)據(jù)展示系統(tǒng)
數(shù)據(jù)采集系統(tǒng)包括任何能產(chǎn)生并收集數(shù)據(jù)的平臺與工具，如 App 端應(yīng)用、Web 應(yīng)用、原始數(shù)據(jù)庫、原始日志管理系統(tǒng)等。
數(shù)據(jù)處理系統(tǒng)就是指 Hadoop 生態(tài)圈中的那些軟件框架了?，F(xiàn)階段 Hadoop 生態(tài)圈中的框架能夠滿足任何業(yè)務(wù)處理場景要求。工程師們根據(jù)實際需求選擇并搭建相關(guān)大數(shù)據(jù)處理系統(tǒng)即可。
數(shù)據(jù)展示系統(tǒng)則是直接面向公司高管的。上一步中處理出來的結(jié)果仍然是保存在 HDFS 上的，而工程師們當(dāng)然不可能直接讓公司領(lǐng)導(dǎo)們?nèi)ピL問 HDFS 系統(tǒng)來查詢結(jié)果。所以我們通常會引入很精美的報表系統(tǒng)，將結(jié)果數(shù)據(jù)導(dǎo)出到外部數(shù)據(jù)庫中，再通過這些專業(yè)的報表展示系統(tǒng)展示出來，以供領(lǐng)導(dǎo)層查看。除了公司內(nèi)部查看用的報表系統(tǒng)外，還有一種 “監(jiān)控大屏” 在現(xiàn)今也很流行，比如每年雙十一阿里巴巴直播時使用的實時監(jiān)控大屏就是一個數(shù)據(jù)結(jié)果展示應(yīng)用場景。
除此之外，由于一套數(shù)據(jù)分析作業(yè)流程通常都比較復(fù)雜。有些作業(yè)還要依賴于前面階段的執(zhí)行結(jié)果。因此，作業(yè)調(diào)度也是大數(shù)據(jù)工程師日常工作中的重要環(huán)節(jié)。對于某些簡單的作業(yè)系統(tǒng)，可能直接使用 Shell 腳本加 crontab 就能滿足要求了。而復(fù)雜一些的，就要用到專業(yè)的任務(wù)調(diào)度框架了。在大數(shù)據(jù)領(lǐng)域比較常見的任務(wù)調(diào)度框架有 Oozie、Azkaban。
當(dāng)然，不是每家公司都有這個精力與金錢來自己動手搭建一套如此龐大的大數(shù)據(jù)平臺的。且不說前期搭建時的投入成本，就是后期的運維成本也許一般規(guī)模的公司都難以承受。于是，這些商業(yè)嗅覺靈敏的老家伙們就開啟了大數(shù)據(jù)計算服務(wù)商業(yè)化的時代。
大數(shù)據(jù)計算服務(wù)商業(yè)化主要有以下幾種類型的服務(wù)
- 大數(shù)據(jù)平臺商業(yè)化服務(wù)
- 大數(shù)據(jù)云計算商業(yè)化服務(wù)
- 大數(shù)據(jù) SaaS 商業(yè)化服務(wù)
第 1 種商業(yè)化服務(wù)是指購買相應(yīng)的大數(shù)據(jù)軟件框架。提供這種商業(yè)服務(wù)的公司會將你所需要的軟件框架 “打包” 好，讓你以一種 “即插即用” 的形式來搭建自己的大數(shù)據(jù)平臺系統(tǒng)。如果不購買這種商業(yè)服務(wù)的話，我們公司內(nèi)部的工程師就得自己上 Apache 官網(wǎng)，自行選擇對應(yīng)版本的軟件，然后下載、安裝、配置并部署運行。由于這些軟件框架數(shù)量眾多，自己來搭建的話，也需要一筆不小的成本。業(yè)界比較知名的大數(shù)據(jù)平臺商業(yè)化服務(wù)公司有 Cloudera、HortonWorks、星環(huán)科技等。這些商業(yè)化公司除了提供軟件外，還會提供相應(yīng)的技術(shù)支持服務(wù)。
第 2 種則是將計算環(huán)境商業(yè)化的模式。上面第 1 種模式中，我們除了不用費心于軟件問題外，還是要自行去購買設(shè)備，搭建自己的硬件環(huán)境。那這種模式，就可以讓我們連硬件環(huán)境都幫我們解決了。云計算商業(yè)化公司比較知名的有亞馬遜、Google、阿里巴巴等公司咯。一般而言提供這種服務(wù)的公司都會再順便銷售大數(shù)據(jù)平臺軟件。采用這種模式的公司，只需要投入軟件工程師去開發(fā)對應(yīng)的數(shù)據(jù)分析程序即可。其它的基礎(chǔ)環(huán)境問題花點錢，會有專業(yè)的人幫你解決的。
第 3 種則是最省心的一種了。我們在討論到上面第 2 種時，公司還需要投入軟件工程師去開發(fā)軟件。而 SaaS 商業(yè)化公司則是連數(shù)據(jù)分析軟件都能幫你解決掉。你只需要將待分析的數(shù)據(jù)上傳到云端，點擊一下 “運行” 按鈕，坐等分析結(jié)果就好了。
3.3、大數(shù)據(jù)技術(shù)都有哪些應(yīng)用場景？
不知從什么時候開始，大數(shù)據(jù)這個概念經(jīng)?？M繞在我們耳邊。有的時候就感覺，大數(shù)據(jù)這個行業(yè)是必然會隨著時間的推移而出現(xiàn)的。因為不論哪個行業(yè)，其積累的數(shù)據(jù)只會越來越多。數(shù)據(jù)量的增加，其價值密度也會越來越低，但偏偏其所蘊含的價值又是巨大的，誰能將數(shù)據(jù)中的價值全部挖掘出來，誰就一定能成為行業(yè)翹楚。
目前大數(shù)據(jù)技術(shù)的應(yīng)用領(lǐng)域主要有以下幾個
- 醫(yī)療健康領(lǐng)域
- 教育領(lǐng)域
- 社交媒體領(lǐng)域
- 金融領(lǐng)域
- 新零售領(lǐng)域
- 交通領(lǐng)域
無論哪個領(lǐng)域，都可以從大量的歷史數(shù)據(jù)當(dāng)中找出規(guī)律進(jìn)行相關(guān)的 “預(yù)測” 操作，從而實現(xiàn) “智能化” 的目的。由此可見，大數(shù)據(jù)技術(shù)在未來可以有兩條路。一條是作為公司內(nèi)部的數(shù)據(jù)分析利器，另一條則是為人工智能技術(shù)提供堅實后盾。
3.4、大數(shù)據(jù)行業(yè)的軟件工程師該何去何從？
在未來，不敢說所有軟件行業(yè)，至少大數(shù)據(jù)軟件開發(fā)行業(yè)，其編程難度一定會越來越低。即使是現(xiàn)在都已經(jīng)如此了。整個大數(shù)據(jù)分析項目跑下來，要寫的代碼還真沒多少行。大數(shù)據(jù)開發(fā)行業(yè)，其重點就不在編碼上，而在于系統(tǒng)架構(gòu)的設(shè)計、業(yè)務(wù)邏輯的梳理之上。
這樣一來，大數(shù)據(jù)行業(yè)的軟件工程師，除了編碼能力，更多的還應(yīng)將精力放在綜合能力的提升上面。如果未來想繼續(xù)走技術(shù)方向，那么就應(yīng)該多提升下系統(tǒng)架構(gòu)能力。如果未來想升管理層，想往商業(yè)方向發(fā)展，那就應(yīng)該多關(guān)注下自己公司的業(yè)務(wù)，熟悉每個項目的整體運行流程。不管你要選擇哪一條道路，一定不要忘記堅持學(xué)習(xí)，要知道，我們的能力并是隨著工作年限的增加就會自動提升的。能力的提升最重要的來源在于我們的思考與總結(jié)。而學(xué)習(xí)，能給我們提供源源不斷的思考與總結(jié)的機會。
結(jié)語
說好只是簡單寫寫總結(jié)的，沒想到寫到這兒時，已經(jīng)洋洋灑灑大幾千字了。自己到目前為止雖然馬上就滿三年的工作經(jīng)驗了，但我卻絲毫不對自己的這個 “三年經(jīng)驗” 頭銜滿意，因為我前面兩年多的時光簡直就是白白浪費掉的。那時后的我不懂學(xué)習(xí)的重要性，每天除了工作就是等待再次工作，導(dǎo)致個人能力停滯不前?，F(xiàn)在每每想起從前這段時光，我都無比悔恨。
不過亡羊補牢，為時未晚。在我堅持學(xué)習(xí)這大半年時間里，我真的感受到了自己尤如蛻變般的變化。尤其這段時間再接觸到諸如李智慧老師這般優(yōu)秀的軟件工程師，在為我解惑的同時還激起了我更深入學(xué)習(xí)的斗志。
李智慧老師說的沒錯，任窗外時光荏苒，我們必須在學(xué)習(xí)的道路上大步前行，讓時間不僅僅只是日歷上的數(shù)字，讓時光因為我們的付出而更加厚重，而我們?nèi)缃竦倪@些付出，又會給我們的未來增加無限的可能。
大象正在飛奔，我們身處象背，借助著大象飛奔的初速度發(fā)起沖刺，相信我們一定能比以往取得更好的成績。
為那個在未來更強大的我們而努力！
