リアルタイムなデータを処理する際、様々な製品を利用する必要があります。
私も、保存したデータのリアルタイムな分析と大規模な分析をどう切り分けるかや、サービスに落とし込む方法を悩むことがよくあります。
「リアルタイムな製品」と聞くと様々なサービスを考えられます。
アプリケーションレベルで利用するものや、ストリーム処理を行うものなどが分けられるかと思いますが、私の思いつく限りの製品での違いを記載してみました。
製品比較
私の思いつく限りの製品での違いを記載してみました。
| 製品/サービス | 用途 | リアルタイム分析 | 大規模分析 | サービス提供事業者/OSS |
|---|---|---|---|---|
| RabbitMQ | メッセージング | △ | △ | OSS |
| Redis | DB | ○ | △ | OSS |
| Apache Kafka | ストリーム | ○ | ○ | OSS |
| Amazon Kinesis | ストリーム | ○ | ○ | Amazon Web Services |
| Google Cloud Pub/Sub | ストリーム | ○ | ○ | Google Cloud |
| Apache Storm | ストリーム処理 | ○ | ○ | OSS |
| AnalyticDB for MySQL | DB | ○ | ○ | Alibaba Cloud |
- メッセージング: アプリケーション間でのメッセージの非同期通信に特化しており、システムの結合度を低く保ちながら信頼性の高いデータ転送を実現。
- ストリーム: データストリームの処理や分析の保管場所に特化している。リアルタイムデータの収集、処理が主な用途。
- ストリーム処理: リアルタイムまたはほぼリアルタイムでのデータストリーム処理に特化しており、複雑なイベント処理や時間窓に基づく分析を行う。
- DB: データの永続化、クエリ処理、トランザクション管理など、典型的なデータベース機能を提供。
この中で、リアルタイムなデータ処理だけではなく、大規模なデータ分析でも利用が可能なAnalyticsDB for MySQLを、他の製品と比較してみました。
| 製品 | リアルタイム性の分析 |
|---|---|
| Amazon Redshift | △ |
| Google BigQuery | △ |
| Snowflake | △ |
| Microsoft Azure Synapse Analytics | △ |
| Apache Druid | ○ |
| AnalyticDB for MySQL | ○ |
AnalyticDB for MySQL を利用するメリット
データ分析を行う過程で、既に存在するデータをどのようにDWHやDataLakeとして専用の分析DBへ渡すかというETLは、重要な課題です。データが散在し、一貫性がなくデータの管理も煩雑になることが多々あります。
AnalyticDB for MySQLは公式にもある通り、MySQLと同様のエンジンということもあり、アプリケーション開発に利用していたデータをそのままビッグデータのテクノロジーと統合している点は大きな強みになりそうです。
AnalyticDB for MySQL は、高い同時実行性と低遅延でペタバイト級のデータ処理が可能なリアルタイムデータウェアハウスサービスです。MySQL プロトコルおよび SQL:2003との完全な互換性を持ち、大量のデータに対して即時の多次元分析およびビジネス探索を可能にします。
AnalyticDB for MySQLにはエディションと言う概念があり、Data Lakehouse Edition (V3.0)とData Warehouse Edition (V3.0)の2つのエディションで提供されています。これは、異なるビジネスニーズとデータ処理要件に対応するそうです。
Data Lakehouse Edition は、コンピューティングとストレージを分離する分離アーキテクチャを使用し、バッチ処理とリアルタイム分析の両方を効率的に統合しています。これにより、データ収集、ストレージ、コンピューティング、およびアプリケーションの機能が強化され、データ同期の一貫性と適時性の問題を回避しています。
Data Warehouse Edition は、リアルタイムでの大量データ書き込みと高性能リアルタイム分析を可能にするストレージとコンピューティングが分離されたアーキテクチャに基づいて構築されており、ビジネス要件に基づいてコンピューティングとストレージリソースを個別にスケールアップできます。これにより、複雑なETL操作、大量データに対する複雑なクエリの実行、履歴データとログの分析など、異なるシナリオに適したソリューションを提供しています。
Data Lakehouse と Data Warehouse の違い
よく耳にする データレイク・データウェアハウス があります。今回はそれに追加で、データレイクハウスという言葉が出てきています。これらの違いを調べてみました。
まず、データレイクとデータウェアハウスの違いは、「扱うデータの種類の違い」にあるようです。データウェアハウスは処理された構造化データのみを扱い、データレイクは非構造化データ、構造化データなどさまざまなデータを扱うことができます。
データレイクハウスは、これらの優れた要素を組み合わせ、多様なデータを柔軟に分析できる点が特長です。
https://www.databricks.com/jp/glossary/data-lakehouse
https://www.nttdata.com/jp/ja/trends/data-insight/2023/0620/
どのように試してみるか？
下記は公式のユースケースに存在する画像。この画像の全てを行うのは難しい為、RDSに入っているデータをAnalyticDB for MySQLにリアルタイムにインポートし、データを出力する検証を行いました。
【検証方法】
- AnalyticDB for MySQLを立ち上げる
- DTSを利用し、AnalyticDB for MySQLへデータを送信する
- RDSからAnalyticDB for MySQLのインポートを行う
- 別記事で「RDSの立ち上げとDMSを使ってみた」のデータを利用
- AnalyticDBからデータを読み出す
- RDSへ登録後に自動的にAnalyticDBに保存されていることを確認する
- リアルタイムに処理が出来ている確認
- RDSへ登録後に自動的にAnalyticDBに保存されていることを確認する
DTSとは？
Alibaba CloudのData Transmission Service (DTS)は、リアルタイムデータストリーミングサービスで、さまざまなデータソース間のデータ同期、移行、変更追跡、データ統合、データ処理をサポートしているようです。DTSは高い互換性、性能、セキュリティ、信頼性、使いやすさを提供し、データ管理を簡素化します。これにより、移行による作業は大幅に削減することが出来、アプリケーション開発に集中できます。
主なポイント
- 使いやすさ: DTSコンソールは、ウィザード形式のビジュアル管理インターフェースを提供し、DTSタスクの作成が簡単です。
- 多様な機能: DTSは異なるデータベースエンジンやアーキテクチャを持つ異種データベース間のデータ移行や同期を可能にし、複数のデータ複製モードを提供します。
- 高性能: 高スペックのサーバーを使用し、最適化されたインフラストラクチャで最高70 MB/sのデータ伝送速度を実現します。また、圧縮データの並行伝送により帯域幅の利用を最小限に抑えます。
- 高いセキュリティと信頼性: DTSはノードの災害復旧をサポートし、失敗したタスク接続を数秒以内に回復します。さらに、送信可能なデータ伝送やデータ検証をサポートし、データの整合性と一貫性を確保します。
https://www.alibabacloud.com/help/ja/dts/product-overview/what-is-data-transmission-service
上記のように、データ移行の全てが詰まっているサービスになるようです。
データ検証のサポート対象
送信元データベースと送信先データベース間のデータの整合性と一貫性を確保するためのデータ検証のサポート対象が下記のとおりとなります。下記のようにMySQLにフォーカスを当てただけでも多くデータ移行が可能になります。
-
MySQL→
- MySQL
- AnalyticDB for MySQL
- PolarDB for MySQL
- PostgreSQL
- AnalyticDB for PostgreSQL
- Oracle
-
[PostgreSQL, SQL Server, Oracle] →
- AnalyticDB for MySQL
- MySQL
- PolarDB for MySQL
https://www.alibabacloud.com/help/ja/dts/user-guide/enable-data-verification
同期可能な SQL 操作
データの同期は、SQL操作のサポートによって確認できます。
DMLについては、INSERT/UPDATE/DELETE 。DDLは、 CREATE TABLE/DROP TABLE/RENAME TABLE/TRUNCATE TABLE/ADD COLUMN/DROP COLUMN がサポートされており、基本的な操作は網羅されていると思います。
費用感
動作した分だけ、費用がかかりますが、設定自体は費用はかからないようです。
時間当たりの最小費用は下記のようです。
AnalyticDB for MySQLを立ち上げる
下記のURLから、日本リージョンのAnalyticDB for MySQLの画面に移ります。
日本リージョンにはないサービスもまだあるのですが、今回は日本リージョンもありました。
https://ads.console.aliyun.com/adb/ap-northeast-1/instances
Buy Clusterボタンから、作成画面に移ります。
それぞれの設定を行っていきます。
Region: Japan (Tokyo)
Zone: Tokyo Zone A
VPC: 自動で作成
VSwitch: 自動で作成
Mode: Elastic Mode
問題なければ、Buy Nowを押します。分析用DBにしては、料金は高くない印象です。
確認画面にて、問題なければ Activate Nowを押します。
作成が完了すると、Runningの状態になり、立ち上げは完了です。
アカウントも無いので作成しておきましょう。Create Privilleged Account で作成していきます。
出来れば細かなアカウント作成を行っていくほうが良いのですが、今回は時短で。
DTSを利用し、AnalyticDB for MySQLへデータを送信する
RDSからAnalyticDBへデータを移動するにはどうするべきか？
これには、AlibabaCloudの DTS（Data Transfer Service）を利用しました。RDSとADMのアカウント情報を設定し、同期させるように設定。この設定を行うだけでおそらく同期出来るのではないか？と考えました。
DTS用RDSのDatabase Connection作成
まずはDatabase Connectionを作成します。rdsとadbの両方のアカウントの設定を行います。
ちなみに後ほど気づいたのですが、この設定は行わなくても同期設定時にID/PWの設定があるので行わなくても良いです。
同期設定 - Create Data Synchronization Task
次にRDSとADBを同期させます。Database Connectionの設定を行っている場合、選択のみで設定完了です。Task Connectivity and Proceed で次に進みます。
対象のテーブルや同期設定を行います。今回はworldテーブルを Selected Objectsに移動してます。他の設定は初期設定のまま行います。 Next: Advanced Settings で次へ
追加設定も今回はそのままで Next Step: Verification Configurations で次へ
確認画面にて、事前確認を行い、全てSuccessfulなのを確認し、 Next: Purchase Instance で次へ
実行用インスタンスの設定をします。
今回は小さいインスタンスで問題ないデータ量なので mincro を選択し、Buy and Startを押します。インスタンスの作成が始まります。
同期設定の確認
インスタンスの作成が完了すると、Incremental Data Collrection と Incremental Write の情報が閲覧できます。
どれだけのデータが増分したのか、リアルタイム性は維持出来ているのかが一目瞭然です。
Incremental Data Collrection
Incremental Write
動作チェック
ここまでで設定が完了しました。
RDSに対してデータを追加後、自動でAnalyticDBに低レイテンシで届いている事を確認します。
この設定だけで様々なETLのバッチ処理を考えることも不要になり、リアルタイムにデータが同期され、安全に高速な解析が可能になります。
まずは、設定後に対象としたテーブルを確認します。
RDSに対してName: test, District: Hokkaidoのデータを追加し、AnalyticDBにも同様のデータが同期されて追加されていることを確認します。下記のように、同期されて追加されていました。
まとめ
DTSを利用することで、とても簡単にRDSとAnalyticDBが繋がり、リアルタイムに同期されたデータウェアハウスとアプリケーションが構築が出来ました！
アプリケーションを運用していく上でデータ分析による意思決定が欠かせませんが、分析基盤を用意するのがこれほど簡単に出来るようになると、今後はアプリ基盤とセットでデータ分析基盤の構築も初回からセットで考えていく事がありそうだと思います。