阿里妹導讀：近幾年裡，大資料行業發展勢頭迅猛，故而相應的分散式產品和架構層出不窮，本文分享作者在大資料系統實踐過程中接觸過的一些工具及使用感受，拋磚引玉，和同學們一起構建一個分散式產品的全景圖。
下圖是由著名的資料觀察家Matt Turck在他的BLOG（https://mattturck.com/）裡發出的2019年人工智慧和大資料產業圖，他從2012年開始每年都會繪製一張，大致描述這個產業裡的公司及其資料相關的產品，以及所屬問題的領域。這裡面大部分是商業軟體，而對於絕大多數網際網路公司，中間綠色的開源產品可能大家接觸的更多一些，而這些產品裡，絕大多數都屬於Apache基金會。
下面我從中挑選一些東西隨便聊聊，因為是隨便聊聊，所以知識點並不全，也不能幫助大家知道如何搭建和使用，以及如何避坑，只是談談我對這些東西的印象，描述一個大概的輪廓，如有使用需求可以搜尋網上其它文章，資料還是很多的。當然，大家對其中的內容有興趣可以隨時找我交流討論，對文中如有描述錯誤的地方也歡迎大家斧正，共同學習，謝謝。官網：http://hadoop.apache.org/Hadoop專案下包含了很多子專案，從計算到儲存都有，比如HDFS、MapReduce、YARN、HBase。HDFS全稱叫做Hadoop分散式檔案系統，其主要由一個NameNode(NN)和多個DataNode(DN)組成，資料檔案會分成多個Block，這些Block按照不同主機，不同機架的策略以預設一備三的情況分佈儲存在各個節點。現在每個Block大小預設是128MB，以後隨著磁碟定址速度的增加，這個Block也會不斷增大。而NN裡面則儲存了這些Block後設資料的資訊，這樣客戶端進行資料查詢的時候，DN告知所需資料的位置。從這種結構上能看出一些比較明顯的問題就是NN節點的單點問題，所以在Hadoop 2.x的時候，針對NN做了一些改進。
首先是在系統可用性上，增加了一個StandBy狀態的NN，作為服務中NN（Active NN）的備機，當服務中的NN掛掉後，由StandBy的NN自動接替工作。而NN節點狀態的健康和服務切換，由ZKFC負責。主備NN之間的資訊同步則由Quorum Journal Node負責。其次，由於單臺NN中儲存了大量的後設資料資訊，所以隨著HDFS資料量的不斷增加，顯然NN必將成為系統的瓶頸，為了解決這個問題，Hadoop 2.x增加了Federation，該技術允許系統中有多臺NN同時對外提供服務，這多臺NN將DN中的所有檔案路徑進行了橫向拆分，每個DN負責不同的路徑，達到了橫向擴充套件的效果。除了HDFS，Hadoop 2.x也引入了YARN，該工具負責對叢集中的資源進行管理和任務的協調。該工具分成一個ResourceManager(RM)和多個NodeManager(NM)，當一個任務提交給YARN之後，會先在某一伺服器上啟動一個ApplicationMaster(AM)，AM向RM申請資源，RM透過NM尋找叢集中空閒的資源，NM將資源打包成一個個Container，交給AM。AM將資料和程式分發到對應節點上處理，如果某個Container中的任務執行失敗了，AM會重新向RM申請新的Container。Apache Hadoop HBase & Kudu官網：http://hbase.apache.org/
眾所周知，HBase一個分散式列式儲存系統，同樣屬於Hadoop的子專案，列式儲存的優劣在這裡不說了，提一下HBase的WAL和LSM，WAL全稱為Write Ahead Log，只是在資料修改操作前，會先將此操作記錄在日誌中，這樣一旦服務崩潰，透過該日誌即可進行資料的恢復，提到這裡有些人就會聯想到MySQL，因為InnoDB引擎的redo log就是典型的WAL應用。而在HBase中該功能是由叫做HLog的模組所完成的。再說LSM，其全稱為Log Structured Merge Trees，介紹原理的文章也有很多，在HBase中，LSM樹是MemStore模組的底層儲存結構，而MemStore有三個作用，一是當有資料寫入的時候，直接寫到MemStore中，從而提升寫資料的效率。二是充當讀取資料時的快取。三是定期對資料操作去重，並進行資料落盤。HBase的主要角色分別有HMaster和HRegionServer，同樣是一對多的關係，而各節點的狀態全都交由Zookeeper負責。Kudu是一個和HBase非常類似的產品，其不同之處在於Kudu不依賴Zookeeper來管理自己的叢集，並且HBase的資料是儲存在HDFS上的，而Kudu擁有自己的資料檔案格式。官網：https://spark.apache.org/Spark是由加州大學伯克利分校推出的分散式計算引擎，在Spark的官方主頁上有一張和Hadoop的效能對比圖，姑且不談這張圖中資料的準確性，但是Spark的確將Hadoop（主要是指MapReduce）的效能提升了一個量級。我理解這主要得益於兩個方面：第一個是Spark計算過程中生成的中間資料不再落盤，沒有了Spill的階段。第二個是引入DAG對任務進行拆解，一個完整的Job被分成多個Stage，每個Stage裡面又有多個Task，透過一張有向無環圖，使得沒有依賴關係的Task可以並行執行。Spark不只是在批處理上有所成績，而是更加註重整個生態圈的建設，其擁有流式處理框架SparkStreaming，採用微批的形式達到類似流處理的效果，現在又推出了Structured Streaming，實現基於狀態的流處理框架。此外還擁有SparkSQL來幫助非開發人員更加便捷的呼叫Spark的服務和Spark MLlib這個機器學習庫。Spark雖好，但其對記憶體資源消耗也很大，同時也使得他在穩定性上不如MapReduce，所以有些大公司數倉的日常任務仍舊採用傳統MapReduce的方式執行，不求最快，但求最穩。我們的系統在剛從MapReduce上切到Spark時，每天夜裡也是任務異常頻發，最後調整了任務和資源分配，再加上一個很粗暴的重試機制解決了。官網：https://flink.apache.org/Flink是德國Data Artisans公司開發一款分散式計算系統，該公司於19年初被阿里巴巴集團收購。包括Spark和Kafka，也都看到了未來流式計算的前景是非常巨大的，紛紛建立屬於自己的流式計算生態圈。Flink和Spark Streaming相比，前者是真正的流式計算，而後者是微批處理，雖然批次足夠小，但其本質畢竟還是批處理，這就導致有些場景SparkStreaming註定無法滿足，雖然Spark現在將重心轉移到了Structured Streaming，它彌補了Spark Streaming很多的不足，但是在處理流程上仍然是微批處理。
而Flink在設計之初就同時考慮了批處理和流處理這兩種需求，所以使用者也可以只透過一個計算引擎，就能實現批處理和流處理兩種計算場景，其主要幾個需要清楚的特性我覺得分別是：State狀態管理，CheckPoint容錯機制，Window滑動視窗，和Watermark亂序解決。這些內容網上都有很多介紹，不再闡述。官網：https://impala.apache.org/Impala是Cloudera公司用C++開發的支援SQL語義的查詢系統，可以用來查詢HDFS、HBase、Kudu的內容，也支援多種序列化和壓縮格式，因為也是基於記憶體的計算，比傳統MapReduce快很多。不過因為已經使用了Spark，所以組裡並沒有對Impala進行大規模的應用。經過一些零散的調研和了解，好像其它公司對Impala的應用也不是非常多。官網：https://zookeeper.apache.org/Zookeeper無論在資料系統還是在其它後端系統的使用場景都非常廣，它可以用作分散式鎖服務，可以用做系統的配置中心，可以協助完成一致性演算法的選主過程，可以用於ZKFC做節點健康情況的探查，總之用處還有很多。而它的工作機制，基本就是ZAB協議的機制，一個支援崩潰恢復的原子廣播協議，其主要組成也是由一個Leader和多個Follower組成的，資料的提交遵循2PC協議。當Leader崩潰時，Follower會自動切換狀態開始重新選主，重新選完之後再進行多節點的資料對齊。官網：https://sqoop.apache.org/一款用於在傳統關係型資料庫和HDFS之間互相進行資料傳遞的工具，無論是import還是export都提供了大量的引數，因為是分散式執行，資料傳輸的速度也非常快。只是在使用的過程中需要注意資料來源中的異常資料，會比較容易造成資料傳遞過程中的異常退出。為了彌補Sqoop的功能單一，推出了Sqoop 2，架構上比Sqoop 1複雜了很多，不過我沒有用過。官網：http://flume.apache.org/分散式資料傳輸工具，支援包含檔案、Netcat、JMS、HTTP在內的多種資料來源。其結構上分成Source、Channel、Sink三部分，Source將獲取到的資料快取在Channel中，這個Channel可以是檔案，可以是記憶體，也可以使用JDBC，Sink從Channel消費資料，傳遞給系統中的其他模組，比如HBase、HDFS、Kafka等等。官網：http://kafka.apache.org/曾經是一款由Scala開發的分散式訊息佇列產品，現在生態已經擴充套件了，因為它推出了Kafka Streaming，所以現在也應該被稱作是一個流處理平臺了，但這裡不說Kafka Streaming，因為沒有用過和了解過。Kafka的佇列按照Topic劃分，每個Topic下由多個Partition組成，在單個Partition中的訊息保證是有序的。這種結構下確保了訊息是在磁碟順序寫入的，節省了磁碟定址的時間，所以資料落盤的速度非常快。加之採用了mmap的方式，減少了使用者態和核心態之間的資料複製次數，mmap是一種將檔案內容和記憶體地址對映的技術，提效十分明顯。Kafka和Flume的配合使用，形成了流式處理領域裡的經典框架。官網：http://ranger.apache.org/官網：http://sentry.apache.org/Ranger和Sentry都是分散式的資料安全工具，這兩個產品的功能也基本是一樣的，就是去管理大資料計算生態圈產品的許可權，Sentry是採用外掛的形式，將自己整合到Impala、Hive、HDFS、Solr等產品上，當使用者向這些產品發起請求，產品會先向Sentry Server進行校驗，Sentry也可以和Kerberos配合使用，從而完成跨平臺統一許可權管理。而Ranger所提供的功能也類似，但是所支援的產品更加多樣，包括HDFS、HBase、Hive、YARN、Storm、Solr、Kafka、Atlas等，其同樣也是採用一個Ranger Admin連線多個整合到產品上的Ranger外掛完成的許可權驗證過程。官網：https://atlas.apache.org/Apache Atlas是資料治理體系中比較重要的一個產品，它主要負責後設資料的管理，這個後設資料就是指用來描述資料的資料，比如資料的型別、名稱、屬性、作用、生命週期、有效範圍、血緣關係等等，在大資料系統中，後設資料有著非常大的價值，一個比較成熟的資料系統中一般都會存在著這麼一個後設資料管理平臺，後設資料除了能讓業務人員更加方便快捷理解我們的資料和業務，也有著幫助我們提升資料質量，消除資訊不對稱，以及快速定位資料問題等作用，所以如何有效的利用好這些後設資料，使這些資料產生更大的價值，也是很多人一直在思考的事情。現在Atlas支援的資料來源有Hive、Sqoop、Storm，其匯入方式有HOOK和Batch兩種方式，首次使用是Batch的同步方式，之後Atlas會利用HOOK主動獲取到資料來源的變化，並更新自身資料。官網：http://kylin.apache.org/
Kylin是一個為OLAP場景量身定製的分散式資料倉儲產品，提供多維分析的功能，並可以和很多BI分析工具無縫對接，比如Tableau、Superset等。Kylin提供了前端平臺，使用者可以在該平臺上去定義自己的資料維度，Kylin會定時完整分析所需資料的預計算，形成多個Cube，並將之儲存在HBase中，所以部署Kylin的時候需要HBase環境的支援。在資料與計算的時候，對其所在裝置的資源消耗也比較大。官網：https://hive.apache.org/官網：https://tez.apache.org/Hive應該是最有名氣的資料倉儲工具了吧，他將HDFS上的資料組織成關係型資料庫的形式，並提供了HiveSQL進行結構化查詢，使得資料分析人員可以從傳統的關係型資料庫幾乎無縫的過渡到HDFS上，但其個別函式和傳統SQL還是有區別的，並且預設也不支援update和delete操作。但開發人員可以開發UDF，為HiveSQL擴充屬於自己的功能函式。Hive本身的計算是基於MapReduce的，後來為了應對SparkSQL的出現，開發組推出了Hive on Spark，使得SQL的解釋、分析、最佳化還是在Hive上，而執行階段交由Spark去完成，從而以達到和SparkSQL近似的速度。Tez是對Hive的另一項最佳化，為其引入了DAG的概念，增加任務並行度從而提升Hive的查詢速度，但其本質仍舊是MapReduce，所以提升效果相比Hive on Spark來講並不足夠明顯。Presto是由facebook公司開發的一款分散式查詢引擎，其主要特點是支援了非常多的Connector，從而實現在一個平臺上連線多個資料來源，並且可以將這些資料來源的內容進行聚合計算，同時Presto也支援使用者自行開發新的Connector。並且Presto的計算過程全程是基於記憶體的，所以速度也是非常的快，但其實Presto也只是針對個別計算場景的效能最佳化會非常明顯，網上有非常詳細的分析文章。之前使用該工具是為了將離線數倉和實時數倉的資料進行聯合查詢，提供給實時資料平臺使用。在使用過程中我覺得有點不好的地方有三點。一是因為Presto基於記憶體計算，所以在資源緊張的情況下經常Crash導致任務失敗。二是Presto任務為序列提交，所以會出現大任務阻塞小任務的情況出現。或許透過調參可以解決該問題吧，但沒有再深入調研了。三是沒有找到一個比較好的Web平臺去查詢Presto，網上有Hue透過PostgreSQL去連結Presto的方案，覺得有點麻煩，看上去比較成熟的Airpal平臺也已不再更新了。最後使用了yanagishima，基本功能可以滿足，但該平臺沒有使用者管理功能，沒法控制許可權。官網：https://parquet.apache.org/官網：https://orc.apache.org/Parquet和ORC是兩種比較應用比較多的列式儲存格式，列式儲存不同於傳統關係型資料庫中行式儲存的模式，這種主要的差別可能由於聯機事務處理（OLTP）和聯機分析處理（OLAP）的需求場景不同所造成的。在OLTP場景多是需要儲存系統能滿足快速的CRUD，這種操作物件都是以行為單位的。而在OLAP場景下，主要的特徵是資料量巨大，而對實時性的要求並不高。而列式儲存正式滿足了這一需求特徵。因為當資料以列的方式儲存，在查詢的時候引擎所讀取的資料量將會更小，而且同一列的資料往往內容類似，更加便於進行資料壓縮，但列式儲存不適於更新和刪除頻繁的場景。Parquet和Orc同為列式儲存，但他們的儲存格式並不相同，這種差異造成了兩者在儲存不同型別的資料時所出現的效能差異，從網上的一些文章看，Orc的效能要比Parquet好一點，但是Impala是不支援Orc的，並且諸如Delta Lake這種資料湖產品，也是基於Parquet去做的。所以在選擇採用哪種列式儲存格式時，還是要根據自身的業務特點來決定。官網：http://griffin.apache.org/
資料質量管理是資料系統中不可或缺的一環，初期的時候我們往往在ETL的各個階段，加入一些簡單的指令碼來對生成的資料進行檢查，而Apache Griffin也是一款這樣的產品，它是由eBay開發的一個資料質量監控平臺，後上升為Apache頂級專案。它提供了資料校驗和報警的功能，也支援一些引數的視覺化展現，相關的配置步驟都可以在Griffin的頁面上完成。除了能完成一些最基本最簡單的諸如是否存在異常值的資料檢查，也能完成一些諸如最值、中值的資料統計需求等等，並且提供了專業的圖表報告。官網：http://zeppelin.apache.org/
Zeppelin是一款非常方便的線上筆記本，使用體驗有點像Python的Jupyter NoteBook，可以從圖中看到使用者可以線上執行，並繪製簡單的圖表。並且Zeppelin有了使用者的概念，使得多人協同工作更加方便。Zeppelin支援了非常多的資料來源，透過該平臺，可以呼叫Hive、Cassandra、R、Kylin、Flink、Spark、ElasticSearch、HBase、Python、Shell等等。我在使用時出現了Spark連線不穩的情況，需要使用者反覆登入才可以。但總之我還是非常喜歡這款工具的。官網：http://superset.apache.org/Superset是一款開源的視覺化工具，使用該工具可以方便快速的建立資料Dashboard，同型別的產品還有Redash、Metabase，但調研過後個人還是更喜歡Superset一些。不過因為同期引入了Tableau，Superset並沒有在實際專案中使用。官網：https://www.tableau.com/
和介紹的其它軟體不同，Tableau是一款商用軟體，根據購買的賬號數量按年付費，之所以這裡提到它，也是因為Tableau在BI領域內的名氣著實有點高。Tableau分為Server端和本地客戶端，使用者透過在客戶端上的拖拽，即可快速生成一個資料Dashboard，使得Dashboard的開發工作從開發側下放到了需求方。並且Tableau也提供了完備的使用者管理功能，還支援了非常多的資料來源。商業軟體和開源軟體比起來，無論功能完備性上還是使用體驗上，的確都有明顯的提升。我覺得唯一的難度可能就是如何把這個開發維護的工作在需求方落地吧，畢竟它還是有一些學習成本的。TPC全稱是事務處理效能委員會，是由數十家公司組成的非盈利性組織，負責訂製各個行業的基準測試規範，阿里巴巴的MaxCompute和OceanBase都參加過該項測試，並取得了非常好的成績。TPCx-BB是一個大資料基準測試工具，該工具模擬了一個網上零售的場景，首先工具會先向被測系統中插入預定好的表和資料，然後經過一系列的SQL操作，來對大資料叢集的效能進行評估。TPC針對不同的被測場景，提供了很多現成的工具，可以供大家下載使用：http://www.tpc.org/tpc_documents_current_versions/current_specifications5.asp
