Hadoop –大胆思考

近年来，存储价格下降了，到2012年底，甚至1 GB的SSD存储都将跌破1美元。 拥有数千台计算机的集群不再仅仅是大公司的标准。 借助Apache Hadoop和HBase之类的技术，“无所不包的文化”已变得司空见惯。 数据科学家很高兴地筛选所有原始数据，以找到更有价值的信息，并提取可提供竞争优势的业务相关数据。 机器学习可以帮助解决甚至几年前似乎很难解决的问题。 数据革命已经开始。 还是有？

阅读当今关于大数据的出版物给人的印象是必须重塑开发流程：必须存储越来越多的数据以保持竞争力。 涉及存储，分析和可视化数据的项目到处都有。 仔细研究当今生产中的各个解决方案，视图的一致性就会大大降低-通常，解决方案是由不同成熟度的多个不同部分构成的。 开发人员花费比最初估计更长的时间才能使体系结构正常工作。

本文试图将数据驱动的开发置于上下文中，并将其与实践中已经进行的工作进行比较和对比。 它显示了大数据技术如何组合在一起，以及适合它们的黄色大象和机器在哪里安装。

让我们从建立网络商店的假设示例开始。 进行头脑风暴时，想到的要求是诸如存储产品，用户数据，用户交易的地方（例如“ Mary购买了新耳机，产品ID为9887876，它们正在发货”）的活动，并且最好是过去稍后可以为Mary提供更好的产品推荐）。 商店到位后，我们可能会猜测用户可能会发现有哪些更改和改进有所帮助。 我们可能会明确要求玛丽提出她的建议。 但是，普通用户非常懒惰：他们很少提供反馈。

更容易的是在线观看用户：观看他们看到的产品，最终购买的产品，调查哪些页面的用户离开网站的比例最高，哪些页面是典型的进入页面。 当走那条路时，发展变成了四个步骤的循环：

发展的四个步骤 ：

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

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

3.决定实施什么–实施细节可能有所不同，在我们的玩具示例中，选项可能是使耳机的颜色成为索引的一部分，以便用户可以搜索它们或将其包括在构面用户界面中。

4.采取行动–实施修复程序。

最后，通过观察用户对您的修复的React，周期再次开始。 最后一步是可以对当前和将来的实施情况进行反馈。 周期越紧密，反馈可以更快地反馈到开发中，那么项目越有可能超越竞争对手（图1）。

图1：开发的四个步骤

这个开发周期不足为奇，也不应该是特别新的。 相反，对于任何成功的实现，它都是隐式完成的。 但是，这种明确的形式表明，有些步骤可以从收集定义明确的其他数据集或使用已经存在的数据集中受益匪浅。

跟踪用户的任何行为（无论是成功的还是失败的，无论是普通的还是异常的），都可以极大地支持观察。 每次用户与网上商店成功互动时，它就会显示哪些功能特别有效。 互动失败会显示缺陷和改进空间。 度量标准由新功能的成功定义，然后需要对方向进行评估。 使这一步骤明确且可衡量，可以给出明确的数字，可以将其与之进行比较。 它还使更改的目标明确化，并有助于定义是否以及何时实现该目标。

收集交互数据的第二个目标是使用该数据为单个用户提供更好的服务：最有可能的用户Mary不想再搜索另一对她评价不佳的耳机。 因此，她应该获得不同的搜索结果。 另外，她可能对非常特定的音乐类型感兴趣，并且在收到喜欢的作品时可能会很高兴。

最后，两种使用交互数据的方式都将导致图2中显示的流程图。

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

两种关于数据收集的思考方式都是新的吗？ 并不是的。 自互联网成立以来，就已经收集了交互数据。 用户倾向于在获得的基础架构中做各种有趣的事情。 结果，服务提供商很早就开始记录用户交互-只是为了诊断出导致问题的原因。

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

