7种最常见的Hadoop和Spark项目

简介:

有一句古老的格言是这样说的,如果你向某人提供你的全部支持和金融支持去做一些不同的和创新的事情,他们最终却会做别人正在做的事情。如比较火爆的Hadoop、Spark和Storm,每个人都认为他们正在做一些与这些新的大数据技术相关的事情,但它不需要很长的时间遇到相同的模式。具体的实施可能有所不同,但根据我的经验,以下所列的是最常见的七种项目。

项目一:数据整合

称之为“企业级数据中心”或“数据湖”,这个想法是你有不同的数据源,你想对它们进行数据分析。这类项目包括从所有来源获得数据源(实时或批处理)并且把它们存储在hadoop中。有时,这是成为一个“数据驱动的公司”的第一步;有时,或许你仅仅需要一份漂亮的报告。“企业级数据中心”通常由HDFS文件系统和HIVE或IMPALA中的表组成。未来,HBase和Phoenix在大数据整合方面将大展拳脚,打开一个新的局面,创建出全新的数据美丽新世界。

销售人员喜欢说“读模式”,但事实上,要取得成功,你必须清楚的了解自己的用例将是什么(Hive模式不会看起来与你在企业数据仓库中所做的不一样)。真实的原因是一个数据湖比Teradata和Netezza公司有更强的水平扩展性和低得多的成本。许多人在做前端分析时使用Tabelu和Excel。许多复杂的公司以“数据科学家”用Zeppelin或IPython笔记本作为前端。

项目二:专业分析

许多数据整合项目实际上是从你特殊的需求和某一数据集系统的分析开始的。这些往往是令人难以置信的特定领域,如在银行领域的流动性风险/蒙特卡罗模拟分析。在过去,这种专业的分析依赖于过时的,专有的软件包,无法扩大数据的规模经常遭受一个有限的功能集(大部分是因为软件厂商不可能像专业机构那样了解的那么多)。

在Hadoop和Spark的世界,看看这些系统大致相同的数据整合系统,但往往有更多的HBase,定制非SQL代码,和更少的数据来源(如果不是唯一的)。他们越来越多地以Spark为基础。

项目三:Hadoop作为一种服务

在“专业分析”项目的任何大型组织(讽刺的是,一个或两个“数据整理”项目)他们会不可避免地开始感觉“快乐”(即,疼痛)管理几个不同配置的 Hadoop集群,有时从不同的供应商。接下来,他们会说,“也许我们应该整合这些资源池,”而不是大部分时间让大部分节点处于资源闲置状态。它们应该组成云计算,但许多公司经常会因为安全的原因(内部政治和工作保护)不能或不会。这通常意味着很多Docker容器包。

我没有使用它,但最近Bluedata(蓝色数据国际中心)似乎有一个解决方案,这也会吸引小企业缺乏足够的资金来部署Hadoop作为一种服务。

项目四:流分析

很多人会把这个“流”,但流分析是不同的,从设备流。通常,流分析是一个组织在批处理中的实时版本。以反洗钱和欺诈检测:为什么不在交易的基础上,抓住它发生而不是在一个周期结束?同样的库存管理或其他任何。

在某些情况下,这是一种新的类型的交易系统,分析数据位的位,因为你将它并联到一个分析系统中。这些系统证明自己如Spark或Storm与Hbase作为常用的数据存储。请注意,流分析并不能取代所有形式的分析,对某些你从未考虑过的事情而言,你仍然希望分析历史趋势或看过去的数据。

项目五:复杂事件处理

在这里,我们谈论的是亚秒级的实时事件处理。虽然还没有足够快的超低延迟(皮秒或纳秒)的应用,如高端的交易系统,你可以期待毫秒响应时间。例子包括对事物或事件的互联网电信运营商处理的呼叫数据记录的实时评价。有时,你会看到这样的系统使用Spark和HBase——但他们一般落在他们的脸上,必须转换成Storm,这是基于由LMAX交易所开发的干扰模式。

在过去,这样的系统已经基于定制的消息或高性能,从货架上,客户端-服务器消息产品-但今天的数据量太多了。我还没有使用它,但Apex项目看起来很有前途,声称要比Storm快。

项目六:ETL流

