Apache Flinkとは｜ストリーム処理の仕組みとKafka・Sparkの違い

Apache Flinkとは｜ストリーム処理エンジンの基本

Flinkは、終わりのないデータの流れを対象に計算を続けるためのエンジンです。 バッチ処理が「溜まったデータをまとめて処理する」のに対し、Flinkはイベントが届いた端から処理します。

定義と立ち位置

Apache Flink はApache Software Foundation配下のオープンソースプロジェクトで、分散環境でステートフルな計算を行うためのフレームワークです。Java／Scalaに加え、Python API（PyFlink）とSQL（Flink SQL）でも記述できます。

バッチ処理も実行できますが、設計思想としてはストリームが先にあります。Flinkは有限のデータを「終わりのあるストリーム」として扱う、という整理の仕方をしています。バッチをストリームの特殊ケースとみなす、といえば分かりやすいでしょうか。

2026年9月の確認時点では、公式ダウンロードページ上で2.3.0系が最新安定版として案内され、1.20系がLTSとして維持されています。バージョンは数か月単位で動くため、学習や検証を始める前に必ず公式ページで現行の安定版を確認してください。

「無限のデータ」を扱うという考え方

ストリーム処理で最初につまずくのは、処理がいつ終わるのかという感覚がないことです。

バッチなら「1月分のログを集計する」で完結します。ストリームでは入力が途切れないので、「直近5分の売上」「直近1時間のエラー率」のように、時間や件数で窓を切って結果を出し続けます。この窓がウィンドウです。

そして窓の途中経過を覚えておく必要がある。それがステートです。Flinkの設計は、ほぼこの2つの都合から逆算されています。

バッチ処理との違い

バッチとストリームの違いは処理速度だけではありません。障害が起きたときの復旧の考え方が根本的に違います。

バッチなら失敗したジョブを最初から流し直せばいい。ストリームは流し直す起点がないため、どこまで処理したかを定期的に記録しておく必要があります。これが後述するチェックポイントです。

なお分散バッチ処理そのものの仕組みはApache Sparkとは｜分散処理の仕組み・Hadoopとの違い・案件単価で扱っています。本記事はストリーム処理側に絞ります。

Flinkの仕組み｜ステート・チェックポイント・イベント時間

Flinkの仕組みを理解する鍵は3つです。ステート、チェックポイント、イベント時間。 この3語で設計の議論のほとんどがカバーできます。

ステートフル処理とは何か

公式ドキュメントは、ステートフルストリーム処理を「複数のイベントにまたがって情報を記憶する処理」と定義しています。

具体例で言えば、こうしたものです。

• ユーザーIDごとの直近10分の購入金額を保持する

• 「ログイン失敗が5回続いたら」というパターンを検出するため、失敗回数を覚えておく

• 機械学習の特徴量を、イベントが届くたびに更新する

ステートの置き場所はステートバックエンドと呼ばれます。保持方式には主にメモリ中心の方式と、RocksDBのようにローカルディスクを活用する方式があり、ステート量や復旧要件に応じて選びます。ステート量がメモリに収まらない規模ならディスク活用型、というのが実務での典型的な分岐点です。選べる方式はバージョンによって変わるため、採用時は対象バージョンのドキュメントで確認してください。

チェックポイントとexactly-once

Flinkは処理状態のスナップショットを定期的に永続ストレージへ書き出します。障害時はこのスナップショットまで巻き戻し、ストリームを再生して復旧します。公式は、障害時の内部ステートの一貫性についてexactly-onceを保証すると明記しています。あくまで保証の対象はFlink内部のステートであり、出力先まで含めた保証とは範囲が異なります。

仕組みの中核はバリアです。データストリームにバリアという目印を差し込み、レコードと一緒に流します。バリアはレコードを追い越さないため、どのレコードまでがスナップショットに含まれるかが一意に決まります。

チェックポイント間隔は数秒から数分の範囲で設定することが多く、短くすれば復旧時のデータ再処理量は減りますが、処理スループットへの負荷は増えます。ここはレイテンシ要件とコストのトレードオフです。

