File Format Benchmark - Avro, JSON, ORC & Parquet
This document summarizes a benchmark study of file formats for Hadoop, including Avro, JSON, ORC, and Parquet. It found that ORC with zlib compression generally performed best for full table scans. However, Avro with Snappy compression worked better for datasets with many shared strings. The document recommends experimenting with the benchmarks, as performance can vary based on data characteristic
Impalaチューニングポイントベストプラクティス
http://www.cloudera.co.jp/jpevents/cwt2014/ http://connpass.com/event/9031/
TEXTFILE/SEQUENCEFILE/RCFILEのサイズ比較
基本的には以下のエントリーを自分なりに再試・咀嚼したものです。 HDFS and Hive storage - comparing file formats and compression methods - Adaltas Hiveテーブルを作成する際、SequenceFileはTextFileに比べてMapReduce時の処理効率は概ね良くなる傾向にありますが、様々なヘッダー情報が付与されるためファイルサイズ的には若干冗長になります。 僕もHiveを触り始めてまだ１ヶ月ちょっとなので色々調べている中、RCFileという、HDFS上でHiveテーブルのように構造化されたデータを扱うのに適したデータ構造がある、という事を知ったので、それぞれ以下３種のデータフォーマットについてデータサイズの比較を行いました。 TEXTFILE SEQUENCEFILE RCFILE ◯前提条件 今回試験に使
Hiveのファイル圧縮とSTOREの種類とマージの関係
Hiveの設定項目に「hive.merge.size.per.task」という項目があります。 マージ処理が有効になっている（hive.merge.mapredfiles=true）上で、上述の項目で指定した所定のファイルサイズにHiveの計算結果ファイル（MapReduceの結果ファイル）のサイズが満たない場合、所定のサイズを超えるようにマージ処理が行われます。 用途としては、結果ファイルとしてあまりに細かいファイルが大量に作られHDFSのブロックが有効活用出来ない状況を回避するため、と認識しています。 （できるだけ１ファイルをHDFSのブロックサイズに一致するようなサイズにマージしたい。） もしくは解析時に大量のMapタスクを生成したくない、という目的もあると思います。 ただ、こちらのパラメータはケースによっては有効にならないようです。 ◯有効になるケース 計算結果ファイルを非圧縮にし
Best splittable compression for Hadoop input = bz2?
We've realized a bit too late that archiving our files in GZip format for Hadoop processing isn't such a great idea. GZip isn't splittable, and for reference, here are the problems which I won't repeat: Very basic question about Hadoop and compressed input files Hadoop gzip compressed files Hadoop gzip input file using only one mapper Why can't hadoop split up a large text file and then compress t
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
org.apache.hadoop.io.compress (Apache Hadoop Main 2.7.2 API)