通常使用的数据源包括Web服务器访问日志，运行状况检查结果和响应时间日志。 所有这些都以不同但通常基于文本的格式出现，并使用sed，awk或python脚本之类的工具进行处理。 然后，结果将显示在自定义的仪表板，gnuplot图形或什至是用于日志分析的半标准工具中– AWStats是一个著名的Web服务器日志示例。

特定于应用的数据

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

在新要求方面，我们可能会发现所有客户都来自欧洲，因此营销应扩展到不同的国家。 根据用户的人口统计，网站本身可能需要不同的功能–与那些几乎无法访问网站并通过付款流程的人相比，您的普通技术客户具有不同的信息需求。 在用户功能方面，可能要根据用户过去的行为向他们推荐产品。

这里使用的工具是标准的关系数据库。 为了进行分析，有一种标准的查询语言，其中某些自定义扩展名取决于数据库系统提供程序。 为了可视化，开发人员可以提出自定义报告或使用诸如tableau之类的工具。

现在，如果日志大小超出了一台计算机的存储或计算能力，该怎么办？ 如果对客户数据库的分析在一台计算机上花费的时间太长，或者因通过扩展一台计算机来加速而太昂贵，该怎么办？ 有一个非常简单的答案：使用Apache Hadoop。

不太简单，但可能更正确的答案是：您不会绕开分布式系统进行数据分析。 选择商品硬件时，最好的选择是使用Apache Hadoop作为系统的基础。 您最需要的取决于您的具体情况。

输入Hadoop

Hadoop本身包含两个组件：HDFS和MapReduce。 HDFS在您的GNU / Linux文件系统之上提供了一个分布式文件系统（尚未正式支持Windows）。 它是基于系统运行在商用硬件上的假设而建立的，因此确实会发生故障。 为了应对，它具有自动故障转移和内置复制功能。 它还假定您正在操作硬件； 磁盘扫描比磁盘搜索便宜-这种假设甚至适用于SSD。 第三个假设是您的系统将处理大量数据–由于移动数据比移动计算更昂贵，因此Hadoop会尝试在尽可能接近数据的位置运行处理，最好是在存储数据的同一台机器上进行。 然后，MapReduce提供编程库以有效利用HDFS的功能。

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

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

MapReduce

当涉及分析时，开发人员将需要编写MapReduce作业。 有一个Java（包括一个使单元测试更容易的单独的库）以及一个C ++ API。 但是，Hadoop还带有流接口，可以使用STDIN和STDOUT进行处理，从而可以启用任何脚本语言。

但是，有时开发人员将不需要接触任何一种底层编程语言。 取而代之的是，查询语言（例如Pig，Latin或Hive的语言）与SQL非常接近，足以完成大多数任务。 如果语法不够，开发人员可以选择使用自己的运算符扩展语言。

级联试图在底层Java MapReduce和高层Pig之间提供中间立场。 Apache Giraph专注于处理图形数据，其中包括在分析图形时特别重要的运算符。

编写作业时，很快就需要链接多个MapReduce阶段。 可能要混合使用Java编写的阶段和使用Pig编写的阶段。 基于计时器或基于数据可用性的触发处理。 Hadoop的工作流管理器Oozie可以解决这些任务。

如果目标不是提供简单的统计信息，而是根据用户购买的产品类型自动将其分组，该怎么办？ 如果目标是根据用户偏爱某种产品的可能性对用户进行分类怎么办？ 如果目标是预测用户接下来最有可能键入哪些查询该怎么办？ 大多数更复杂的问题都可以用易于使用自动化方法解决的方式来表述。 Apache Mahout可解决大规模问题，并在必要时提供Hadoop绑定。

同样，在可视化方面，剩下要做的就是创建自定义报告，然后提出自定义仪表板。 同样，可以将数据导出为您喜欢的文件格式，然后在gephi等通用工具中可视化结果以进行图形可视化，也可以将数据导入常规关系数据库中并使用其工具进行可视化。

在现实世界中从未如此简单

