大数据架构师必读：常见的七种Hadoop和Spark项目案例.pdfVIP

大数据架构师必读：常见的七种Hadoop和Spark项目案例 如果您的Hadoop项目将有新的突破，那么它必定与下边介绍的七种常见项目很相像。 有一句古老的格言是这样说的，如果你向某人提供你的全部支持和金融支持去做一些不同 的和创新的事情，他们最终却会做别人正在做的事情。如比较火爆的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也很贵，我们不需要为你的