Spark 快速理解

時間 2019-12-05

標籤 spark 快速理解欄目 Spark 简体版

原文原文鏈接

轉載自：http://blog.csdn.net/colorant/article/details/8255958
算法

==是什麼 ==數據庫

目標Scope（解決什麼問題）編程

在大規模的特定數據集上的迭代運算或重複查詢檢索緩存

官方定義架構

aMapReduce-like cluster computing framework designed for low-latency iterativejobs and interactive use from an interpreter框架

我的理解分佈式

首先，MapReduce-like是說架構上和多數分佈式計算框架相似，Spark有分配任務的主節點（Driver）和執行計算的工做節點（Worker）函數

其次，Low-latency基本上應該是源於Worker進程較長的生命週期，能夠在一個Job過程當中長駐內存執行Task，減小額外的開銷oop

而後對interative重複迭代類查詢運算的高效支持，是Spark的出發點了。最後它提供了一個基於Scala的Shell方便交互式的解釋執行任務性能

==如何實現 ==

核心思路，架構

RDD：Spark的核心概念是RDD (resilientdistributed dataset)，指的是一個只讀的，可分區的分佈式數據集，這個數據集的所有或部分能夠緩存在內存中，在屢次計算間重用。

Lineage：利用內存加快數據加載在衆多的其它的In-Memory類數據庫或Cache類系統中也有實現，Spark的主要區別在於它處理分佈式運算環境下的數據容錯性（節點實效/數據丟失）問題時採用的方案。爲了保證RDD中數據的魯棒性，RDD數據集經過所謂的血統關係(Lineage)記住了它是如何從其它RDD中演變過來的。相比其它系統的細顆粒度的內存數據更新級別的備份或者LOG機制，RDD的Lineage記錄的是粗顆粒度的特定數據變換（Transformation）操做（filter, map, join etc.)行爲。當這個RDD的部分分區數據丟失時，它能夠經過Lineage獲取足夠的信息來從新運算和恢復丟失的數據分區。這種粗顆粒的數據模型，限制了Spark的運用場合，但同時相比細顆粒度的數據模型，也帶來了性能的提高。

總之，Spark的核心思路就是將數據集緩存在內存中加快讀取速度，同時用lineage關聯的RDD以較小的性能代價保證數據的魯棒性。

適用領域

正如其目標scope，Spark適用於須要屢次操做特定數據集的應用場合。須要反覆操做的次數越多，所需讀取的數據量越大，受益越大，數據量小可是計算密集度較大的場合，受益就相對較小。

細節

使用內存緩存數據集快在哪裏？主要是幾個方面：首先是磁盤IO，其次數據的序列化和反序列化的開銷也節省了，最後相對其它內存數據庫系統，粗顆粒度的內存管理機制減少了數據容錯的代價（如典型的數據備份複製機制）

==相關項目 ==

上下游項目

Discretized Streams (Spark streaming)

構建在Spark上處理Stream數據的框架，基本的原理是將Stream數據分紅小的時間片段（幾秒），以相似batch批量處理的方式來處理這小部分數據。我的理解構建在Spark上的緣由大概是由於Spark的低延遲執行引擎（100ms+）勉強能夠用於實時處理，而Spark的核心理念數據重用和流式數據處理自己並無直接的交集，相反我的感受流式數據的無窮連續性的特性必定程度上和數據重用是衝突的。相比基於Record的其它處理框架（如Storm），RDD數據集更容易作高效的容錯處理。此外小批量處理的方式使得它能夠同時兼容批量和實時數據處理的邏輯和算法。方便了一些須要歷史數據和實時數據聯合分析的特定應用場合。

Shark ( Hive on Spark)

Shark基本上就是在Spark的框架基礎上提供和Hive同樣的H iveQL命令接口，爲了最大程度的保持和Hive的兼容性，Shark使用了Hive的API來實現query Parsing和 Logic Plan generation，最後的PhysicalPlan execution階段用Spark代替Hadoop MapReduce。經過配置Shark參數，Shark能夠自動在內存中緩存特定的RDD，實現數據重用，進而加快特定數據集的檢索。同時，Shark經過UDF用戶自定義函數實現特定的數據分析學習算法，使得SQL數據查詢和運算分析能結合在一塊兒，最大化RDD的重複使用。

相似項目

Twister :http://www.iterativemapreduce.org大概的意思也是經過Cache數據，實現迭代的MapReduce過程當中的數據重用,不過它的模型貌似相對簡單些，大體是經過拓展MapReduce API，分發管理緩存數據，而後經過本身的Daemon進程管理和分配MapReduce Task到Cache對應的節點上，容錯性和計算模型方面沒有Shark的RDD來得精巧和通用。