hive on spark記憶體模型

来源:https://www.cnblogs.com/lhk20213937/p/18136064
-Advertisement-
Play Games

內容介紹 hive on spark的調優,那必然涉及到這一系列框架的記憶體模型。本章就是來講一下這些框架的記憶體模型。 hive on spark的任務，從開始到結束。總共涉及了3個框架。分別是：yarn、hive、spark 其中，hive只是一個客戶端的角色。就不涉及任務運行時的記憶體。所以這裡主要 ...


內容介紹

hive on spark的調優,那必然涉及到這一系列框架的記憶體模型。本章就是來講一下這些框架的記憶體模型。
hive on spark的任務，從開始到結束。總共涉及了3個框架。分別是：yarn、hive、spark
其中，hive只是一個客戶端的角色。就不涉及任務運行時的記憶體。所以這裡主要講的yarn和spark的記憶體模型。
其中，由於spark是運行在yarn的container中。所以我們從外到內。先將yarn的資源分配。後講spark的記憶體模型。

hive on spark提交流程

hive階段

首先上場的是hive框架。當我們寫了一個SQL語句的時候，會被hive進行解析（hive用的SQL解析框架是Antlr4）。解析的流程是：

  • 解析器將SQL解析成AST（抽象語法樹）
  • 邏輯生成器
  • 邏輯優化器 (這裡主要做一些謂詞下推的操作)
  • 物理生成器
  • 物理優化器(這裡則是做基於代價的優化，簡稱CBO)
  • 執行器 (在這裡就會將Spark任務提交給yarn)
    這裡是進行物理優化器的地方，可以看見，從這裡開始，就已經根據引擎的不同，進行不同的優化了。
    img
    此處就是執行器
    img
    我們進去之後就可以看見 提交Spark任務
    img
    我們可以在這裡看見，把job上傳到yarn上，並且添加了一些監聽器來獲取job的狀態
    img

這樣之後，SQL就會被轉為Spark一系列的RDD。

yarn資源

在hive中，我們已經把spark job提交到yarn上面。現在我們就來看一下yarn的記憶體模型。

yarn的組成很簡單，有ResourceManager和NodeManager，其中ResourceManager是大哥。對客戶端傳來的請求做處理。NodeManager是小弟。負責運行任務。
就此而言，我們就可以做出一個簡單的判斷：對於資源（記憶體和CPU）的分配，我們要多給NodeManager資源。ResourceManager無需很多的資源。因為ResourceManager僅僅是處理客戶端的請求和管理NodeManager。並不進行任務的計算。
NodeManager裡面是很多的Container，我們的Spark任務就是跑在Container裡面的。

yarn中關於資源的參數

由於spark任務是跑在NodeManager下的Container中。所以我們可以對NodeManager和Contaniner進行參數的調整（資源的配置）

NodeManager的參數
  • yarn.nodemanager.resource.memory-mb : NodeManager可以給Container分配記憶體
  • yarn.nodemanager.resource.cpu-vcores ：NodeManager可以給Container分配的虛擬核數（因為不同的CPU可能計算能力不同。有可能一個i7的CPU頂兩個i5的。所以就可以把i7的cpu映射為兩個虛擬核。這樣的話，就不會出現因為CPU的差異，而導致的：相同的任務跑多次。每次所耗的時間相差特別大。）
Container的參數
  • yarn.scheduler.maximum-allocation-mb ： 單個Container可以使用的最大記憶體
  • yarn.scheduler.minimum-allocation-mb ： 單個Container可以使用的最小記憶體

Spark資源

Spark的記憶體模型可以大致分為堆內記憶體和堆外記憶體
img

堆內記憶體

img
動態占用機制：簡單的來說，

  • 當存儲和執行的記憶體都不足時。存儲會存放到硬碟。
  • 當存儲占用了執行的記憶體後，執行想收回記憶體時。存儲會將占用的部分轉存到硬碟。歸還記憶體
  • 當執行占用了存儲的記憶體後，存儲想收回記憶體時，執行無法歸還記憶體。需要等到執行使用完畢，才可以歸還記憶體。（朴素的想一想，比較計算重要。不能停止，只好讓存儲等一等。等執行計算完畢，再歸還記憶體）

堆外記憶體

img

在預設情況下，堆外記憶體並不啟用。可以通過spark.memory.offHeap.enabled開啟。
堆外記憶體的大小由spark.memory.offHeap.size指定。
堆外記憶體的優點：

  • Spark直接操作系統堆外記憶體，減少了不必要的記憶體開銷，和頻繁的GC的掃描和回收，提高了性能
  • 可以被精準的申請和釋放。（因為堆內記憶體是由JVM管理的。所以無法實現精準的釋放）

整合yarn和Spark

