首页 > 编程技术 > 怎么选择一个合适的数据格式

[悬赏]怎么选择一个合适的数据格式 (已翻译100%)

查看 (385次)
英文原文:How to Choose a Data Format
标签: 编程技术
admin 发布于 2017-04-25 11:05:46 (共 7 段, 本文赏金: 27元)
参与翻译(4人): jollogn1992 glma urnotlyy 廿九_ 默认 | 原文

【已悬赏】 赏金: 2元

编者注:欢迎来到星期四!每个月的第三个星期四,我们都会发布一篇来自公司早期的经典文章,并在适当的时候进行更新。我们仍然觉得它很有帮助我们认为你也会的!这篇文章的原版可以在这里找到。我们还将于4月28日在DataEngConf上讨论数据格式;学习更多内容,并提供我们的幻灯片。


廿九_
翻译于 2018-01-25 10:50:49
 

参与本段翻译用户:
廿九_

显示原文内容

【已悬赏】 赏金: 2元

HDFS上有各种可用的数据格式,并且你的选择很大程度上影响你项目的表现和空间要求。这里提供的发现基于我的团队过去的经验,以及我们在文本、Apache Hadoop的SequenceFile、Apache Avro、Apache Parquet和ORC格式的文件上读写运行时间的对比测试。

关于这些数据格式的更多细节,包括特征以及他们结构的概况,可以在这里找到。

urnotlyy
翻译于 2017-11-17 19:44:09
 

参与本段翻译用户:
urnotlyy

显示原文内容

【已悬赏】 赏金: 1元

Where to start?

There are several considerations that need to be taken into account when trying to determine which data format you should use in your project; here, we discuss the most important ones you will encounter: system specifications, data characteristics, and use case scenarios.

当决定程序应该选择哪种数据格式时,需要考虑诸多因素;在此,我们主要讨论会遇到最重要的几点:系统规格,数据特点,以及使用场景。

jollogn1992
翻译于 2017-05-29 00:02:19
 

参与本段翻译用户:
jollogn1992

显示原文内容

【已悬赏】 赏金: 4元

系统规范

首先看看您选择使用的技术及其特性;这包括用于ETL(提取、转换和加载)过程的工具,以及用作查询和分析的工具。这些信息将帮助您确定您可以使用的格式。

并不是所有的工具都支持所有的数据格式,编写额外的数据解析器和转换器会给项目增加不必要的复杂性。例如,在撰写这篇文章的时候,Impala不支持ORC格式;因此,如果您计划在Impala中运行大多数查询,那么ORC将不是一个好的候选。相反,相反,您可以使用类似的RCFile格式或Parquet。

您还应该考虑系统的实际情况。你被存储或内存限制了吗?有些数据格式可以比其他数据格式压缩得多。例如,存储为Parquet和ORC的具有snappy压缩的数据集可以将其大小缩小到其未压缩文本格式对应数据的四分之一,Avro压缩可以达到类似的结果。但是,编写这些格式都会增加内存密集型,您可能需要调优系统中的内存设置,以分配更多的内存。有许多选项可以调整以适应您的系统,在完全承诺使用某种格式之前,在系统中运行一些测试通常是可取的。我们将讨论一些测试,您可以在本文后面的部分中运行这些测试。


廿九_
翻译于 2018-01-25 11:19:59
 

参与本段翻译用户:
廿九_

显示原文内容

【已悬赏】 赏金: 11元

数据的特征和大小

接下来要考虑的是要在系统中处理和存储的数据。让我们看一下影响数据格式性能的一些方面。

您的原始数据是如何构造的?

也许您有常规的文本格式或CSV文件,并且您正在考虑将它们作为这样的存储。虽然文本文件可以被人类读取,很容易排除故障,也很容易处理,但它们会影响系统的性能,因为每次都必须解析它们。文本文件也有隐式格式(每一列都是某个值),如果您不仔细地记录这一点,它可能会导致问题的发生。

如果您的数据是XML和JSON格式,那么在HDFS中可能会遇到一些文件可拆分性问题。可拆分性决定了独立处理文件各部分的能力,而这反过来又使Hadoop中的并行处理成为可能,因此,如果您的数据不可分离,我们将失去允许快速查询的并行性。更先进的数据格式(序列、Avro、Parquet、ORC)提供可拆分性,而不管压缩编解码器是什么


你的管道是什么样子的,涉及哪些步骤?

