メインコンテンツまでスキップ

Dinky

· 約8分
tanzhuo

はじめに​

リアルタイム処理をやっている方の多くは、似たような実感を持っているのではないでしょうか。Flink 自体は十分に強力なのに、それを取り巻く開発・運用の体験はあまり親切ではありません。書き上げた SQL はパッケージングして提出しなければならず、デバッグはログをめくる必要があり、複数のクラスタはそれぞれバラバラに管理され、タスクが増えると混乱してしまいます。最近リアルタイムデータウェアハウスのツールチェーンを調査する中で Dinky に出会ったので、これがどんな問題を解決してくれるのかをここに記録しておきます。

Dinky はオープンソースの Flink ジョブ管理・開発プラットフォーム で、全体の設計が軽量で使いやすく、複数の Flink クラスタを統一的に管理できます。
開発者は Web コンソールから直接オンラインで Flink SQL を作成・デバッグでき、開発完了後はワンクリックで指定した Flink クラスタにジョブを提出して実行できます。これによりリアルタイム処理タスクの開発・運用コストが大幅に下がります。

言い換えれば、「SQL を書く、デバッグする、提出する、監視する」という一連のチェーン全体を、1 つのブラウザページに収めてくれるのです。ネイティブな Flink の使い方——ローカルでコードを書き、jar をビルドし、コマンドラインで提出し、Flink Web UI で状態を確認する——と比較すると、このワンストップの体験は、純粋な SQL ベースのリアルタイムタスク開発にとって非常に手間を省いてくれます。

公式サイト​

https://github.com/DataLinkDC/dinky

機能の説明​

Dinky には データベース丸ごと同期（整庫同期）機能 が組み込まれており、マイクロサービスシステム内のデータベーステーブルのデータをリアルタイムデータウェアハウスに同期できます。これにより、マイクロサービスアーキテクチャにおけるデータサイロの問題を効果的に解決できます。

この点は少し掘り下げる価値があります。マイクロサービスアーキテクチャでは各サービスが自分のデータベースを持っており、データ分析の際には数十から数百のテーブルを 1 か所に集約する必要がしばしばあります。ネイティブな Flink CDC を使う場合、通常はテーブル 1 枚につき source 定義を 1 つ書く必要があり、テーブルが多いと煩雑なうえに大量のデータベース接続を占有します。丸ごと同期の考え方はこうです。1 つのジョブでデータベース全体の変更ログ（MySQL の binlog など）を読み取り、ジョブ内部でテーブルごとに分流して下流に書き込む。これなら設定量もリソース占有もはるかに小さくなります。

同時に、Dinky は マルチバージョンの Flink SQL の開発と管理 をサポートし、データリネージ（血縁）分析機能 も提供しています。これにより開発者はデータの流れと依存関係をより明確に把握でき、問題の調査やシステムの保守がしやすくなります。

リネージ分析の価値は、タスクの規模が大きくなってから初めてはっきりします。ある結果テーブルのデータに異常が出たとき、リネージグラフをたどって、それが依存する中間テーブルやソーステーブルへ遡って調査できます。人間の記憶やコードの読み返しに頼る必要はありません。逆に、あるテーブルを廃止・変更したいときも、どの下流タスクが影響を受けるかを先に見通せます。

全体として見ると、Dinky はリアルタイムデータ開発、タスク管理、データガバナンスの面で機能がかなり充実しており、非常に実用的な Flink データ開発プラットフォームです。リアルタイムデータウェアハウスのプロジェクトでの使用と普及に値します。

リアルタイムデータウェアハウスの構築​

Flink SQL + Dinky によって、リアルタイムデータウェアハウスのタスクを素早く構築できます。例えば：

  • ユーザー行動のリアルタイム分析
  • 取引データのリアルタイム集計
  • リアルタイムのリスク管理システム

