肖寒

摘要：本文構(gòu)建一套具有巨量數(shù)據(jù)分析計(jì)算平臺架構(gòu)的商業(yè)智能系統(tǒng)，它整合Apache Hive、Cloudera Impala、BDAS Spark SQL使平臺支持SQL命令的巨量數(shù)據(jù)檢索能力。大數(shù)據(jù)環(huán)境要求高性能的運(yùn)算，系統(tǒng)優(yōu)化成為首要問題。因此本文所設(shè)計(jì)的最優(yōu)程序通過存取單一接口后，由程序自動選擇執(zhí)行性能最佳的巨量數(shù)據(jù)倉儲平臺執(zhí)行工作。再則運(yùn)用Memcached分布式內(nèi)存存儲系統(tǒng)以及Apache HDFS分布式文件系統(tǒng)對查詢結(jié)果進(jìn)行快取，因此輸入相同的SQL查詢則會經(jīng)由高性能的快取系統(tǒng)取得檢索結(jié)果，避免重復(fù)執(zhí)行巨量數(shù)據(jù)倉儲平臺所導(dǎo)致冗長的檢索時間。

關(guān)鍵詞：商業(yè)智能、巨量數(shù)據(jù)處理、數(shù)據(jù)倉儲、分布式文件系統(tǒng)

中圖分類號：TM76?文獻(xiàn)標(biāo)識碼：A?文章編號：1672-9129（2020）09-0034-01

1?引言

近年來，企業(yè)能夠即時掌握巨量數(shù)據(jù)，便能掌握商機(jī)，巨量數(shù)據(jù)對于企業(yè)的影響日益明顯。但對于巨量數(shù)據(jù)的處理與分析，使用傳統(tǒng)的方法卻無法有效進(jìn)行，尤其當(dāng)數(shù)據(jù)量越趨于巨大，數(shù)據(jù)的存儲無法由少數(shù)的服務(wù)器或是存儲設(shè)備進(jìn)行，且數(shù)據(jù)的存取所帶來的嚴(yán)重I/O延遲問題，都隨著數(shù)據(jù)的成長而更嚴(yán)重。在預(yù)估未來即將發(fā)生巨量數(shù)據(jù)問題前，利用集群架構(gòu)分布式計(jì)算與存儲是近期相當(dāng)熱門的解決方案，不僅具有加速運(yùn)算與大量存儲的特性，更提供了高性能、高可用性的行環(huán)境，卻又相當(dāng)符合經(jīng)濟(jì)成本，且擁有優(yōu)異的縱向和橫向擴(kuò)充能力。

2?系統(tǒng)方案設(shè)計(jì)

本文的研究目標(biāo)是在基于OpenStack上構(gòu)建一套具有高性能、高可用性、高擴(kuò)展性的多重巨量數(shù)據(jù)處理平臺并希望達(dá)成能與任何現(xiàn)存的商業(yè)智能與分析工具相容。構(gòu)建的平臺可以支持SQL-like的Query命令語句對巨量數(shù)據(jù)平臺進(jìn)行操作。運(yùn)用Open Source的資源構(gòu)建平臺。由于各種巨量數(shù)據(jù)處理平臺在執(zhí)行時，所需耗用的內(nèi)存容量不同，而且集群剩余的內(nèi)存容量將嚴(yán)重影響各平臺的執(zhí)行性能，因此本文將通過偵測集群剩余的內(nèi)存容量進(jìn)行自動化的平臺選擇，選出目前執(zhí)行性能最佳的一組平臺，以便進(jìn)行Query命令的檢索任務(wù)。利用Memcached分布式內(nèi)存存儲系統(tǒng)進(jìn)行對檢索結(jié)果進(jìn)行高性能的快取，并輔以Apache HDFS作為第二層的快取，延伸快取的容量。

2.1 方案算法。為了評估在本文幾個平臺的性能，從最初在所導(dǎo)出的必要方程式（1），該方程式在任何指定的環(huán)境中，進(jìn)行下各種命令在所有提及目標(biāo)平臺上來測量平均存取時間。

緊接在任何指定的環(huán)境中的各種數(shù)據(jù)大小的文件上使用方程式（2），該方程式計(jì)算加權(quán)平均存取時間。

然后根據(jù)所有指定環(huán)境中的各平臺使用方程式（3），該方程式可導(dǎo)出正規(guī)化性能指標(biāo)。

最后根據(jù)上面的不同測試使用4），該方程式獲得性能指標(biāo)。

2.2 執(zhí)行步驟。

（1）整合多重巨量數(shù)據(jù)分析平臺：本文使用CDHClouderaDistribution Including Apache Hadoop）來構(gòu)建Hadoop、Hive、Spark及Impala，Spark SQL則需另外裝。多重巨量數(shù)據(jù)處理平臺內(nèi)的Hive、Impala、Spark SQL是安裝在Openstack所構(gòu)建出來的Virtual Machine（CentOS）中執(zhí)行。

（2）平臺自動選擇程序：本文在實(shí)驗(yàn)時發(fā)現(xiàn)當(dāng)剩余內(nèi)存容量在每臺服務(wù)器 2GB 以下時，Impala與Spark SQL會產(chǎn)生大量的分頁swap動作，導(dǎo)致性能極度低落。當(dāng)剩余內(nèi)存容量在相當(dāng)充足時，Spark SQL在執(zhí)行速度上領(lǐng)先Hive及Impala。而Impala所需的內(nèi)存介于兩者之間，在達(dá)到此之間的內(nèi)存剩余量可以發(fā)揮Impala最大性能。本文每臺服務(wù)器分配內(nèi)存20G給集群計(jì)算使用，以集群整體內(nèi)存剩余量Level 1：3%0.6G） 、Level 2：15%（3G）、Level 3：75%15G）為分界點(diǎn)，當(dāng)剩余量低于15%時程序自動選擇Hive 進(jìn)行任務(wù)，剩余量15%～75%區(qū)間時采用Impala進(jìn)行任務(wù)，剩余量高于75%時采用Spark SQL進(jìn)行任務(wù)。最優(yōu)程序具有相當(dāng)高的可擴(kuò)充性，若需要新增支持的分析平臺，只需要撰寫JDBC界面程序即可，撰寫完成后的界面程序僅需放入bin數(shù)據(jù)夾即可與主程序進(jìn)行連結(jié)，使用者可以通過enforced指令對新增支持的分析平臺進(jìn)行SQL操作。

3?總結(jié)

通過巨量數(shù)據(jù)平臺的整合，本文發(fā)現(xiàn)到即使是同質(zhì)性功能的分析平臺，仍會于不同的實(shí)驗(yàn)環(huán)境下產(chǎn)生極大的性能差異。通過程序自動偵測集群狀態(tài)，并選擇最佳的平臺進(jìn)行數(shù)據(jù)檢索可以大幅節(jié)省時間。在多人使用同一集群的情況下，自動選擇程序更可以妥善的選擇合適的平臺，有效避免資源競爭導(dǎo)致的整體性能低落問題。

參考文獻(xiàn)：

[1]王覓也，黃勇，畢永東，等.醫(yī)院商業(yè)智能系統(tǒng)的應(yīng)用[J].醫(yī)療衛(wèi)生裝備，2012，（1）.82-84.

[2]于洋，房坤，劉丹，等.基于Power BI的大數(shù)據(jù)分析在醫(yī)用耗材管理中的實(shí)踐[J].中國醫(yī)學(xué)裝備，2020，17（7）：145-149