大資料大綱&大資料生態圈所涉及的技術
阿新 • • 發佈：2019-01-09
今天博主是做一個大概的概述，缺少的章節會在後面慢慢補充，感興趣的同學可以在下面評論留言。
測試結果對比如下：
我們目前使用的是SparkSQL，至於為什麼用SparkSQL，原因大概有以下吧：使用Spark還做了其他事情，不想引入過多的框架;Impala對記憶體的需求太大，沒有過多資源部署。5.1 關於Spark和SparkSQL什麼是Spark，什麼是SparkSQLSpark有的核心概念及名詞解釋SparkSQL和Spark是什麼關係，SparkSQL和Hive是什麼關係SparkSQL為什麼比Hive跑的快5.2 如何部署和執行SparkSQLSpark有哪些部署模式?如何在Yarn上執行SparkSQL?使用SparkSQL查詢Hive中的表。Spark不是一門短時間內就能掌握的技術，因此建議在瞭解了Spark之後，可以先從SparkSQL入手，循序漸進在實際業務場景下，特別是對於一些監控日誌，想即時的從日誌中瞭解一些指標(關於實時計算，後面章節會有介紹)，這時候，從HDFS上分析就太慢了，儘管是通過Flume採集的，但Flume也不能間隔很短就往HDFS上滾動檔案，這樣會導致小檔案特別多。為了滿足資料的一次採集、多次消費的需求，這裡要說的便是Kafka6.1 關於Kafka什麼是Kafka?Kafka的核心概念及名詞解釋。6.2 如何部署和使用Kafka使用單機部署Kafka，併成功執行自帶的生產者和消費者例子。使用Java程式自己編寫並執行生產者和消費者程式。Flume和Kafka的整合，使用Flume監控日誌，並將日誌資料實時傳送至Kafka。這時，使用Flume採集的資料，不是直接到HDFS上，而是先到Kafka，Kafka中的資料可以由多個消費者同時消費，其中一個消費者，就是將資料同步到HDFS截止到這裡你應該已經具備以下技能和知識點：為什麼Spark比MapReduce快使用SparkSQL代替Hive，更快的執行SQL使用Kafka完成資料的一次收集，多次消費架構自己可以寫程式完成Kafka的生產者和消費者從前面的學習，你已經掌握了大資料平臺中的資料採集、資料儲存和計算、資料交換等大部分技能，而這其中的每一步，都需要一個任務(程式)來完成，各個任務之間又存在一定的依賴性，比如，必須等資料採集任務成功完成後，資料計算任務才能開始執行。如果一個任務執行失敗，需要給開發運維人員傳送告警，同時需要提供完整的日誌來方便查錯。不僅僅是分析任務，資料採集、資料交換同樣是一個個的任務。這些任務中，有的是定時觸發，有點則需要依賴其他任務來觸發。當平臺中有幾百上千個任務需要維護和執行時候，僅僅靠crontab遠遠不夠了，這時便需要一個排程監控系統來完成這件事。排程監控系統是整個資料平臺的中樞系統，類似於AppMaster，負責分配和監控任務。7.1 Apache OozieOozie是什麼?有哪些功能?Oozie可以排程哪些型別的任務(程式)?Oozie可以支援哪些任務觸發方式?安裝配置Oozie。7.2 其他開源的任務排程系統Azkaban，light-task-scheduler，Zeus，等等。另外，我這邊是之前單獨開發的任務排程與監控系統在第六章介紹Kafka的時候提到了一些需要實時指標的業務場景，實時基本可以分為絕對實時和準實時，絕對實時的延遲要求一般在毫秒級，準實時的延遲要求一般在秒、分鐘級。對於需要絕對實時的業務場景，用的比較多的是Storm，對於其他準實時的業務場景，可以是Storm，也可以是Spark Streaming。當然，如果可以的話，也可以自己寫程式來做。8.1 Storm什麼是Storm?有哪些可能的應用場景?Storm由哪些核心元件構成，各自擔任什麼角色?Storm的簡單安裝和部署。自己編寫Demo程式，使用Storm完成實時資料流計算。8.2 Spark Streaming什麼是Spark Streaming，它和Spark是什麼關係?Spark Streaming和Storm比較，各有什麼優缺點?使用Kafka + Spark Streaming，完成實時計算的Demo程式。至此，你的大資料平臺底層架構已經成型了，其中包括了資料採集、資料儲存與計算(離線和實時)、資料同步、任務排程與監控這幾大模組。接下來是時候考慮如何更好的對外提供資料了。第九章：資料要對外通常對外(業務)提供資料訪問，大體上包含以下方面。離線：比如，每天將前一天的資料提供到指定的資料來源(DB、FILE、FTP)等;離線資料的提供可以採用Sqoop、DataX等離線資料交換工具。實時：比如，線上網站的推薦系統，需要實時從資料平臺中獲取給使用者的推薦資料，這種要求延時非常低(50毫秒以內)。根據延時要求和實時資料的查詢需要，可能的方案有：HBase、Redis、MongoDB、ElasticSearch等。OLAP分析：OLAP除了要求底層的資料模型比較規範，另外，對查詢的響應速度要求也越來越高，可能的方案有：Impala、Presto、SparkSQL、Kylin。如果你的資料模型比較規模，那麼Kylin是最好的選擇。即席查詢：即席查詢的資料比較隨意，一般很難建立通用的資料模型，因此可能的方案有：Impala、Presto、SparkSQL。這麼多比較成熟的框架和方案，需要結合自己的業務需求及資料平臺技術架構，選擇合適的。原則只有一個：越簡單越穩定的，就是最好的