Cloudera Manager擴展MariaDB服務的方法研究

黃杰 馬凱 陳雪瓶 孫伯清 何宏靖

DOI：10.19850/j.cnki.2096-4706.2024.02.021

收稿日期：2023-05-10

基金項目：重慶工程學院校本科研項目（2022xzcr04）

摘? 要：大數(shù)據(jù)平臺的優(yōu)點在于能夠快速處理超出單機能力的數(shù)據(jù)，平臺中的數(shù)據(jù)倉庫不僅具備存儲功能，還兼具離線式的數(shù)據(jù)處理和分析能力。然而，數(shù)據(jù)倉庫在服務響應方面效率不高，并且事務處理支持較弱，因此許多企業(yè)仍采用傳統(tǒng)關系數(shù)據(jù)庫提供查詢和聯(lián)機事務處理服務。Cloudera Manager管理的CDH可以動態(tài)擴展數(shù)據(jù)倉庫，但不能部署關系數(shù)據(jù)庫，為突破這局限性，以MariaDB為研究對象，并利用Cloudera Manager的擴展能力引入MariaDB parcel應用包和CSD管理包用來實現(xiàn)對其部署和管理。最終，經(jīng)過實際驗證，通過Cloudera Manager可視化動態(tài)部署和監(jiān)控管理MariaDB服務是完全可行的，這為關系數(shù)據(jù)庫服務的擴展奠定了基礎。

關鍵詞：Cloudera Manager擴展；部署MariaDB服務；Parcel包；Custom Service Descriptors

中圖分類號：TP311.5? ? 文獻標識碼：A? ? 文章編號：2096-4706（2024）02-0096-06

Research on the Method of Extending MariaDB Service of Cloudera Manager

HUANG Jie， MA Kai， CHEN Xueping， SUN Boqing， HE Hongjing

（Chongqing Institute of Engineering， Ba'nan? 400056， China）

Abstract： The advantage of big data platforms is that they can quickly process data beyond the capacity of individual machines. The data warehouse in the platform not only has the storage function， but also has the offline data processing and analysis ability. However， data warehouses are not efficient in service response and the support of transaction processing is weak， so many enterprises still use traditional relational databases to provide query and online transaction processing services. CDH managed by Cloudera Manager can dynamically expand the data warehouse， but cannot deploy the relational database. In order to break this limitation， this paper takes MariaDB as the research object， uses the extension capability of Cloudera Manager to introduce MariaDB parcel application package and CSD management package， so as to deploy and manage them. Finally， after actual verification， it is feasible to dynamically deploy and monitor and manage MariaDB services visually through Cloudera Manager， laying the foundation for the expansion of relational database services.

Keywords： Cloudera Manager extension; deployment of MariaDB service; Parcel package; Custom Service Descriptors

0? 引? 言

經(jīng)過近幾年大數(shù)據(jù)的高速發(fā)展，大數(shù)據(jù)應用產(chǎn)品及研究產(chǎn)物在業(yè)界催生下層出不窮，其中Cloudera公司主要大數(shù)據(jù)產(chǎn)品CDH（Cloudera's Distribution Including Apache Hadoop）/CDP（Cloudera Data Platform）尤為知名。CDH是最完整的Apache Hadoop及相關項目的發(fā)行版[1]，具有大數(shù)據(jù)倉庫可擴展存儲和分布式計算的功能，但其本身在實時服務上表現(xiàn)有所不足，通常有高延遲[2]、不支持事務性[3，4]操作以及不具備數(shù)據(jù)增刪改的功能等缺陷。一種解決方案是以定時運行的方式利用計算框架計算得到分析結果的數(shù)據(jù)更新提供數(shù)據(jù)服務的數(shù)據(jù)庫中對應數(shù)據(jù)，進而實現(xiàn)非實時數(shù)據(jù)更新服務，也能實現(xiàn)事務性等操作。

