問題文：-
Table12 つのテーブルを比較する必要がTable2あり、両方とも同じものを格納しています。したがって、比較をTable2行う必要Table1がTable1あるメインテーブルと比較する必要があります。Table2したがって、比較した後、何らかの矛盾があるレポートを作成する必要があります。これら 2 つのテーブルには、約 TB のデータが大量に含まれています。HiveQLそのため、現在、比較を行ってデータを取り戻すように書いています。
だから私の質問は、この種の仕事をするために をPERFORMANCE書くのと、何百万ものレコードでこれらの 2 つのテーブルを結合するので、私が書いた の面でどちらが優れているかということです。私の知る限り、内部的に (舞台裏で) 最適化されたカスタム map-reducer を生成し、実行のために送信して結果を取得します。CUSTOM MAPPER and REDUCERHiveQLHiveQL
あなたの質問に対する答えは2つあります。
まず、Hive QL構文で表現できる処理がある場合、Hiveのパフォーマンスはカスタムmap-reduceの作成と同等であると私は主張します。ここでの唯一の落とし穴は、マップリデュースコードで使用しているがHiveでは使用していないデータに関する追加情報がある場合です。たとえば、データが並べ替えられている場合、マッパーでファイル分割を処理するときにこの情報を利用できますが、Hiveがこの並べ替え順序を認識していない限り、この情報を利用することはできません。アドバンテージ。多くの場合、（メタデータまたは構成プロパティを介して）そのような追加情報を指定する方法がありますが、Hiveで使用するためにこの情報を指定する方法さえない場合もあります。
次に、SQLのようなステートメントで簡単に表現できないほど、処理が複雑になる場合があります。これらのケースでは通常、処理中に断続的な状態を保存する必要があります。Hive UDAFは、この問題をある程度軽減します。ただし、もっとカスタムなものが必要な場合は、 HiveTransform機能を使用してカスタムマッパーやレデューサーを接続することを常にお勧めします。これにより、Hiveクエリのコンテキスト内でmap-reduceを利用できるようになり、HiveSQLのような機能をカスタムのmap-reduceスクリプトとすべて同じクエリで組み合わせることができます。
簡単に言うと、Hive QLクエリを使用して処理を簡単に表現できる場合、同じことを実現するためにmap-reduceコードを作成する理由はあまりありません。Hiveが作成された主な理由の1つは、map-reduceを作成する代わりに、私たちのような人々がSQLのようなクエリを作成できるようにすることでした。（パフォーマンス上の理由などで）典型的なHiveクエリの代わりにmap-reduceを作成することになった場合、Hiveはその主な目的でうまく機能していないと主張することができます。一方、Hiveが利用できないデータに関する情報がある場合は、その情報を利用するカスタムmap-reduce実装を作成する方がよい場合があります。ただし、前述のように、Hive変換機能を使用してマッパーとリデューサーをプラグインするだけでよい場合は、map-reduceプログラム全体を作成する必要はありません。