非传统数据存储的数据工程师指南

数据工程

随着大数据和数据科学的兴起，许多工程角色正在受到挑战和扩展。 一个新时代的角色是数据工程。

最初，数据工程的目的是加载外部数据源和设计数据库（设计和开发用于收集、操作、存储和分析数据的管道）。

从那以后，它已经发展到支持大数据的数量和复杂性。 因此，数据工程现在包含了广泛的技能，从网络爬取、数据清理、分布式计算以及数据存储和检索。

对于数据工程和数据工程师来说，数据存储和检索是管道的关键组成部分，以及如何使用和分析数据。

最近，出现了许多新的和不同的数据存储技术。 但是，哪一个最适合并具有最适合数据工程的特性？

大多数工程师都熟悉 SQL 数据库，例如 PostgreSQL、MSSQL 和 MySQL，这些数据库以关系数据表的形式结构化，并具有面向行的存储。

鉴于这些数据库无处不在，我们今天不讨论它们。 相反，我们探索了三种类型的替代数据存储，它们越来越受欢迎，并引入了不同的数据处理方法。

在数据工程的上下文中，这些技术是搜索引擎、文档存储和列式存储。

• 搜索引擎擅长文本查询。 与 SQL 数据库中的文本匹配（例如LIKE ）相比，搜索引擎提供了更高的查询能力和更好的开箱即用性能。
• 文档存储提供比传统数据库更好的数据模式适应性。 通过将数据存储为单个文档对象，通常表示为 JSON，它们不需要模式预定义。
• 列式存储专门用于单列查询和值聚合。 SQL 操作（例如SUM和AVG ）在列存储中要快得多，因为同一列的数据在硬盘驱动器上存储得更近。

在本文中，我们将探讨所有三种技术：作为搜索引擎的 Elasticsearch、作为文档存储的 MongoDB，以及作为列式存储的 Amazon Redshift。

通过了解替代数据存储，我们可以为每种情况选择最合适的一种。

为了比较这些技术，我们将研究它们如何索引、分片和聚合数据。

每种数据索引策略都改进了某些查询，同时阻碍了其他查询。

了解最常使用哪些查询可以影响采用哪个数据存储。

分片是一种数据库将其数据分成块的方法，它决定了基础架构将如何随着更多数据的摄取而增长。

选择与我们的增长计划和预算相匹配的公司至关重要，这适用于任何数据科学公司，无论规模大小。

最后，这些技术各自聚合其数据的方式非常不同。

当我们处理千兆字节和千兆字节的数据时，错误的聚合策略会限制我们可以生成的报告的类型和性能。

作为数据工程师，我们在评估不同的数据存储时必须考虑所有三个方面。

竞争者

搜索引擎：弹性搜索

Elasticsearch 因其可扩展性和易于集成性而迅速在同行中广受欢迎。 它建立在 Apache Lucene 之上，提供了强大的、开箱即用的文本搜索和索引功能。 除了传统的搜索引擎任务、文本搜索和精确值查询之外，Elasticsearch 还提供分层聚合功能。

文档存储：MongoDB

在这一点上，MongoDB 可以被认为是首选的 NoSQL 数据库。 它的易用性和灵活性很快赢得了它的欢迎。 MongoDB 支持丰富且适应性强的查询，以挖掘复杂的文档。 经常查询的字段可以通过索引来加速，当聚合大量数据时，MongoDB 提供了多级管道。

列式存储：Amazon Redshift

随着 NoSQL 的普及，列式数据库也引起了人们的关注，尤其是在数据分析方面。 通过将数据存储在列中而不是通常的行中，可以直接从磁盘执行聚合操作，从而大大提高性能。 几年前，亚马逊为一家名为 Redshift 的柱状商店推出了托管服务。

索引

Elasticsearch 的索引能力

在许多方面，搜索引擎是专门用于索引文本的数据存储。

虽然其他数据存储基于字段的确切值创建索引，但搜索引擎允许仅使用（通常是文本）字段的片段进行检索。

默认情况下，此检索是通过分析器对每个字段自动完成的。

分析器是一个模块，它通过评估字段值并将它们分解为更小的值来创建多个索引键。

例如，一个基本的分析器可能会将“the quick brown fox jumped over the lazy dog”检查成诸如“the”、“quick”、“brown”、“fox”等单词。

此方法使用户可以通过在结果中搜索片段来查找数据，按与相同文档数据匹配的片段数量进行排序。

更复杂的分析器可以利用编辑距离、n-gram 和停用词过滤来构建全面的检索索引。

MongoDB的索引能力

作为通用数据存储，MongoDB 在索引数据方面具有很大的灵活性。

与 Elasticsearch 不同的是，它默认只索引_id字段，我们需要手动为经常查询的字段创建索引。

与 Elasticsearch 相比，MongoDB 的文本分析器没有那么强大。 但它确实为索引方法提供了很大的灵活性，从用于优化查询的复合和地理空间到用于减少存储的 TTL 和稀疏。

Redshift 的索引能力

与 Elasticsearch、MongoDB 甚至包括 PostgreSQL 在内的传统数据库不同，Amazon Redshift 不支持索引方法。

