Apache Flink + TiDB: 分析のためのリアルタイムデータウェアハウスを数秒でスケールアウト

※このブログは2020年11月11日に公開された英語ブログ「Apache Flink + TiDB: A Scale-Out Real-Time Data Warehouse for Analytics Within Seconds」の拙訳です。

著者: Zhi Qi (PingCAPのリアルタイム分析研究開発エンジニア)

トランスクリエイター: Caitin Chen; エディター: Tom Dewan

データ駆動型の企業が一定の規模に成長すると、従来型のデータストレージではそのニーズに応えられなくなります。リアルタイムのビジネスインテリジェンスを得るには、リアルタイムのデータウェアハウスが必要です。企業はリアルタイムのデータウェアハウスを使用することで、リアルタイムのオンライン分析処理（OLAP）、リアルタイムのデータパネル、リアルタイムのアプリケーション監視、リアルタイムのデータインターフェースサービスを導入できます。

リアルタイムのデータウェアハウスアーキテクチャは複雑で、運用も保守も難しいと考える人もいます。ここでは、なぜそれが正しくないかを説明します。Apache Flinkは、ステートフルコンピュテーションのためのフレームワークとなる、無制限および有界のデータストリームに対する分散型処理エンジンです。TiDBは、オープンソースの分散型ハイブリッドトランザクション/分析処理（HTAP）データベースです。Flink 1.11でのSQL言語のサポート強化と、TiDBのHTAP機能に基づき、FlinkとTiDBを組み合わせて、水平的なスケーラビリティと高可用性を特徴とする、効率的で使いやすい、リアルタイムデータウェアハウスが構築されました。

この記事ではリアルタイムデータウェアハウスとは何かを説明し、またFlink + TiDBリアルタイムデータウェアハウスのアーキテクチャとその利点、このソリューションの導入例によるケーススタディ、Docker Composeを使用したテスト環境を示します。

リアルタイムデータウェアハウスとは

オフラインデータウェアハウス

Bill Inmonは1990年代に、経営層の意思決定を支援する、サブジェクト指向の統合された、時変型で不揮発性のデータコレクションとして、データウェアハウスを定義しました。データウェアハウスはメッセージキューを通じてデータを収集し、1日1回または週に1回データを計算してレポートを作成します。データウェアハウスはオフラインデータウェアハウスとも呼ばれました。

リアルタイムデータウェアハウス

テクノロジーの向上に伴い、リアルタイムの推奨やリアルタイムのモニタリング分析が求められるようになりました。それに応じて、意思決定のための時間が日単位から秒単位に徐々に短縮されています。そうしたニーズに対応するために、リアルタイムデータウェアハウスが生まれました。

リアルタイムデータウェアハウスには、メインとなる3つのデータ処理アーキテクチャとして、Lambdaアーキテクチャ、Kappaアーキテクチャ、リアルタイムOLAPバリアントアーキテクチャがあります。

Lambdaアーキテクチャはバッチレイヤとストリームレイヤを維持するため、他の2つに比べて多くの開発コストを要します。Kappaアーキテクチャと比べて、リアルタイムOLAPバリアントアーキテクチャでは、より多くの柔軟な計算が可能ですが、リアルタイムOLAPのコンピューティングリソースを多く必要とします。

Lambdaアーキテクチャ

Lambdaアーキテクチャはリアルタイムデータウェアハウスとオフラインデータウェアハウスで構成されますが、ストリーム処理エンジンは高度なリアルタイム要件に基づいて直接データを計算します。Lambdaアーキテクチャはオフラインおよびオンラインのアプリケーションの結果を集約します。

Kappaアーキテクチャ

Kappaアーキテクチャでは、オフラインデータウェアハウスレイヤを廃して、リアルタイムデータウェアハウスのみを使用しています。コンピューティングエンジンの統合によって開発コストを削減します。

リアルタイムOLAPバリアントアーキテクチャ

