1. 1. 数据整合
  2. 2. 专业分析
  3. 3. hadoop作为一种服务
  4. 4. 流分析
  5. 5. 复杂事件处理
  6. 6. etl流
  7. 7. 更换或增加 SAS

正如原文所说的那样“如果您的Hadoop项目将有新的突破,那么它必定与下边介绍的七种常见项目很相像。”
这7中场景确实比较常见的应用,在遇到一下这些场景的时候可以考虑使用hadoop和spark生态系统完成项目。

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

数据整合

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

专业分析

许多数据整合项目实际上是从你特殊的需求和某一数据集系统的分析开始的。这些往往是令人难以置信的特定
领域,如在银行领域的流动性风险/蒙特卡罗模拟分析。在过去,这种专业的分析依赖于过时的,专有的软件包,
无法扩大数据的规模经常遭受一个有限的功能集(大部分是因为软件厂商不可能像专业机构那样了解的那么多)。
在Hadoop和Spark的世界,看看这些系统大致相同的数据整合系统,但往往有更多的HBase,定制非SQL代码,
和更少的数据来源(如果不是唯一的)。他们越来越多地以Spark为基础

hadoop作为一种服务

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

  

流分析

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

在某些情况下,这是一种新的类型的交易系统,分析数据位的位,因为你将它并联到一个分析系统中。这些系统
证明自己如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,你可能了
解它们。几年前我已经实施了这些项目中的部分案例,使用的是其它技术