Spark的發(fā)展勢頭正猛，可是對主流用戶們來說還是太難了。云外加可視化也許有所幫助。

開源項目Apache Spark如今可能是從加州大學伯克利分校的AMP實驗室孕育而來的最有名的項目。AMP實驗室置身于機器學習、云計算和眾包這三大潮流的交匯處，正在結合算法、機器和人員三者的力量，充分解讀大數(shù)據(jù)。

開發(fā)Spark的初衷是擴展AMP實驗室另一個項目Apache Mesos的功能，沒想到迅速流行起來，幾位開發(fā)者在2013年開了一家初創(chuàng)企業(yè)：Databricks，出資方是知名風投機構Andreessen Horowitz，通過主機托管的云平臺來提供Spark，因而讓數(shù)據(jù)專業(yè)人員很容易充分發(fā)揮Spark的功能。

作為一種替代Hadoop的MapReduce，并用來處理大數(shù)據(jù)的技術，Spark具有極大的吸引力。它結合了速度、易于使用的編程模型和統(tǒng)一設計，讓用戶能夠將交互式查詢、流式分析、機器學習和圖形計算合并到單一系統(tǒng)里面。

將這種功能放到云端，又提供一種單一而出色的用戶體驗，你就為從事數(shù)據(jù)探查和構建端到端數(shù)據(jù)管道的任何人提供了一種殺手級平臺。使用從頭開始為大數(shù)據(jù)開發(fā)的可視化分析應用程序，比如Zoomdata，你就有了一種殺手級價值主張，可以進行超快速的商業(yè)智能(BI)可視化分析。

我采訪了Databricks公司的客戶互動副總裁Arsalan Tavakoli，請他談談Spark和數(shù)據(jù)分析技術如何成為強大的組合。

為何Spark放在云端?既然我下載Spark后可以在內部本地運行Spark，為何還需要向Databricks租用Spark呢?

Tavakoli：很顯然，Spark是作為一種開源產品來提供的。誰都可以從眾多供應商處下載，并使用它。但是我們考察了大數(shù)據(jù)項目失敗的客戶后，發(fā)現(xiàn)通常有三個原因可以解釋項目為何會失敗。

首先，基礎設施管理很難。如果是在內部本地運行，你要考慮6到9個月的過渡期，才能讓大數(shù)據(jù)基礎設施投入到生產環(huán)境，有時需要更長的時間。即便你在亞馬遜網絡服務(AWS)上運行Spark，也得編寫EC2腳本，讓開發(fā)運營(DevOps)人員參與其中。這并不好。

切記，基礎設施很難。而許多公司求助于Spark，很大程度上是由于其快速的創(chuàng)新周期。它們想獲得由數(shù)百人貢獻代碼、一直日臻完善的這樣一項技術帶來的好處。這意味著，這也是一項迅速前進的技術。你的團隊需要花多長時間才能將最新版本部署并運行起來?

其次，一旦你的Spark集群安搭建并運行起來，該如何處理它?數(shù)據(jù)科學家往往使用偏愛的語言，比如R和Python。現(xiàn)在，他們不得不弄清楚如何導入數(shù)據(jù)，如何讓任務盡快運行起來。處理獨立式Spark所必不可少的工具鏈可能對這些用戶來說難以使用。你又該如何運行你的分析技術、與同事合作呢?

這并非易事。

第三，在你全面測試了查詢和模型后，你想進入到生產環(huán)境――這個過程看起來像什么?在大多數(shù)公司，這意味著將你的模型交給工程團隊，這支團隊回過頭去，將你認為需要的特性重新實施到所有新的基礎設施上。

