問題タブ [parquet]

avro データ ファイルを変換して作成した寄木細工のファイルがあります。ファイルには複雑なレコードが含まれています。また、これらのレコードの avro スキーマと同等の寄木細工のスキーマがあります (ファイルを変換したときに取得しました)。寄木細工のファイルに裏打ちされたハイブ テーブルを作成したいと考えています。

私のレコード スキーマには多くのフィールドがあるため、これらのフィールドに対応するハイブ列を手動で宣言するのは非常に難しく、エラーが発生しやすくなっています。そのため、AvroSerDe が avro スキーマを使用してテーブルの列を定義するのとほぼ同じように、レコードの寄木細工のスキーマを使用して、寄木細工のファイルに基づくテーブルの列を Hive で定義する必要があります。これは ParquetSerDe でサポートされていますか? どうやってやるの？

PS 最初に avro スキーマを使用して avro でバックアップされたテーブルを定義し、次に CTAS ステートメントを使用してそこから寄木細工のテーブルを作成できる回避策を認識しています。ただし、AvroSerDe は Hive が (!!) を実質的にサポートしていない Hive ユニオンを使用し、ParquetSerDe はそれらの処理方法を知らないため、スキーマにユニオンがある場合は機能しません。

私はspark-shellでspark sqlジョブを実行していました。ジョブは寄木細工のファイルからテーブルを作成します。

ドライバー ノードの Web UI には、タスクの多くのメトリックがあります。

期間 / スケジューラの遅延 / タスクのデシリアライズ時間 / GC 時間 / 結果のシリアライズ時間 / 結果の取得時間 / 書き込み時間

ディスクから寄木細工のブロックを読み取るのに実際にどれくらいの時間が費やされたかを知りたいです (逆シリアル化、タプルの再構築、シャッフル書き込みなどの時間は含まれません)。

どのように計算すればよいですか？は

読み取り時間=期間 - スケジューラの遅延 - タスクの逆シリアル化時間 - GC 時間 - 結果のシリアル化時間 - 結果の取得時間 - 書き込み時間 ?

ありがとう、

具体的には、論理型とタイムスタンプに関する寄木細工の仕様は、 https://github.com/Parquet/parquet-format/blob/master/LogicalTypes.md 「TIMESTAMP_MILLIS は、論理的な日付と時刻の組み合わせ型に使用されます。注釈を付ける必要があります。 Unix エポック (UTC 1970 年 1 月 1 日の 00:00:00.000) からのミリ秒数を格納する int64。

"

つまり、ここでは、型はミリ秒単位までしか正確ではなく、1970 年から始まると書かれています。

しかし、 https://github.com/apache/hive/blob/branch-0.14/ql/src/java/org/apache/hadoop/hive/ql/io/parquet/convert のhive-parquetコードを見ると /ETypeConverter.java#L142 https://github.com/apache/hive/blob/branch-0.14/ql/src/java/org/apache/hadoop/hive/ql/io/parquet/timestamp/NanoTime.java# L54 寄木細工のタイムスタンプのハイブのエンコーディングは、ナノ秒のポイントまで正確で、「Monday, January 1, 4713」(jodd.datetime.JDateTime で定義) から始まる別の仕様のようです。

Hive の parquet タイムスタンプ ストレージは、上記の仕様とはまったく異なりますか?

デートのサポートは？https://issues.apache.org/jira/browse/HIVE-8119 上記のドキュメントで指定されている「int32」とは異なるオンディスク バイナリ エンコーディングを使用する予定ですか?

ありがとう

バイナリ データ ファイル (csv 形式に変換可能) がある場合、そこから直接 parquet テーブルを読み込む方法はありますか? 多くのチュートリアルでは、csv ファイルをテキスト テーブルにロードしてから、テキスト テーブルから寄木細工のテーブルにロードする方法を示しています。効率の観点から、私がすでに持っているようなバイナリファイルから寄木細工のテーブルを直接ロードすることは可能ですか? 理想的には、create external table コマンドを使用します。または、最初にcsvファイルに変換する必要がありますか? ファイル形式の制限はありますか?

cloudera の寄木細工のドキュメントには、pig/hive/impala との統合の例が示されています。しかし、多くの場合、デバッグ目的で寄木細工のファイル自体を読みたいと思っています。

寄木細工のファイルを読み取るための簡単な Java リーダー API はありますか?

ありがとうヤン

