Presto と Hive の最大の違いは以下の５つが挙げられます：
- Hive だと EC企業はカスタムコードが使えるが、Preso だとできない。
- Presto は ANSI SQL に準拠するように設計されているが、Hive は HiveQL を使う。
- Presto が Eコマースで扱えるデータ量は限られているため、大規模なレポートを作成する場合は Hive を使う方がいい。
- Hive は失敗を許容できることが多いが、Presto はそうではない。
- Hive は map-reduce のアーキテクチャを使ってデータをディスクに書き込むが、Presto は map-reduce なしの HDFS アーキテクチャを使う。
Presto は、エンジニアが同社の巨大な （300PB）データウェアハウスに対してインタラクティブな分析クエリを実行できるようになる、Facebook のプロジェクトとして始まりました。(Facebook は Presto を Apache Software の下でオープンソースツールとしてリリースしました)。Facebook は Presto ができる前は、同様に Hive を使っていましたが、Hive を放棄して Presto を採用した後、Hive もオープンソースの Apache ツールデータ ウェアハウスツールになりました。今日、ビッグ データを扱う企業は、Presto または Hive を好む傾向があり、Integrate.io による Presto と Hive のこのレビューでは、両方のツールに類似点や相違点があるものの、どちらにも Eコマースのコンテクストでビッグデータの管理や変換をするのに必要な総合的な機能が備わっていないことが示されています。
Integrate.io は、EC 専用に構築された新しいデータウェアハウス統合プラットフォームであり、それを使って CRM（顧客関係管理）システム、トランザクションデータベース、リレーショナルデータベース、その他の ECデータプラットフォームなどのソースから Presto や Hive にデータを移動することができます。また、プログラミングやデータエンジニアリングのスキルがなくても、Integrate.io のすぐに使えるネイティブデータコネクタとドラッグ＆ドロップのクリック＆ポイントインターフェースを介して、これを行うことができ、ELT、リバースETL、CDC（変更データキャプチャ）も効率化できます。詳しくは、Integrate.io のデモでお問い合わせください。
さらに読む（英語）：Why is Ecommerce Integration Important for Stores?（店舗にとって EC の統合が重要な理由）
Presto と Hive：ANSI SQL と HiveQL
Presto と Hive を比較する場合、企業はクエリ言語の考慮が必要です。多くのデータエンジニアが Presto を試してまず気づくことの一つに、既存の SQL の知識が使えるという点があります。Presto は、クエリの実行やデータの取得、データベース内のデータの変更に標準 SQL が使われていることから、SQL を知っていれば、すぐに Presto を使い始めることができ、多くの人がこれを利点と見ています。
Apache Hive は SQL に似た言語を使いますが、初心者がクエリをいくつか学び直す必要が出てくるほどの違いがあります。HiveQL は Hive Query Language の略で、新しいユーザーが惑わされるかもしれない奇妙な点もありますが、SQL に馴染みのある人であれば、HiveQL を比較的すぐに使いこなすことができるはずです。
Apache には HiveQL のための包括的な言語マニュアルがあるので、コマンドを忘れたときにいつでも調べることができますが、それでも、情報を調べることで気が散って効率が落ちてしまいます。
カスタムコード
EC 企業は、Presto と Hive を比べる際にはカスタムコードにも考慮が必要です。Presto は 標準SQL で実行されるため、必要なコマンドはすでにすべて揃っています。また、データの取得や変更をサッと実行できるため、それを利点と考えるエンジニアもいます。
ただし、カスタムコードを挿入することができないため、高度なビッグデータユーザーにとっては問題が生じる可能性があり、その場合だと、Hive の方が Presto よりも使いやすいです。Hive の言語をよく知っていれば、クエリにカスタムコードを挿入することができるので、頻繁に行う必要はないかもしれませんが、必要なときには便利です。
HiveQL でカスタムコードを記述する時間を取る前に、Hive の Plugins ページで類似のコードを検索してください。プロジェクトに必要なコードがすでに書かれているかもしれません。必要な特定のコードが見つからない場合は、独自のコマンドを実行するためにわずかな変更のみが必要なプラグインが見つかる場合があります。
データの制限
頻繁に EC のレポートを作成する場合、Presto がうまく機能すると思わない人はほとんどいないでしょう。ただ残念ながら、Presto のタスクには保存できるデータ量の上限があり、その壁にぶつかると Presto のロジックは崩壊してしまいます。１時間ごとや１日ごとにレポートを作成するのであれば、Presto に任せておけばほぼ間違いないでしょう。 ちなみに Facebook では Presto が使われており、同社では膨大な量のデータが生成されますが、制限に達してしまう可能性があります。
対する Hive には、少なくとも現実のシナリオに影響するようなデータ制限はないようです。なので、週次や月次のレポートを作成する企業にとっては、Hive はより優れたデータクエリオプションとなります。関係するデータが多くなるほど、プロジェクトにかかる時間は長くなりますが、Hive は失敗することなく、コマンドの最後まで動作し続けます。Presto と Hive を比較するときは、これらをすべて念頭に置いておきましょう。
HDFS とディスクへのデータ書き込み
Presto と Hive の違いには、アーキテクチャが重要な役割を果たしています。
Hive と MapReduce
Hive は MapReduce を使っており、分散サーバー上でタスクを管理しながらフィルタリングとソートを行います。ただし、Reduce ステージと Map ステージの間に、Hive はデータをディスクに書き込まなければならず、ディスクに書き込むことで、Hive は次のタスクに進む前に少しの間の待機を余儀なくされます。
また、MapReduce は複数のサーバーでタスクを処理できるので、Hive でうまく機能します。タスクを分散させることでスピードが上がりますが、それでもデータはディスクに書き込まれないといけません。
幸い、MapReduce は Hive に卓越した柔軟性をもたらし、膨大なデータ形式を扱うことができます。Hive がデータ障害に遭遇した場合でも、MapReduce で作業を継続することができ、MapReduce が失敗を認識して、可能な限り次に進んでくれます。
Presto と HDFS
Presto には、ある場面では有効で、ある場面では厄介になる、さまざまなアーキテクチャがあります。Presto は、タスク間でディスクにデータを書き込む必要のない非リレーショナル ソースである HDFS（Hadoop 分散型ファイルシステム）に対応しており、その代わり、HDFS アーキテクチャが分散システム全体にデータを保存します。これはデータが１か所にロックされないため、Presto はディスクへのデータの書き込みのために止まることなくタスクを実行できます。
明らかに、HDFS には利点がいくつかありますが、驚くことではないにしても、このアーキテクチャで課題に出くわすこともあります。HDFS は MapReduce ほど障害に強くなく、何かしらの不具合があると、Presto は対応に困ってシャットダウンしてしまう傾向にあります。頻繁に起こるわけではありませんが、障害によって何時間もの作業が失われる可能性があります。手順をたどって問題を解決し、中断したところから再開できることに気づくかもしれませんが、そのような解決策があったとしても、ユーザーは障害の原因を突き止めて、問題を診断するのに貴重な時間を持っていかれてしまうことになります。これは、Presto と Hive のどちらにするかを決める際に考慮すべき点です。
Presto と Hive のどちらかを選んだ後、このツールのいどちらかにデータを移動するのは大変ですが、Integrate.io には、複雑なコードやデータエンジニアリングを必要としない EC データウェアハウスソリューションがあります。詳しくは、こちらのデモでぜひお問い合わせください。
さらに読む（英語）： What Are the Benefits of Using Big Data in B2B E-Commerce? （B2B のE コマースにおけるビッグデータ活用のメリットとは）
Presto と Hive のどちらを選ぶかを決める際に Integrate.io ができること
ビッグデータを扱うプロフェッショナルの多くにとって、Presto よりも Hive がいいようです。そして Eコマースのビッグデータを専門的に扱う場合、プロジェクトをより効率的にするカスタム コードを書きたいと思うことがあります。
Hive を好む人がいるからといって、必ずしも Presto が否定されるべきということではありません。意図したとおりに使えばうまくいきますし、Presto はタスクの処理が早いです。ただし、Prestoに一度に多くのことをさせてはいけません。それで失敗する危険性がありますからね。
もし豊富な技術的バックグラウンドがなければ、Presto と Hive の比較は無意味な議論に思えるかもしれないません。カスタム コードを書くのに十分な SQL の知識がないのに、それがなぜ問題になるのでしょうか。多くの人にとっては重要なことでも、そうでない人にはそれが重要かわからないでしょう。
Integrate.io は、EC 向けに設計された新しいデータウェアハウス統合ツールで、しっかりした技術的背景がある人とない人の橋渡しをします。また、この ETL ソリューションは、ノーコード、ローコードプラットフォームを採用しており、それで Presto と Hive の両方が使いやすくなっています。コーディングの経験がない人でも、Integrate.io を使って最小限のトレーニングでデータの抽出、変換、格納を行うことができ、コーディングの知識がある専門家は、Java やその他の言語を使ってプロジェクト用のカスタムコマンドを書くことができます。言い換えれば、Integrate.io は、組織に両方の一番いいところを提供します。
Integrate.io はまた、以下のような ELT、リバースETL、CDC（変更データキャプチャ）機能により、データ統合を効率化します：
- ELT：ソースから大量のデータを抽出し、それを Amazon（AWS）の Redshiftなどのウェアハウスに格納して、データエンジニアやデータサイエンティストがいなくても、そのデータをリアルタイムのデータ分析のために正しい形式に変換する。
- リバース ETL：データをウェアハウスから、チームメンバーが好んで使用する運用システムに移動する。
- CDC： ２つ以上のデータベースを同期し、それらのデータベースに加えられた変更を追跡する。
データ統合に関連する専門用語をすべて取り除くことで、Integrate.io はデータ障害問題の解決にも使えます。複数のデータベースから複数のデータ形式を同時に抽出して、ワークロードを改善することができ、障害は、データパイプラインで論理エラーが発生した場合にのみ起こります。また、Integrate.io のプラットフォームは、このような問題が発生した際にユーザーに警告を発するため、速やかに問題が解決されます。
その他の Integrate.io の利点として、世界規模の顧客サービス、柔軟な価格モデル、ポイント＆リック機能、Salesforce からデータウェアハウスにデータを移動して再びデータウェアハウスにデータを戻す、すぐに使える Salesforce 間コネクタなどがあり、ワークフローの最適化をお手伝いします。Integrate.io でデータを統合すれば、集計データ、クエリの実行、スキーマ、ベンチマーク、データ処理、ペタバイト、メタデータ、大規模データセット、データストア、構文、テラデータ、レイテンシー、ランタイム、データ型の扱いなど、複雑なデータ管理タスクについての心配はなくなります。
Presto と Hive のどちらを選ぶか決めかねている方は、Integrate.io だと、すぐに使えるコネクタとシンプルなドラッグ＆ドロップのインターフェースで、両プラットフォームへのデータ移行ができるようになります。また、Eコマースの業務のニーズに応じて、データ管理と統合のワークフローを作成できます。詳しくは、こちらのデモでぜひお問い合わせ下さい。
