Spark和Hadoop分析遇障碍?可以试试容器啊
将定制的Spark和Hadoop试点项目转移到生产中是一项艰巨的任务,但容器技术缓解了这种艰难的过渡。
当团队试图将小型试点项目转变为面向数据科学团队和业务分析人员的大型运营应用程序时,Spark和Hadoop分析工作往往会遇到困难。对于许多人来说,这是他们在大数据分析之路上遇到的最大障碍。
配置的复杂性有时候也是绊脚石。由一个单独的数据科学家构建的自定义配置的原型可能需要很长的时间来重新创建,一旦失败,是由一个更广泛的用户池共享。为了解决这些问题,一些人利用DevOps型容器和微服务技术将Spark和Hadoop组件衔接在一起。
“我们的数据科学团队和业务利益相关者不希望等待过长的时间,等我们建立一个新的Spark集群或其他大型数据环境,并提供所需的所有工具、版本、配置和数据,” 为医疗机构提供分析和咨询服务的公司董事Ramesh Thyagarajan说道。他将Docker容器视为在大数据科学家和企业用户上实现敏捷性的关键技术。
为了将这种DevOps风格部署到其大数据应用程序,咨询委员会正在使用BlueData Software的EPIC软件平台来运行Spark SQL和Spark分析引擎以及Apache Zeppelin开发人员笔记本。Thyagarajan表示:“对我们而言,这是关于敏捷性和更快速的业务创新的。BlueData平台的强大功能是将大数据部署作为基于容器的架构。”
据Thyagarajan介绍,该平台为数据科学家和业务分析师提供了新的Spark集群的按需分配,这些分析人员基本上避免了此类部署所需配置的复杂性。
他表示,他的团队建立了自己的框架,将数据带入Hadoop分布式文件系统(HDFS)。这种集中处理是很重要的,他说,“我们没有办法支持400多名用户,每个用户都创建自己的集群。”
是在脚本中运行吗?
在容器中谈论大数据为时尚早。BlueData的联合创始人兼首席架构师Tom Phelan表示,到目前为止,Spark集群主要是在裸机服务器中实施。
Tom在最近在波士顿举行的Spark Summit East 2017年的演讲中表示,裸机意味着难以改变的架构和静态实施。
容器的实现可以使用脚本由手动完成,但是由于大数据管道组件较多,因此容器变得更具挑战性。他说,Spark常常是比较复杂的、协调工作负载的一部分,这些工作量并不一定容易适应容器的方法。
他告诉会议与会者,“必须要跨过容器管理者这一关。 这也是BlueData软件需要解决的问题之一。”
弹性缩放的路径
Phelan表示,BlueData平台最近的更新解决了使用Spark的数据科学家(如咨询委员会)的实施需求。
BlueData最新版本在本月初推出,支持常用的Spark工具,如JupyterHub,RStudio Server和Zeppelin编程笔记本,作为预配置的Docker映像。目的是为数据科学带来更多DevOps风格的敏捷性。
使用Docker容器和其他微服务方法是实现应用程序部署自动化的驱动力。这些方法通常是弹性缩放的一个途径,它允许管理员根据工作负载来建立和分解计算资源。
这在云计算以及内部部署实施中日益普及,如果Spark和Hadoop的使用范围在企业中逐渐扩大,拥抱容器的加入未尝不是一件好事。
本文转自d1net(转载)

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
The Twelve-Factor在Cloud Native时代是否依然适用?
按语 Heroku是云应用平台的先驱,从对外提供服务以来,他们已经有上百万应用的托管和运营经验。其创始人Adam Wiggins根据这些经验,提出了十二要素应用宣言 。The Twelve-Factor App定义了一个优雅的互联网应用在设计过程中,需要遵循的一些基本原则。 不过, The Twelve-Factor是在特定的时期,针对特定的平台实践所总结出来的。12元素依然璀璨,很多原则依然具有普适性;但是在应用全面迁移到云端的今天,Cloud Native时代的应用开发,需要有更多与时俱进的实践新原则。The Twelve-Factor的哪些原则依然是适用的?哪些在实践需要与时俱进?这些都是众多Cloud Native的实践者需要探求的答案。 新原则1:微服务应该以无状态的方式运行 The Twelve-Factor指出一个应用在运行时,应该以一个或者多个无状态的进程来运行。进程之间需要做到无状态,并且无共享。任何需要持久化的数据,都应该写入到后端服务中,譬如数据库。这一原则,目的是避免进程和进程之间的耦合。让每一个进程,能够独立于其他实体单独构建和运行。 在很多在线系统中,会使用...
- 下一篇
美国科技公司祸不单行,亚马逊后微软云计算也发生故障
亚马逊云计算故障余温尚未过去,16日媒体又报道,微软的云计算也发生全球性故障,全球28个数据中心有26个受到波及。 据VentureBeat报道,微软证实发生故障的是Azure公共云服务中的数据存储服务(即云存储或网盘),然后又导致其他服务故障。从北京时间周四早上开始,全球访问微软存储服务的客户无法创建、更新与删除数据资源。 微软表示,他们大概知道了故障原因,并不断发布更新通知。最终,微软宣布云计算服务恢复正常。 早些时候,亚马逊云计算出现宕机情况。 随后亚马逊对外表示,此次故障持续超过了3个半小时,故障原因是人为操作失误,一项错误的指令,让比计划中更多的服务器被移除。 由于很多美国科技公司都从亚马逊处购买云计算服务,这次宕机造成了海量网站和APP大面积瘫痪。 本文转自d1net(转载)
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 设置Eclipse缩进为4个空格,增强代码规范
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Hadoop3单机部署,实现最简伪集群
- CentOS8编译安装MySQL8.0.19
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2配置默认Tomcat设置,开启更多高级功能