なお手動で取るスナップショットはセーブポイントと呼ばれ、自動チェックポイントと違って新しいものができても自動削除されません。バージョンアップやジョブ改修の際の退避点として使います。

イベント時間とウォーターマーク

ストリーム処理で最も事故が起きやすいのが時間の扱いです。

Flinkは時間の概念として、処理時間（オペレータを実行するマシンのシステム時間）とイベント時間（イベントが発生デバイスで生じた時刻）を区別します。

モバイルアプリのログを想像してください。電波が悪くて3分遅れて届いたイベントを、「届いた時刻」で集計すると結果が歪みます。正しい集計には、イベント自身が持つ発生時刻で窓を切る必要がある。 それがイベント時間です。

ただしイベント時間を使うと、別の問題が出ます。「もう遅れて届くイベントはない」とどう判断するのか。ここでウォーターマークが登場します。

公式の定義では、ウォーターマークはタイムスタンプtを持つ宣言であり、そのストリームのイベント時間が時刻tに到達した（t以前のタイムスタンプを持つ要素はもう無い）ことを意味します。ウォーターマークが進むと、対応するウィンドウが確定して結果が出力されます。

それでもウォーターマークより後に古いイベントが来ることはあります。Flinkは許容遅延（allowed lateness）という仕組みでこれを扱えます。

ウィンドウ処理の3タイプ

ウィンドウは時間駆動（30秒ごと等）とデータ駆動（100要素ごと等）に分かれ、代表的な型は次の3つです。

このセクションのミニFAQ

Q. ステートは無限に増えませんか？

増えます。だからキーごとの生存期間（TTL）を設定し、不要になったステートを破棄する設計が必要です。TTLを入れ忘れてステートが膨張し、チェックポイントが失敗し始めるのはFlink運用の典型的な事故です。

Q. exactly-onceは「絶対に重複しない」という意味ですか？

Flink内部のステート一貫性についての保証です。出力先のシステムまで含めてexactly-onceにするには、書き込み先がトランザクションや冪等な書き込みに対応している必要があります。Flink側の設定だけでエンドツーエンドが保証されるわけではありません。

KafkaとFlinkの違い｜「運ぶ」と「処理する」の役割分担

違いを一言で言うと、Kafkaはイベントを運ぶ基盤、Flinkはイベントを処理する計算基盤です。 役割が異なるため両者は競合しません。ここを取り違えたまま技術選定の議論に入ると話が噛み合わなくなります。

役割の違いを一枚で整理する

Kafka自体の仕組み（パーティション、レプリケーション、コミットログ）はApache Kafkaとは｜分散イベントストリーミング基盤の仕組み・用途・案件単価を解説で整理しています。

Kafka StreamsとFlinkはどう違うか

Kafkaにも処理機能はあります。Kafka Streamsです。では何が違うのか。

Kafka StreamsはKafkaに密結合したライブラリで、アプリケーションに組み込んで動かします。入力も出力もKafka前提。「Kafkaで完結する軽めの変換・集計」ならこちらのほうが構成がシンプルです。

Flinkは独立したクラスタとして動き、Kafka以外のソース・シンクも扱えます。複雑なステート管理、大規模なジョイン、イベント時間の厳密な制御が要る場合に強みが出ます。その代わり、クラスタの運用というコストを引き受けることになります。

選定の目安はこうです。処理がKafkaトピック間で完結し、ステートも小さいならKafka Streams。複数データソースをまたぐ、ステートが大きい、SQLで分析者にも触らせたい、ならFlink。

組み合わせが定番構成になる理由

実務では、Kafkaがイベントを受けてFlinkが加工し、結果をデータウェアハウスや検索エンジン、あるいは別のKafkaトピックへ返す、という構成をよく見ます。

理由は単純で、それぞれが自分の苦手分野を相手に預けられるからです。Kafkaは計算が苦手、Flinkはデータの長期保持とバッファリングが苦手。組み合わせると穴が埋まります。

Confluentのストリーム処理製品ページでも、KafkaとFlinkはセットで提示されています。

このセクションのミニFAQ

Q. Kafkaを使わずにFlinkだけ導入することはできますか？