到目前为止，我们所看到的是一个完全基于Apache Hadoop的强大，一致的基础架构。 但是，现实世界中的基础架构从来都不是那么简单。 将会保留一些关系数据库，这些数据库过于昂贵而无法迁移。 如果不能与Hadoop设置很好地集成，那么这些将仍然是孤立的数据孤岛，只有原始开发人员才能从中受益。 直接在数据库上运行的MapReduce作业将很快使该系统停机。 Hadoop对于生成针对现有系统的DOS攻击非常有效。 通常的做法是定期将数据库内容导入HDFS。 使用Sqoop，有一种工具被证明可以可靠地工作。

现在剩下的就是一个可行的解决方案，用于将日志文件从分布式系统中恢复到HDFS中。 借助Flume，Scribe和Chukwa，可以从三种系统中进行选择，以帮助进行分布式日志记录并提供Hadoop绑定。

退后一步，结果看起来已经很干净了：可以进行数据存储，分析和可视化，并且可以很好地集成现有系统。 但是，现在我们有了可以将系统扩展到数十台，数百台甚至数千台机器的软件。 这些数字不再由任何运营团队手动管理。 取而代之的是，自动配置管理和受控回滚选项变得越来越重要。 对于系统来说，诸如Chef和Puppet之类的系统，以及用于配置管理的Zookeeper之类的系统，对于扩展而言突然变得至关重要（图3）。

图3：复杂但连贯的曲线锯

最终的画面不再看起来那么简单。 除了许多不同的部分和最佳实践之外，还有很多步骤涉及对一个系统做出有意识的决定，而对另一个系统则作一个有意识的决定，如果要避免混合使用各种可以解决非常普遍的问题但在重要方面有所不同的系统细节。

这样的设置将带来什么？ 最重要的优势是数据存储的集成。 如果不再将数据隔离在数据孤岛中，那么各种各样的应用程序将成为可能，并且构建成本会降低，因为不再需要在团队之间复制数据，而是所有人都可以使用和处理这些数据。 而且，通过使以一致的方式集成所有必要的数据源成为可能，业务报告变得简单。

但是，可处理意味着数据格式是已知的，有据可查的或至少是自描述的。 突然记录不再是可选的，在出现问题时进行调试和验尸分析时将不再需要。 突然，日志文件本身就是一种资产–如果它们包含正确的信息，足够的数据和有效的条目。

通常，已经观察到Hadoop的用例在引入后就很容易确定。 但是，不应太轻率地介绍这种系统-开发人员的学习曲线仍然很陡峭。

系统仍需在DevOps级别上考虑，这意味着开发和运营必须紧密协作才能使事情正常进行。 集成尚未像其他更常见的系统那样得到充分优化和完善。 最有前途的途径是确定可以从使用Hadoop中大大受益的现有用例。 引入Apache Hadoop及其支持所需要的全部知识，将提供足够的经验，以随着时间的推移简化和适应越来越多的用例。 拥有一个驾驶项目有助于将重点放在实际业务需求上，并弄清重要特征是什么。 它还可以帮助您决定使用哪些项目来解决实际的技术问题。

Hadoop结论

总体而言，Hadoop及其生态系统提供了独特的功能，可以以合理的成本扩展到商品硬件上的大型分布式系统。 大型公司（Yahoo！，Facebook，Twitter）和小型公司（Neofonie GmbH，nurago，nuxeo）都已在生产中使用该系统来解决其分析需求。 作为Apache项目，有可能在合理的时间内参与进来并解决问题。 尽管过去的发布周期一直在增长，但是该项目本身已经发布了更快的版本，以便以较短的间隔获得功能和错误修复。 此外，该项目本身团结了来自不同背景的开发人员，并汇集了在全球范围内具有丰富分布式处理经验的团队的知识，这不仅有助于强化实施，而且为开发新功能提供了广阔的基础。 。

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

翻译自: https://jaxenter.com/hadoop-think-big-104497.html