Hadoop–大处着眼

近年来，存储设备的价格有所下降，到2012年底，甚至一GB的SSD存储设备也有望跌破一美元。拥有数千台机器的集群不再仅仅是大公司的标准。有了apachehadoop和HBase这样的技术，“一无所获的文化”已经变得很普遍。数据科学家们正在愉快地筛选所有这些原始数据，以发现更有价值的信息，并提取与业务相关的部分，从而提供竞争优势。机器学习有助于解决几年前似乎难以解决的问题。数据革命已经开始。还是有？

今天阅读有关大数据的出版物给人的印象是，必须重塑开发过程：必须存储越来越多的数据才能保持竞争力。处理存储、分析和可视化数据的项目到处都在炒作。当仔细观察当今生产中的单个解决方案时，这种观点就不那么一致了——通常解决方案是由不同成熟度的几个不同部分构建的。对于开发人员来说，使用一个体系结构所花费的时间比最初估计的要长是很正常的。

本文试图将数据驱动的开发放在上下文中—将其与已经在实践中完成的工作进行比较和对比。它展示了大数据技术是如何结合在一起的，以及黄象和适应它们的机器是如何结合在一起的。

让我们从一个假设的例子开始建立一个网上商店。头脑风暴时，脑海中浮现的需求是存储产品、用户数据、用户事务（那些活动的，例如“Mary购买了新耳机，产品ID为9887876，正在发货”，最好是过去的，以便以后能够为Mary提供更好的产品建议）。一旦商店就位，我们就可以猜测用户可能会发现哪些变化和改进是有用的。我们可以明确地征求玛丽的意见。然而，普通用户非常懒惰：他们很少提供反馈。

更容易的是在线观察用户：观察他们看什么产品，最终购买什么产品，调查哪些页面的用户离开网站的比率最高，哪些页面是典型的入口页面。沿着这条路走下去，发展就变成了四个步骤的循环：

发展的四个步骤：

1. 观察用户与应用程序的交互方式–这将导致发现多个缺陷，修复后会带来不同的好处：产品搜索可能并不理想，因为用户经常搜索特定颜色的耳机，但颜色可能尚未被索引。用户可能正在搜索“购买”按钮，因为它不在页面顶部。

2. 通过定义应用程序应该改进的方向来确定方向-决定在下一次迭代中修复哪些缺陷，并定义衡量修复成功程度的标准：使耳机的颜色可导航，并期望在一个月内使耳机销量翻番。

3. 决定要实现什么–实现细节可能会有所不同，在我们的玩具示例中，选项可能是将耳机的颜色作为索引的一部分，这样用户就可以搜索它们，或者将它们包含在刻面用户界面中。

4. 行动–实施修复

最后，通过观察用户对修复的反应，这个周期又开始了。最后一步是可以对当前和未来的执行情况作出哪些反馈。周期越紧，反馈就越快地反馈到开发中，项目就越有可能超越竞争对手（图1）。

图1：开发的四个步骤

这种发展周期并不奇怪，也不应该是特别新的。相反，它是为任何成功的实现所隐含的。但是，这种显式形式表明，有些步骤可以从收集定义良好的附加数据集或使用已有的数据集中获益匪浅。

通过跟踪任何用户行为（常见和不常见、成功和不成功）可以极大地支持观察。每次用户成功地与网店进行交互时，都会显示哪些功能特别有效。不成功的互动揭示了不足和改进的空间。一个度量是由一个新特征的成功定义的，然后需要在方向上进行评估。使这一步骤明确和可衡量，就可以得到明确的数字，可以将变化与之进行比较。它还明确了变革的目标，并有助于确定是否以及何时达到该目标。

收集交互数据的第二个目标是利用这些数据为个人用户提供更好的服务：用户Mary很可能不想再寻找另一副她评价不好的耳机。所以她应该得到不同的搜索结果。此外，她可能对一种非常特殊的音乐类型感兴趣，当她收到自己喜欢的音乐集时，她可能会非常高兴。

最后，两种类型的使用交互数据的结果都显示在图2中的流程图中。

图2：两种类型的交互数据

关于数据收集的任何一种方法都是新的吗？不是真的。自互联网出现之初，人们就开始收集互动数据。用户倾向于在所提供的基础设施中做各种有趣的事情。因此，服务提供商很早就开始记录用户交互——可能只是为了在效果之后诊断是什么导致了问题。

