工程数据

随着 big data 在数据科学领域，许多工程角色正在受到挑战和扩展. 一个新时代的角色是 工程数据.

Originally, 数据工程的目的是加载外部数据源和设计数据库(设计和开发用于收集的管道), manipulate, store, 并分析数据).

它已经发展到能够支持大数据的数量和复杂性. 因此，数据工程现在包含了广泛的技能, 从网页, data cleansing, 分布式计算, 以及数据存储和检索.

对于数据工程和 data engineers, 数据存储和检索以及如何使用和分析数据是管道的关键组成部分.

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

大多数工程师都熟悉SQL数据库, 例如PostgreSQL, MSSQL, and MySQL, 哪些是在面向行存储的关系数据表中结构化的.

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

在数据工程的上下文中, 这些技术就是搜索引擎, 文档存储, 柱状商店.

• Search engines 擅长文本查询. 与SQL数据库中的文本匹配进行比较时，例如 LIKE，搜索引擎提供更高的查询能力和更好的开箱即用性能.
• 文档存储 提供比传统数据库更好的数据模式适应性. 通过将数据存储为单独的文档对象, 通常表示为JSONs, 它们不需要模式预定义.
• 柱状的商店 专注于单列查询和值聚合. SQL操作，如 SUM and AVG, 在柱状存储中速度更快吗, 由于同一列的数据存储在硬盘驱动器上的距离更近.

在本文中，我们将探讨这三种技术: Elasticsearch 作为一个搜索引擎， MongoDB 作为文档存储，和 亚马逊红移 作为柱状存储.

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

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

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

了解最常用的查询可以影响采用哪种数据存储.

Sharding, 数据库将数据分成块的一种方法, 确定随着数据的增加，基础设施将如何增长.

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

最后，这些技术的数据聚合方式各不相同.

当我们处理千兆字节和兆兆字节的数据时, 错误的聚合策略会限制我们生成的报表的类型和性能.

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

Contenders

搜索引擎:Elasticsearch

Elasticsearch因其可扩展性和易于集成而迅速在同行中流行起来. 建在…之上 Apache Lucene，它提供了一个强大的，开箱即用的文本搜索和索引功能. 除了传统的搜索引擎任务, text search, 精确值查询, Elasticsearch还提供分层聚合功能.

文档存储:MongoDB

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

柱状存储:亚马逊红移

随着NoSQL越来越受欢迎, 列式数据库也引起了人们的注意, 特别是对于数据分析. 通过将数据存储在列中而不是通常的行中, 聚合操作可以直接从磁盘执行, 大大提高性能. 几年前，亚马逊为一个名为Redshift的列式商店推出了托管服务.

Indexing

Elasticsearch的索引能力

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

而其他数据存储则根据字段的确切值创建索引, 搜索引擎只允许检索字段的一部分(通常是文本).

默认情况下，通过分析器对每个字段自动进行检索.

An analyzer 模块是否通过评估字段值并将其分解为更小的值来创建多个索引键.

For example, 一个基本的分析者可能会把“敏捷的棕色狐狸跳过了懒惰的狗”这句话转换成文字, such as “the,” “quick,” “brown,“狐狸”等等.

该方法使用户可以通过在结果中搜索片段来查找数据, 根据有多少片段匹配相同的文档数据进行排序.

一个更复杂的分析仪可以利用 edit distances, n-grams, and filter by stopwords，建立全面的检索索引.

MongoDB的索引能力

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

不像Elasticsearch，它只索引 _id 字段，我们需要手动为常用查询字段创建索引.

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

红移的索引能力

不像Elasticsearch, MongoDB, 甚至是传统的数据库, 包括PostgreSQL, 亚马逊红移不支持索引方法.

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

作为用户，我们可以配置一组有序的列值作为表排序键. 磁盘上的数据已经排序了, 如果它的值超出查询范围，红移可以在检索期间跳过整个块, 大幅提升性能.

Sharding

Elasticsearch的分片能力

Elasticsearch是建立在Lucene之上的，可以横向扩展，并且可以用于生产.

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

默认情况下，每个文档通过其 _id field.

