Table of Contents
  • シンプルさ： バッチETLは、通常、実装し、実行するために、それが好ましいことになり、あなたが最新の洞察力を必要としないときに、よりシンプルです。
  • レガシーシステムのサポート： 多くのレガシーシステムは、ストリーミングETLとの互換性がなく、バッチ処理でしか動作しません。あなたがサポートするIT環境にレガシーテクノロジーがある場合は、バッチ処理は、少なくともETLパイプラインの一部として必要になります。

ETL（抽出、変換、ロード）は、現代のデータ統合パイプラインのバックボーンであり、1970年代から何らかの形で存在しています。小さなスタートアップ企業から大規模な多国籍企業まで、組織はETLパイプラインに依存しており、競合他社を打ち負かしたり、顧客により良いサービスを提供したりするのに役立つ、新鮮で正確なインサイトを享受しています。

従来、企業はETLのワークロードを実行するためにバッチ処理に頼ってきました。しかし最近では、ストリーミングやリアルタイムETLに切り替える企業が増えています。では、バッチETLからストリーミングへの進化の背景には何があるのでしょうか、また、独自のストリーミングETLパイプラインを構築するにはどうすればよいでしょうか？

  1. バッチETLとは?
  2. ストリーミングETLとは?
  3. リアルタイムETL：バッチETLからストリーミングパイプラインへの進化
  4. ストリーミングETLパイプラインが本当に必要ですか?
  5. まとめ

バッチETLとは?

バッチETLは、ETLを実行するための伝統的な方法です。ここでいう「バッチ」とは、一定期間内にデータを収集することを指します。

まず、データのバッチは、一定の間隔でソース（ファイル、データベース、ウェブサイト、SaaSアプリケーションなど）から抽出されます。次に、各バッチのデータを様々なビジネス・ルールに従って変換し、ターゲット・ロケーションに保存するための準備をします。最後に、データはターゲットのデータウェアハウスまたはデータレイクにロードされます。

ファーストフードのチェーンでは、例えば、各レストランが各場所で毎日の収益を計算するために、夜間の閉店時間に、バッチETLを実行するかもしれません。おそらくあなたが常に一日中すべてのポイントでレストランの収益を監視する必要はありませんので、ストリーミングETLは、このユースケースではあまり有用ではないでしょう。

バッチETLの利点は、次のとおりです。

ストリーミングETLとは?

ストリーミングETLは、リアルタイムETLやストリーム処理と呼ばれることもありますが、これは、データソースが利用可能になるとすぐに情報がインジェストされるETLの代替手段です。

ストリーミングETLプロセスのアーキテクチャは、情報が何らかのソースまたはいくつかのソースから抽出され、その後、ディスティネーション（シンクと呼ばれることもあります）にロードされる前に変換を行うバッチETLと同じではありません。むしろ、ストリーミングETLは、データソースとデータベース内の最終目的地との間の橋渡し役として機能するストリーム処理プラットフォームを利用しています。

ストリーミングETLは、現代のビジネス環境に適していると考える企業が増えています。ソーシャルメディアやモノのインターネット（IoT）センサーなどのソースに大きく依存している場合、ユーザーは常に新しいソーシャルメディアの投稿をしていたり、IoTデバイスでは常に新しいデータを送信しています。この場合、大量の情報を処理するには、バッチETLでは時間がかかりすぎて扱いにくいかもしれません。

不正検知は、ストリーミングETLがバッチ処理よりもはるかにスマートな選択肢である1例です。クレジットカードの所有者がトランザクションを行うたびに、クレジットカード会社は、不正の疑いがあるかどうかを分析し、トランザクションが疑わしい場合、数分以内に所有者に警告する必要があります（例えば、購買活動が、通常とは異なる州や外国、時間帯に行われた場合）。バッチETLは数時間から数日のタイムスケールで行われることもあるため、犯罪者を捕まえるのに時間がかかりすぎて、さらなる悪用を防ぐことができません。

ストリーミングETLの利点は、次のとおりです。

スピード：ストリーミングETLを使用すると、それが到着するとすぐに新鮮な新しいデータへのアクセスを楽しむことができます。リアルタイムETLは通常、この情報が100％正確であることを保証することよりも、新しい情報に反応できることが重要な場合には、より良い選択です。
クラウドベース：多くのストリーミングETLツールは、クラウド技術を活用しており、従来のオンプレミス型ETLよりも独自の利点があります。

