コンテンツに移動
データ分析

Striim を使用した Oracle から Google BigQuery へのリアルタイム データ統合

2022年11月11日
https://storage.googleapis.com/gweb-cloudblog-publish/images/da_2022_Ax1JWDQ.max-2500x2500.jpg
Google Cloud Japan Team

※この投稿は米国時間 2022 年 11 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今回のゲストブログでは、Striim の創業者 / EVP プロダクト担当である Alok Pareek 氏をお迎えし、Striim を使用した Oracle から Google Cloud BigQuery へのリアルタイム データ統合を対象に実施したパフォーマンス調査における、最新のテスト結果を共有していただきます。


Oracle をはじめとするリレーショナル データベースは、データを格納するように設計されてはいますが、大規模な分析のサポートにはあまり適していません。Google Cloud BigQuery は、分析のユースケースに最適な、サーバーレスでスケーラブルなクラウド データ ウェアハウスです。タイムリーで正確な分析を行うには、最小限のレイテンシで継続的にデータ ストリームを BigQuery に移動できることが不可欠です。

データベースから BigQuery にデータをストリーミングする最良の方法は、ログベースの変更データ キャプチャ(CDC)を使用することです。ログベースの CDC は、トランザクション ログを直接読み取り、挿入、更新、削除などの DML 操作を収集することによって機能します。他の CDC メソッドとは異なり、ログベースの CDC は、データベースの変更をストリーミングするための非干渉型のアプローチを提供し、データベースへの負荷を最小限に抑えます。

統合リアルタイム データのインテグレーションとストリーミングのプラットフォームである Striim には、すぐに使えるログベースの CDC リーダーが付属しており、さまざまなデータベース(Oracle を含む)から BigQuery にリアルタイムでデータを移動できます。Striim を使用すれば、各チームはデータに基づいて迅速に行動し、新しいインサイトを生み出すほか、最適なカスタマー エクスペリエンスをサポートし、イノベーションを推進できます。

このブログ投稿では、Striim の最近のホワイトペーパー「Real-Time Data Integration from Oracle to Google BigQuery: A Performance Study」(Oracle から Google BigQuery へのリアルタイム データ統合: パフォーマンス調査)で引用されているテスト結果の概要を説明します。

Striim を使用して Oracle から Google BigQuery へのデータ パイプラインを構築する: コンポーネント

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Striim.max-2000x2000.jpg

次のコンポーネントを使用してデータ パイプラインを構築し、Oracle データベースと BigQuery の間でリアルタイムにデータを移動しました。

Oracle CDC アダプタ

Striim アダプタは、Striim プラットフォームを特定のタイプの外部アプリケーションまたはファイルに接続するプロセスです。アダプタを使用すると、リアルタイムのデータ統合向けのストリーミング データ パイプラインを使用して、さまざまなデータソースをターゲット システムに接続できます。

Striim には、さまざまなワークロードの管理に役立つ 2 つの Oracle CDC アダプタが付属しています。

  • LogMiner ベースの Oracle CDC Reader は、Oracle LogMiner を使用してサーバーサイドでデータベース変更を取り込み、ストリーミング プラットフォームに複製します。このアダプタは、小規模および中規模のワークロードに最適です。

  • OJet アダプタは、高性能ログ マイニング API を使用して、ソースにおける大量のデータベース変更をサポートし、それらをリアルタイムに複製します。このアダプタは、ボリュームが多い、高スループットの CDC ワークロードに最適です。

2 種類の Oracle アダプタから選択できますが、それぞれに適切な使用のタイミングがあります。

結果は、データベース ワークロード プロファイルが 1 時間あたり 20 GB から 80 GB の CDC データである場合、LogMiner ベースの Oracle CDC リーダーが適切な選択であることを示しています。より大量のデータを処理する場合は、OJet アダプタの方が優れています。現状利用可能な最速の Oracle CDC リーダーです。以下は、両方のアダプタのレイテンシ(読み取りラグ)を示す表とグラフです。
https://storage.googleapis.com/gweb-cloudblog-publish/images/2_Striim.max-1300x1300.jpg
https://storage.googleapis.com/gweb-cloudblog-publish/images/3_Striim.max-2000x2000.jpg

BigQuery ライター

Striim の BigQuery ライターは、時間とストレージ容量を節約するように設計されています。ターゲットの BigQuery システムでパーティション分割テーブルを利用し、マージクエリでパーティションのプルーニングをサポートします。

データベース ワークロード

このテストでは、特注の大規模なデータベース ワークロード シミュレーションを使用しました。使用したワークロードは SwingerMultiOps で、Oracle データベースの一般的なワークロードである Swingbench に基づいています。これは、ソース データベースに対して同時データベース セッションを生成するマルチスレッド JDBC(Java Database Connectivity)アプリケーションです。Swingbench ワークロードの Order Entry(OE)スキーマを採用しました。SwingerMultiOps では、合計 50 テーブルに達するまでテーブルを追加し続けました。この各テーブルは、さまざまなデータ型で構成されています。

