基于商業(yè)智能系統(tǒng)的大數(shù)據(jù)分析平臺(tái)架構(gòu)研究

肖寒

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

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

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

1?引言

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

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

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

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

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

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

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

2.2 執(zhí)行步驟。

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

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

3?總結(jié)

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