最後に、「イベントドリブンETL」という用語は、本質的にストリーミングETLと同義です。イベントドリブンETLでは、ETLプロセスは何らかのイベント（新しいサーバーログの到着やセンサーの読み取りなど）に反応して開始され、新しいデータはできるだけ早くインジェストされます。

リアルタイムETL：バッチETLからストリーミングパイプラインへの進化

前述したように、ETLの起源は1970年代にあり、企業が複数のデータベースに情報を保存し始めたことに始まります。このようなデータをすべて一枚のガラスの中に表示するために、これらの企業は、効率的かつ繰り返しデータ統合を実行する方法を必要としていました。

ETLの歴史のほとんどの間、技術的な制限により、企業はリアルタイムの分析を行うことができませんでした。しかし現在では、技術的な制限により、バッチETLワークフローを最大限に活用することができなくなっています。例えば、一部の企業では、手元に非常に多くのデータがあるため、単にバッチETLで満足のいくほど高速に処理することができません。ビッグデータの継続的な上昇傾向を観察し、いくつかのアナリストも、バッチETLの 「死 」を発表し、彼らの新しいストリーム処理の支配者の到着を歓迎するようなところにまで至っています。

バッチからストリーミングETLへの進化を可能にしたトレンドは以下の通りです。

  • シングルサーバ・データベースは、廃れつつあります。その代わりに、企業内に散在する様々なタイプのデータプラットフォームが増殖しています。このような多面的なアーキテクチャは、バッチETLの相対的なシンプルさを複雑にしています。
  • 同様に、ウェブ、ソーシャルメディア、モバイル、ログ、IoTセンサーなど、多様なデータソースが存在しています。バッチ処理では、現代の企業が扱う大量かつ多様なビッグデータに追いつくことができません。
  • 企業は、リアルタイムのアナリティクスをすぐに利用できる魅力をますます実感しています。例えば、ハーバード・ビジネス・レビューの調査では、60%の企業が、異なるタッチポイントやデバイスにまたがるリアルタイムの顧客とのやりとりを提供することが「非常に重要」であることに同意していることがわかりました（これはストリーミングETLでしか不可能なことです）。

バッチETLの死の噂は大幅に誇張されていますが、リアルタイムのストリーム処理が急速に採用され、人気を集めているのは事実です。しかし、どちらか一方を一方的に選択しなければならないという理由はありません。次のセクションでは、リアルタイムETLが本当にあなたの企業のために必要かどうかを見てみましょう。

ストリーミングETLパイプラインが本当に必要ですか?

ストリーミングETLの様々な利点を考えると、あなたがリアルタイムETLへの移行を検討していることは驚くことではありません。しかし、ストリーミングETLはあなたにとって正しいのでしょうか、また比較的小さな利益のためにIT環境により複雑さを付加することになるのではないでしょうか？

まず、ストリーミングETLパイプラインを構築しようとしている場合、どのようなオプションがあるでしょうか？リアルタイムETLパイプラインのバックボーンとして使用できるリアルタイム・ストリーミング・プラットフォームには事欠きません。ストリーミングETLパイプラインを構築するためのKafka Streamsライブラリを含むApache Kafkaのようなオープンソースのツールは、優れた（そして費用対効果の高い）オプションです。しかし、それらにはそれぞれの欠点があります。

  • オープンソースのツールは、提供されているものの中で最も直感的で使いやすいものとは限らないので、それらを使った経験のある開発者を雇う必要があります。これは、「フリーでオープンソース」という言葉とは程遠い多額の費用がかかることを意味しています。
  • 健全なユーザーコミュニティがあるにもかかわらず、オープンソースツールのサポートとメンテナンスサポートを見つけるのは、サードパーティのETLプロバイダと一緒に仕事するよりも難しいでしょう。

リアルタイムETLへの移行があなたにとって正しいと決定する前に考慮すべき多くの問題があります。例えば、ストリーミングETLの利点としてスピードがよく挙げられていますが、欠点になることもあります。 Kaggleの調査によると、データサイエンスの課題として最も一般的なトップ5には、「ダーティデータ」（不完全、重複、不正確なデータ）や、必要なデータの可用性やアクセスに関する課題が含まれています。エンタープライズグレードのストリーミングETLソリューションは、このダーティデータを処理し、必要な人に迅速かつ効率的にインサイトを提供することができなければなりません。