该级别上更常见的需求工程类型包括基于过去流量模式的机器大小调整，针对可见的入侵尝试强化设置。基于用户数据的典型功能包括仅向在线杂志的读者显示新内容或根据用户请求的来源显示不同的内容。

使用的数据源通常包括web服务器访问日志、运行状况检查结果和响应时间日志。所有这些都有不同的格式，但通常都是基于文本的格式，可以通过sed、awk或python脚本等工具进行处理。结果随后会显示在定制的仪表板、gnuplot图表甚至日志分析的半标准工具中——AWStats是web服务器日志的一个著名例子。

应用程序特定数据

让我们更进一步，看看特定于应用程序的数据：这些数据包括客户数据库、事务日志等。从中可以学到什么？

根据新的要求，我们可能会发现所有的客户都来自欧洲，所以营销应该扩展到不同的国家。根据用户的统计数据，网站本身可能需要不同的功能——一般精通技术的客户对信息的需求不同于那些几乎无法访问网站并通过支付流程的客户。在用户特性方面，人们可能希望根据用户过去的个人行为向用户推荐产品。

这里使用的工具是标准关系数据库。对于分析，有一种标准的查询语言，根据数据库系统提供程序，有一些自定义扩展。对于可视化，开发人员可以使用自定义报告或使用tableau之类的工具。

现在，如果日志大小超出了一台计算机的存储或计算容量，该怎么办？如果客户数据库的分析在一台机器上花费的时间太长，或者成本太高，无法通过扩展这台机器来加快速度，该怎么办？有一个非常简单的答案：以apachehadoop为例。

答案不那么简单，但可能更正确：您将无法绕过分布式系统进行数据分析。当选择商品硬件时，最好的选择是使用apachehadoop作为系统的基础。你需要什么取决于你的具体情况。

输入Hadoop

Hadoop本身有两个组件：HDFS和MapReduce。HDFS在GNU/Linux文件系统之上提供了一个分布式文件系统（Windows还没有得到官方支持）。它是建立在假设系统在商品硬件上运行的基础上的，因此故障确实会发生。为了应对这种情况，它提供了自动故障切换和内置复制。它还假设您正在操作硬件；磁盘扫描比磁盘查找便宜—这种假设即使对于SSD也是成立的。第三个假设是，您的系统将处理大量数据—由于移动数据比移动计算更昂贵，Hadoop将尝试尽可能靠近数据运行处理，理想情况下是在存储数据的同一台机器上。MapReduce然后提供了编程库来有效地利用HDFS的特性。

由于HDFS只提供原始文件存储，因此有多个库提供数据的结构化存储—以压缩二进制格式提供可升级的数据结构。例如Avro、Thrift和protocolbuffers。

HDFS本身非常适合后台处理，但不太适合在线使用。如果您有如此多的用户，以至于标准数据库无法再处理流量，并且希望您的系统能够与Hadoop（尤其是MapReduce作业）很好地集成，那么Apache HBase（以及Hypertable）就是需要考虑的存储系统。两者都提供了良好的在线访问性能。

MapReduce

在分析方面，开发人员需要编写MapReduce作业。有一个java（包括一个单独的库，使单元测试更容易），以及C++的API可用。不过，Hadoop还提供了一个流接口，它可以使用STDIN和STDOUT进行处理，从而支持任何脚本语言。

然而，有时开发人员不需要接触任何一种低级编程语言。相反，查询语言（如Pig、Latin或Hive的语言）非常接近SQL，对于大多数任务来说已经足够了。在语法不够的地方，开发人员可以选择使用自己的操作符来扩展语言。

级联试图在低级javamapreduce和高级Pig之间提供一个中间地带。apachegiraph专注于处理图形数据，包括在分析图形时特别重要的操作符。

在编写作业时，需要快速链接多个MapReduce阶段。可能需要将用Java编写的阶段和用Pig编写的阶段进行混合和匹配。基于计时器或基于数据可用性的触发处理。这些任务可以由Oozie——Hadoop的工作流管理器来解决。

如果我们的目标不是提供简单的统计数据，而是根据用户购买的产品类型自动对用户进行分组呢？如果目标是根据用户偏好某种产品的可能性来对用户进行分类呢？如果目标是预测用户下一步最有可能键入什么查询呢？大多数更复杂的问题都可以用某种方式来表达，使它们更容易用自动化方法来解决。apachemahout有助于解决大规模的问题，并在必要时提供Hadoop绑定。

