企业使用大数据架构的几种选择

如果询问十家公司为了运行大数据负载需要使用怎样的基础架构，那么可能会得到十种不同的答案。现在这个领域当中几乎没有可以遵循的原则，甚至没有可以参考的最佳实践。

　　不管是从资源还是从专业性方面来说，大数据分析已经成为基础架构领域当中真正的难题。顾名思义，大数据分析工具所针对的数据集合规模将会非常庞大，并且需要大量的计算、存储和网络资源来满足性能需求。但是这些大数据工具通常是由超大规模企业开发的，这些企业并不存在普通企业需要考虑的同等级安全顾虑和高可用性问题，而主流IT企业还没有深入了解这些工具，再加上大数据在投资回报率方面的不确定性，导致只有非常少的企业愿意在大数据方面进行投入。

　　此外，即便对于曾经在Hadoop、Spark和类似产品上运行过大数据集群的部分企业来说，也会在大数据基础架构方面遇到技术和业务方面的挑战。

　　大数据带来大问题

　　一家大型远程通讯提供商正在构建一种新的数字服务，预计在今年年底正式推出，并且准备使用Hadoop来分析这种服务所产生的内容、使用情况和收入(广告服务)数据。但是负责这个项目的技术副总裁表示，由于这种服务是全新的，因此很难分析应该使用哪种大数据基础架构。

　　“对于一个还没有推出的项目来说，我们不可能进行任何容量规划，”他说。

　　确实，现在很多大数据项目仍然处于初级阶段。“大多数大数据项目的性质比我们想象的还要低，” Andrew Warfield表示，他是可扩展存储基础架构提供商Coho Data的CTO。

　　即便企业还不是十分俩了解大数据技术，但这并不意味着企业不应该在大数据方面投入精力。“但是运行这种技术可能面临着很大风险，提前认识到这点非常重要，” Warfield说，他认为企业应该提前考虑基础架构方面的因素。

　　对于这家远程通讯提供商来说，他们将会采用一种渐进的方式，其使用来自于BlueData Software的软件在商用硬件环境当中运行大数据集群，这样就能够从现有的存储系统上访问数据了。

　　无处不在的数据

　　如果数据来自于云中，那么当然可以直接在云中进行分析;如果数据全部位于本地，那么底层的基础架构也应该位于本地。但是如果数据分散在不同位置，那么无疑会使得基础架构更加复杂。

　　远程通讯提供商的服务将会同时使用来自于云中和本地的数据。对于任何大数据解决方案来说，考虑到合规性、节省时间和网络带宽等因素，能够同时支持两种数据来源都是十分重要的。“同步生产环境当中的数据是一件非常困难的事情，”这位副总裁说，“我们希望将所有的实例全都指向一个单一数据源。”

　　此外，虽然数据科学家想要分析的信息是可用的，但是现在还不能进行使用，因为其位于大数据计算工具无法访问的存储基础架构当中。一种解决方案是存储硬件使用Hadoop Distributed File System或者RESTful API这样的协议公开这些数据。

　　注意延迟

　　对于某些大数据分析来说，将数据从存储阵列移动到计算环境所花费的时间将会对性能造成严重影响。但是如果不将数据跨越整个网络移动到计算环境当中，而是将应用程序移动到数据附近以降低延迟，将会怎样呢?

　　将计算环境移动到数据附近并不是一种全新的概念，但是现在出现了一种前所未有的实现方式：Docker。比如Coho Data和Intel通过合作证明了这种概念的有效性，在一个大型金融服务公司当中，使用Docker格式封装计算节点，之后在上面直接运行Hadoop负载。

　　在存储阵列上直接运行Docker容器，这样做的意义在于直接对附近的数据进行分析，而不再需要跨网络移动数据，同时利用任何可用的计算资源。“相比于其他存储平台来说，大数据平台的CPU使用率通常会很高，”Warfield说，“更何况如果你将闪存加入其中，那么问题就会变成‘我该如何从这种资源当中获得更多价值?’”

　　直接在存储阵列当中运行容器化应用程序是一件非常有趣的事情，但是需要提前对负载进行认真评估，以确保其能够很好地适应当前环境，Signature Tech Studios的副总裁Bubba Hines说。这家公司为建筑行业提供文档管理服务。这种服务基于Amazon Web服务，使用来自于Zadara Storage的存储服务。这家公司最近开始评估新的Zadara Container Service，其中容器化应用程序运行在存储阵列上，可以直接访问本地磁盘。根据Hines的想法，现在有几种可能的使用情况：在存储阵列上运行其灾难恢复软件的容器版本来持续监控用户数据和工作方面的变化，更改或者验证主要存储数据。

　　但是如果使用Zadara Container Service处理全部数据将没有什么意义。Signature Tech Studio的系统正在按照计划执行数据转换，并且已经实现大规模容器化了。但是“我们可能不会将所有这些(Docker容器)移动到(Zadara)容器服务当中，因为从体积和规模方面考虑这样做并没有意义，”Hines说，“我们必须寻找能够真正从降低延迟当中获利的负载。”