偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

如何根據(jù)數(shù)據(jù)冷熱程度分層存儲(chǔ),讓HDFS更高效?

存儲(chǔ)
隨著大數(shù)據(jù)技術(shù)相關(guān)技術(shù)的發(fā)展和普及,越來越多的公司開始使用基于開源Hadoop的平臺(tái)系統(tǒng),同時(shí),越來越多的業(yè)務(wù)和應(yīng)用也在從傳統(tǒng)的技術(shù)架構(gòu)遷移到大數(shù)據(jù)平臺(tái)上。在典型的Hadoop大數(shù)據(jù)平臺(tái)中,人們使用HDFS作為存儲(chǔ)服務(wù)的核心。

主題簡(jiǎn)介:

HDFS優(yōu)化存儲(chǔ)功能講解

SSM系統(tǒng)架構(gòu)設(shè)計(jì)

SSM系統(tǒng)應(yīng)用場(chǎng)景分析

一、背景

隨著大數(shù)據(jù)技術(shù)相關(guān)技術(shù)的發(fā)展和普及,越來越多的公司開始使用基于開源Hadoop的平臺(tái)系統(tǒng),同時(shí),越來越多的業(yè)務(wù)和應(yīng)用也在從傳統(tǒng)的技術(shù)架構(gòu)遷移到大數(shù)據(jù)平臺(tái)上。在典型的Hadoop大數(shù)據(jù)平臺(tái)中,人們使用HDFS作為存儲(chǔ)服務(wù)的核心。

而在大數(shù)據(jù)發(fā)展之初,最主要的應(yīng)用場(chǎng)景仍然是離線批處理場(chǎng)景,對(duì)存儲(chǔ)的需求追求的是吞吐量,HDFS正是針對(duì)這樣的場(chǎng)景而設(shè)計(jì)的,而隨著技術(shù)不斷的發(fā)展,越來越多的場(chǎng)景會(huì)對(duì)存儲(chǔ)提出新的需求,HDFS也面臨著新的挑戰(zhàn)。主要包括幾個(gè)方面:

[[208366]]

1、數(shù)據(jù)量問題

一方面隨著業(yè)務(wù)的增長(zhǎng)和新的應(yīng)用接入,會(huì)給HDFS帶來更多的數(shù)據(jù),另一方面隨著深度學(xué)習(xí),人工智能等技術(shù)的發(fā)展,用戶通常希望能保存更長(zhǎng)時(shí)間的數(shù)據(jù),以提升深度學(xué)習(xí)的效果。數(shù)據(jù)量的快速增加會(huì)使集群不斷面臨擴(kuò)容需求,從而導(dǎo)致存儲(chǔ)成本不斷增加。

2、小文件問題

眾所周知,HDFS的設(shè)計(jì)是針對(duì)離線批處理大文件的,處理小文件并非傳統(tǒng)HDFS擅長(zhǎng)的場(chǎng)景。HDFS小文件問題的根源在于文件的元數(shù)據(jù)信息都是維護(hù)在單點(diǎn)Namenode的內(nèi)存中,單臺(tái)機(jī)器的內(nèi)存空間始終是有限的。據(jù)估算,單臺(tái)namenode集群能容納系統(tǒng)文件數(shù)量極限大約在1.5億左右。實(shí)際上,HDFS平臺(tái)通常作為底層存儲(chǔ)平臺(tái)服務(wù)于上層多種計(jì)算框架,多個(gè)業(yè)務(wù)場(chǎng)景,所以小文件問題從業(yè)務(wù)的角度也難以避免。目前也有方案例如HDFS-Federation解決Namenode單點(diǎn)擴(kuò)展性問題,但同時(shí)也會(huì)帶來巨大的運(yùn)維管理難度。

3、冷熱數(shù)據(jù)問題