Cloudera Manager[5]（后文簡稱CM）是用于管理CDH集群的應用程序，具有可視化部署CDH功能以及動態(tài)擴展CDH節(jié)點以增加CDH網(wǎng)絡算力[6]的能力。如果CM能可視化部署或者擴展CDH，那么MariaDB數(shù)據(jù)庫是否也能集成到CM之中接受CM管控呢？答案是肯定的。本文旨在解決如何使用CM可視化部署和管理MariaDB服務，擴大CM管理的范圍，為CM擴展新應用打下牢固的基礎。

在遵從CM應用部署規(guī)則的情況下，從CM擴展功能出發(fā)，研發(fā)MariaDB的Parcel應用包和CSD（Custom Service Descriptors）管理信息包，以至于能夠使用CM部署管理MariaDB服務。在完成研發(fā)擴展包后，主要從四方面進行驗證：一是在CM UI（CM的用戶界面）界面檢查MariaDB信息是否存在；二是測試利用CMUI添加MariaDB服務是否能夠順利部署；三是測試部署好的MariaDB服務被CM UI管理操作是否出現(xiàn)異常，比如停止是否異常；四是對MariaDB進行連接測試是否存在異常。通過實驗表明，利用CM擴展MariaDB是完全有效的。

本文第1節(jié)介紹CM和MariaDB的概念；第2節(jié)介紹CM擴展功能，并解讀其具體構成；第3節(jié)配置MariaDB的參數(shù)，并在CM UI上驗證研發(fā)的MariaDB擴展包是否有效；第4節(jié)總結本文工作。

1? 相關介紹

1.1? CM介紹

CM是管理CDH集群的端到端應用程序。CM制定了可視化的企業(yè)部署的標準，能控制CDH集群授權操作的每部分，具有增強性能、強化服務質(zhì)量、提高順從性以及減少管理成本作用。通過CM可以容易地部署和中心化操作整個CDH棧和其他受控服務，能夠自動安裝程序，減少大量安裝時間，提供一個中心控制平臺能夠改變整個集群的配置，以及集成了日志和診斷工具進行監(jiān)控集群環(huán)境[7]。

CM以Server為中心節(jié)點，其中心服務與數(shù)據(jù)庫進行元數(shù)據(jù)交互，提供集群管理服務，并與客戶端進行交互，管理著以Agent管理的服務和接受CM管控的應用程序，如圖1所示，從遠程Cloudera Repository庫獲取最新和更多應用軟件。每個部件都有在其位置對應的作用，如表1所示。

CM管理的主機間是通過心跳機制完成信息和命令同步。默認情況下，每個Agent間隔15秒向CM服務器發(fā)送一次心跳。當狀態(tài)改變時，為了減少用戶延遲，心跳頻率會增加。通過心跳交換，Agent將正在進行的活動報告給CM服務器，同樣地，CM服務器會將當前任務反應給Agent。例如，如果在CM UI上啟動了一個服務，Agent會嘗試啟動相關進程；如果進程啟動失敗，CM服務會將啟動命令標記為失敗。

圖1? Cloudera Manager架構

Clients 與服務器交互的接口：

1）管理控制臺——基于Web的用戶界面，管理員可以使用它管理集群和Cloudera Manager

2）API——開發(fā)人員用來創(chuàng)建自定義Cloudera Manager應用程序的API

1.2? MariaDB介紹

MariaDB[8]是一個全球流行的開源關系數(shù)據(jù)庫，由MySQL的原始開發(fā)人員設計開發(fā)，與MySQL兼容，并被承諾永久保持開源狀態(tài)，能夠輕松部署并兼容所有主流Linux發(fā)行版本，比如：CentOS系列、Debian Linux系列及衍生版本等。目前擁有兩種類型版本：Community版（MariaDB Community Server）和Enterprise版（MariaDB Enterprise Server），其中Enterprise版本構建在Community版本上，借助MariaDB MaxScale數(shù)據(jù)庫代理，提供一流的性能、數(shù)據(jù)安全性、復制、集群和高可用性。并且可以在任何云（含私有云、公共云、混合云）中從單個節(jié)點擴展到全球規(guī)模，適用于從OLTP到OLAP的任何工作負載。