我們先對一臺伺服器的資源配置做出假設，並根據這些假設，對資源進行合理的分配。

伺服器的資源情況： 32核CPU，128G記憶體

因為我們的伺服器不可能只是為yarn一個框架提供資源。其他的框架也需要資源。所以我們可用分配給yarn的資源為：16核CPU，64G記憶體

Spark任務分為Driver和Executor。

Executor

由於 Spark 的Executor的CPU建議數量是4~6個。 然後伺服器中yarn可用的CPU資源數是16。

16/4=4;16/5=3...1;16/6=2...4;可以看出。單個Executor的CPU核數為5、6的時候，都會有一些CPU核未使用上，造成CPU的浪費。所以我們選取 單個Executor的CPU核數為4。然後我們根據1CU原則（1個CPU對應4G記憶體）。所以Executor的記憶體數為4*4G。

單個Executo資源情況： 4核CPU，16G記憶體。

根據資源的配置情況可知， 一個節點能運行的Executo數量為 4

這樣，我們對於單個Executor 的資源分配好了。我們再來看Executor內部的記憶體分配。

由上面的Spark的記憶體模型可知。Spark的記憶體分為堆內和堆外記憶體。在預設情況下 堆外記憶體=堆內記憶體0.1 (spark.executor.memoryOverhead=spark.executor.memory0.1)
所以簡單的計算一下就可知：

  • spark.executor.memoryOverhead=$\frac{1}{11}*16G(單個Executor的可用的總記憶體)$
  • spark.executor.memory=$\frac{10}{11}*16G(單個Executor的可用總記憶體)$

當然，很多情況下這個結果都不是整數。所以計算出結果後，再進行一些個人的調整就好。

在這裡Executor內部實際的記憶體分配情況如下：

spark.executor.memoryOverhead=2G

spark.executor.memory=14G

到這裡，我們給各個組件的資源就已經分配完畢了。
下麵我們來從Spark任務的角度談一下，一個Spark任務，應該使用多少個Executor合適。

對於一個Spark任務的Executor數量，有靜態分配和動態分配兩種選擇。
我們當然是選擇動態分配。（因為靜態分配相比於動態分配，更容易造成資源的浪費或者Spark任務資源的不足。）

動態分配： 根據Spark任務的工作負載，可用動態的調整所占用的資源（Executor的數量）。需要時申請，不需要時釋放。下麵是動態分配的一些參數的設置

#啟動動態分配
spark.dynamicAllocation.enabled    true
#啟用Spark shuffle服務
spark.shuffle.service.enabled    true
#Executor個數初始值
spark.dynamicAllocation.initialExecutors    1
#Executor個數最小值
spark.dynamicAllocation.minExecutors    1
#Executor個數最大值
spark.dynamicAllocation.maxExecutors    12
#Executor空閑時長，若某Executor空閑時間超過此值，則會被關閉
spark.dynamicAllocation.executorIdleTimeout    60s
#積壓任務等待時長，若有Task等待時間超過此值，則申請啟動新的Executor
spark.dynamicAllocation.schedulerBacklogTimeout    1s
#spark shuffle老版本協議
spark.shuffle.useOldFetchProtocol true

$\color{ForestGreen}{為什麼啟動Spark的shuffle}$：作用是將map的輸出文件落盤。供後續的reduce使用。

$\color{ForestGreen}{為什麼落盤}$：因為如果map的輸出的文件不落盤。map就不會被釋放。也就無法釋放這個空閑的Executor。只有將輸出文件落盤後，這個Executor才會被釋放。

Driver

Driver主要的配置參數有spark.driver.memory和spark.driver.memoryOverhead。

此處spark.driver.memory和spark.driver.memoryOverhead的分配的記憶體比例和Executor一樣。都是spark.driver.memoryOverhead=spark.driver.memory*0.1

對於Driver的總記憶體，有一個經驗公式：（假定yarn.nodemanager.resource.memory-mb設為$X$）

  • 若$X>50G$，則Driver設為12G
  • 若$12G<X<50G$，則Driver設為4G
  • 若$1G<X<12G$，則Driver設為1G

因為我們的yarn.nodemanager.resource.memory-mb=64G。所以：

  • spark.driver.memory = 10G
  • spark.driver.memoryOverhead = 2G

配置文件的設置

spark-defaults.conf

配置文件的位置：$HivE_HOME/conf/spark-defaults.conf

由於我們多個節點有Spark。所以可能會有一些疑問：$\color{ForestGreen}{這麼多Spark，這麼多配置文件，究竟是Spark任務運行的節點 的配置文件生效呢？還是Hive目錄下的配置文件生效呢？}$
答案：當然是Hive目錄下的配置文件生效。如果我們瞭解過Spark的任務提交流程就知道。當我們運行了一條命令行後。Spark-submit會解析參數。然後再向yarn提交請求。