リアルタイムOLAPバリアントアーキテクチャは、コンピューティング負荷の一部を、ストリーミング処理エンジンからリアルタイムOLAP分析エンジンに移行させます。それにより、柔軟性に優れたリアルタイムデータウェアハウスコンピューティングが実現します。

次に、リアルタイムOLAPバリアントアーキテクチャの例として、リアルタイムデータウェアハウスのためのFlink + TiDBソリューションを紹介します。

リアルタイムデータウェアハウスとしてのFlink + TiDB

Flinkは、低レイテンシ、高スループット、統合ストリーム処理、バッチ処理を特徴とする、ビッグデータコンピューティングエンジンです。高度なリアルタイムコンピューティングが求められる環境で広範に使用されており、正確に1回のセマンティクスを実現します。

TiDB 4.0は真正のHTAPデータベースです。リアルタイムデータウェアハウスアーキテクチャでは、TiDBをアプリケーションデータソースとして使用して、トランザクションクエリを実行できます。またリアルタイムOLAPエンジンとして、分析のためのコンピューティングにも利用できます。

FlinkとTiDBをリアルタイムデータウェアハウスに組み入れることで、次のような利点が得られます。

• 高速化：ストリーミングデータを数秒で処理できるため、リアルタイムのデータ分析が実現します。
• 水平的なスケーラビリティ：FlinkとTiDBの両方にノードを追加することで、演算能力が向上します。
• 高可用性：TiDBでは、特定のインスタンスでエラーが発生しても、クラスタサービスは影響を受けず、データが完全なまま保持されます。Flinkは、ジョブやインスタンスをバックアップおよび復元する複数の手段を提供します。
• 学習・設定に要するコストを削減：TiDBはMySQL 5.7プロトコルと互換性があります。Flink 1.11では、Flink SQL構文と強力なコネクタを使用してタスクを作成し、送信できます。

よく使用されているFlink + TiDBのプロトタイプをいくつか見てみましょう。

MySQLをデータソースとして使用

Ververicaのflink-connector-mysql-cdcを導入すれば、Flinkをコレクションレイヤとして使用してMySQL binlogを収集し、動的テーブルを生成するだけでなく、ストリームコンピューティングレイヤとして使用して、ストリーム結合や事前集約などのストリームコンピューティングを実行できます。Flinkでは最終的にJDBCコネクタを通じて、計算したデータをTiDBに書き込みます。

これはシンプルで使いやすいアーキテクチャです。MySQLとTiDBに対応するデータベースとテーブルを用意すれば、Flink SQLステートメントを記述して、タスクを登録し送信できます。このアーキテクチャは、Docker ComposeでFlink + TiDBを試すのセクションで試すことができます。

KafkaとFlinkの接続

他のチャンネルを通じてデータをKafkaに保存した場合、FlinkはFlink Kafka Connectorからデータを取得できます。

MySQL変更ログやその他のデータソースをKafkaに保存してFlinkで処理できるようにするには、CanalまたはDebeziumを使用して、データソースの変更ログを収集することを推奨します。Flink 1.11ではそれらのツールの変更ログを解析できます。さらにパーサーを実装する必要はありません。

TiDBをデータソースとして使用

TiCDCはTiDBの変更データキャプチャフレームワークです。これは、TiDBの増分変更を下流のプラットフォームに復元する、オープンソースの機能です。TiDB変更データをメッセージキューに出力し、それをFlinkが抽出します。

TiDB 4.0.8では、TiCDCオープンプロトコルを通じてTiDBをFlinkに接続できます。以降のバージョンでは、TiCDCはFlinkで使用できるcanal-json出力形式をサポートします。

ケーススタディ

Flink + TiDBアーキテクチャ基本を理解したところで、次に実際の導入例によるケーススタディを行ってみましょう。参考になる点があるはずです。

Xiaohongshu

