[發(fā)明專利]基于Spark SQL的數(shù)據(jù)處理方法及裝置、存儲(chǔ)介質(zhì)及計(jì)算設(shè)備

在審

• 申請(qǐng)?zhí)枺?/td>: 201811214789.5
• 申請(qǐng)日: 2018-10-18
• 公開（公告）號(hào): CN109408537A
• 公開（公告）日: 2019-03-01
• 發(fā)明（設(shè)計(jì)）人: 姚琴
• 申請(qǐng)（專利權(quán)）人: 網(wǎng)易（杭州）網(wǎng)絡(luò)有限公司
• 主分類號(hào): G06F16/2453
• 分類號(hào): G06F16/2453;G06F16/2455
• 代理公司: 北京漢昊知識(shí)產(chǎn)權(quán)代理事務(wù)所(普通合伙) 11370
• 代理人: 朱海波

本發(fā)明的實(shí)施方式提供了一種基于Spark SQL的數(shù)據(jù)處理方法。該方法包括：響應(yīng)于會(huì)話的發(fā)起，根據(jù)發(fā)起會(huì)話的代理用戶的用戶名，在預(yù)設(shè)關(guān)系集中查找該用戶名對(duì)應(yīng)的Spark上下文變量實(shí)例；若未查找到則新建與之對(duì)應(yīng)的Spark上下文變量并實(shí)例化，并在預(yù)設(shè)關(guān)系集中添加該用戶名至少與對(duì)應(yīng)的Spark上下文變量實(shí)例之間的對(duì)應(yīng)關(guān)系；根據(jù)發(fā)起會(huì)話的代理用戶的用戶名對(duì)應(yīng)的Spark上下文變量實(shí)例，創(chuàng)建對(duì)應(yīng)的運(yùn)行時(shí)環(huán)境來執(zhí)行對(duì)應(yīng)的數(shù)據(jù)處理，該方法能夠通過在一臺(tái)服務(wù)器上運(yùn)行單個(gè)應(yīng)用實(shí)例來為多個(gè)租戶提供服務(wù)，實(shí)現(xiàn)多租戶功能。此外，本發(fā)明的實(shí)施方式提供了一種基于Spark SQL的數(shù)據(jù)處理裝置、存儲(chǔ)介質(zhì)及計(jì)算設(shè)備。

技術(shù)領(lǐng)域

本發(fā)明的實(shí)施方式涉及數(shù)據(jù)處理領(lǐng)域，更具體地，本發(fā)明的實(shí)施方式涉及一種基于Spark SQL的數(shù)據(jù)處理方法及裝置、存儲(chǔ)介質(zhì)及計(jì)算設(shè)備。

背景技術(shù)

大數(shù)據(jù)技術(shù)是目前較為熱門的一項(xiàng)技術(shù)，指對(duì)規(guī)模巨大的數(shù)據(jù)進(jìn)行查詢、分析等處理的技術(shù)。隨著大數(shù)據(jù)時(shí)代的來臨，與大數(shù)據(jù)相關(guān)的數(shù)據(jù)倉庫、數(shù)據(jù)安全、數(shù)據(jù)分析、數(shù)據(jù)挖掘等應(yīng)用已逐漸成為IT行業(yè)的研究熱點(diǎn)。

例如，誕生于加州大學(xué)伯利克分校AMPLab的Apache Spark是一個(gè)基于內(nèi)存計(jì)算的大數(shù)據(jù)計(jì)算框架。其中，Spark是MapReduce(MR)的替代方案，目的在于提供更高效的數(shù)據(jù)處理能力，且其能夠兼容HDFS分布式存儲(chǔ)層，兼容Apache Hive元數(shù)據(jù)倉庫，可融入Hadoop的生態(tài)系統(tǒng)，以彌補(bǔ)缺失MapReduce的不足。通常，Spark程序?yàn)橹鲝?master/slave)結(jié)構(gòu)，驅(qū)動(dòng)器(Driver)作為master(指主動(dòng)發(fā)起請(qǐng)求的一方)負(fù)責(zé)其計(jì)算最小單位任務(wù)(task)的調(diào)度，而執(zhí)行器(Executor)負(fù)者task的運(yùn)算。但是，MapReduce不能滿足大部分大數(shù)據(jù)場(chǎng)景下的即席查詢。

又如，Spark SQL作為SQL on Hadoop技術(shù)的其中一種，其作用是將SQL查詢語句經(jīng)其自帶的查詢優(yōu)化器翻譯成Spark底層計(jì)算邏輯，以提供高效的SQL查詢能力。基于SparkSQL對(duì)諸如Apache Hive等的標(biāo)的產(chǎn)品實(shí)現(xiàn)計(jì)算邏輯，相比于MapReduce而言能夠提高處理性能。

發(fā)明內(nèi)容

但是，上述大數(shù)據(jù)計(jì)算框架無法通過在一臺(tái)服務(wù)器上運(yùn)行單個(gè)應(yīng)用實(shí)例來為多個(gè)租戶提供服務(wù)，也即，不具備多租戶(Multi Tenancy/Tenant)功能。

例如，如圖1A所示的HiveServer2(以下簡(jiǎn)稱技術(shù)一)提供了一種基于Hive查詢引擎的SQL on Hadoop多租戶方案，該多租戶方案對(duì)于每一個(gè)來自用戶的客戶端(Client)請(qǐng)求，HiveServer2都為該請(qǐng)求創(chuàng)建一個(gè)會(huì)話(Session)，并分配一個(gè)執(zhí)行上下文環(huán)境，對(duì)應(yīng)于一輪MR任務(wù)。在該多租戶方案中，計(jì)算層啟動(dòng)的執(zhí)行環(huán)境與Client個(gè)數(shù)一一對(duì)應(yīng)，無法重用影響效率，未能實(shí)現(xiàn)在一臺(tái)服務(wù)器上運(yùn)行單個(gè)應(yīng)用實(shí)例來為多個(gè)租戶提供服務(wù)的目的，故而不具有真正的多租戶功能。

再如，如圖1B所示的SparkThriftServer(以下簡(jiǎn)稱技術(shù)二)提供了一種基于SparkSQL查詢引擎的SQL On Hadoop方案，由于單個(gè)SparkThriftServer不具備多租戶特性，為了能讓用戶訪問其所對(duì)應(yīng)的存儲(chǔ)在HDFS的數(shù)據(jù)，必須為其啟動(dòng)單獨(dú)的服務(wù)器(server)，即用戶User2無法實(shí)現(xiàn)通過User1的server來訪問自己資源的目的。因此，該方案也不具備多租戶特性，并且，該方案通過為特定用戶預(yù)置一個(gè)server的方式而增加了系統(tǒng)維護(hù)的復(fù)雜度，降低了服務(wù)器資源的并發(fā)能力和資源利用率。

因此在現(xiàn)有技術(shù)中，往往是上述技術(shù)一和技術(shù)二混合部署的模式，但兩者無法實(shí)現(xiàn)無縫兼容，這是非常令人煩惱的過程。

為此，非常需要一種改進(jìn)的基于Spark SQL的數(shù)據(jù)處理方法，以使其通過在一臺(tái)服務(wù)器上運(yùn)行單個(gè)應(yīng)用實(shí)例即可為多個(gè)租戶提供服務(wù)。