MariaDB具有數(shù)據(jù)倉庫的特性：

1）兼容現(xiàn)代SQL，支持現(xiàn)代SQL特性，如公共表表達式（CTEs）、窗口函數(shù)、時態(tài)數(shù)據(jù)表和JSON函數(shù)。MariaDB的SQL與MySQL兼容，同時擴展了柱狀存儲以及其他功能。

2）可插拔式存儲引擎，InnoDB、Aria、ColumnStore、MyRocks以及其他第三方引擎都允許MariaDB使用前端進行擴展，不僅僅是事務處理。

3）柱狀存儲，MariaDB列存儲功能植入MariaDB Community Server中，用于柱狀分析（MPP）或混合事務分析處理（HTAP）。

4）集群化，Galera集群引擎實現(xiàn)集群的復制和狀態(tài)轉換。

5）高可用性，MaxScale是能夠?qū)崿F(xiàn)故障轉移和事務重放的數(shù)據(jù)庫代理。

6）復雜關系支持，高版本MariaDB支持JSON數(shù)據(jù)類型，其中使用了“混合關系/JSON”數(shù)據(jù)模型，擁有更大的模式靈活性和更快的開發(fā)速度，除了能將數(shù)據(jù)存儲為JSON，還提供了一套完整的JSON函數(shù)進行查詢。

針對不同的應用場景，MariaDB提供了對應策略，相對地使用不同的數(shù)據(jù)庫架構，如：圖2是一個OLTP架構，使用MaxScale作數(shù)據(jù)庫代理實現(xiàn)自動故障切換，數(shù)據(jù)后臺數(shù)據(jù)庫同步實現(xiàn)高可用，ES表示企業(yè)版服務。圖3是Galera集群架構，主要不同是后臺數(shù)據(jù)同步以Galera集群冗余的方式實現(xiàn)虛擬同步。圖4中的混合結構是兼顧分析和事務處理，支撐不同引擎之間的Join操作。

2? CM擴展機制

CM是一個用于管理CDH服務及其所運行集群的工具。通過使用CM擴展機制[9]，CM集群中能夠正常部署除Cloudera提供的CDH范圍內(nèi)的服務，如：非Cloudera提供的軟件MariaDB，還能夠為此類應用進行如同CDH類似的管理和監(jiān)控。

CM通過它的兩個部分（Parcel包部分和CSD部分）與MariaDB建立聯(lián)系，如圖5 Parcel包含有應用程序的二進程代碼和與CM和CSD聯(lián)系的元信息，其中關鍵文件是parcel.json。CSD提供了能在CM UI上展示現(xiàn)出來的軟件基本信息和控制MariaDB的服務信息，與CM聯(lián)系的service.sdl文件詳述了CMUI所有行為描述。Parcel包和CSD具有一定的聯(lián)系，CSD通過Parcel包提供的tags識別目標應用軟件，因此，CM方能管控MariaDB應用服務。

2.1? meta文件結構

以MariaDB為例說明（下同），在Parcel包中，meta文件夾是CM能夠識別有效Parcel包的必要組成部分，該路徑文件結構如圖6所示。它路徑下可以包含多級文件路徑及其路徑下的文件，其中Parcel.json和mariadb-env.sh是MariaDB parcel包必備配置文件，在meta根路徑下，決定了Parcel包是否能被CM有效使用。

2.2? parcel.json結構

關于parcel.json，其內(nèi)容結構是一個JSON格式，存儲著Parcel配置信息，它能夠被CM服務解析，解析出的信息能夠被CM充分利用，如提供版本信息。parcel.json內(nèi)容這里分為三部分：基礎信息、加載信息和用戶權限。

2.2.1? 基礎信息