できます。FlinkのソースはKafkaに限らず、ファイルシステム、データベースのCDC、各種メッセージキューを指定できます。ただしイベントの再生（リプレイ）やバッファリングをKafkaに任せられなくなるため、障害時の復旧設計を自前で詰める必要が出てきます。

SparkとFlinkの違い｜マイクロバッチと真のストリーム

違いを一言で言うと、Sparkはバッチ寄り、Flinkはストリーム寄りの設計です。 どちらも両方できますが、得意分野は明確に分かれます。

処理モデルの違い

Spark Structured Streamingは主にマイクロバッチ方式で処理します。到着したデータを短い間隔で小さなバッチにまとめて実行する方式です。対してFlinkは、継続的なストリーム処理を主軸に設計されています。

この差がレイテンシに出ます。一般に、Spark Structured Streamingは100ミリ秒〜数秒程度のレイテンシで運用されることが多く、Flinkは要件次第でより低いレイテンシを狙いやすいとされます。ただしレイテンシはワークロード・クラスタ構成・設定で大きく変わるため、実際の数値は自分の環境で計測して判断してください。

ただしこの差が意味を持つ場面は限られます。分析ダッシュボードの更新が3秒遅れて困る現場は多くありません。不正検知、リアルタイム入札、異常検知のように、遅延が直接損失につながる用途で効いてきます。

使い分けの判断軸

判断は3つの問いで整理できます。

1. 要求レイテンシはサブ秒か、数秒〜数分で許されるか。 後者ならSparkでもマネージドのバッチでも足ります

2. ステートは大きいか。 ユーザー単位の長期ステートを大量に持つならFlinkが有利

3. 既存資産は何か。 すでにSparkでETLを回しているなら、Structured Streamingで始めるほうが学習コストも運用コストも低い

実際、既存のSpark基盤からFlinkへ移した事例も出ています。リクルートのエンジニアがData Streaming World Tour 2026での登壇資料で、特徴量集計をSpark Structured StreamingからFlinkへ移行検証した内容を公開しています。レイテンシとコストが動機として挙げられており、「適材適所」という整理がされています。移行が常に正解なのではなく、要件が合ったから動いた、という読み方が妥当です。

Flinkが向く場面・向かない場面と選定チェックリスト

Flinkは強力ですが、運用負荷という対価があります。 採用判断は要件で決めるべきで、技術的な新しさで決めると後悔します。

向いているケース

• サブ秒〜数秒のレイテンシがビジネス要件として定義されている（不正検知、異常検知、リアルタイム推薦など）

• キー単位のステートを大量に持ち、それを長期間維持する必要がある

• イベントの遅延や順序の乱れを、正確に扱う必要がある

• 複数のストリームを結合したり、複雑なイベントパターンを検知したりする

向かないケース（過剰投資になるパターン）

• 実態は日次・時間次のバッチで足りるのに、「リアルタイム」という言葉だけが要件になっている

• ステートがほぼ不要な単純なフィルタ・変換のみ（Kafka ConnectやKafka Streamsで足りる）

• 運用を担当できる人員が1人もおらず、マネージドサービスも使わない前提

3つ目は特に重要です。Flinkはクラスタ運用、ステート管理、バージョンアップの手間がかかります。担当者が1人しかいない体制で自前運用に踏み込むと、その人が抜けた瞬間に基盤が止まります。

採用判断チェックリスト

議論が空転しがちな技術選定の場で、そのまま使える確認項目を並べます。

Yesが3つ以下なら、まずはバッチやdbtとは｜データ変換(ELT)の仕組み・使い方・案件単価で扱っているELT寄りの構成、あるいはApache Airflowとは｜DAGの仕組み・dbt/Dagsterとの違い・案件単価のワークフロー基盤で足りないかを先に検討する価値があります。

Flinkの実行環境｜自前運用とマネージドサービス

運用コストをどこまで自分で持つかで、Flinkの現実的な難易度は大きく変わります。

セルフマネージド（自前運用）

KubernetesやYARN上に自分でクラスタを構築する方式です。設定の自由度は最大ですが、JobManagerの冗長化、ステートバックエンドの置き場所、チェックポイントの保存先、バージョンアップ時のセーブポイント運用まで、すべて自分たちで設計・運用します。

