大数据架构的未来
大数据问题
大家应该都清楚，数据正在以巨幅的速度增长。如果能够有效地利用这些数据，可以发现非常有价值的内容，然而传统技术（许多早在40年前设计的，比如RDBMS这样的技术）对于“大数据”的大肆宣传的商业价值的创造是远远不够的。一个使用大数据技术的典型例子就是“客户的单一视图” - 旨在汇总有关客户的所有信息，以优化客户的参与度和收益，例如精准地确定通过哪种渠道和什么时间向他们发推送。
然而，现在最大的问题是什么样的架构和解决办法能让我们能够实现这种可能性。高级关键功能要求至少包括以下能力：
- 聚集跨流量、外部和串流的数据
- 管理对数据的存取
- 根据需要来转换数据
- 汇总数据
- 提供分析数据的工具
- 对数据的汇报
- 将理念纳入运营流程
- 在最少的TCO和响应时间内完成这些所有工作
数据湖的愿景作为一种答案
许多企业都在寻找某种叫数据湖（Data Lake）的架构，这是一种灵活的数据平台，用于在单一[逻辑]位置中汇总跨流量[流式和持久性]数据，以便透过企业的数据和第三方进行挖掘和深入了解。出于多种原因，用Hadoop（包括Spark）作数据湖的有着相当大的势头。它利用低TCO商品硬件水平扩展，允许模式读取（用于接受各种各样的数据），是开源的，并且包含具有SQL和通用语言的分布式处理层。此外，像雅虎和谷歌这样的网络比例公司是早期的参考，他们在索引网络遇到问题时使用它取得了巨大的成功。
Hadoop中的数据持久性选项
因此，这好像是个可以评估数据湖愿景的解决方案的合适的地方。当您从更深的层来了解Hadoop到底是什么时，您会发现它真的是一个覆盖各种数据处理的一个宽广的工程。当我们在Hadoop的Data Lake中探索如何存储数据时，主要有两个选项：HDFS和HBase。通过HDFS，您可以在为仅附加文件的情况下决定如何将数据编码（从JSON到CSV，再到Avro等），这取决于您，因为HDFS只是一个文件系统而已。相比之下，HBase是一个数据库，它具有编码数据的特定方式，这些数据为了快速写入记录已经进行了优化，并且仅在通过主键进行查询时才相对较快。
这正是数据湖与Hadoop独有的吸引人的愿景，他们满足了实现，因此我们可以开始根据上面列出的高级需求评估Hadoop的功能。您仍然可以利用Hadoop生态系统中的分布式处理层（如Spark和Hive），而无需使用HDFS或HBase，因此您可以选择与分布式处理层分开的持久层。作为一个例子，你可以看到我以前的博客文章使用Spark DataFrames读取和写入MongoDB的数据。同样，之前的另一篇博客文章将MongoDB演示为另一个读/写的Hive表。
索引是仍然重要的
大多数熟悉RDBMS的技术人员意识到，从表达式查询能力和二级索引中快速查询（即使是RDBMS的固定模式，高TCO和有限的水平缩放使其难以用作数据湖）具有巨大的价值。如果我们只使用HDFS和HBase来实现数据湖的持久性，那么我们不会从数据库中获得临时索引的好处，并且显然会遇到一些限制：
- 临时切片 - 我们如何有效分析通过多于一个主键标识的数据切片而不是二级索引，例如对我们最好的客户群运行分析，还有那些与我们一起花费超过X数量的分析？我们在寻找我们的最优客户时将被困在扫描大量的数据中。
- 低延迟报告 - 如果我们没有灵活的索引，我们将如何对用户提供所有这些有价值数据所需的亚秒响应时间的报告？再一次我们只能使用客户的账号或其他主键来快速报告，而不是使用客户的姓名，电话号码，邮政编码，支出等。需要提醒的是，MongoDB刚刚为任何基于SQL的报告发布了BI连接器工具来使用MongoDB。
- 实施 - 同样，我们如何将最有价值的洞悉纳入最能影响公司和客户的运营应用程序中，并在没有灵活索引的情况下将数据货币化？想象一下，客户服务代表（CSR）告诉客户他/她只需要提供一个帐号来查询他们的所有信息，因为Data Lake只支持主键，或者需要10分钟才能扫描所有数据他们的信息。
当然，有些解决方法可以解决其中的一些问题，但它们引入了更高的TCO、更多的开发或操作工作、和/或更高的延迟。例如，您可以使用搜索引擎或物化视图通过除主键以外的方式进行查询，但是您必须返回到数据库主表的另一个往返行程以获得所有您想要的数据。除了延迟加倍之外，它需要更多的管理、开发工作和/或基础设施来使用单独的搜索引擎并保持物化视图，再加上将数据写入额外位置存在不必要的一致性问题。我们仍然保持我们的设计原则的同时，又拥有正常灵活的索引是不是很好吗？
MongoDB是有效数据湖的一个组成部分
我们开始探讨Hadoop是否能够满足数据湖的要求时，发现至少有3个缺口。我们是否可以在我们的体系结构中添加另一个持久层，以填补这些空白，并符合我们使用低TCO商品硬件和开源模型，架构在读和Hadoop分布式处理层的设计原则？
我选择写这个主题，是因为MongoDB是填补仅Hadoop数据湖中空白的最佳数据库。如果你使用另一个开源的NoSQL数据库，你会发现他们几乎没有二级索引（如果他们这样做，他们与数据不一致（即同步）），他们也没有分组和聚合数据库。您可以使用其中一些数据库将数据写入Data Lake，但如果您还想根据业务需求灵活地使用二级索引来同时读取数据，那么它将不符合您的要求。如果您在Data Lake中使用开源RDBMS，我们已经提到他们的固定模式和昂贵的垂直缩放模型违背了我们针对Data Lake的设计原则。
因此，下图是数据湖的推荐架构。
MongoDB集成到数据湖
该体系结构将MongoDB添加作为您需要表达式查询的任何数据集的持久层，与您上述想要索引的3个理由相关。我建议决策一个治理的功能，它根据消费者的数据要求决定是否将数据发布到HDFS和/或MongoDB。无论您是将它存储在HDFS还是MongoDB上，都可以运行分布式处理作业，例如Hive和Spark。但是，如果数据位于MongoDB上，则可以在特定的数据片上有效地运行分析，因为过滤条件被推送到数据库，并且不会像在HDFS中那样跨文件扫描。同样，MongoDB中的数据可用于实时低延迟报告，并且可用作您可能构建的所有参与和数字应用系统的运营数据平台。
我发现一些公司现在正在做的就是将他们的数据复制到Hadoop中，将其转换完成，然后把它复制到其他地方用来做任何有价值的事情。为什么不直接从数据湖中获取最大价值？使用MongoDB，您可以多次乘以该值。
总结
如果您看看您的短期和长期需求，并确保您使用核心Hadoop分销版中提供的最佳工具满足这些要求，而且还可以满足像MongoDB这样的生态系统中的最佳工具，那么数据湖愿景是有价值的且是可行的。我看到一些企业从一个数据湖开始，只花费一年时间清理所有数据并将其写入HDFS，以期在未来从中获得价值。然后，企业没有从中看到任何价值，但实际上他们和客户之间还有另一个批次层。
通过将Hadoop与MongoDB相结合，您可以确保你的数据湖成功，从而实现低TCO和灵活的数据平台，从而为所有用户（包括数据科学家和分析师，业务用户和客户本身）提供最佳响应时间。通过利用好数据湖，您的公司和您可以实现数据湖的承诺，从而获得独特的洞察力，有效地吸引客户，通过数据货币化取得竞争优势。
本文最初由Matt Kalan 在MongoDB发表。