相反，它通过在磁盘上保持一致的排序来减少查询时间。

作为用户，我们可以将一组有序的列值配置为表排序键。 在磁盘上对数据进行排序后，如果其值超出查询范围，Redshift 可以在检索期间跳过整个块，从而大大提高性能。

分片

Elasticsearch 的分片能力

Elasticsearch 建立在 Lucene 之上，可水平扩展并为生产做好准备。

扩展是通过创建多个 Lucene 实例（分片）并将它们分布在集群内的多个节点（服务器）上来完成的。

默认情况下，每个文档都通过其_id字段路由到其各自的分片。

在检索过程中，主节点向每个分片发送查询的副本，然后最终汇总和排列它们以供输出。

MongoDB的分片能力

在 MongoDB 集群中，存在三种类型的服务器：路由器、配置和分片。

通过扩展路由器，服务器可以接受更多请求，但繁重的工作发生在分片服务器上。

与 Elasticsearch 一样，MongoDB 文档（默认情况下）通过_id路由到它们各自的分片。 在查询时，配置服务器通知路由器，路由器将查询分片，然后路由器服务器分发查询并聚合结果。

Redshift 的分片能力

一个 Amazon Redshift 集群由一个领导节点和多个计算节点组成。

领导节点处理查询的编译和分发以及中间结果的聚合。

与 MongoDB 的路由器服务器不同，领导节点是一致的，不能横向扩展。

虽然这会造成瓶颈，但它也允许有效缓存流行查询的已编译执行计划。

聚合

Elasticsearch 的聚合能力

Elasticsearch 中的文档可以按精确、范围甚至时间和地理位置值进行分类。

这些桶可以通过嵌套聚合进一步分组为更精细的粒度。

可以为每一层计算指标，包括平均值和标准差，从而提供在单个查询中计算分析层次结构的能力。

作为基于文档的存储，它确实受到文档内字段比较的限制。

例如，虽然它擅长过滤字段关注者是否大于 10，但我们无法检查关注者是否大于关注的另一个字段。

作为替代方案，我们可以将脚本作为自定义谓词注入。 此功能非常适合一次性分析，但在生产中性能会受到影响。

MongoDB的聚合能力

聚合管道功能强大且快速。

顾名思义，它以分阶段的方式对返回的数据进行操作。

每个步骤都可以过滤、聚合和转换文档，引入新的指标，或者展开以前聚合的组。

因为这些操作是分阶段完成的，并且通过确保将文档和字段减少到仅过滤，可以最小化内存成本。 与 Elasticsearch 甚至 Redshift 相比，Aggregation Pipeline 是一种查看数据的极其灵活的方式。

尽管具有适应性，但 MongoDB 与 Elasticsearch 一样缺乏文档内字段比较。

此外，一些操作，包括$group ，需要将结果传递给主节点。

因此，它们不利用分布式计算。

那些不熟悉分阶段流水线计算的人会发现某些任务不直观。 例如，对数组字段中元素的数量求和需要两个步骤：首先是$unwind ，然后是$group操作。

Redshift 的聚合能力

Amazon Redshift 的优势不容小觑。

Amazon Redshift 快速解决了在分析移动流量时在 MongoDB 上聚合缓慢的问题。

支持 SQL，传统数据库工程师可以轻松地将他们的查询迁移到 Redshift。

除了入门时间，SQL 是一种经过验证、可扩展且功能强大的查询语言，可轻松支持文档内/行内字段比较。 Amazon Redshift 通过编译和缓存在计算节点上执行的流行查询进一步提高了性能。

作为关系数据库，Amazon Redshift 不具备 MongoDB 和 Elasticsearch 所具有的架构灵活性。 针对读取操作进行了优化，它在更新和删除期间会受到性能影响。

为了保持最佳读取时间，必须对行进行排序，从而增加额外的操作工作量。

为那些有 PB 级问题的人量身定做，它并不便宜，而且可能不值得投资，除非其他数据库存在扩展问题。

挑选获胜者

在本文中，我们在数据工程的背景下研究了三种不同的技术——Elasticsearch、MongoDB 和 Amazon Redshift。 但是，没有明显的赢家，因为这些技术中的每一项都是其存储类型类别的领先者。

对于数据工程，根据用例，某些选项比其他选项更好。

• MongoDB是一个很棒的入门数据库。 当数据模式仍有待确定时，它提供了我们想要的灵活性。 也就是说，MongoDB 的性能并不优于其他数据库擅长的特定用例。
• 虽然Elasticsearch提供了与 MongoDB 类似的流动模式，但它针对多个索引和文本查询进行了优化，但以牺牲写入性能和存储大小为代价。 因此，当我们发现自己在 MongoDB 中维护大量索引时，我们应该考虑迁移到 Elasticsearch。
• Redshift需要预定义的数据模式，并且缺乏 MongoDB 提供的适应性。 作为回报，它在仅涉及单个（或几个）列的查询方面优于其他数据库。 在预算允许的情况下，当其他人无法处理数据量时，Amazon Redshift 是一个很好的秘密武器。