チューニングの余地が事業価値に直結する規模なら選択肢になります。そうでないなら、次のマネージドから入るほうが現実的です。

マネージドサービス

代表的なのはAmazon Managed Service for Apache Flinkです。公式説明では、インフラのセットアップやクラスタ管理なしにアプリケーションを実行でき、スケーリング管理・マルチAZ配置による高可用性・アプリケーションライフサイクル管理が自動で処理されます。処理能力としては1秒未満のレイテンシで秒間ギガバイト規模のデータ処理に対応すると記載されています。

Confluent Cloudでも、KafkaとセットでマネージドのFlinkが提供されています。

案件の観点で言えば、マネージド前提の現場が増えるほど、求められるスキルは「クラスタ構築」より「ジョブ設計とステート設計」に寄ります。 学習の優先順位もそれに合わせるのが合理的です。

Flinkエンジニアの案件動向と単価の見方

ここからは、Flinkを学ぶ・使う立場で気になる実務面を補足します。技術そのものの理解が目的なら、ここは読み飛ばしても構いません。

公開案件を確認する限り、Flink単独で募集される案件は多くありません。 データ基盤案件の要件の一部として現れる、というのが実態に近い捉え方です。

案件はどこに現れるか

2026年9月時点で、首都圏中心の主要フリーランスエージェント数社の公開案件ページ（週3〜5日・準委任を中心とする募集）を横断確認した範囲では、「Apache Flink」を必須スキルとして明記した公開案件は数件程度にとどまりました。募集要件の自由記述欄まで含めた確認のため、取りこぼしはありえます。公開案件数がまだ多くない領域でもあるので、以下はあくまで観測ベースの目安として読んでください。

実際に多いのは次の形です。

• データ基盤構築案件の要件欄に「Kafka／Flink／Spark等のストリーム処理経験」と併記される

• リアルタイム推薦・不正検知システムの開発案件で、技術スタックの一部として登場する

• 既存バッチ基盤のリアルタイム化プロジェクトで、検証フェーズから参画する

探し方としては、エージェントの検索で「Flink」だけを入力しても件数が出ません。「ストリーム処理」「Kafka」「データ基盤」と併用し、案件詳細の技術スタック欄まで読むほうが到達率が上がります。フリコンの案件一覧でも、データ基盤系の募集要件を確認できます。

単価の考え方

まず短答から。データ基盤案件の中でも、ストリーム処理の設計まで担える人は募集母数に対して少なく、比較的高めのレンジで提示される傾向があります。

そのうえで母集団の注記です。以下の数字は、2026年9月時点で首都圏中心の主要フリーランスエージェント数社の公開案件（週4〜5日・準委任）を確認した範囲の目安で、実務経験3年以上のデータエンジニアを想定しています。

上の層に該当するのは、Kafkaを含むイベント基盤の設計経験があり、イベント時間とウォーターマークを踏まえた集計設計や、ステート肥大化への対処を自分で判断できる人です。言語はJava／Scalaの実務経験があると選択肢が広がります。 PyFlinkやFlink SQLだけで完結する案件は、現時点では多くありません。

非公開案件については、個別条件で上振れするケースがあります。ただし公開案件ほど条件の再現性がないため、同じ相場として期待しない前提で見てください。

レイヤー別のより詳しい相場はデータ基盤案件の単価相場｜ETL・DWH・BIレイヤー別の目安とスキルで整理しています。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方を参照してください。

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。

このセクションのミニFAQ

Q. Flinkの実務経験がなくても、データ基盤案件に応募できますか？

Kafkaやバッチ基盤の実務経験があれば、ストリーム処理は参画後にキャッチアップ前提とする案件もあります。ただし「Flink未経験だが学習中」だけでは通りにくい。個人開発でもいいのでKafka連携のジョブを動かし、ステート設計とチェックポイントの挙動を説明できる状態にしてから応募すると、面談での説得力が変わります。エージェント経由の場合、登録から初稼働まで2〜4週間かかるのが一般的なので、準備はその前に済ませておくのが現実的です。