一些文件格式经过优化,可以在某些情况下工作。例如,序列文件的设计是为了方便地在Map Reduce(MR)作业之间共享数据,因此如果管道涉及MR作业,那么序列文件是一个很好的选择。同样,Parquet和ORC等柱状数据格式的设计是为了优化查询时间;如果需要优化管道的最后阶段,使用柱状文件格式的计时器将提高查询数据的速度。

存储了多少列,使用了多少列进行分析?

当您有很多列,但只需要分析其中的几个列Parquet和ORC这样的柱状数据格式提供了一个优势(在查询速度方面),因为Parquet和ORC包含执行查询的速度。但是,如果您在搜索过程中仍然需要所有列,则可以放弃优势,在这种情况下,您可以在系统内进行实验以找到最快的替代方案。列文件的另一个优点是压缩数据的方式,这既节省了空间,也节省了时间。

你的数据会随着时间的推移而变化吗?如果发生了,它会发生多久一次,以及它是如何变化的?

了解您的数据是否经常更改很重要,因为接下来我们必须考虑数据格式如何处理模式演化。模式演化是指文件的结构在以前以不同的结构存储后发生变化的术语,这种结构更改可以包括更改列的数据类型、添加列和删除列。文本文件不显式地存储架构,因此,当一个新人加入项目时,由他们来确定数据的列和列值。如果您的数据突然变化(添加列、删除列、更改数据类型)则需要了解如何将旧数据和新数据与格式协调起来。

某些文件格式比其他文件格式更能处理模式的演变。例如,目前Parquet只允许在列的末尾添加新列,但它不能处理列的删除,而Avro则允许添加、删除和重命名多个列。如果您知道您的数据一定会经常更改(也许开发人员每隔几个月就添加一次新的指标来帮助您跟踪应用程序的使用情况)那么Avro将是一个不错的选择。如果您的数据不经常更改或不会更改,则不需要模式演化。

在模式演化中要记住的还有一些事情是跟踪新模式的权衡。如果需要指定像Avro或Parquet这样的数据格式的模式(而不是从数据中提取),那么我们将需要更多的精力来存储和创建模式文件。


廿九_
翻译于 2018-01-25 11:08:14
 

参与本段翻译用户:
廿九_

显示原文内容

【已悬赏】 赏金: 4元

用例场景

每种数据格式都有自己的优点、弱点和权衡,所以使用哪种格式的决定应该基于您的特定用例和系统。

如果您的主要关注点是能够尽可能快地编写数据,并且不关心空间,那么您可以只以文本格式存储数据,但有一项理解是:大型数据集的查询时间将更长。

如果您的主要关注点是能够处理系统中不断变化的数据,那么您可以依赖Avro来保存模式。但是,请记住,当将文件写入系统时,Avro需要一个预先填充的模式,这可能需要在开始时进行一些额外的处理。

最后,如果您的主要用例是分析数据,并且希望优化查询的性能,那么您可能需要查看一种列式格式,如Parquet或ORC BEC因为它们提供最好的查询性能,特别是在只读取特定列的部分搜索中。

但是,如果要读取所有列,则速度优势可能会降低。

在上述用例中有一个模式:如果一个文件需要更长的时间写,那是因为它在读取过程中进行了优化以提高速度。


廿九_
翻译于 2018-01-25 11:13:52
 

参与本段翻译用户:
廿九_

显示原文内容

【已悬赏】 赏金: 3元

-测试

我们已经讨论过怎么通过几个影响因子来为你的系统选择正确的数据格式.为了l提供更多综合的解释,我们根据经验来比较不同的数据格式在读和写文件方面的表现。在hdfs当中,我们创建一些定量的测试,来比较下面5数据类型

-Text

-Sequence

-Avro

-Parquet

-ORC

我们使用下面的技术来 进行不同的探索性查询来测试计算的时间

-hive

-Impala

我们测试三个不同的数据集

-窄的数据集--它包含10,000,000行,10列,像Apache日志文件

-宽的数据集---它包含4,000,000行,1000列,一开始的几列人为定义的数据,其他的集合是通过随机数和真假值来设定的

-巨大的宽数据集---1Tb的数据集合包含302,924,000条数据

-点击这里,你能在自己的系统里尝试测试全部结果和对应适合的代码

glma
翻译于 2017-09-09 12:55:19
 

参与本段翻译用户:
glma

显示原文内容

GMT+8, 2018-10-16 07:17 , Processed in 0.042838 second(s), 11 queries .