JSON文件中基礎信息包含name、version、packages以及components。name表示Parcel包的名字，命名規(guī)則除了不能使用短橫線“-”，其他字符沒有明確限制，并且不能和其他已存在CM中的應用重復；version描述Parcel包的版本號；packages不為CM提供任何信息，純粹記錄子包信息，描述了兩個信息，子包的name和version；components描述Parcel包的對應邏輯組件，記錄的信息提供給CM服務，進而供用戶查看參考。它下面有四個信息項，name描述組件名，version描述組件的版本號，pkg_version表示組件打包的版本號，pkg_release表示組件打包發(fā)行的版本號。

2.2.2? 加載信息

這部分包含provides和scripts兩項。provides字段是一個字符串列表，提供一組標簽（圖5中的tags），CM可以通過這組標簽識別Parcel包的軟件服務。因此，命名時應當避開CM內(nèi)置的標簽，也要避免使用已經(jīng)存在的第三方標簽，更不能使用“*”命名標簽，否則這會影響所有進程。標簽對于CM具有區(qū)分Parcel包的作用，當CM啟動一個服務時后臺開啟一個進程，這個進程就會請求訪問一個或者多個Parcel中的文件。為了避免把每個進程暴露給每個Parcel，便有了標簽的概念。通過Parcel發(fā)布標簽，服務通過訂閱標簽的方式，就能實現(xiàn)什么Parcel影響什么進程，不干擾其他進程。scripts字段只有defines一個項，用于指定環(huán)境腳本程序路徑，該項只能定義一個腳本。

2.2.3? 用戶權限

用戶權限用于指定訪問用戶及其組，這項有users和groups兩項。users項主要包含五個信息，用戶名、用戶的描述名稱（longname）、用戶的主目錄（home）、用戶的shell程序（shell）、用戶要加入的其他組的列表（extra_groups）。CM不允許配置應用軟件要求禁用的用戶。groups這項是創(chuàng)建除了用戶部分中列出的每個用戶創(chuàng)建的每個用戶組之外的用戶組列表。在運行應用軟件時，CM服務會檢查環(huán)境中用戶的信息，若沒有發(fā)現(xiàn)用戶信息則會創(chuàng)建該用戶以及組（如MariaDB應用軟件設置MySQL用戶和MySQL組，則會創(chuàng)建MySQL用戶和MySQL組），以至于應用軟件能夠在用戶權限內(nèi)正常運行。

2.3? Parcel定義腳本

Parcel定義腳本（如mariadb-env.sh文件）是一個關鍵組件，它允許Parcel影響CM管理的進程。由于Parcel位于它們自己獨立的目錄中，所以不會有什么程序發(fā)現(xiàn)它們，也不會在其中查找文件，定義腳本恰好補充了這點。定義腳本定義并export環(huán)境變量，通過這些變量能夠找到程序啟動程序。CM設置兩個特殊變量，用于Parcel確定其所在位置，PARCELS_ROOT是文件系統(tǒng)中所有包所在的目錄（默認值：/opt/cloudera/parcels）。PARCEL_DIRNAME是PARCELS_ROOT下的包目錄的名稱。因此，激活的Parcel軟件應用的絕對路徑是PARCELS_ROOT/PARCEL_DIRNAME（若定義PARCEL_DIRNAME值是MARIADB，則該路徑為：/opt/cloudera/parcels/MARIADB）。

2.4? Parcel包的形成

Parcel本身是一個gzip壓縮包，后綴以parcel表示。它包含了部署的所有文件和一些定義的元數(shù)據(jù)（如圖6所示）。Parcel包的命名格式必須為[name]-[version]-[distro_suffix].parcel，其中distro_suffix表示系統(tǒng)版本，如：el7可用于Redhat Enterprise Linux 7及其克隆版Centos 7。

2.5? CSD主路徑結構

MariaDB parcel包與MariaDB CSD一起工作能更好地完成協(xié)同工作，因為使用CSD的第三方服務可以利用CM的特性，如監(jiān)控、資源管理、配置、分發(fā)、生命周期管理等。CSD文件結構包含scripts、descriptor和aux路徑，如圖7所示，主要有control.sh文件、service.mdl和service.sdl文件。其中MariaDB服務僅考慮service.sdl和control.sh文件，它們決定了MariaDB服務是否能正常運行以及是否能順利被CM管控。

