ハイパーパーティショニングとオーバーパーティショニングの対処方法

Question

Hadoopのデータセットには、過去10年以上の履歴データ（6.5B行とカウント）があります。私たちは年と月にそれを分割しました。

多くの理由でパフォーマンスが低下します。ほとんどすべてのクエリはcustomer_idによってさらに修飾されますが、私たちは500人の顧客を持ち、急速に成長しています。クエリを特定の月に絞り込むと、1人の顧客のレコードを見つけるためにすべてのレコードをスキャンする必要があります。データはここではParquetとして保存されるため、主なパフォーマンスの問題はレコードのすべての内容をスキャンすることに関連しません。

私たちは120年分のパーティションを持ち、それぞれ500人の顧客がHiveメタストアが効果的に処理できる60Kのパーティションを作成するので、顧客にパーティションを追加することを躊躇しました。また、顧客の中には巨大で小さなものもあるので、のみをパーティションに入れることをためらっています。そのため、自然なデータスキューがあります。

理想的には、1つのルール（年+ customer_id）と現在のデータ（年/月+ customer_idなど）を使用して、それほど頻繁に使用されない履歴データをパーティション化することができます。複数のデータセットを使用することを検討しましたが、時間の経過とともにこれを管理することは、より多くの作業や変更などのようです。

パフォーマンスのためにたくさんのパーティションを必要としているが、メタストアによって制限されているこのようなケースを処理する方法を提供する戦略や機能はありますか？

私はバケッティングの利点についても混乱しています。たとえば、顧客IDに基づく適切なバケット処理は、パーティション化と同様に役立ちます。しかし、ホートンワークス "strongly recommends against"バケツ（理由は何もない）。他のいくつかのページでは、バケッティングはサンプリングに便利ですHortonworksのもう一つの良いdiscussion of bucketingは、Hiveがパーティションと同じ方法でバケツをプルーニングできないことを示しています。

最近のバージョンのHive/Hadoop（CDH 5.7からAWS EMRへ移行中）です。

Answer 1

実際の60Kパーティションでは、ハイブにとって大きな問題はありません。私は1つのHaveテーブルの約2MMのパーティションでの経験があり、かなり速く動作します。あなたがリンクhttps://andr83.io/1123で見つけることができるいくつかの詳細もちろん、慎重にクエリを書く必要があります。また、インデックスとブルームフィルタのサポートでORCフォーマットを使用することをお勧めします。