Leaf in the Wild: Stratio整合Apache和MongoDB爲世界上最大的銀行之一開啓新的客戶洞察

本文源地址：http://www.mongoing.com/blog/post/leaf-in-the-wild-stratio-integrates-apache-spark-and-mongodb-to-unlock-new-customer-insights-for-one-of-worlds-largest-banks
歡迎關注MongoDB中文社區獲取更多關於MongoDB的信息。

毫無疑問，Apache Spark如今很是熱門。它是Apache軟件基礎中最活躍的大數據項目，最近也被IBM「神化」——其中IBM還投入了3, 500個工程師來推進它。儘管一些人還對Spark是什麼有所疑惑，或者聲稱它將會淘汰Hadoop（也許它並不會，或者至少不是它非Map-Reduce部分）。現在已經有一些公司利用它的能力來構建下一代分析應用程序。

Stratio就是一個這樣的公司。擁有着包括BBVA, Just Eat, Santander, SAP, Sony 以及Telefonica在內很是有影響力的客戶列表，Stratio聲稱使用Apache Spark認證大數據平臺的更多項目及客戶端將會比其它任何工具好不少。

MongoDB常常被用做Stratio大數據平臺中的數據庫，所以我很是榮幸可以獲得一個坐下來與他們鏈接件開發團隊以及Stratio負責人Steve Galache交談的機會。咱們討論了一些他們近期的項目以及在新一代分析性工做負載中他們學習用於利用Spark的最佳實踐。

你能先向咱們稍微介紹一下你的公司嗎？大家正在嘗試實現什麼？你如何看待在接下來幾年中自身的發展？

在Stratio，咱們研究大數據已經超過十多年了。幾年前，咱們預見到大數據的將來就是快數據，而後甚至在孵化階段以前就已經開始投入Apache Spark的工做了。在2014年早期的時候，咱們就已經將第一個平臺投入市場。並且它目前已經在涉及銀行、電子商務、能源以及電信到其它一些領域的大型企業中進入生產。該平臺支撐着一系列用戶案例，從互聯網範圍、顧客應用到網絡安全的各個方面。咱們不只僅是一個認證的Spark發佈者，咱們專一於使用快數據簡化應用的開發。在Spark之上，咱們搭建了用於數據攝取、處理以及可視化的應用，而並不須要寫任何一行代碼，而後與相似於MongoDB之類的領先非關係型數據庫提供了完整的集成。

請描述大家使用MongoDB和Stratio的項目。你的客戶正在嘗試解決什麼問題？MongoDB和Spark如何幫助他們解決這些問題？

一個很是廣泛的場景是：一個已經實現了複雜的商務智能過程用於理解其業務的大型企業。可是，他們目前但願在下一步經過探索新的數據源來進一步提升他們關於顧客的理解。該公司基於大量來自服務日誌、瀏覽行爲、社交數據以及更多渠道的、未開發的原始數據。可以分析這些數據，以顧客作出的行爲、沒有作出的行爲或者他們嘗試作出的行爲的形式，幫助企業加深他們對顧客的理解。最終，這將會幫助他們提升客戶體驗，也能夠預測新的商業機會。這正是Stratio和咱們的大數據平臺能夠幫助的地方。

做爲該場景的一個案例，咱們近期實現了一個統一實時的監控平臺，用於全世界31個國家、51,000,000客戶端的多國銀行操做團隊。該銀行但願保證在線渠道之間的高品質服務，所以須要連續監控客戶端活動來檢查服務響應時間以及識別潛在問題。爲了構建該應用，咱們使用了下面的技術：

• Apache Flume整合日誌數據

• Apache Spark實時處理日誌事件

• MongoDB持久化日誌數據、處理事件以及重要性能指標 (KPI)

整合的重要性能指標容許銀行實現分析客戶端及系統行爲的目標，用於提升客戶體驗。收集原始的日誌數據容許銀行在一個服務失敗以後，當即使用由提供了完整可追溯能力、用於識別問題根本緣由的分析來從新構建用戶會話。

並非只有金融服務公司看到了分析日誌及社交流的機遇。咱們也已經爲保險和電商領域的客戶實現了相似的項目。

爲何MongoDB對這個項目來講是很是合適的選擇？

咱們須要一個可以爲咱們提供隨時在線可用性、高性能以及線性可擴展性的數據庫。此外，咱們也須要一個徹底動態的模式來支撐大容量的、快速改變的、半結構化及非結構化的JSON數據，它們從各類類型的日誌、點擊流以及社交網絡中獲取。當咱們評估該項目的需求時，MongoDB是最合適的選擇。

在這種類型的項目之下，咱們也發現數據池（來自於多個應用的數據中心倉庫）不斷在使用中增加。MongoDB的動態模式是對這種用戶案例類型而言很是合適的選擇，由於咱們並不能預測咱們須要管理的數據結構類型。

