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

本文概述

数据工程
竞争者
索引编制
分片
汇总
选择优胜者

数据工程随着大数据和数据科学的兴起, 许多工程角色正在受到挑战和扩展。新时代的角色之一是数据工程。
最初, 数据工程的目的是加载外部数据源和设计数据库(设计和开发用于收集, 操纵, 存储和分析数据的管道)。
从那以后, 它已经发展为支持大数据的数量和复杂性。因此, 数据工程现在囊括了从爬网, 数据清理, 分布式计算以及数据存储和检索到的广泛技能。
对于数据工程和数据工程师而言, 数据存储和检索以及如何使用和分析数据都是管道的关键组成部分。
最近, 出现了许多新的和不同的数据存储技术。但是, 哪一个最适合并且具有最适合数据工程的功能？
大多数工程师都熟悉SQL数据库, 例如PostgreSQL, MSSQL和MySQL, 它们是在具有面向行存储的关系数据表中构造的。
鉴于这些数据库无处不在, 我们今天不再讨论它们。取而代之的是, 我们探索三种类型的替代数据存储, 它们日益流行并且引入了处理数据的不同方法。
在数据工程的上下文中, 这些技术是搜索引擎, 文档存储和列式存储。

搜索引擎擅长文本查询。与SQL数据库(例如LIKE)中的文本匹配进行比较时, 搜索引擎可以提供更高的查询功能和更好的性能。
与传统数据库相比, 文档存储提供了更好的数据模式适应性。通过将数据存储为通常表示为JSON的单个文档对象, 它们不需要架构预定义。
列式存储专门用于单列查询和值聚合。在列存储中, SQL操作(例如SUM和AVG)的速度要快得多, 因为同一列的数据在硬盘驱动器上的存储距离更近。

在本文中, 我们探索了所有三种技术：Elasticsearch作为搜索引擎, MongoDB作为文档存储, 以及Amazon Redshift作为列式存储。
通过了解备用数据存储, 我们可以为每种情况选择最合适的数据存储。

文章图片
对于数据工程师来说, 数据存储最重要的方面是
他们如何索引, 分片和聚合数据。
鸣叫
为了比较这些技术, 我们将研究它们如何索引, 分片和汇总数据。
每种数据索引策略都可以改善某些查询, 而又会阻碍其他查询。
知道最常使用哪些查询会影响采用哪个数据存储。
分片(Sharding)是一种数据库将其数据分成多个部分的方法, 它决定了随着摄取更多数据而基础架构将如何发展。
选择与我们的增长计划和预算相匹配的方案至关重要, 这适用于任何规模的数据科学公司。
最后, 这些技术各自汇总数据的方式非常不同。
当我们处理千兆字节和TB级的数据时, 错误的汇总策略可能会限制我们可以生成的报告的类型和性能。
作为数据工程师, 我们在评估不同的数据存储时必须考虑所有三个方面。
竞争者搜索引擎：Elasticsearch
Elasticsearch的可扩展性和易于集成性很快在同行中获得欢迎。它基于Apache Lucene构建, 提供了功能强大的即用型文本搜索和索引功能。除了传统的搜索引擎任务, 文本搜索和精确值查询之外, Elasticsearch还提供分层的聚合功能。
文档商店：MongoDB
此时, 可以将MongoDB视为NoSQL数据库。它的易用性和灵活性很快赢得了人们的欢迎。 MongoDB支持丰富且适应性强的查询, 可用于挖掘复杂的文档。经常查询的字段可以通过建立索引来加快速度, 当聚合大量数据时, MongoDB提供了多级管道。
柱状商店：Amazon Redshift
随着NoSQL的普及, 列式数据库也引起了人们的关注, 尤其是在数据分析方面。通过将数据存储在列而不是通常的行中, 可以直接从磁盘执行聚合操作, 从而大大提高了性能。几年前, 亚马逊为名为Redshift的柱状商店推出了托管服务。
索引编制 Elasticsearch的索引编制能力
在许多方面, 搜索引擎是专门用于索引文本的数据存储。
尽管其他数据存储区基于字段的确切值创建索引, 但是搜索引擎仅允许使用(通常是文本)字段的一部分进行检索。
默认情况下, 此检索是通过分析器针对每个字段自动完成的。
分析器是一个模块, 通过评估字段值并将其分解为较小的值来创建多个索引键。
例如, 一个基本的分析器可能会检查” 跃过懒惰的狗的快速褐狐狸” 成单词, 例如” the” , ” quick” , ” brown” , ” fox” 等。
该方法使用户可以通过搜索结果中的片段来查找数据, 这些片段按与同一文档数据匹配的片段数进行排序。
功能更强大的分析器可以利用编辑距离, n-gram和停用词进行过滤, 以建立全面的检索索引。
MongoDB的索引功能
作为通用数据存储, MongoDB在索引数据方面具有很大的灵活性。
与Elasticsearch不同, 它默认情况下仅对_id字段建立索引, 并且我们需要为常见查询的字段手动创建索引。
与Elasticsearch相比, MongoDB的文本分析器功能不那么强大。但是它确实为索引方法提供了很大的灵活性, 从复合和地理空间(用于最佳查询)到TTL和稀疏(用于减少存储)。
Redshift的索引功能
与Elasticsearch, MongoDB甚至传统数据库(包括PostgreSQL)不同, Amazon Redshift不支持索引方法。
相反, 它通过在磁盘上保持一致的排序来减少查询时间。
作为用户, 我们可以配置一组有序的列值作为表排序键。通过将数据排序到磁盘上, 如果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操作。
相关：商业智能平台：使用MongoDB聚合管道的教程
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是一个很好的秘密武器。