これらのシナリオに共通するのは、データが絶え間なく流れ込み、ビジネス側が分単位、さらには秒単位で結果を見たいと要求することです。従来のオフラインデータウェアハウスは日次や時間単位のバッチ実行で、この即時性の要求を満たせません。一方、Flink SQL でロジックをストリーミングタスクとして書き、Dinky にライフサイクルの管理を任せれば、開発のリズムはオフラインの SQL を書くのとかなり近いものになります。

データ同期と CDC​

Dinky のデータベース丸ごと同期機能を利用すれば、データベースの変更データキャプチャ（CDC）を実現し、ビジネスデータベースのデータをデータウェアハウスやメッセージキューへリアルタイムに同期できます。

CDC の原理は、簡単に言えばデータベースのトランザクションログを購読することです。INSERT / UPDATE / DELETE の 1 件 1 件がログに記録を残し、CDC ツールがそれらの記録を変更イベントのストリームとして解析します。定期的にテーブル全体をスキャンする同期方式に比べて、ソースデータベースへの侵入が小さく、レイテンシが低く、削除操作までキャプチャできます。典型的な Flink SQL の CDC ソーステーブル定義は、だいたい次のような形です：

-- CDC ソーステーブルを宣言し、MySQL の orders テーブルの変更をリアルタイムにキャプチャする
CREATE TABLE orders_source (
  order_id BIGINT,
  user_id BIGINT,
  amount DECIMAL(10, 2),
  PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
  'connector' = 'mysql-cdc',   -- MySQL CDC コネクタを使って binlog を読み取る
  'hostname' = '...',
  'database-name' = '...',
  'table-name' = 'orders'
);

Dinky ではこの SQL をそのままオンラインでデバッグして結果をプレビューでき、問題がないことを確認してからクラスタに提出できます。ローカルで何度もパッケージングして検証するプロセスを省けるのです。

リアルタイムデータ開発プラットフォーム​

Dinky は企業内部の統一されたリアルタイム処理開発プラットフォームとしても使え、データ開発エンジニアに標準化された開発環境を提供します。

統一プラットフォームの意義は手間の削減だけではありません。SQL スクリプトが集中管理されてバージョン履歴が残り、タスクの提出と運用の方式が統一されるので、新しいメンバーがプロジェクトを引き継ぐときに、各人バラバラの提出スクリプトや環境の違いを先に把握する必要がなくなります。チームコラボレーションに対するこの価値は、個々の機能ポイントよりも大きいことが少なくありません。

ハマりどころと注意点​

  • Dinky 自体は計算タスクを実行しません。あくまで提出と管理の入り口であり、Flink クラスタは別途デプロイ・保守する必要があります。両者のバージョン互換性は事前に確認しましょう。
  • CDC によるデータベース丸ごと同期を使う前に、ソースデータベースで変更ログ（MySQL の binlog など）が有効になっていることを確認し、同期用アカウントに相応の権限を付与する必要があります。そうしないとジョブが起動しません。
  • オンラインデバッグは便利ですが、デバッグ環境のリソースとデータ量は本番クラスタとは異なります。ロジックが複雑なタスクは、リリース前に本番と同スペックの環境で一度検証することをおすすめします。
ヒント

選定の際は、テスト環境を直接立ち上げて、自分のビジネスで最も複雑なチェーン 1 本（例えば大きなテーブルの丸ごと同期 + 複数テーブル join の SQL）で全フローを通してみることをおすすめします。機能リストを眺めるよりずっと多くのことがわかります。

まとめ​

Dinky が補っているのは、Flink エコシステムにおける「開発体験」という弱点です。オンラインでの SQL 作成、ワンクリック提出、データベース丸ごと同期、リネージ分析と、リアルタイムデータウェアハウス開発の主な日常業務をカバーしています。チームのリアルタイムタスクが Flink SQL 中心で、統一された開発・管理の入り口がなくて困っているなら、選定候補に加える価値があります。

COMMENTS