2.6? service.sdl文件配置

CSD的核心是服務描述符語言（Service Descriptor Language， SDL）文件：descriptor/service.sdl，用于向CM描述CSD服務細節(jié)。整個文件內(nèi)容由一個JSON結構呈現(xiàn)，描述了如何管理與CSD同名的服務。其作用主要有：提供服務類型和關聯(lián)的角色類型信息；如何啟動服務和角色；配置服務/角色參數(shù)；配置文件生成器。嚴格地是service.sdl文件必須位于descriptor目錄中，否則CM服務無法進行解析。MariaDB service.sdl主要包含：name表示服務邏輯名，規(guī)則是大寫英文字母、數(shù)字和下劃線的組合并且全局唯一；label在UI顯示，面向用戶；description向用戶提供服務描述；version定義版本是CSD包命名規(guī)則的一部分；定義Parcel的子項requiredTags用于匹配Parcel的標簽；roles子結構主要定義角色，關聯(lián)腳本（如control.sh）配置具體行為。

2.7? control.sh描述

scripts目錄包含用于控制底層服務的所有可執(zhí)行腳本，如control.sh，這些腳本會被service.sdl文件內(nèi)容指定。能用任何可以在集群上執(zhí)行的語言編寫，通常使用Bash，因為它默認內(nèi)置在常見的Linux中。在運行時，此目錄中的所有文件發(fā)送給CM管理的Agent，并寫入Agent的進程路徑下。當啟動一個角色進程或者執(zhí)行一個角色命令或者部署客戶端配置時，會執(zhí)行這些腳本。通常control.sh提供應用軟件的啟動和關閉，CM的這些行為沒有默認的參數(shù)比如“start”“stop”等，具體行為在SDL文件中定義。

2.8? CSD包的形成

CSD包是一個jar文件，包含了圖7中的所有文件，其命名規(guī)則為：--.jar，文件名的extra是為使用maven構建時CSD的快照構建保留，如“MARIADB-1.0.1-SNAPSHOT.jar”。

2.9? Parcel包和CSD的部署流程

若CM與Parcel和CSD需要建立聯(lián)系，還需有以下步驟：

1）Parcel包放入CM的parcels-repo路徑下并將其sha1碼植入同名sha文件中，以至于能確保Parcel包的完整性。

2）CSD包置入CM的csd路徑中，以確保CM能通過此路徑找到MariaDB的管理應用程序。

3）重啟完成配置更新，運行的CM并不能識別到CSD。

4）完成，如果沒有出現(xiàn)錯誤，通過CM UI能夠正常管控MariaDB服務。

3? 實現(xiàn)效果

3.1? 配置部署

以MariaDB 10.6.12版本為例，配置parcel.json參數(shù)，如表2所示，其中JSON結構存在多層情況，這里使用路徑方式區(qū)別分層，如scripts/defines表示scripts字段下還有子json，它有defines字段，定義為“mariadb-env.sh”。通過表2和表3的配置信息，創(chuàng)建Parcel包和CSD包（完整包參考文獻[10]），并按照部署流程進行部署，完成部署后接下來查看效果。

3.2? 實現(xiàn)效果

CMUI引入的Parcel包需要進行下載、分發(fā)和激活三個步驟。而CSD需要重新啟動CM服務或者重啟CM管理主節(jié)點。

3.2.1? 服務安裝性檢查

1）Parcel安裝成功檢查。通常CM UI的Parcel列表中出現(xiàn)MARIADB安裝項，表示這個Parcel處于一個可以被安裝的狀態(tài)，CM獲取到meta中元數(shù)據(jù)。若狀態(tài)項出現(xiàn)已分配和以激活，如圖8所示，表示MariaDB已經(jīng)成功部署到集群中，此時CM可以通過CSD管控MariaDB服務。