Flinkの学習ロードマップとつまずきやすい点

先にKafkaを理解してからFlinkに入るのが遠回りに見えて最短です。 ストリーム処理の前提知識がないままFlinkのAPIを触ると、何を解決している機能なのかが掴めません。

学習の順序

1. Kafkaの基本概念（トピック、パーティション、オフセット、コンシューマグループ）を押さえる。1〜2週間

2. FlinkのDataStream APIで単純な変換を動かす。ローカルでKafkaと接続し、イベントを読んで書き出すところまで。2〜3週間

3. ウィンドウ集計とイベント時間を扱う。ここで遅延イベントを意図的に流し、結果がどう変わるかを観察する。3〜4週間

4. ステートとチェックポイントの挙動を確認する。ジョブを落として復旧させ、どこから再開するかを体験する。2〜3週間

5. Flink SQLに触れる。分析者と共同作業する現場では、SQLで書ける範囲を知っておくと価値が出る

実務の会話についていける水準までは、腰を据えて週10時間程度で2〜3か月が目安です。設計を任される水準にはもう少しかかります。

つまずきやすい点

ステートのTTL未設定。 検証環境では問題なく動いていたジョブが、本番でステートが膨れ上がり、チェックポイントがタイムアウトして止まる。Flink運用で最もよく聞く失敗です。

イベント時間と処理時間の取り違え。 開発中は処理時間で動かしていて、本番で遅延イベントが来た途端に集計値が合わなくなる。最初からイベント時間で設計し、遅延イベントを意図的に流すテストを用意しておくべきです。

チェックポイント間隔の設定ミス。 短くしすぎてスループットが落ちる、長くしすぎて復旧時の再処理が膨大になる。レイテンシ要件とリカバリ許容時間の両方から決めます。

バージョンアップ時のセーブポイント運用漏れ。 ステートを持つジョブを無停止で更新するにはセーブポイントが前提です。運用手順に組み込まれていないと、更新のたびにステートを捨てることになります。

データエンジニアとしてのキャリア全体の設計はデータエンジニアとは？仕事内容・年収・将来性をわかりやすく解説で整理しています。周辺のデータ基盤技術についてはDatabricksとは｜レイクハウスの仕組み・Snowflakeとの違い・案件単価やBigQueryとは？特徴・できること・データ分析案件の単価をフリーランス視点で解説もあわせて確認してみてください。

まとめ

Kafkaは運び、Flinkは処理する。Sparkはバッチが主戦場で、Flinkはストリームが主戦場。 この役割分担を押さえれば、Flinkまわりの技術選定の議論はほぼ追えます。

• Flinkの核はステート・チェックポイント・イベント時間の3点。ここを説明できる状態が実務の入口

• SparkとFlinkの差が効くのは、レイテンシが金額や意思決定に直結する用途。そうでなければ既存資産を活かすほうが合理的

• 採用判断は本記事のチェックリストで確認する。Yesが3つ以下なら、まずバッチやELT構成で足りないかを先に検討する

• Flink単独の公開案件は少なく、データ基盤案件の要件の一部として現れる。探すときは「ストリーム処理」「Kafka」と併用して絞る

• 学習はKafka理解から入り、週10時間で2〜3か月が実務会話についていける目安

• ステートのTTL未設定とイベント時間の取り違えが、最も頻度の高い失敗

次のステップとしては、ローカルでKafkaとFlinkを接続し、遅延イベントを意図的に流してウィンドウの確定挙動を観察するところから始めるのが実践的です。手を動かした経験があるかどうかで、案件面談での話の解像度が変わります。

参照した一次情報は次のとおりです。

• Apache Flink 公式サイト

• Apache Flink 公式ドキュメント｜Stateful Stream Processing

• Apache Flink 公式ドキュメント｜Timely Stream Processing

• Apache Flink 公式ダウンロードページ

• Amazon Managed Service for Apache Flink

• Confluent｜Apache Flink 製品ページ

• Data Streaming World Tour 2026 登壇資料｜ストリーム処理基盤のFlink移行検証と適材適所の実践