隨著數(shù)據(jù)量的不斷增長(zhǎng)積累,數(shù)據(jù)也會(huì)呈現(xiàn)出訪問熱度不同的巨大差異。例如一個(gè)平臺(tái)會(huì)不斷地寫入***的數(shù)據(jù),但通常情況下最近寫入的數(shù)據(jù)訪問頻率會(huì)比很久之前的數(shù)據(jù)高很多。如果無論數(shù)據(jù)冷熱情況,都采用同樣的存儲(chǔ)策略,是對(duì)集群資源的一種浪費(fèi)。如何根據(jù)數(shù)據(jù)冷熱程度對(duì)HDFS存儲(chǔ)系統(tǒng)進(jìn)行優(yōu)化是一個(gè)亟待解決的問題。

二、現(xiàn)有HDFS優(yōu)化技術(shù)

從Hadoop誕生到今天也有超過10年的時(shí)間,在此期間HDFS技術(shù)本身也在不斷優(yōu)化演進(jìn)。HDFS現(xiàn)有一些技術(shù)能夠一定程度上解決上述一些問題。這里簡(jiǎn)要介紹一下HDFS異構(gòu)存儲(chǔ)和HDFS糾刪碼技術(shù)。

HDFS異構(gòu)存儲(chǔ):

Hadoop從2.6.0版本開始支持異構(gòu)存儲(chǔ)功能。我們知道HDFS默認(rèn)的存儲(chǔ)策略,對(duì)于每個(gè)數(shù)據(jù)塊,采用三個(gè)副本的存儲(chǔ)方式,保存在不同節(jié)點(diǎn)的磁盤上。異構(gòu)存儲(chǔ)的作用在于利用服務(wù)器不同類型的存儲(chǔ)介質(zhì)(包括HDD硬盤、SSD、內(nèi)存等)提供更多的存儲(chǔ)策略(例如三個(gè)副本一個(gè)保存在SSD介質(zhì),剩下兩個(gè)仍然保存在HDD硬盤),從而使得HDFS的存儲(chǔ)能夠更靈活高效地應(yīng)對(duì)各種應(yīng)用場(chǎng)景。

HDFS中預(yù)定義支持的各種存儲(chǔ)包括:

  • ARCHIVE:高存儲(chǔ)密度但耗電較少的存儲(chǔ)介質(zhì),例如磁帶,通常用來存儲(chǔ)冷數(shù)據(jù)
  • DISK:磁盤介質(zhì),這是HDFS最早支持的存儲(chǔ)介質(zhì)
  • SSD:固態(tài)硬盤,是一種新型存儲(chǔ)介質(zhì),目前被不少互聯(lián)網(wǎng)公司使用
  • RAM_DISK :數(shù)據(jù)被寫入內(nèi)存中,同時(shí)會(huì)往該存儲(chǔ)介質(zhì)中再(異步)寫一份

HDFS中支持的存儲(chǔ)策略包括:

  1. Lazy_persist:一個(gè)副本保存在內(nèi)存RAM_DISK中,其余副本保存在磁盤中
  2. ALL_SSD:所有副本都保存在SSD中
  3. One_SSD:一個(gè)副本保存在SSD中,其余副本保存在磁盤中
  4. Hot:所有副本保存在磁盤中,這也是默認(rèn)的存儲(chǔ)策略
  5. Warm:一個(gè)副本保存在磁盤上,其余副本保存在歸檔存儲(chǔ)上
  6. Cold:所有副本都保存在歸檔存儲(chǔ)上

總體上HDFS異構(gòu)存儲(chǔ)的價(jià)值在于,根據(jù)數(shù)據(jù)熱度采用不同策略從而提升集群整體資源使用效率。對(duì)于頻繁訪問的數(shù)據(jù),將其全部或部分保存在更高訪問性能的存儲(chǔ)介質(zhì)(內(nèi)存或SSD)上,提升其讀寫性能;對(duì)于幾乎不會(huì)訪問的數(shù)據(jù),保存在歸檔存儲(chǔ)介質(zhì)上,降低其存儲(chǔ)成本。但是HDFS異構(gòu)存儲(chǔ)的配置需要用戶對(duì)目錄指定相應(yīng)的策略,即用戶需要預(yù)先知道每個(gè)目錄下的文件的訪問熱度,在實(shí)際大數(shù)據(jù)平臺(tái)的應(yīng)用中,這是比較困難的一點(diǎn)。