データ パイプラインを構築する: 手順

次の手順に沿って、テスト用のデータ パイプラインを構築しました。

1. ソース データベースを構成し、ワークロードをプロファイリングする

Striim の Oracle アダプタは、Oracle サーバー インスタンスに接続して redo データをマイニングします。そのため、redo マイニングのパフォーマンスが最適になるようにソース データベース インスタンスを調整することが重要です。構成については、次の点に注意する必要があります。

  • データベース ワークロードをプロファイリングして、そのワークロードがソース データベースに生成する負荷を測定する

  • redo ログのサイズを、ログ グループごとに 2G という適度に大きな値にする

  • OJet アダプターの場合、データベースの stream_pool_size に大きなサイズを設定して、redo を可能な限り迅速にマイニングする

  • 約 150 Gb/時間の非常に速い CDC データ転送速度の場合、streams_pool_size を 4G に設定する

2. Oracle アダプタを構成する

どちらのアダプタについても、開始するにはデフォルト設定で十分です。必要な構成は、ソース データベースからデータを読み取るように、データベース エンドポイントを設定することだけです。必要に応じ、Striim を使用して以下を実行できます。

  • 大規模なトランザクションの処理

  • ダウンストリーム データベースに対するデータの読み取りと書き込み

  • 特定の SCN またはタイムスタンプからのマイニング

どちらの Oracle アダプタを選択しても、ソース データベースからすべてのデータ ストリームを収集するうえで必要となるアダプタは 1 つだけです。この方法は、両方のアダプタで発生するオーバーヘッドの削減に効果的です。

3. BigQuery ライターを構成する

BigQuery ライターを使用して、ソースからデータベースへのデータの移動方法を構成します。たとえば、大量のデータを並行して移動するために、指定されたデータセットを操作するようにライターを設定できます。

パフォーマンスを向上させるために、複数の BigQuery ライターを使用して、受信するデータを並行して統合できます。ルーターを使用すると、単一のイベントが複数のライターに送信されないようにイベントを分散できます。

ライターの数とそのプロパティを調整すると、データが Oracle から BigQuery にリアルタイムで移動するようになります。大量の受信ストリームを扱っているため、テストでは 20 の BigQuery ライターを構成しています。データの移動と制御に役立つ BigQuery ライターのプロパティは他にも多くあります。詳細については、こちらをご覧ください。

Striim アプリを実行して結果を分析する方法

Google BigQuery データセットを使用して、データ統合インフラストラクチャを実行しました。シミュレーションを実行し、分析のために結果を取得するために、次のタスクを実行しました。

  1. Striim サーバーで Striim アプリを起動します。

  2. 簡単なスクリプトを渡し、Tungsten コンソールを使用してアプリ コンポーネントのモニタリングを開始します。

  3. データベース ワークロードを開始します。

  4. Striim アプリですべてのデータベース イベントを取得し、アプリがすべての受信データを BigQuery ターゲットに commit できるようにします。

  5. アプリのパフォーマンスを分析します。

以下の Striim UI 画像は、Striim サーバーで実行されているアプリを示しています。この UI から、アプリのスループットとレイテンシをリアルタイムにモニタリングできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_Striim.max-1900x1900.jpg

結果の分析: 2 つの Oracle リーダーのパフォーマンスの比較

データベース ワークロードの実行の終わりに、取得したパフォーマンス データを確認し、パフォーマンスを分析しました。詳細は、ソース アダプタの種類ごとに以下の表にまとめられています。

以下のグラフは、データベース サーバーでワークロードが進行するにつれて、CDC リーダーのラグが入力レートによってどのように変化するかを示しています。

Oracle リーダーのラグを表すグラフ

https://storage.googleapis.com/gweb-cloudblog-publish/images/6_Striim.max-1200x1200.jpg

OJet リーダーのラグを表すグラフ

https://storage.googleapis.com/gweb-cloudblog-publish/images/7_Striim.max-1200x1200.jpg

Striim を使用して、リアルタイムにデータを Google Cloud BigQuery に移動する

このテストでは、Striim を使用して大量のデータを Oracle から BigQuery にリアルタイムで移動する方法を紹介しました。Striim は、Oracle データベースからのデータ ストリーミングをサポートする 2 つの高性能 Oracle CDC リーダーを提供しています。読み取りラグ、エンド ツー エンドのラグ、CPU とメモリの使用率を測定することで、Striim の OJet Oracle リーダーがより大きなワークロードに最適であることを実証しました。小規模なワークロードについては、Striim の LogMiner ベースの Oracle リーダーが優れたパフォーマンスを提供します。詳細については、ホワイトペーパーデモStriim の Marketplace リスティングをご覧ください。または、Striim までお問い合わせください。

- Google Cloud プロダクト マネジメント担当シニア ディレクター Sudhir Hasbe

- Striim、創業者 / EVP プロダクト担当 Alok Pareek 氏
投稿先