众望所归的新趋势

目前的趋势是摆脱MapReduce,降低构建和维护MapReduce作业的复杂度并提高性能,同时利用现有的IT资源。至于如何摆脱MapReduce、如何替代MapReduce作业、使用怎样的工作负载,这些问题都是战略性的决策。同时,要考虑Hadoop可以发挥怎样的战略性作用,使企业通过数据获得利润。

由于要访问存储在HDFS的数据,就要使用MapReduce中的键,因此MapReduce是Big Data项目至关重要的组件。这意味着,只有数据专家和编写MapReduce作业的数据工程师才有权访问数据。同时,由于不断在摄取新的数据,因此需要一直修改MapReduce作业。这是一项较大的维护费用。

MapReduce阻碍了Hadoop数据以及使用数据的用户和应用程序,从而影响了Hadoop的ROI。

观看网络研讨会

选择MapReduce的替代方案不只是技术决策

  • 使用Big Data和Hadoop实现更多——目前,分析和非结构化数据仍然是Hadoop的核心,企业都希望拓宽Hadoop部署的用途,以获取更高的ROI,因此纷纷建立了企业数据湖和数据管理政策。企业的各个业务部门和IT自然希望具有数据湖的访问权限。
  • Big Data项目的成本——虽然大多数Big Data平台和附加工具都是开源的,只有一小部分商业版本,但是Big Data项目还是有以下几项主要的成本。
    • 数据工程师和数据专家的成本——数据工程师和数据专家的人才短缺,薪酬高昂。如果您想要构建一支经验丰富的数据团队,成本就更加高昂了。
    • 实验成本——由于Big Data技术的碎片化,很多技术的功能和要求都是相同的,实验的成本正在飞速增长。很多开发人员开始测试解决具体问题的新技术,但他们不必进行宏观的思考。即使新的技术是有效的,也往往无法在更大的规模上发挥作用。
    • 扩展成本——虽然Hadoop及其云服务(例如,AWS和Microsoft Azure HDInsight)都是用于扩展的,但随着时间的推移,扩展的总成本越来越高,因为有越来越多的Big Data问题需要适应专有的计算资源。
  • 将现有的IT应用程序迁移到Big Data和数据湖——当前,企业纷纷将数据从数据湖迁移到RDBMS,以提供报告应用程序。但是最理想的情况是,在最大程度上减少从数据湖中迁移数据的需求。

寻找MapReduce的替代方案

选择MapReduce的替代方案时,您需要从多个角度进行考量。根据您想要解决的问题,您可能会做出不同的决策。通常,您会考虑当前和未来的需求以及所有权的总费用。

问题考虑事项
性能
由于用例和工作负载需要较低的延迟响应,因此用于批量处理和扩展的MapReduce不会降低性能。
  • 使用最先进的缓存架构
  • 增加尽可能少的附加硬件
  • 减少使用专门的编程语言
  • 并行的数据架构
  • 内存中执行
  • 减少数据迁移(包括临时数据)
获得回报的时间
由于Java程序的复杂性较高,因此增加了获得回报的时间。创建、测试、部署MapReduce作业的时间越长,创建POC、了解结果、将应用程序推广到生产的时间也越长,从而削弱了Big Data项目的价值。
  • 使用周知的查询语言(例如,SQL)
  • 提高数据专家的实验速度
  • 使用现有的工具,进行查询的创建和维护
缺乏人才资源和人才预算
建立数据团队是耗时而昂贵的。
  • 降低对数据专家和Java程序员的依赖
  • 利用现有的SQL的开发人员,扩充数据团队
不止于分析的深入思考
当前的关注点主要在于高延迟的批处理模式下的复杂分析。在Big Data项目取得初步的成功之后,很多客户都超越了Hadoop分析,深入了解Hadoop部署的构建和运行。
  • 解锁不同应用程序的数据,而不增加额外成本
  • 将应用程序迁移到数据湖时,最大程度地减少摩擦
  • 寻找支持多种工作负载(运营型、分析型、事务型工作负载)的数据基础设施

SQL引擎何以替代MapReduce?

选择MapReduce的替代方案是一项战略性决策,应该主要考虑企业已经在工具、应用程序、资源等方面进行了投资的成熟技术。选择一款SQL-on-Hadoop引擎是非常重要的,因为:

  • 企业拥有大量受过SQL培训的IT人才。相比SQL开发人员,行业内的数据专家和Java程序员更加稀缺。
  • 有大量的IT应用程序都依赖于SQL连接到数据库,因此SQL引擎便于数据的迁移。
  • 只要拥有适合的SQL引擎,您就可以拥有SQL+MapReduce的最优组合。

选择合适的SQL引擎并非易事

有多种SQL引擎供企业选择。要选择合适的SQL解决方案,就要考虑以下方面:

  • 功能——使用SQL引擎会产生长期的影响,所以应该选择能够承担多种工作负载的SQL引擎。
  • 性能——这是MapReduce的主要问题,因此要选择能够满足您性能需求的SQL引擎。MPP SQL引擎是很好的选择。
  • 成熟度——建立SQL引擎是一项长期的努力。各种专有RDBMS的供应商(例如,Oracle、Microsoft、HP/Tamdem、IBM)都投资了大量时间和金钱,用于开发、完善、优化RDBMS。
  • 成本——当您尝试通过Big Data实现更多时,成本是扩展部署(数据量以及应用程序和使用)的重要影响因素。
  • 扩展性——如果将SQL引擎用于大多数的用例和工作负载,您可能不想要同时维护SQL和MapReduce作业。您需要选择能够支持分析,并在DB引擎内部运行MapReduce类作业的SQL引擎。
  • 兼容性——您选择的SQL引擎应该支持生态系统内的各种组件/产品,以实现完整的解决方案。
  • 云和On-prem——大家都希望把数据迁移到云,但还是有很多企业仍然在On-prem上部署解决方案。SQL引擎应该同时支持云端和On-prem解决方案。

下载我们的完整清单,比较不同的SQL-on-Hadoop解决方案。

我们的建议

二十年来,我们团队始终处于数据库行业的领先地位,为各种全球性企业提供服务。我们很高兴看到Big Data领域的发展和创新,为数据库注入新的生机。企业应该把握时机,加快Big Data的投资回报。我们拥有Apache Trafodion(正在孵化)支持的企业级SQL数据库EsgynDB。同时,我们整合了您应该向SQL供应商提出的13个问题,以便选择合适的SQL引擎。

下载白皮书——评估您的SQL供应商