像Databricks這樣的云平臺提供了一套集成的、主機托管的解決方案，消除了企業(yè)采用Spark和確保大數(shù)據(jù)項目成功所面臨的這三大障礙。我們?yōu)槟闾峁┝巳婀芾砗驼{優(yōu)的Spark集群，開發(fā)Spark的一群專家在大力支持。我們的平臺為你提供了一種互動式工作區(qū)域，以便探查、可視化、合作和發(fā)布。如果你已準備好進入生產環(huán)境，只要點擊一下鼠標即可啟動任務。我們會自動搭建基礎設施。

另外，我們還提供了一組豐富的API，以便通過編程訪問該平臺，這還讓用戶能夠無縫整合第三方應用程序。

請說一下為何客戶們想要在云端進行商業(yè)智能可視化。有沒有特別的原因可以解釋交付的這種平臺最適合商業(yè)智能可視化?

Tavakoli：人們想要使用數(shù)據(jù)來獲得洞察力，以便深入了解公司業(yè)務，而數(shù)據(jù)工程師和數(shù)據(jù)科學家致力于提供這種洞察力。但是除非你是像Pinterest、Netflix或Facebook這樣的技術型公司，否則他們(數(shù)據(jù)工程師和數(shù)據(jù)科學家)只是任何企業(yè)組織的一小部分。業(yè)務分析員和最終用戶這個用戶群要大得多。

比如說，營銷部門的人想對數(shù)據(jù)進行大致的交叉分析，可是苦于沒有相應的技術技能。他們就想在受到嚴重制約的決策空間獲得儀表板或諸如此類的工具。

明智的公司知道，自己應該幫助員工能夠自我管理。這時候，商業(yè)智能可視化可以發(fā)揮其作用。你可能會需要一款針對特定領域的應用程序。

這么說來，這是貴公司與Zoomdata達成合作伙伴的原因?Databricks Cloud的用戶可以從這種合作關系中得到原本得不到的哪些好處?

Tavakoli：我們的客戶使用場合與Zoomdata存在諸多重疊之處。許多這些企業(yè)是典型的早期采用者，它們高度依賴數(shù)據(jù)工程師和數(shù)據(jù)科學家。所有這些企業(yè)組織還有一個主要的商業(yè)智能倉庫組件。

但是這些公司可能會問自己的下一個問題是：我如何才能讓這對更多的用戶來說更簡單?我擁有所有這些數(shù)據(jù)，可以用Spark來處理，如何才能提供給不是開發(fā)人員的那些用戶呢?

為此，商業(yè)智能可視化應用程序再理想不過，而Zoomdata證明了它很適合我們的云。

您在這種Databricks/Zoomdata聯(lián)合解決方案方面看到一些常見的使用場合有哪些?

Tavakoli：一種常見的使用場合是廣告技術(AdTech)垂直領域。

廣告技術公司通常有下列流程：它們從眾多來源匯集數(shù)據(jù)，建立起內部數(shù)據(jù)庫，然后這些數(shù)據(jù)通過又長又深的抽取、轉換和加載(ETL)管道，轉換成經過處理的形式。

隨后，每個客戶提供來自CRM和營銷自動化系統(tǒng)的數(shù)據(jù)，這些數(shù)據(jù)需要與該內部數(shù)據(jù)庫結合起來，才能解答營銷活動效果方面的問題。這個過程由全面檢驗了深入理論的數(shù)據(jù)工程師和數(shù)據(jù)科學家來處理。

另一方面，數(shù)據(jù)分析師和產品經理們想要提出更大致的問題，比如產品中哪項功能最有效，或者他們想知道移動廣告的效果怎樣。這一群用戶在使用Zoomdata之類的商業(yè)智能用戶界面時得心應手。

另一種使用場合是物聯(lián)網。Automatic Labs等公司獲取來自汽車里面所有設備的全部數(shù)據(jù)。數(shù)據(jù)科學家分析與汽車、成本和駕駛模式有關的基本趨勢方面的更深入問題。

像客戶經理這些非專家人員可能就是想查看不同的數(shù)據(jù)，以便與保險費率關聯(lián)起來。這些人可不想處理搭建Spark集群以及編寫Python或SQL代碼之類的事情。