在可视化方面，仍然需要做的是创建自定义报告，然后生成自定义仪表板。此外，还可以将数据导出到首选的文件格式，然后在通用工具（如gephi）中可视化结果以进行图形可视化，或者将数据导入常规关系数据库并使用它们的工具进行可视化。

在现实世界中从来没有这么简单过

到目前为止，我们看到的是一个完全基于apachehadoop的强大、一致的基础设施。然而，现实世界中的基础设施从来就不是那么简单。会有一些关系数据库继续运行，但迁移成本太高。如果没有与Hadoop设置很好地集成，那么这些将仍然是孤立的数据仓库，除了最初的开发人员之外，没有人能从中受益。直接针对数据库运行的MapReduce作业将很快导致系统瘫痪。Hadoop对于生成针对现有系统的DOS攻击非常有效。通常的做法是定期将数据库内容导入HDFS。使用Sqoop，有一个工具已经被证明是可靠的。

现在只剩下一个可行的解决方案，将分布式系统中的日志文件恢复到HDFS中。对于Flume、Scribe和Chukwa，有三种系统可供选择，它们有助于分布式日志记录并提供Hadoop绑定。

退一步来看，结果看起来已经相当清晰：数据存储、分析和可视化都可用，现有系统集成良好。然而，现在我们有了软件，可以将系统扩展到几十台、几百台甚至几千台机器。这些数字不再由任何运营团队手动管理。相反，自动化配置管理和受控回滚选项变得越来越重要。像Chef和Puppet这样的系统，以及Zookeeper这样的配置管理系统，突然间成为了扩展的关键（图3）。

图3：一个复杂但连贯的拼图

最后的画面看起来不再那么简单了。除了许多不同的部分和最佳实践之外，如果要避免混合和匹配所有解决非常常见的问题但在重要细节上不同的各种系统，还有许多步骤涉及到有意识地对一个系统和另一个系统做出决策。

这样的设置有什么好处？最重要的优点是数据存储的集成。如果数据不再在数据筒仓中分离，那么所有类型的应用程序都将成为可能，而且构建成本也会降低，因为数据不再需要从一个团队复制到另一个团队，而是可以供所有人使用和处理。此外，通过以一致的方式集成所有必要的数据源，业务报告变得非常简单。

然而，可处理意味着数据格式是已知的、文档化的或至少是自描述的。突然之间，日志记录不再是可选的，并且在出现问题时需要进行调试和事后分析。突然之间，如果日志文件包含正确的信息、足够的数据和有效的条目，那么日志文件本身就是一种资产。

一般来说，Hadoop的用例在引入之后很容易识别。然而，我们不应该对这样一个系统的引入掉以轻心——开发人员的学习曲线仍然相当陡峭。

系统仍然需要在DevOps级别上考虑，这意味着开发和操作必须紧密地结合在一起才能工作。集成还没有完全优化，并且没有像其他更常见的系统那样做得很好。最有希望的途径是确定一个现有的用例，它将从使用Hadoop中获益匪浅。引入apachehadoop，以及支持它所需的一切，将提供足够的经验来简化和适应越来越多的用例。拥有一个驱动项目有助于关注真实的业务需求，并找出重要的特性。它还有助于决定使用什么项目来解决实际的技术问题。

Hadoop结论

总的来说，Hadoop及其生态系统提供了独特的特性，允许以合理的成本扩展到商品硬件上的大型分布式系统。该系统已在生产中使用的两个较大的（雅虎！，Facebook，Twitter）和更小的（Neofonie GmbH，nurago，nuxeo）公司来解决他们的分析需求。作为一个Apache项目，可以在合理的时间内参与并解决问题。尽管发布周期在过去一直在增长，但项目本身发布了更快的版本，以便在更短的时间间隔内获得特性和bug修复。此外，项目本身将来自不同背景的开发人员团结在一起，并将来自世界各地具有大量分布式处理经验的团队的知识汇集在一起，这不仅有助于强化实现，而且为开发新功能提供了广泛的基础。

几年后发布了1.0版本，它显示了开发人员对代码库成熟度的信任。在即将发布的版本中，将资源管理与计算库分离的体系结构将变得更加灵活。这将使开发人员能够将MapReduce视为一个简单的编程库，并独立于集群版本开发mapreduceapi。2012年将给该项目带来许多改进。通过加入用户和开发人员的邮件列表，确保成为流程的一部分。您可以通过提供有价值的补丁程序来解决仍然存在的问题，从而将您的知识和工作投入到流程中来。