HDFS糾刪碼:

傳統(tǒng)HDFS數(shù)據(jù)采用三副本機(jī)制保證數(shù)據(jù)的可靠性,即每存儲(chǔ)1TB數(shù)據(jù),實(shí)際在集群各節(jié)點(diǎn)上占用的數(shù)據(jù)達(dá)到3TB,額外開銷為200%。這給節(jié)點(diǎn)磁盤存儲(chǔ)和網(wǎng)絡(luò)傳輸帶來了很大的壓力。

在Hadoop3.0開始引入支持HDFS文件塊級(jí)別的糾刪碼,底層采用Reed-Solomon(k,m)算法。RS是一種常用的糾刪碼算法,通過矩陣運(yùn)算,可以為k位數(shù)據(jù)生成m位校驗(yàn)位,根據(jù)k和m的取值不同,可以實(shí)現(xiàn)不同程度的容錯(cuò)能力,是一種比較靈活的糾刪碼算法。

常見的算法為RS(3,2)、RS(6,3)、RS(10,4),k個(gè)文件塊和m個(gè)校驗(yàn)塊構(gòu)成一個(gè)組,這個(gè)組內(nèi)可以容忍任意m個(gè)數(shù)據(jù)塊的丟失。

HDFS糾刪碼技術(shù)能夠降低數(shù)據(jù)存儲(chǔ)的冗余度,以RS(3,2)為例,其數(shù)據(jù)冗余度為67%,相比Hadoop默認(rèn)的200%大為減少。但是糾刪碼技術(shù)存儲(chǔ)數(shù)據(jù)和數(shù)據(jù)恢復(fù)都需要消耗cpu進(jìn)行計(jì)算,實(shí)際上是一種以時(shí)間換空間的選擇,因此比較適用的場(chǎng)景是對(duì)冷數(shù)據(jù)的存儲(chǔ)。冷數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)往往一次寫入之后長(zhǎng)時(shí)間沒有訪問,這種情況下可以通過糾刪碼技術(shù)減少副本數(shù)。

三、大數(shù)據(jù)存儲(chǔ)優(yōu)化:SSM

前面介紹的無論HDFS異構(gòu)存儲(chǔ)還是糾刪碼技術(shù),前提都是需要用戶對(duì)特定的數(shù)據(jù)指定存儲(chǔ)的行為,就是說用戶需要知道哪些數(shù)據(jù)是熱點(diǎn)數(shù)據(jù),哪些是冷數(shù)據(jù)。那有沒有一種方法可以自動(dòng)對(duì)存儲(chǔ)進(jìn)行優(yōu)化呢?

答案是有的,這里介紹的SSM(Smart Storage Management)系統(tǒng),它從底層存儲(chǔ)(通常是HDFS)中獲取元數(shù)據(jù)信息,并通過數(shù)據(jù)讀寫訪問信息分析獲取數(shù)據(jù)熱度情況,針對(duì)不同熱度的數(shù)據(jù),按照預(yù)先制定的一系列規(guī)則,采用相應(yīng)的存儲(chǔ)優(yōu)化策略,從而提升整個(gè)存儲(chǔ)系統(tǒng)的效率。SSM是一個(gè)由Intel主導(dǎo)的開源的項(xiàng)目,中國移動(dòng)也參與其中的研發(fā),項(xiàng)目可以在Github中獲取到:https://github.com/Intel-bigdata/SSM 。

