ETLの2つの処理「バッチ」と「リアルタイム（ストリーミング）」を理解する
データを抽出・変換・ロードするためのツールである「ETL」は、主に「バッチ処理」と「リアルタイム（ストリーミング）処理」の2つの処理があります。
以下では、それぞれの処理で実現できることと特性について解説いたします。
目次
ETLのバッチ処理について理解する
私たちが日常的に接している最も分かりやすいバッチ処理としては、「給与振り込み」「クレジットカードの引き落とし」などがあります。毎月決められた日になったら、「全従業員に対して給与を振り込む処理を行う」「カード契約者の口座から請求額を引き落とす処理を行う」など、ひとまとまりのデータを一括して処理をするのがバッチ処理です。
ETLのバッチ処理もこれと同じです。「決められたタイミングになったら、処理をまとめて実施」します。処理を行うタイミングは、「毎日深夜0時」「毎月25日」「年に1度」など自由に設定できます。
ETLの処理をバッチで行う理由は以下の通りです。
(1)定期的な処理で十分間に合う
「毎月発信しているメールマガジンの配信先リスト更新」という処理を例に挙げて説明します。
メールマガジンの配信頻度が「毎月1回」である場合は、「メールマガジン配信前までにリストが最新の状態」になっていれば十分です。例えば、毎月25日に顧客に対してメールマガジンを出している会社は、1月10日に「メールアドレス変更」の連絡があったとしても即座に処理する必要はありません。配信日の25日、または1日余裕をもって前日の24日までにリストを更新していれば十分です。
(2)処理遅延や同時更新を回避する
ユーザーが業務を行っている時間帯に、データベースやシステムに対して大量の書き込み処理を行うと、ユーザーがデータベースやシステムを使う際に「処理が遅延する」「同時更新の問題が発生してしまう」場合があります。
これを回避するために、ユーザーが業務を行っていない「深夜・早朝」にバッチ処理（夜間バッチ）を行うことで、処理遅延や同時更新の問題を回避できます。
(3)非連続なデータである
データソースが絶え間なく更新されているわけでなく、ある時点でのデータが問題なく抽出可能である場合は、バッチ処理が最適です。例えば「営業時間が午前9時から午後10時までで、一日の売り上げは午後10時には確定し以後変動しない」ような場合であれば、バッチ処理が最適と言えます。
ETLのリアルタイム (ストリーミング)処理について理解する
バッチ処理の対局にあるのが、リアルタイム処理（ストリーミング処理）です。常にデータが作成され続けており、かつ、連続したデータをリアルタイムで取得し続けることが重要となる場合に用いられます。
リアルタイム処理を利用すべき理由は以下の通りです。
(1)連続データである
例えば、「IoTモニターから気象情報（温度・湿度・風速など）を取得」する場合を考えてみましょう。この場合は、毎秒（またはもっと短い単位）でデータが生成されます。そして、各IoTモニターから生成される連続したデータを見ながら、何かしらの判断や決断がなされます。こうした連続データの処理には、リアルタイム処理が必要です。
(2)データが常に生成され膨大である
アクセスが非常に多いサイトの「アクセス情報を取得」する場合を考えてみましょう。
仮に、アクセス数が月に1億件を超えているポータルサイトの場合、毎日のアクセス数は330万件以上です。1つのアクセスに多数の情報（IPアドレス、訪問ページ、滞在時間、直帰率、離脱率など）が紐づいているため、これを日次にまとめて処理しようとすると、相当大きなリソースを割り当てなければなりませんし、件数によっては既定の時間で処理が終了できない可能性があります。
リアルタイムで処理を行うことは、常にETL側で処理が走っている「24時間常時稼働状態」であることを意味します。短時間で多くのリソースを割り当てて処理するのではなく、常に同じリソースを割り当てて常時処理させるので、リソース管理が容易になります。
- IoTモニターからの気象情報（温度・湿度・風速など）の取得
- Webサイトのアクセス情報の取得
- ソーシャルメディアの投稿情報の取得
- インターネット広告の運用情報の取得
- クラウド基盤 (仮想マシンなど) の利用状況の取得
あくまで例ですが、上記のようなケースは「常に情報が変動しており、バッチで処理するには多すぎるデータ量が生成され続ける」こともあり、リアルタイム処理が望ましいといえます。
バッチとリアルタイムの中間：マイクロバッチ処理
リアルタイムほどの頻繁な処理は必要ない、しかし日次バッチでは間に合わないという場合に利用されるのが、マイクロバッチ処理です。
マイクロバッチ処理とは、バッチ処理とリアルタイム処理の中間ともいうべき処理で、「バッチ処理の頻度を高めて、半リアルタイムを実現する」というものです。
例えば、1日に1回のバッチではなく、「15分～1時間間隔のバッチを繰り返す」という設定を行うもので、データを一定間隔で継続して処理、ロードすることが可能です。例えば、リアルタイムでサービスを稼働させている最中に行った施策を、ある程度まとめて確認したいという場合などに利用できます。
特性に合った処理を選んで実施することが大切
以上、バッチ処理、リアルタイム処理、そしてマイクロバッチ処理についてご説明させていただきました。
ETLの処理頻度を決定するうえで重要なのは、必要性に合った処理を選ぶことです。処理頻度を高めたとしても、それだけの高頻度処理が必要ない場合は、ETL利用コストを無駄に高めてしまう可能性があります。逆に、コストの節約を重視しすぎて、必要性を満たさないデータ頻度での処理となった場合、データを基にした業務判断に悪影響が及ぶ可能性があります。
担当者がそれぞれの処理の特性を見極めて、適切な処理を選んでいただければと思います。もし、どの処理を選べばよいか迷った場合は、Reckoner担当者にお気軽に相談ください。
ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。