spark.master                               yarn
spark.eventLog.enabled                   true
spark.eventLog.dir    hdfs://myNameService1/spark-history
spark.executor.cores    4
spark.executor.memory    14g
spark.executor.memoryOverhead    2g
spark.driver.memory    10g
spark.driver.memoryOverhead    2g
spark.dynamicAllocation.enabled  true
spark.shuffle.service.enabled  true
spark.dynamicAllocation.executorIdleTimeout  60s
spark.dynamicAllocation.initialExecutors    1
spark.dynamicAllocation.minExecutors  1
spark.dynamicAllocation.maxExecutors  12
spark.dynamicAllocation.schedulerBacklogTimeout 1s
spark.shuffle.useOldFetchProtocol    true

spark-shullfe

Spark的shullfe會因為Cluster Manager（standalone、Mesos、Yarn）的不同而不同。
此處我們是yarn。

步驟如下：

  • 拷貝$SPARK_HOME/yarn/spark-3.0.0-yarn-shuffle.jar到$HADOOP_HOME/share/hadoop/yarn/lib
  • 向集群分發$HADOOP_HOME/share/hadoop/yarn/lib/spark-3.0.0-yarn-shuffle.jar
  • 修改$HADOOP_HOME/etc/hadoop/yarn-site.xml
<property>
    <name>yarn.nodemanager.aux-services</name>
    <value>mapreduce_shuffle,spark_shuffle</value>
</property>

<property>
    <name>yarn.nodemanager.aux-services.spark_shuffle.class</name>
    <value>org.apache.spark.network.yarn.YarnShuffleService</value>
</property>
  • 分發$HADOOP_HOME/etc/hadoop/yarn-site.xml
  • 重啟yarn

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • MySQL 8.0 Reference Manual（讀書筆記41節-- Data Types(3)）
    在實際項目中，從Kafka到HDFS的數據是每天自動生成一個文件，按日期區分。而且Kafka在不斷生產數據，因此看看kettle是不是需要時刻運行？能不能按照每日自動生成數據文件？ 為了測試實際項目中的海豚定時調度從Kafka到HDFS的Kettle任務情況，特地提前跑一下海豚定時調度這個任務，看看 ...
  • 這篇 DolphinScheduler on k8s 雲原生部署實踐，值得所有大數據人看！
    在當前快速發展的技術格局中，企業尋求創新解決方案來簡化運營並提高效率成為一種趨勢。 Apache DolphinScheduler作為一個強大的工具，允許跨分散式系統進行複雜的工作流任務調度。本文將深入探討如何將Apache DolphinScheduler適配並整合進現代IT環境，提升其在雲原生部 ...
  • 達夢資料庫-初步學習
    本文分享自華為雲社區《DTC2024，華為雲資料庫創新融合大發展，打造世界級資料庫！》，作者：GaussDB 資料庫。 4月12日-13日，以“智能·雲原生·一體化——DB與Al協同創新，模型與架構融合發展”為主題的第十三屆數據技術嘉年華(DTC 2024)在北京新雲南皇冠假日酒店成功舉行。作為本次 ...
  • GreatSQL優化技巧：半連接(semijoin)優化
    何為半連接？ 半連接是在GreatSQL內部採用的一種執行子查詢的方式，semi join不是語法關鍵字，不能像使用inner join、left join、right join這種語法關鍵字一樣提供給用戶來編寫SQL語句。 兩個表t1表和t2表進行半連接的含義是：對於t1表的某條記錄來說，我們只關 ...
  • MySQL 8.0 Reference Manual（讀書筆記40節-- Data Types(2)）
    版本說明 由於作者目前接觸當前最新版本為2.3.4 但是官方提供的web版本未1.0.0，不相容2.3.4，因此這裡仍然使用2.3.3版本。 可以自定義相容處理，官方提供了文檔：https://mp.weixin.qq.com/s/Al1VmBoOKu2P02sBOTB6DQ 因為大部分用戶使用Se ...
  • redis哨兵模式的原理及部署
    目錄一、什麼是哨兵模式1、為什麼需要哨兵機制2、哨兵架構拓撲3、Redis Sentinel的功能：二、搭建哨兵架構1、涉及主機2、拓撲結構3、設置一主兩從4、master伺服器狀態5、編輯哨兵的配置文件6、啟動哨兵7、驗證哨兵埠8、查看哨兵日誌9、驗證當前sentinel狀態三、故障轉移1、re ...
  • 天翼雲入選“2023年度數據要素價值創新標桿示範案例”！
    近日，由新一代信息技術產業研究院、賽迪未來產業研究中心共同主辦，中國電子學會區塊鏈分會、至頂科技聯合承辦的“2024未來信息技術大會暨首屆數據要素創新發展論壇”於北京成功舉辦。大會公佈了“2023年度數據要素價值創新標桿示範案例”評選結果，天翼雲“海南省數據產品超市公共數據資源開發利用平臺”與“福州... ...
  • 裁員了！別錯過2024年大數據工程師必備的10項技能
    在當今快速發展的世界中，數據被視為新的石油。隨著對數據驅動洞察的日益依賴，大數據工程師的角色比以往任何時候都更為關鍵。 這些專業人員在管理和優化組織內的數據操作中扮演著至關重要的角色。在本文中，我們將探索2024年大數據工程師必須具備的十項技能。 理解大數據工程師的角色 在深入技能之前，瞭解大數據工 ...