2）CSD有效性檢查。查看集群的服務列表，出現(xiàn)MARIADB SERVER項則表示CSD已成功被CM識別。接下來嘗試安裝。

3.2.2? MariaDB服務安裝檢查

1）運行的服務列表。圖9中表示MariaDB安裝在Cluster1的CDH集群中，但是這個集群只有MariaDB服務，充分表示第三方服務可以脫離CDH存在；綠色對勾標記表示了MariaDB服務處于正常運行中。

2）服務實例。圖10中MARIADB_SERVER NODE是在service.sdl中對服務角色的命名，MariaDB服務成功運行在cdh2（192.168.56.102）和cdh3（192.168.56.103）兩個節(jié)點上，并且處于已啟動狀態(tài)。

3.2.3? MariaDB服務連接測試

MariaDB服務部署到cdh2和cdh3個節(jié)點，如圖11所示，通過DBeaver[11]的MariaDB服務，顯示成功連接，說明CM成功實現(xiàn)MariaDB的部署，驗證CM能夠部署和管控MariaDB關系數(shù)據(jù)庫的設想。

3.2.4? 停用測試

執(zhí)行停止服務命令后，如圖12所示，cdh2和cdh3主機狀態(tài)處于停止狀態(tài)，與圖10啟動狀態(tài)呈現(xiàn)鮮明對比，MariaDB服務運行端口號和進程均已退出，這表明通過CM成功實現(xiàn)停止MariaDB服務，測試通過。

通過CMUI進行信息檢查、軟件部署和功能操作以及使用DBeaver數(shù)據(jù)庫客戶端連接測試，并且均以無異常顯示，證實了利用CM能夠擴展MariaDB關系數(shù)據(jù)庫。

4? 結? 論

本文利用CM擴展方法研發(fā)了MariaDB的Parcel應用包和CSD管理包，并提供了這兩個擴展包的使用方法，進而實現(xiàn)CM對關系數(shù)據(jù)庫MariaDB的部署和管控。通過實驗安裝和服務測試，驗證了此方法有效性，為CM用戶使用關系數(shù)據(jù)庫功能開拓渠道，同時為CM擴展更多應用軟件提供了方法。

參考文獻：

[1] CLOUDERA.CDH Overview [DB/OL].（2021-09-29）.https：//docs.cloudera.com/documentation/enterprise/6/6.3/topics/cdh_intro.html.

[2] 張延松，王珊，周烜.內(nèi)存數(shù)據(jù)倉庫集群技術研究 [J].華東師范大學學報：自然科學版，2014（5）：117-132.

[3] 田燕軍，王玥.hbase與hive整合研究 [J].山西電子技術，2022（1）：81-83.

[4] 李翀，張彤彤，杜偉靜，等.基于Hive的高可用雙引擎數(shù)據(jù)倉庫[J].計算機系統(tǒng)應用，2019，28（9）：65-71.

[5] POL U R. Big data and hadoop technology solutions with cloudera manager [J].International Journal，2014，4（11）.

[6] CHAI R，GAO S，LAN J，et al. Efficient Computing Resource Metric Method in Computing-First Network [J].Journal of Computer Research and Development，2023，60（4）：763-771.

[7] TURLAND M，SLADE P. Farmers' willingness to participate in a big data platform [J].Agribusiness，2019，36（1）：20-36.

[8] MARIADB. MariaDB Server [DB/OL].（2023-01-24）.https：//mariadb.com/docs/server.

[9] GITHUB. Cloudera Manager Extensions [DB/OL].（2020-12-12）.https：//github.com/cloudera/cm_ext/wiki.

[10] GITHUB.CM的MariaDB擴展 [DB/OL].（2023-04-20）.https：//github.com/huangjie155/Store.

[11] DBeaver. Universal Database Tool [DB/OL].（2023-05-07）.https：//dbeaver.io.

作者簡介：黃杰（1992—），男，漢族，重慶人，碩士研究生，講師，研究方向：大數(shù)據(jù)部署監(jiān)控、模式匹配。