NetflixのシニアデータエンジニアであるShriya Arora氏は、「ストリーミングデータセットを使用したNetflixのパーソナライズ」という彼女の講演の中で、リアルタイムETLを利用する予定のユーザーに対して、「すべてのものをストリーミングしたい」という衝動に駆られないように注意を促しました。ストリーミングETLを使用することの潜在的な欠点としては、以下のようなものがあります

  • 未知の領域： バッチETLは何十年も前からありますが、リアルタイムETLは比較的未知の領域です。つまり、特定のユースケースやアプリケーション（例：機械学習）にリアルタイムETLを使用するには、バッチETLよりも多くの努力と実験が必要になります。
  • 高い障害耐性：リアルタイムETLシステムは24時間365日データを収集しているため、取り返しのつかないデータ損失を避けるために、常に利用可能な状態にしておく必要があります。これには、常時監視とアラートを備えた高い耐障害性を持つインフラストラクチャが必要となります。また、ストリーミングETLではバッチETLよりもはるかに緊急性の高い何らかのシステム停止やパフォーマンスの問題が起こります。
  • 精度と品質：バッチETLを使用すると、すでに様々なソース間で調整された高品質で高精度なデータで作業していることを確認するための時間が増えます。一方、ストリーミングデータは、ほぼ瞬時に処理されなければなりません。これは、そうしたスピードにも関わらず、データの品質と精度についても保証する方法が必要があることを意味しています。
  • 復旧とリカバリ：バッチETLでのクラッシュからの復旧は比較的簡単です。ストリーミングETLでは、どこかにバックアップを取っていない限り、データが利用できなくなる可能性があります。

ストリーミングETLの欠点にもかかわらず、それを使用する説得力のある理由がまだあります。特にあなたが作業しているデータが実際にリアルタイムで到着している場合。バッチとストリーミングETLの2つのオプションの間で妥協点を探すかもしれません。同時にバッチとストリーミングETLの両方を使用することはできない理由はありません。お互いの強みを補完し、それぞれの弱点を補うことができます。

もう一つの解決策は、ストリーミングとバッチETLの間の中間をとること、つまり「マイクロバッチ」ETLを使用することです。マイクロバッチ処理では、データはマイクロバッチとして知られている少量のデータで、従来のバッチ処理よりも頻繁に（例えば、数分から数時間ごとに）収集されます。

マイクロバッチを使用することは、あなたが現在それらを取得しているよりも早く結果が必要な場合に効果的なソリューションとなります（ただし、ユースケースが必ずしもストリーミングETLへの移行をサポートしていない場合）。マイクロバッチETLのための1つの良い使用例は、そのウェブサイトへの大きな変更（例：ユーザーインターフェイスのアップグレード）の効果をテストしたい電子商取引のウェブサイトです。リアルタイムでデータを取得することは厳密には必要ではありませんが、新鮮なインサイトを得ることは依然として重要です。何かがうまくいっていない場合、それは非常に迅速にユーザーの行動に影響を与えるでしょう。

どのソリューションを選択しても、バッチETLにはその用途があり、重要であることは明らかです。そのため、Integrate.ioはバッチETLのためのクラウドベースのデータ統合プラットフォームを構築しました。Integrate.ioのプラットフォームは、シンプルなドラッグアンドドロップのインターフェースと100以上のコネクターがあらかじめ用意されており、誰でも簡単に堅牢なETLパイプラインを構築して必要なインサイトを得ることができるようになっています。

まとめ

バッチETLからストリーミングへの進化に関しては、ここで知っておくべきことがあります。

  • ストリーミングETLはリアルタイム（またはほぼ）でデータを処理しますが、バッチETLはスケジュールされた間隔でバッチでデータを処理することを指します。
  • バッチETLはより簡単で、レガシーシステムとの互換性がありますが、ストリーミングETLは最新の情報を提供し、不正行為の検出や支払い処理などの用途に必要です。
  • 様々な技術開発により、ストリーミングETLの人気が高まっていますが、バッチETLはまだ多くの状況で正しい選択肢です。
  • ほとんどの場合、リアルタイムETLへの極端な移行は必要ないでしょう：あなたは、バッチETL、またはバッチとストリーミングの組み合わせで必要なインサイトを手に入れ続けることができます。

成熟した、機能豊富で直感的なバッチETLソリューションをお探しですか？Integrate.ioを試してみてください。私たちのパワフルでユーザーフレンドリーなデータ統合プラットフォームは、データソースを統合し、Amazon Redshift、Google BigQuery、Microsoft Azure、Snowflakeなどを含むデータウェアハウスやデータレイクを選択して、堅牢なパイプラインを構築することを容易にします。お客様のビジネスニーズと目的についてのチャットや、Integrate.ioプラットフォームの無料トライアルに申し込むには、今すぐオンラインデモにお申し込みください。