一周排行
    -Advertisement-
    Play Games
  • WPF中輕鬆生成動態圖表：實例詳解(MVVM模式)
    概述：本文代碼示例演示瞭如何在WPF中使用LiveCharts庫創建動態條形圖。通過創建數據模型、ViewModel和在XAML中使用`CartesianChart`控制項，你可以輕鬆實現圖表的數據綁定和動態更新。我將通過清晰的步驟指南包括詳細的中文註釋，幫助你快速理解並應用這一功能。 先上效果： 在 ...
  • .NET 中使用 GaussDB C# ORM
    openGauss(GaussDB ) openGauss是一款全面友好開放，攜手伙伴共同打造的企業級開源關係型資料庫。openGauss採用木蘭寬鬆許可證v2發行，提供面向多核架構的極致性能、全鏈路的業務、數據安全、基於AI的調優和高效運維的能力。openGauss深度融合華為在資料庫領域多年的研 ...
  • .NET中使用 openGauss C# ORM
    openGauss(GaussDB ) openGauss是一款全面友好開放，攜手伙伴共同打造的企業級開源關係型資料庫。openGauss採用木蘭寬鬆許可證v2發行，提供面向多核架構的極致性能、全鏈路的業務、數據安全、基於AI的調優和高效運維的能力。openGauss深度融合華為在資料庫領域多年的研 ...
  • 輕鬆使用Aspire rabbitmq framework
    概述：本示例演示了在WPF應用程式中實現多語言支持的詳細步驟。通過資源字典和數據綁定，以及使用語言管理器類，應用程式能夠在運行時動態切換語言。這種方法使得多語言支持更加靈活，便於維護，同時提供清晰的代碼結構。 在WPF中實現多語言的一種常見方法是使用資源字典和數據綁定。以下是一個詳細的步驟和示例源代 ...
  • .net事件
    描述（做一個簡單的記錄）： 事件（event）的本質是一個委托；（聲明一個事件： public event TestDelegate eventTest;） 委托（delegate）可以理解為一個符合某種簽名的方法類型；比如：TestDelegate委托的返回數據類型為string，參數為 int和 ...
  • .NET CORE 完美支持AOT 的 ORM SqlSugar 教程
    1、AOT適合場景 Aot適合工具類型的項目使用，優點禁止反編 ，第一次啟動快，業務型項目或者反射多的項目不適合用AOT AOT更新記錄: 實實在在經過實踐的AOT ORM 5.1.4.117 +支持AOT 5.1.4.123 +支持CodeFirst和非同步方法 5.1.4.129-preview1 ...
  • 【UWP】修改清單脫離沙盒運行
    總說周知，UWP 是運行在沙盒裡面的，所有許可權都有嚴格限制，和沙盒外交互也需要特殊的通道，所以從根本杜絕了 UWP 毒瘤的存在。但是實際上 UWP 只是一個應用模型，本身是沒有什麼許可權管理的，許可權管理全靠 App Container 沙盒控制，如果我們脫離了這個沙盒，UWP 就會放飛自我了。那麼有沒... ...
  • 《Effective C++》第三版-4. 設計與聲明（Design and Declarations）
    目錄條款17：讓介面容易被正確使用，不易被誤用（Make interfaces easy to use correctly and hard to use incorrectly）限制類型和值規定能做和不能做的事提供行為一致的介面條款19：設計class猶如設計type（Treat class de ...
  • 從零開始：Django項目的創建與配置指南
    title: 從零開始：Django項目的創建與配置指南 date: 2024/5/2 18:29:33 updated: 2024/5/2 18:29:33 categories: 後端開發 tags: Django WebDev Python ORM Security Deployment Op ...
  • mORMot 1.18 第18章 使用REST/JSON的客戶端/伺服器
    1、BOM對象 BOM:Broswer object model,即瀏覽器提供我們開發者在javascript用於操作瀏覽器的對象。 1.1、window對象 視窗方法 // BOM Browser object model 瀏覽器對象模型 // js中最大的一個對象.整個瀏覽器視窗出現的所有東西都 ...
所有分類