コンパイル時に不明な形式のデータを含む Parquet ファイルを作成したいと考えています。後でスキーマをテキストとして取得していますが、一部の列に日付と時刻が含まれていることがわかっています。Spark と Java を使用してこれを行いたいと考えています。そこで、http://spark.apache.org/docs/1.2.1/sql-programming-guide.html#programmatically-specifying-the-schemaに従い、適切な型のスキーマを作成しました。SparkDataType.TimestampTypeとDataType.DateType日付のような列を使用しようとしました。しかし、どちらも機能していません。ファイルを保存しようとするとJavaSchemaRDD.saveAsParquetFile、エラーUnsupported datatype+ 日付に試したタイプが表示されます。これで試してみたemptyRDDので、データ変換に問題はありません。

調べた後: http://parquet.incubator.apache.org/documentation/latest/と https://github.com/Parquet/parquet-format/blob/master/LogicalTypes.mdを変換する必要があると思いますdata を integer/long 型に変換し、それらが Date を表しているという事実を通知します。もしそうなら、どうすればSparkでこれを行うことができますか? それとも、何か他のことをする必要がありますか？

テーブルの場合

次のようにハイブSQLを実行しています。

読み戻された値は、最後の項目ではなく、各行の最初の項目として「my_part_columns」を示しています。

現在、本番 Hadoop クラスターのほとんどのデータセットは、AVRO + SNAPPY 形式で保存されています。Parquet について多くの良いことを聞いたので、試してみたいと思います。

この Web ページに従って、ETL の 1 つを変更して、Avro ではなく Parquet ファイルをレデューサーの出力として生成するようにしました。Parquet + Avro スキーマを使用して、最終出力データとスナッピー コーデックを生成しました。すべて正常に動作します。したがって、最終出力の寄木細工のファイルは、元の Avro ファイルと同じスキーマを持つ必要があります。

ここで、これらの Parquet ファイル用の Hive テーブルを作成してみます。現在、私たちが使用している IBM BigInsight 3.0 には、Hive 12 と Parquet 1.3.2 が含まれています。Avro スキーマ ファイルに基づいて、次の Hive DDL を作成します。

テーブルは Hive 12 で正常に作成され、問題なく "desc table" を実行できます。しかし、「select * from table limit 2」のようにテーブルをクエリしようとすると、次のエラーが発生しました。

エラーは構造体列の最初のネストされた配列から発生していることに気付きました。私の質問は次のとおりです。

1. Parquet は構造体のネストされた配列をサポートしていますか?
2. これは Parquet 1.3.2 のみに関連していますか? Parquet 1.3.2 に関する解決策はありますか?
3. 上記の問題を修正するために新しいバージョンの Parquet を使用する必要がある場合、実行時に Parquet 1.3.2 を使用できる場合、問題は発生しますか?
4. 寄木細工のデータから、ネスト構造の「展開」など、あらゆる種類の Hive 機能を使用できますか?

私たちが探しているのは、parquet が現在 AVRO を使用しているのと同じように使用できるかどうかを知ることですが、AVRO に欠けている列型ストレージの利点を提供してくれます。

列の 1 つの値を変更する必要がある非常に大きな寄木細工のファイルがあります。これを行う1つの方法は、ソーステキストファイルでこれらの値を更新し、寄木細工のファイルを再作成することですが、これに対するより安価で全体的に簡単な解決策があるかどうか疑問に思っています.

ストリームから Avro メッセージを読み取り、parquet.hadoop.ParquetWriter を使用してそれらを Parquet ファイルに書き込んでいます。出力ファイルのサイズをしきい値の制限より大きくしようとしています。問題は、ParquetWriter がすべてをメモリに保持し、ライターが閉じられたときに最後にのみディスクに書き出すことです。Parquet のドキュメントに基づいて、データは最終的な形式でメモリ オブジェクトに書き込まれます。つまり、メモリ内のオブジェクトのサイズはディスク上の最終的なサイズと同じです。私の質問は、ライターを閉じるかどうかを決定するために、メモリに書き込まれたデータのサイズを取得する方法です。

ParquetWriter ファイル サイズの見積もりとして、ParquetWriter に書き込む avro メッセージのバイト サイズを使用してみましたが、寄木細工のデータの格納方法 (列形式) が異なるため、これは寄木細工ライターのサイズとは大きく異なります。私がやったことの擬似コードは次のとおりです。

getLength() から取得した値は、寄木細工のファイルの実際のファイル サイズとは大きく異なることがわかりました。スキーマがファイルの最後に追加されることはわかっていますが、それは非常に小さいです。参考までに、getLength() が 130MB を報告した場合、実際のファイル サイズはわずか 80MB です。