MapR 如何提高我们的生产力并简化我们的设计。
MapR 如何提高我们的生产力并简化我们的设计。
一年前，我们开始考虑如何解决一些与数据相关的问题。那时，我们当前的环境正在努力管理我们的销售点(POS)馈送。我们收到了 POS 生成的数百万条消息，以便对它们进行分析。
我们遇到的第二个问题是将 POS 数据与其他数据源相关联，这最终有助于预测商店的销售额，同时从分销商那里获得适量的产品。
我们希望能够轻松快速地关联所有这些来源，但我们还远未能有效地做到这一点，然而我们的组织付出了很多努力。
我们的 Hadoop 日志
我们从公司的另一个团队那里得到了尝试 Hadoop 的想法，该团队已经投入时间进行了调查，因为他们也有类似的问题。
我们的第一个概念验证(POC)花了几周时间才完成，在我看来，这是进入 Hadoop 世界的第一步。
这个概念验证是使用 亚马逊弹性 Mapreduce (AWS EMR) 完成的。我们在 亚马逊简单存储(S3) 存储了一堆数据，我们可以动态启动集群并使用 Apache Spark 处理这些数据。这只是一个概念验证，因此我们只展示了该解决方案的一些关键功能。我们需要知道如何处理存储在某处的数据，如何保护数据，以及如何使用非技术人员可以使用的商业智能(BI)工具进行分析，例如Microstrategy
在完成我们的第一种方法后，我们基本上被否决了，因为我们有内部基础架构来做同样的事情，基于云的解决方案不应该是我们的重点，而是在内部实施类似的解决方案。
尽管我们实际上有能力托管像提议的解决方案这样的基础架构，但我们知道实施我们需要的东西需要时间，但我们都致力于解决我们组织的问题。
现在是 Hortonworks
我们尝试的第一个厂商是Horton works(Horton)，但那时我们才刚刚起步，学习的过程缓慢而痛苦。
来自霍顿的一个团队确实在接下来的几周里每周都加入我们，检查我们在他们的平台上取得的进展。我可以说，他们是非常有知识的人，但是仍然缺少一些东西。Horton 基于开源社区，我们需要的一些组件没有更新，我们无法使用它们。
霍顿使用的商业模式也是基于开源思想的，他们免费给你整个平台，但在有资金之前不会有任何支持。对我们来说，这是一件大事，我们正在一个全新的环境中探索，我们没有任何人可以寻求帮助。
这太疯狂了
我的一个同事在试图找出为什么 Hive 在我们的 Hadoop 集群上不工作时不时地说。
是的，我们有很多配置问题，我们的集群没有正确设置，并且一些最新的软件组件不存在。此外，我们无法使用推荐的 Horton 工具找到一种好的方法来自动创建虚拟机并将其添加到集群中。
我们有问题，这很好，但我们期待他们的帮助，但我们从未得到过。
小型设计会议
从我们使用 Hortonworks 平台的初始测试开始，我们可以定义一个设计，它将成为我们未来实现的*设计。为了让每个人都能遵循，让我们回顾一下我们的数据工作流程。*
我们有源源不断的来自 web 服务的消息，这些消息是用[Apache Kafka](http://kafka.apache.org/)，编写的，这是 LinkedIn 设计的一个通用、分布式、高性能的日志队列。从这里，一个[Apache Spark](http://spark.apache.org/)jobstreams那些消息分成两个不同的流。一个流聚合它们并将其写入 Hadoop 分布式文件系统(HDFS) ，另一个流以与我们的 Teradata 环境相关的方式写入它们。**
现在，我们将信息存储在 HDFS，但大多数时候我们不知道如何关联这些信息，或者如何看待它们。我们需要一种探索这些数据的方法，我们需要一个自我的 BI 环境。
为什么是自我 BI？
BI word 中的一个常见问题是与开发 ETL 作业所需的时间相关的问题。是的，有非常熟练的人，他们的工作就是这样，而且做得又快又准。然而，我们最近看到的是，当开发人员结束创建解决方案(ETL 作业)时，业务问题已经发生了变化，因此以前的作业现在已经没有用了。
另一方面，开发人员可能会花费大量时间来创建只使用几次的作业，然后这些作业就会被废弃，因为它们不再响应业务查询。
你可能想知道为什么会这样。为什么商务人士不能就他们真正想要的达成一致？可能有很多答案，但在我们的世界里，这是因为我们不知道我们拥有的所有数据。我们需要探索它，理解它，然后建立关系，使我们能够从中获得报告。
今天，我们需要某些报告，ETL 开发人员马上开始处理它们。明天，我们会发现一个新的数据可能与 ETL 开发人员正在处理的数据相关，当他们完成时，原始需求已经发生了很大的变化，以至于他们的工作结果完全是无用的。现在，我们需要重新开始一切。
如果商务人士有能力自己探索自己的数据，那不是很好吗？
既然我们解释了为什么我们需要自我 BI 环境，让我们回到我们的设计会议。
我们如何为企业提供一个自我 BI 环境
此时，我们在 HDFS、中写入了数百千兆字节，但是我们需要高效地访问它们。
我们可以使用几个工具。Hortonworks 提供了开箱即用的 Apache Hive。Hive 是一个运行在 HDFS 之上的 SQL 引擎，但是等等，我们的业务人员不需要了解 SQL！基于此，我们将 Microstrategy 置于他们的部署之下，让他们在 Microstrategy 生成 SQL 语句的同时进行拖动和点击，这些语句通过 HDFS 上的 Hive 对我们的数据执行。
因为业务人员将使用 microstrategy 作为前端工具，我们可以将 Hive(我们的后端查询引擎)更改为任何其他处理引擎，如 Spark SQL，他们仍将在他们的终端执行相同的任务，希望不会出现问题。
表演
对于 Hortonworks 平台，我们在使用 Hive 时试验了许多性能问题。这是我们转向下一个尝试的供应商时的主要争论之一。
Apache Spark 工作得很好，但是一些团队成员不愿意在每次添加新的数据时编写一些 Scala 代码(即使所有这些过程都可以自动化，这意味着该论点不再有效)。
Apache Spark 已经成为最受欢迎的数据处理框架之一，我们肯定会回来使用它。
领先的 Hadoop 供应商 Cloudera
有一天，Cloudera 的人出现在办公室，我们被介绍给他们的平台。
为了简短地谈谈我们的体验，我不得不说，这个平台确实是企业级的，是我们一直在寻找的。所有组件都已更新，我们从第一天起就获得了他们的客户支持，他们与我们合作，以便从一开始就正确地设置集群。对我们来说，这是我们与上一个供应商合作后留下的深刻印象。
管理工具易于使用和理解。Cloudera 工具让我们能够快速工作，轻松发现他们平台的优势。
Cloudera 拥有与 Hortonworks 相同的组件，还增加了一个我们非常感兴趣的新组件， [阿帕奇黑斑羚](http://impala.io/) 。**
Impala 是我们迄今为止见过的速度更快的 SQL 遵从工具。它比蜂巢快多了。Impala 与 Microstrategy 集成得很好，所以我们的前端根本不需要改变。
共同的问题
在 Hortonworks 和 Cloudera 这两个平台中，我们面临着一个共同的挑战。我们如何公开还没有定义模式的新数据？
该过程如下:
- 手动打开提要文件(xml、json、csv 等)
- 定义一个指向提要位置的表。
- 表明我们的查询引擎(Hive，Impala)使用定义的表。
- 开始查询新数据。
问题是谁来做这件事？没有人想这样做，它应该是自动化的，但有时业务部门希望查看一些对每个人来说都是全新的文件(从他们手动生成和使用的不同来源提取)。没有办法让它自动化。业务每次要做这些操作都要依赖开发人员按照之前的流程来做。我们的 Self BI 想法是不可能的，它是不完整的，这两个平台对我们来说是不够的。
MapR 的简单性
事实是，当那些来自MapR的家伙出现时，我们是持怀疑态度的。然而，在他们谈话的最后，我想我们有点相信他们有我们的解决方案。**
尽管这个供应商不是 Hadoop 世界中最受欢迎的供应商，但他们向我们展示的内容完全符合我们的要求，所以我们决定尝试一下。
设置集群就像在 Cloudera 中一样简单，我不认为有任何问题。然而，控制台管理工具不如 Cloudera 集群中的工具好。导航和理解起来有点困难。
被 POSIX 合规的好处
MapR 符合 POSIX 标准！这意味着我们的数据路径得到了极大的简化。拥有 POSIX 平台意味着我们可以在集群内部创建一个卷，并在我们的 Linux 或 Window 环境中挂载。该卷将显示为我们计算机上的任何其他驱动器。我们可以像对待任何其他连接的存储器一样对其进行读取/写入。事实上，我们正在读/写一个分布式存储(我们的 MapR 集群)。
现在，我们可以删除卡夫卡，我们可以删除聚合消息并将它们写入 HDFS 的 Spark 作业，这样我们也可以删除数据路径中间所有移动部分的复杂性。现在我们需要担心的组件更少了，对硬件的要求也更低了。
我们最初设计的一部分是将消息流式传输到 Teradata。我们仍然可以通过将我们的 Spark 流源改为文件系统而不是 Kafka 来做到这一点，其他一切都可以正常工作。
在最初的数据移动测试中，我们在网络共享和指向 MapR 文件系统的挂载驱动器之间执行了一个 rsync 命令。我们的环境和 MapR 集群之间的传输速率为 100 Mb / s。对我们来说，这已经足够了。
MapR 如何解决我们自身的 BI 问题
MapR 带来了一个新的工具，作为对其他供应商提供的工具的补充。 Apache Drill ，一个自动发现来自不同来源的模式并在没有任何预先注册的情况下公开它们的工具。这是我们一直在寻找的工具。
是的，我们遇到了很多问题，大部分与性能有关。一些团队成员花了几个小时来解决这个问题，他们做到了。通过添加自动发现模式，我们可以像在 Impala 中一样快地获得结果。
Drill 向 Microstrategy 公开数据的方式与 Hive 和 Impala 相同，因此它可以以相同的方式使用。
因为我们可以装载不同的卷，现在业务人员可以在 MapR 集群中拥有自己的空间，因此他们可以复制和粘贴他们想要浏览的数据(流和自动馈送由 Spark jobs 等自动流程处理)。如果一个人创建了一个提取的文件，并希望将它与自动提要中的另一个文件相关联，他只需要:
- 通过挂载的卷使用复制/粘贴将该文件复制到 MapR。
- 打开 Microstrategy 并查询新数据。
在幕后，
- 钻头会把锉刀捡起来。
- 将推断模式，以便可以向 Microstrategy 公开。
- Microstrategy 会看到这个文件
- 用户将将其加入集群中的其他集群。
小文件问题
小文件问题 在 Hadoop 中是一件大事。在 Hortonworks 和 Cloudera 中，这是我们真正需要注意的事情。这是我们聚集过程背后的主要原因。我们将许多小文件聚合成一个大文件，因此我们可以通过减少写入 HDFS 的文件数量来避免小文件问题。
MapR 不使用 HDFS，相反，他们实现了 MapR-FS，这是一个文件系统，它公开了一个 HDFS 接口，因此它可以被任何设计用于 HDFS 的工具使用。它也可以通过 POSIX 命令访问，增加了与大多数操作系统兼容的任何其他文件系统工作的可能性。
在 MapR-FS 中，我们可以毫无问题地拥有数百万个小文件。这个文件系统的内部规范以及如何使用可以在 这里找到 [。 MapR 在这方面做得非常出色，我们都能从中受益。](http://doc.mapr.com/display/MapR/Working+with+MapR-FS)
阿帕奇火花
MapR 和 Cloudera 一样，在很大程度上依赖 Spark 作为其解决方案的主要组件之一。Spark 被广泛用作数据处理框架，有时也用作驱动 Impala 和 Drill 的引擎。Spark 是迄今为止任何大数据解决方案中使用最多的组件之一，因为它在处理任何任务时都具有多功能性。
关于 MapR 的结尾思考
正如我们所看到的，MapR 不仅简化了我们的解决方案，还提供了一种不同的方法来解决我们所面临的问题。MapR 可以被看作是我们环境的一个扩展，而不是我们需要构建的一个独立的环境，以便在其中移动和处理数据。尽管 MapR 管理工具比 Cloudera 提供的工具落后一点，但它们发挥了应有的作用，保持了我们环境的稳定，一直在工作。MapR 帮助我们消除不必要的流程，这样我们就可以专注于数据以及如何处理数据，这才是我们真正需要的。
如果你喜欢这种平静，你可能也会喜欢把 Apache Spark 作为一个分布式 SQL 引擎
本博客不代表我的雇主的想法、计划或策略。
黑客中午是黑客如何开始他们的下午。我们是 AMI 家庭的一员。我们现在接受投稿并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面、喜欢/在脸书给我们发消息，或者简单地说， tweet/DM @HackerNoon。