标签: snappy

我正在对Hive可用的存储格式进行一些测试,并使用Parquet和ORC作为主要选项.我使用默认压缩包含ORC一次,使用Snappy包含一次.

我已经阅读了许多文件,说明Parquet在时间/空间复杂性方面比ORC更好,但我的测试与我经历的文件相反.

关注我的数据的一些细节.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

就我的桌子的压缩而言,实木复合地板是最糟糕的.

我对上表的测试得出以下结果.

行计数操作

Text Format Cumulative CPU - 123.33 sec

Parquet Format Cumulative CPU - 204.92 sec

ORC Format Cumulative CPU - 119.99 sec 

ORC with SNAPPY Cumulative CPU - 107.05 sec

列操作的总和

Text Format Cumulative CPU - 127.85 sec   

Parquet Format Cumulative CPU - 255.2 sec   

ORC Format Cumulative …

我找不到允许使用Python编写Parquet文件的库.如果我可以使用Snappy或类似的压缩机制,可以获得奖励积分.

到目前为止,我发现的唯一方法是使用Spark和pyspark.sql.DataFrameParquet支持.

我有一些脚本需要编写不是Spark作业的Parquet文件.是否有任何方法在Python中编写不涉及的Parquet文件pyspark.sql？

我有一个500 mb的大文件,可在一分钟内压缩,压缩比最佳.我发现这些算法适合我的使用.

1. LZ4
2. lz4_hc
3. 瞬间
4. quicklz
5. blosc

有人可以比较这些算法之间的速度和压缩比吗？

是否可以使用 Pandas 的DataFrame.to_parquet功能将写入拆分为多个具有近似所需大小的文件？

我有一个非常大的 DataFrame (100M x 100)，并且正在用来df.to_parquet('data.snappy', engine='pyarrow', compression='snappy')写入一个文件，但这会产生一个大约 4GB 的文件。相反，我希望将其分成许多约 100MB 的文件。

我需要在配置“众所周知的应用程序”时选择压缩算法。

此外，作为我日常工作的一部分，我的公司正在开发处理大量数据的分布式应用程序。我们一直在研究压缩数据以尝试减少网络带宽，但我们在使用什么算法方面遇到了困难。有太多的选择。

我如何在 LZ4 和 Snappy 之间做出选择？

我正在尝试在kubernetes中运行Kafka Streams应用程序.当我启动pod时,我得到以下异常:

Exception in thread "streams-pipe-e19c2d9a-d403-4944-8d26-0ef27ed5c057-StreamThread-1"
java.lang.UnsatisfiedLinkError: /tmp/snappy-1.1.4-5cec5405-2ce7-4046-a8bd-922ce96534a0-libsnappyjava.so: 
Error loading shared library ld-linux-x86-64.so.2: No such file or directory 
(needed by /tmp/snappy-1.1.4-5cec5405-2ce7-4046-a8bd-922ce96534a0-libsnappyjava.so)
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
        at java.lang.Runtime.load0(Runtime.java:809)
        at java.lang.System.load(System.java:1086)
        at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:179)
        at org.xerial.snappy.SnappyLoader.loadSnappyApi(SnappyLoader.java:154)
        at org.xerial.snappy.Snappy.<clinit>(Snappy.java:47)
        at org.xerial.snappy.SnappyInputStream.hasNextChunk(SnappyInputStream.java:435)
        at org.xerial.snappy.SnappyInputStream.read(SnappyInputStream.java:466)
        at java.io.DataInputStream.readByte(DataInputStream.java:265)
        at org.apache.kafka.common.utils.ByteUtils.readVarint(ByteUtils.java:168)
        at org.apache.kafka.common.record.DefaultRecord.readFrom(DefaultRecord.java:292)
        at org.apache.kafka.common.record.DefaultRecordBatch$1.readNext(DefaultRecordBatch.java:264)
        at org.apache.kafka.common.record.DefaultRecordBatch$RecordIterator.next(DefaultRecordBatch.java:563)
        at org.apache.kafka.common.record.DefaultRecordBatch$RecordIterator.next(DefaultRecordBatch.java:532)
        at org.apache.kafka.clients.consumer.internals.Fetcher$PartitionRecords.nextFetchedRecord(Fetcher.java:1060)
        at org.apache.kafka.clients.consumer.internals.Fetcher$PartitionRecords.fetchRecords(Fetcher.java:1095)
        at org.apache.kafka.clients.consumer.internals.Fetcher$PartitionRecords.access$1200(Fetcher.java:949)
        at org.apache.kafka.clients.consumer.internals.Fetcher.fetchRecords(Fetcher.java:570)
        at org.apache.kafka.clients.consumer.internals.Fetcher.fetchedRecords(Fetcher.java:531)
        at org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1146)
        at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1103)
        at org.apache.kafka.streams.processor.internals.StreamThread.pollRequests(StreamThread.java:851)
        at org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:808)
        at org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:774)
        at org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:744)

以前我尝试使用docker容器启动kafka和kafka-streams-app,它们工作得非常好.这是我第一次尝试使用Kubernetes.

这是我的DockerFile StreamsApp …

我们的hadoop集群使用snappy作为默认编解码器.Hadoop作业减少输出文件名就像part-r-00000.snappy.JSnappy无法解压缩文件bcz JSnappy要求文件以SNZ开头.减少输出文件以某种方式以某些字节0开始.

我怎么能解压缩文件？

根据这个Cloudera帖子,Snappy IS可拆分.

对于MapReduce,如果您需要可拆分的压缩数据,BZip2,LZO和Snappy格式是可拆分的,但GZip不是.可拆分性与HBase数据无关.

但是从hadoop权威指南来看,Snappy是不可拆分的.

网上也有一些令人信服的信息.有人说这是可拆分的,有些人说不是.

我正在尝试使用Spark SQL来编写parquet文件.

默认情况下,Spark SQL支持gzip,但它也支持其他压缩格式,如snappy和lzo.

这些压缩格式之间有什么区别,哪种格式最适合Hive加载.

社区！

请帮助我了解如何使用 Spark 获得更好的压缩率？

让我描述一下案例：

1. 我有数据集，让我们把它的产品在其上的实木复合地板文件使用的编解码器使用Sqoop ImportTool进口HDFS瞬间。作为导入的结果，我有 100 个文件，总大小为46 GB，文件大小不同（最小 11MB，最大 1.5GB，平均 ~ 500MB）。记录总数超过80 亿条，有84 列

2. 我也在使用snappy对 Spark 进行简单的读取/重新分区/写入，结果我得到：

~ 100 GB输出大小，具有相同的文件数、相同的编解码器、相同的数量和相同的列。

代码片段：

val productDF = spark.read.parquet("/ingest/product/20180202/22-43/")

productDF
.repartition(100)
.write.mode(org.apache.spark.sql.SaveMode.Overwrite)
.option("compression", "snappy")
.parquet("/processed/product/20180215/04-37/read_repartition_write/general")

3. 使用镶木地板工具，我查看了摄取和处理的随机文件，它们如下所示：

摄取：

creator:                        parquet-mr version 1.5.0-cdh5.11.1 (build ${buildNumber}) 
extra:                          parquet.avro.schema = {"type":"record","name":"AutoGeneratedSchema","doc":"Sqoop import of QueryResult","fields"

and almost all columns looks like
AVAILABLE: OPTIONAL INT64 R:0 D:1

row group 1:                    RC:3640100 TS:36454739 OFFSET:4 

AVAILABLE:                       INT64 SNAPPY …