SSM定位是一個(gè)存儲(chǔ)外圍優(yōu)化的系統(tǒng),整體上采用Server-Agent-Client的架構(gòu),其中Server負(fù)責(zé)SSM整體邏輯的實(shí)現(xiàn),Agent用于對(duì)存儲(chǔ)集群執(zhí)行各種操作,Client是提供給用戶的數(shù)據(jù)訪問接口,通常其中包含了原生HDFS的接口。

SSM-Server的主要框架如上圖所示,從上到下,StatesManager與HDFS集群進(jìn)行交互,用于獲取HDFS元數(shù)據(jù)信息,并維護(hù)每個(gè)文件的訪問熱度信息。StatesManager中的信息會(huì)持久化到關(guān)系型數(shù)據(jù)庫中。在SSM中采用TiDB作為底層存儲(chǔ)的數(shù)據(jù)庫。RuleManager維護(hù)和管理規(guī)則相關(guān)信息,用戶通過前臺(tái)界面為SSM定義一系列存儲(chǔ)規(guī)則,RuleManger負(fù)責(zé)規(guī)則的解析和執(zhí)行。CacheManager/StorageManager根據(jù)熱度和規(guī)則,生成具體的action任務(wù)。ActionExecutor 負(fù)責(zé)具體的action任務(wù),把任務(wù)分配給Agent,并在Agent節(jié)點(diǎn)執(zhí)行。

SSM-Server內(nèi)部邏輯實(shí)現(xiàn)依賴于規(guī)則的定義,需要管理員通過前臺(tái)web頁面為SSM系統(tǒng)制定一系列規(guī)則。一條規(guī)則包括幾部分組成:

  • 操作對(duì)象,通常是指符合特定條件的文件。
  • 觸發(fā)器,指規(guī)則觸發(fā)的時(shí)間點(diǎn),例如每天定時(shí)觸發(fā)。
  • 執(zhí)行條件,定義一系列基于熱度的條件,例如文件在一段時(shí)間訪問次數(shù)計(jì)數(shù)要求。
  • 執(zhí)行操作,對(duì)符合執(zhí)行條件的數(shù)據(jù)進(jìn)行相關(guān)操作,通常是指定其存儲(chǔ)策略等。

一個(gè)實(shí)際的規(guī)則示例:

file.path matchs ”/foo/*”: accessCount(10min) >= 3 | one-ssd

這條規(guī)則表示對(duì)于在/foo目錄下的文件,滿足10分鐘內(nèi)被訪問次數(shù)不低于三次,則對(duì)其采用One-SSD的存儲(chǔ)策略,即數(shù)據(jù)一個(gè)副本保存在SSD上,剩余2個(gè)副本保存在普通磁盤上。

四、SSM應(yīng)用場(chǎng)景

SSM能夠針對(duì)數(shù)據(jù)的冷熱程度,采用不同存儲(chǔ)策略進(jìn)行優(yōu)化,以下是一些典型的應(yīng)用場(chǎng)景:

最典型的場(chǎng)景就是針對(duì)冷數(shù)據(jù),如上圖所示,定義相關(guān)規(guī)則,將較長(zhǎng)時(shí)間為沒有訪問的數(shù)據(jù)采用更低成本的存儲(chǔ)。例如原先的數(shù)據(jù)塊,從SSD存儲(chǔ)退化到HDD存儲(chǔ)。

與此類似,對(duì)于熱點(diǎn)的數(shù)據(jù),同樣可以根據(jù)不同的規(guī)則,對(duì)其采用更快速的存儲(chǔ)策略,如上圖所示,短時(shí)間內(nèi)訪問此處較多的熱點(diǎn)數(shù)據(jù),會(huì)從HDD存儲(chǔ)上升至SSD存儲(chǔ),更熱點(diǎn)的數(shù)據(jù)會(huì)采用內(nèi)存存儲(chǔ)的策略。

針對(duì)冷數(shù)據(jù)的場(chǎng)景,SSM也可以采用糾刪碼的優(yōu)化,通過定義相應(yīng)規(guī)則,對(duì)于訪問次數(shù)很少的冷數(shù)據(jù),對(duì)其執(zhí)行erasure code操作,降低數(shù)據(jù)副本冗余。

另外值得一提的是SSM針對(duì)小文件也有相應(yīng)優(yōu)化手段,這個(gè)功能仍然處于開發(fā)過程中。大體邏輯是SSM會(huì)對(duì)HDFS上一系列小文件執(zhí)行合并成大文件的操作,同時(shí),在SSM的元數(shù)據(jù)中記錄下原始小文件和合并后大文件的映射關(guān)系以及每個(gè)小文件在大文件中的偏移量。當(dāng)用戶需要訪問小文件時(shí),通過SSM特定的客戶端(SmartClient),根據(jù)SSM元數(shù)據(jù)中的小文件映射信息,從合并后的文件中獲取到原始小文件。

***SSM是個(gè)開源的項(xiàng)目,目前仍然在非??焖俚牡葸M(jìn)過程中,歡迎任何感興趣的朋友參與項(xiàng)目的開發(fā)貢獻(xiàn)。

Q&A

Q1:HDFS自行搭建應(yīng)該從多大規(guī)模開始?

A1:HDFS支持偽分布模式,即使只有一個(gè)節(jié)點(diǎn),也能搭建一個(gè)HDFS系統(tǒng)。如果希望更好體驗(yàn)和理解HDFS的分布式架構(gòu),建議有3到5個(gè)節(jié)點(diǎn)的環(huán)境來搭建。

Q2:蘇研在實(shí)際各省的大數(shù)據(jù)平臺(tái)用SSM了嗎?

A2:目前還沒有,這個(gè)項(xiàng)目還在快速發(fā)展中,需要等到測(cè)試穩(wěn)定后才會(huì)逐步用到生產(chǎn)上。

Q3:HDFS和Spark區(qū)別是什么?優(yōu)缺點(diǎn)呢?

A3:HDFS和Spark并不是同一個(gè)層面上的技術(shù),HDFS是存儲(chǔ)系統(tǒng),而Spark是一種計(jì)算引擎。我們經(jīng)常拿來和Spark對(duì)標(biāo)的是Hadoop中的Mapreduce計(jì)算框架而非HDFS存儲(chǔ)系統(tǒng)。在實(shí)際項(xiàng)目建設(shè)中,通常HDFS和Spark是協(xié)作的關(guān)系,底層存儲(chǔ)使用HDFS,上層計(jì)算使用Spark。

責(zé)任編輯:武曉燕 來源: DBAplus社群
相關(guān)推薦

2015-04-02 12:42:26

HDFS分層存儲(chǔ)高效

2019-04-19 08:47:00

前端監(jiān)控數(shù)據(jù)

2023-09-12 16:20:04

邊緣AI深度學(xué)習(xí)

2018-05-08 14:58:07

戴爾

2010-12-12 09:40:00

Android UI設(shè)

2015-09-30 14:22:44

Qlik數(shù)據(jù)

2023-11-24 11:20:04

functoolsPython

2016-06-30 16:54:49

UCloud愛數(shù)云計(jì)算

2011-07-21 13:52:43

組策略網(wǎng)絡(luò)打印機(jī)

2016-09-29 13:44:23

數(shù)據(jù)中心

2024-12-20 16:41:22

2025-04-24 08:40:00

JavaScript代碼return語句

2017-12-21 14:36:10

大數(shù)據(jù)健身智慧

2011-08-29 09:33:48

2015-12-31 11:57:17

華為eLTE物聯(lián)網(wǎng)

2013-04-03 09:49:48

LinkedIn大數(shù)據(jù)

2024-06-24 00:05:00

Python代碼

2010-12-23 15:55:00

上網(wǎng)行為管理

2018-10-23 15:20:29

SparkShuffleSpark SQL
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)