在检索, 主节点向每个分片发送查询的副本，然后最终对它们进行聚合和排序以输出.

MongoDB的分片能力

在MongoDB集群中，有三种类型的服务器:路由器、配置和分片.

通过缩放路由器, 服务器可以接受更多的请求, 但是繁重的工作发生在分片服务器上.

与Elasticsearch一样，MongoDB文档(默认情况下)通过 _id 到它们各自的分片. 在查询时间, 配置服务器通知路由器, 哪些对查询进行分片, 然后路由器服务器分发查询并聚合结果.

Redshift的分片能力

一个亚马逊红移集群由一个领导节点和几个计算节点组成.

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

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

这就造成了瓶颈, 它还允许对流行查询的编译执行计划进行高效缓存.

Aggregating

Elasticsearch的聚合能力

Elasticsearch中的文档可以按精确的分类, ranged, 甚至是时间和地理位置值.

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

Metrics, 包括均值和标准差, 可以为每层计算吗, 它提供了在单个查询中计算分析层次结构的能力.

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

例如，虽然它擅长过滤字段 followers 是否大于10，我们无法检查 followers 比别的场大吗 following.

作为替代方案，我们可以将脚本作为自定义谓词注入. 这个特性对于一次性分析非常有用，但是在生产环境中会影响性能.

MongoDB的聚合能力

The 聚合管道 是强大和快速的.

顾名思义，它以分阶段的方式操作返回的数据.

每一步都可以过滤, 聚合和转换文档, 引入新指标, 或者展开先前聚合的组.

因为这些操作是以分阶段的方式完成的, 通过确保文档和字段只被过滤, 内存成本可以最小化. 与Elasticsearch相比, 甚至红移, 聚合管道是一种非常灵活的查看数据的方式.

尽管它具有适应性, MongoDB与Elasticsearch一样缺乏文档内字段比较.

此外，还有一些操作，包括 $group，要求将结果传递给主节点.

因此，它们没有利用分布式计算.

那些不熟悉分段管道计算的人会发现某些任务不直观. 例如，对数组字段中的元素数量求和需要两个步骤:首先，计算数组字段中的元素个数 $unwind, and then the $group operation.

Redshift的聚合能力

亚马逊Redshift的好处不容低估.

在分析移动流量时，MongoDB上令人沮丧的缓慢聚合很快就被亚马逊红移解决了.

Supporting SQL, 传统数据库工程师可以轻松地将他们的查询迁移到Redshift.

不考虑入职时间, SQL是经过验证的, scalable, 强大的查询语言, 轻松支持文档内/行字段比较. 亚马逊红移通过编译和缓存在计算节点上执行的流行查询进一步提高了性能.

作为关系数据库, 亚马逊红移没有MongoDB和Elasticsearch拥有的模式灵活性. 它针对读操作进行了优化，但在更新和删除时性能会受到影响.

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

为那些有pb大小问题的人量身定制, 它并不便宜，而且可能不值得投资，除非存在与其他数据库的扩展问题.

选择赢家

在本文中, 我们研究了三种不同的技术——Elasticsearch, MongoDB, 和亚马逊Redshift——在数据工程的背景下. However, 没有明显的赢家，因为这些技术在其存储类型类别中都是领先者.

对于数据工程，取决于用例，有些选项比其他选项更好.

• MongoDB 是一个很棒的入门数据库吗. 当数据模式尚待确定时，它提供了我们所需的灵活性. 也就是说，MongoDB的性能并不优于其他数据库所擅长的特定用例.
• While Elasticsearch 提供了与MongoDB类似的流体模式, 它以牺牲写性能和存储大小为代价，针对多个索引和文本查询进行了优化. Thus, 当我们发现自己在MongoDB中维护大量索引时，我们应该考虑迁移到Elasticsearch.
• Redshift 需要预定义的数据模式，并且缺乏MongoDB提供的适应性. 作为回报，对于只涉及单个(或几个)列的查询，它优于其他数据库. 当预算允许时, 当其他人无法处理数据量时，亚马逊红移是一个伟大的秘密武器.