將定制的Spark和Hadoop試點項目轉(zhuǎn)移到生產(chǎn)中是一項艱巨的任務(wù)，但容器技術(shù)緩解了這種艱難的過渡。
當(dāng)團隊試圖將小型試點項目轉(zhuǎn)變?yōu)槊嫦驍?shù)據(jù)科學(xué)團隊和業(yè)務(wù)分析人員的大型運營應(yīng)用程序時，Spark和Hadoop分析工作往往會遇到困難。對于許多人來說，這是他們在大數(shù)據(jù)分析之路上遇到的最大障礙。
配置的復(fù)雜性有時候也是絆腳石。由一個單獨的數(shù)據(jù)科學(xué)家構(gòu)建的自定義配置的原型可能需要很長的時間來重新創(chuàng)建，一旦失敗，是由一個更廣泛的用戶池共享。為了解決這些問題，一些人利用DevOps型容器和微服務(wù)技術(shù)將Spark和Hadoop組件銜接在一起。
“我們的數(shù)據(jù)科學(xué)團隊和業(yè)務(wù)利益相關(guān)者不希望等待過長的時間，等我們建立一個新的Spark集群或其他大型數(shù)據(jù)環(huán)境，并提供所需的所有工具、版本、配置和數(shù)據(jù)，” 為醫(yī)療機構(gòu)提供分析和咨詢服務(wù)的公司董事Ramesh Thyagarajan說道。他將Docker容器視為在大數(shù)據(jù)科學(xué)家和企業(yè)用戶上實現(xiàn)敏捷性的關(guān)鍵技術(shù)。
為了將這種DevOps風(fēng)格部署到其大數(shù)據(jù)應(yīng)用程序，咨詢委員會正在使用BlueData Software的EPIC軟件平臺來運行Spark SQL和Spark分析引擎以及Apache Zeppelin開發(fā)人員筆記本。Thyagarajan表示：“對我們而言，這是關(guān)于敏捷性和更快速的業(yè)務(wù)創(chuàng)新的。BlueData平臺的強大功能是將大數(shù)據(jù)部署作為基于容器的架構(gòu)?！?/span>
據(jù)Thyagarajan介紹，該平臺為數(shù)據(jù)科學(xué)家和業(yè)務(wù)分析師提供了新的Spark集群的按需分配，這些分析人員基本上避免了此類部署所需配置的復(fù)雜性。
他表示，他的團隊建立了自己的框架，將數(shù)據(jù)帶入Hadoop分布式文件系統(tǒng)(HDFS)。這種集中處理是很重要的，他說，“我們沒有辦法支持400多名用戶，每個用戶都創(chuàng)建自己的集群?！?/span>
是在腳本中運行嗎?
在容器中談?wù)摯髷?shù)據(jù)為時尚早。BlueData的聯(lián)合創(chuàng)始人兼首席架構(gòu)師Tom Phelan表示，到目前為止，Spark集群主要是在裸機服務(wù)器中實施。
Tom在最近在波士頓舉行的Spark Summit East 2017年的演講中表示，裸機意味著難以改變的架構(gòu)和靜態(tài)實施。
容器的實現(xiàn)可以使用腳本由手動完成，但是由于大數(shù)據(jù)管道組件較多，因此容器變得更具挑戰(zhàn)性。他說，Spark常常是比較復(fù)雜的、協(xié)調(diào)工作負(fù)載的一部分，這些工作量并不一定容易適應(yīng)容器的方法。
他告訴會議與會者，“必須要跨過容器管理者這一關(guān)。 這也是BlueData軟件需要解決的問題之一?！?/span>
彈性縮放的路徑
Phelan表示，BlueData平臺最近的更新解決了使用Spark的數(shù)據(jù)科學(xué)家(如咨詢委員會)的實施需求。
BlueData最新版本在本月初推出，支持常用的Spark工具，如JupyterHub，RStudio Server和Zeppelin編程筆記本，作為預(yù)配置的Docker映像。目的是為數(shù)據(jù)科學(xué)帶來更多DevOps風(fēng)格的敏捷性。
使用Docker容器和其他微服務(wù)方法是實現(xiàn)應(yīng)用程序部署自動化的驅(qū)動力。這些方法通常是彈性縮放的一個途徑，它允許管理員根據(jù)工作負(fù)載來建立和分解計算資源。
這在云計算以及內(nèi)部部署實施中日益普及，如果Spark和Hadoop的使用范圍在企業(yè)中逐漸擴大，擁抱容器的加入未嘗不是一件好事。