Xiaohongshuは中国で人気があるソーシャルメディア/eコマースプラットフォームです。Xiaohongshuアプリでは、商品のレビュー、旅行に関するブログ、ライフスタイルに関するコメントなどを短い動画や写真で投稿し、共有できます。2019年7月には、登録ユーザーが3億人を超えました。以前の投稿では、Xiaohongshuのエンジニアが、TiDBを採用した理由と、TiDBのリアルタイムHTAP機能がデータ管理にどのように役立っているかを説明しました。

Xiaohongshuのアプリケーションアーキテクチャの中で、FlinkはTiDBからデータを取得し、TiDBにデータを集約します。次の図をご覧ください。

• 左上の部分では、オンラインアプリケーションテーブルがOLTPタスクを実行しています。
• TiCDCクラスタがTiDBのリアルタイム変更データを抽出し、変更ログをKafkaに送信します。
• FlinkがKafkaから変更ログを読み取り、ワイドテーブルや集約テーブルの結合などの計算を実行します。
• Flinkが結果をTiDBのワイドテーブルに書き込み、分析を実行します。

このプロセスは、TiDBに基づくクローズドループになっています。TiDBは後続の分析タスクの JOIN 演算をFlinkに転送し、ストリームコンピューティングによって負荷を軽減します。

現在このソリューションでは、Xiaohongshuのコンテンツレビュー、ノートラベル推奨、拡張監査アプリケーションをサポートしています。高スループットのオンラインアプリケーションの課題に応える安定した動作が確保されています。

Beike Finance

Beike Financeは、中国における大手の消費者向け不動産金融サービスプロバイダーです。同社はAIアルゴリズムを使用して多次元の大量のデータを効率的に適用し、ユーザーのプロダクトエクスペリエンスを強化し、個々のユーザーに応じて充実した金融サービスを提供しています。

Beikeのデータサービスでは、一般的なディメンションテーブルのJOIN演算にFlinkを利用しています。

1. Syncer（MySQLからTiDBにデータを複製するツール）がアプリケーションデータソースからディメンションテーブルを収集し、TiDBに複製します。
2. Canalがアプリケーションデータソースのフローテーブルデータのbinlogを収集し、Kafkaのメッセージキューに保存します。
3. FlinkがKafka内のフローテーブルの変更ログを読み取り、ストリームのJOINを実行します。ディメンションテーブルデータが必要な場合は、FlinkがTiDBを検索します。
4. Flinkが、結合されたワイドテーブルをデータ分析サービスのためにTiDBに書き込みます。

このプロセスでは、データサービス内のプライマリテーブルをリアルタイムで結合できます。そのためサービスチームは単一のテーブルのクエリを実行するだけですみます。Beikeデータチームはこのアーキテクチャを使用して、それぞれのコアアプリケーションが使用するシステムを開発します。データサービスはシステム間をまたぐデータを取得します。Beike Financeが、アプリケーションシステムAPIやメモリ集約データコードを開発する必要はありません。

PatSnap

PatSnapはグローバルな特許検索データベースとして、116か国から1億3,000万の特許データレコードと、1億7,000万の化学構造データレコードを集約しています。PatSnapのユーザーは、特許を検索、閲覧、翻訳し、特許分析レポートを作成できます。

PatSnapは、基盤となっていたSegment + RedshiftアーキテクチャをKinesis + Flink + TiDBに置き換えたところ、オペレーショナルデータストア（ODS）レイヤの構築が不要であることがわかりました。

Flinkは事前計算ユニットとして、アプリケーション用にFlink ETL（抽出-変換-読み込み）ジョブを構築します。このETLがデータ保存ルールを完全に管理し、スキーマをカスタマイズします。それにより、アプリケーションが対象とするメトリックだけを取り出してTiDBに書き込み、分析とクエリに使用することが可能になります。