有时你想捕捉流数据并把它们存储起来。这些项目通常与1号或2号重合,但增加了各自的范围和特点。(有些人认为他们是4号或5号,但他们实际上是在向磁盘倾倒和分析数据。),这些几乎都是Kafka和Storm项目。Spark也使用,但没有理由,因为你不需要在内存分析。

项目七:更换或增加SAS

SAS是精细,是好的但SAS也很贵,我们不需要为你的数据科学家和分析师买存储你就可以“玩”数据。此外,除SAS可以做或产生漂亮的图形分析外,你还可以做一些不同的事情。这是你的“数据湖”。这里是IPython笔记本(现在)和Zeppelin(以后)。我们用SAS存储结果。

当我每天看到其他不同类型的Hadoop,Spark,或Storm项目,这些都是正常的。如果你使用Hadoop,你可能了解它们。几年前我已经实施了这些项目中的部分案例,使用的是其它技术。

如果你是一个老前辈太害怕“大”或“做”大数据Hadoop,不要担心。事情越变越多,但本质保持不变。你会发现很多相似之处的东西你用来部署和时髦的技术都是围绕Hadooposphere旋转的。

本文转自d1net(转载)

相关文章
|
存储 分布式计算 Hadoop
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
619 79
|
9月前
|
分布式计算 Java 大数据
springboot项目集成dolphinscheduler调度器 可拖拽spark任务管理
springboot项目集成dolphinscheduler调度器 可拖拽spark任务管理
476 2
|
分布式计算 Kubernetes Hadoop
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
847 6
|
分布式计算 资源调度 Hadoop
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
408 2
|
存储 分布式计算 Hadoop
数据湖技术:Hadoop与Spark在大数据处理中的协同作用
【10月更文挑战第27天】在大数据时代,数据湖技术凭借其灵活性和成本效益成为企业存储和分析大规模异构数据的首选。Hadoop和Spark作为数据湖技术的核心组件,通过HDFS存储数据和Spark进行高效计算,实现了数据处理的优化。本文探讨了Hadoop与Spark的最佳实践,包括数据存储、处理、安全和可视化等方面,展示了它们在实际应用中的协同效应。
675 2
|
存储 分布式计算 Hadoop
数据湖技术:Hadoop与Spark在大数据处理中的协同作用
【10月更文挑战第26天】本文详细探讨了Hadoop与Spark在大数据处理中的协同作用,通过具体案例展示了两者的最佳实践。Hadoop的HDFS和MapReduce负责数据存储和预处理,确保高可靠性和容错性;Spark则凭借其高性能和丰富的API,进行深度分析和机器学习,实现高效的批处理和实时处理。
576 1
|
分布式计算 Java Spark
|
10月前
|
人工智能 分布式计算 大数据
大数据≠大样本:基于Spark的特征降维实战(提升10倍训练效率)
本文探讨了大数据场景下降维的核心问题与解决方案,重点分析了“维度灾难”对模型性能的影响及特征冗余的陷阱。通过数学证明与实际案例,揭示高维空间中样本稀疏性问题,并提出基于Spark的分布式降维技术选型与优化策略。文章详细展示了PCA在亿级用户画像中的应用,包括数据准备、核心实现与效果评估,同时深入探讨了协方差矩阵计算与特征值分解的并行优化方法。此外,还介绍了动态维度调整、非线性特征处理及降维与其他AI技术的协同效应,为生产环境提供了最佳实践指南。最终总结出降维的本质与工程实践原则,展望未来发展方向。
476 0
|
分布式计算 大数据 Apache
ClickHouse与大数据生态集成:Spark & Flink 实战
【10月更文挑战第26天】在当今这个数据爆炸的时代,能够高效地处理和分析海量数据成为了企业和组织提升竞争力的关键。作为一款高性能的列式数据库系统,ClickHouse 在大数据分析领域展现出了卓越的能力。然而,为了充分利用ClickHouse的优势,将其与现有的大数据处理框架(如Apache Spark和Apache Flink)进行集成变得尤为重要。本文将从我个人的角度出发,探讨如何通过这些技术的结合,实现对大规模数据的实时处理和分析。
1119 2
ClickHouse与大数据生态集成:Spark & Flink 实战
|
存储 分布式计算 算法
大数据-106 Spark Graph X 计算学习 案例:1图的基本计算、2连通图算法、3寻找相同的用户
大数据-106 Spark Graph X 计算学习 案例:1图的基本计算、2连通图算法、3寻找相同的用户
354 0

相关实验场景

更多