在你的項目中是否使用了其它的數據庫？

爲了從多個應用中收集和調整數據，咱們的大數據平臺能夠支持一系列數據庫和搜索引擎。這些數據中的每個都有它們各自的優點，其中的一些也能夠提供MongoDB的實用性和性能。

然而，若是一個應用隨着新功能的增長而快速演變，並且正在生成多重結構的數據，而後MongoDB的動態模式爲咱們提供了一個高度敏捷和靈活的數據庫層來進行構建。

此外，部署一個應用進入到開發須要一個綜合的、企業級別的操做平臺，用於安排應用流和主動監控。MongoDB Cloud Manager爲咱們提供了這種工具。

你能描述一個典型的MongoDB和Spark應用嗎？

咱們已經在Stratio大數據平臺中將MongoDB部署於不一樣需求的多個項目中。在一些狀況下，MongoDB與其它數據庫一塊兒使用，所以可能會部署在一個單一的複製集中。

在其它項目中，MongoDB是一個單獨的數據源，常常運行在一個分片集羣中。

你能分享一些關於客戶擴展他們MongoDB和Stratio Spark基礎設施的最佳實踐嗎？

這裏有一些對系統性能有重大影響的因素：

基於Spark分析工做流的讀取模式選擇一個合適的分區策略。在這裏，MongoDB爲咱們提供了很是大的靈活性，咱們能夠支持hash以及基於範圍的分片來知足大範圍的應用模式及查詢模式。
確保你已經爲每一個節點配置了足夠的內存。做爲最佳實踐，MongoDB工做集（即索引以及最頻繁讀取的數據）應該被存儲在RAM中。一樣地，給Spark足夠的內存對性能而言很是重要，由於它避免了在迭代計算的過程當中將數據序列化到磁盤中。
設計你的架構以保證即便是在擴展集羣的狀況下，也能夠在MongoDB和Spark進程之間維護數據的局部性。

圖1：使用MongoDB複製集用於數據局部性而且將分析和操做性工做負載分離

你的客戶使用Spark和MongoDB處理什麼類型的查詢和分析？他們正在使用什麼API?

從Spark Streaming到機器學習算法及SparkSQL的全部，隨着用戶案例的變化而變化。Stratio的SparkSQL MongoDB鏈接件實現了PrunedFilteredScan API而不是TableScan API。這就意味着，除了MongoDB的查詢映射，咱們能夠避免掃描整個集合，而其它數據庫並不會出現這種狀況。

對於MongoDB和Spark之間的SQL集成，Stratio大數據平臺提供了一個實現了Spark 數據框架API的SparkSQL數據源。該鏈接件，所有是由Scala語言實現的，目前支持Spark 1.3 （目前已經被更新到了Spark 1.4，幾周以前發佈）以及MongoDB 3.0。爲何選擇該實現版本呢？由於除了使用SQL語法爲複雜分析提供更高等級的抽象以外，它容許可以實現Spark相同API不一樣數據源集合的集成。

一旦數據存入MongoDB，咱們提供一個ODBC/JDBC鏈接件，用於與其它相似於Tableau和QlikView之類的任何商務智能工具。咱們也使用了鏈接件與咱們本身定製的數據可視化工具集成，用於建立儀表盤和報表。

圖2：Stratio數據可視化-建立報告、儀表盤以及微型站點

你的客戶是如何衡量使用MongoDB及Stratio大數據平臺的影響？

轉化爲洞察力的時間以及進入市場的時間都是很重要的維度。MongoDB以及Stratio大數據平臺都已經進行了集成而且處於企業就緒狀態。所以，顧客避免浪費時間在安裝、配置及監控系統方面。他們能夠僅僅是使用新的和有趣的方法開始分析數據。

搭建在開源軟件上，運行於商業硬件上，該平臺也會經過專利技術進行極大的成本縮減。

對於那些正在考慮使用Spark開發下一個項目的用戶，你有什麼建議？

學習Scala。Scala是Spark的母語。即便有Java和Python的API，大部分Spark開發都使用Scala——一個面向功能及對象的語言。
注意防止數據頻繁移動。一個好的分割策略及RDD緩存使用，以及避免沒必要要的行爲操做，應該已經足夠實現良好的性能。
考慮好序列化策略。若是你知道（或者懷疑）數據不可以徹底放到RAM中。你可使用可用的序列化策略（例如，MEMORY, MEMORY_SER, DISK）進行實驗，以實現最佳性能。
應用程序的包管理。在部署應用時，比較棘手的一類問題與JAR配置及classpath管理相關。強烈推薦使用一個良好的插件，用於生成一個使用傳遞依賴的配置。
Steve和團隊-很是感謝你花時間與MongoDB和Apache Spark社區分享你的見解和看法。

想要了解更多關於使用MongoDB和Apache Spark的信息？閱讀咱們新的白皮書：

瞭解更多關於MongoDB和Spark的信息