PatSnapはTiDBを基盤に、データウェアハウス詳細（DWD）、データウェアハウスサービス（DWS）、分析データストア（ADS）の3つのレイヤを構築します。これらのレイヤがアプリケーションの統計情報を提供し、要件を列挙します。その基になるのが、ユーザー、テナント、地域、およびアプリケーションメトリック、さらに時間枠（分または日）です。上位アプリケーションは構築されたデータを直接利用して、リアルタイムの分析を数秒で実行することができます。

PatSnapはこの新しいアーキテクチャの導入後、次のような効果が得られました。

• インバウンドデータ、インバウンドルール、計算の複雑さが大幅に軽減されました。
• クエリ、更新、書き込みが大幅に高速化されました。
• 合理的なデータレイヤ化によってTiDBベースのリアルタイムデータウェアハウスが格段に簡素化され、開発、スケーリング、メンテナンスが容易になりました。
• このソリューションは随時発生するさまざまなクエリの要求に応えるものであり、Redshiftの事前コンパイルを待つ必要がなくなりました。

現在PatSnapはこのアーキテクチャを本稼働に移行させ、ユーザーの行動分析や、自社の事業とテナントの行動分析に関するデータ全体の追跡と要約に活用しています。

NetEase Games

NetEase, Inc.の系列にあるNetEase Gamesは、自社開発のPCクライアント/モバイルゲームの大手プロバイダーです。世界7大ゲーム会社の1つとして250を超えるゲームを運用しており、その中には1日100万人のアクティブユーザーを維持しているゲームもあります。NetEase Gamesは昨年の投稿の中で、他のMySQLベースのソリューションやNewSQLストレージソリューションではなく、TiDBを選択した理由を語っています。

NetEase Gamesのアプリケーション課金アーキテクチャは次のように運用されています。

• FlinkがデータソースのデータをTiDBにリアルタイムに書き込む。
• TiDBが分析用データソースとして機能し、Flinkクラスタがデータに対してリアルタイムのストリーム計算を行い、分析レポートを作成する。

NetEase GamesはさらにFlinkジョブ管理プラットフォームを開発し、ジョブのライフサイクルを管理しています。

Zhihu

古い中国語で「ご存知ですか」という意味を持つZhihuは、中国版Quoraであると言えます。ユーザーコミュニティがあらゆる質問の作成、回答、編集、整理を行うことができる、Q&Aウェブサイトとして運営されています。2億2,000万人を超える登録ユーザーを擁する中国最大のナレッジ共有プラットフォームとして、サイト上では3,000万件の質問に対し、1億3,000万件を超える回答がやり取りされています。

Zhihuは2019年の投稿で、1.3兆行を超えるデータ行を扱いながら、クエリに対する応答時間をミリ秒レベルに維持している方法を紹介していました。また2020年の投稿では、TiDBを使用してHive Metastoreを水平的にスケーリングし、拡大するビジネスニーズに対応する方法を説明していました。

PingCAPのパートナーであり、本格的なFlinkユーザーであるZhihuは、TiDB + FlinkインタラクティブツールのTiBigDataを開発し、オープンソースコミュニティに公開しました。このツールには次のような特徴があります。

• TiDBがFlinkのためのデータのバッチ複製のソースになっています。
• TiDBがFlinkシンクとして、JDBCをベースに実装されています。
• Flink TiDBカタログがFlink SQL内のTiDBテーブルを直接利用するため、あらためてテーブルを作成する必要がありません。

Docker ComposeでFlink + TiDBを試す

このソリューションについてさらに理解していただくために、またご自身でテストしていただけるように、Docker Composeを使用したMySQL-Flink-TiDBのテスト環境を、GitHubのflink-tidb-rdwで提供しています。

Docker Composeを起動すると、Flink SQLクライアントを通じてFlinkタスクを作成し、送信できます。タスクの実行はlocalhost:8081を通じて確認できます。

Flink + TiDBリアルタイムデータウェアハウスにご興味がある場合、またご質問がある場合は、Slackのコミュニティに加入し、フィードバックをお送りください。qizhi@pingcap.com宛に直接ご質問いただいてもかまいません。