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的信息