さらに技術的な交流や仕事の機会が必要な場合は、ByteDance データ プラットフォームの WeChat 公式アカウントをフォローし、[1] と返信して公式コミュニケーション グループに参加してください。
背景の紹介
ビジネスシーン
私たちの日常業務では、特定のロジックを時々繰り返しスケジュールする必要があるため、スケジューリング システムが必要になります。さまざまなスケジュール要件に応じて、大きく 2 つのカテゴリに分類できます。
タイミングスケジューリング
タスクは一定の期間に従って繰り返しスケジュールされます。このタイプのタスクは実装が比較的簡単で、通常は crontab で定期的にタスクをスケジュールできます。ただし、単純な crontab タスクを実際の運用環境に適用するには、障害処理、監視とデプロイメント、クロスマシン デプロイメント、再試行などのいくつかの課題があります。
スケジュール次第
依存型スケジューリング タイプは通常、特定の「イベント」が発生した後に特定のロジックのトリガーが発生する必要があることを意味します。このイベントには、上流タスクの完了、指定されたパス上のデータの準備完了、またはその他の外部トリガーが含まれます。タスク間の依存関係がワーフローを形成します。典型的な単純なワークフローは次のとおりです。
上図では、「ユーザー維持率の計算」は「データ前処理」が完了するまで待つ必要があり、「ユーザー維持率の計算」は「データ前処理」タスクに依存します。タスク間の依存関係には、「ビジネス タイム オフセット」が必要な場合があります。たとえば、「保持率の計算」は、今日のデータと 7 日前のデータに基づいて計算する必要があるため、このノードは現在のデータの前処理タスクにも依存する必要があります。営業日。7 日前のインスタンスとタスク インスタンス。両方の営業日のインスタンスが成功した場合にのみ、その日の「ユーザー維持率の計算」タスクがトリガーされ、ダーティ データの生成が回避されます。
業界の選択
業界にはすでにスケジューリング システムのソリューションが多数あり、関連するオープンソース スケジューリング システムも初期段階で調査されました。主に以下のものが含まれます
気流
Airflow は最初に Airbnb によって開発され、その後 Apache のスケジューリング システムに貢献しました。現在ではさらに使用されるようになり、コミュニティもより活発になっています。ユーザーは Python を通じてワークフローとスケジュール頻度を定義できます。エアフロー ポジショニングは、単一ノードおよびマルチノードの展開をサポートする一般的なスケジューリング システムです。全体的なアーキテクチャ図は次のとおりです
スケジューリングの主なロジックはスケジューラ モジュールにあり、スケジューラは「ポーリング」を通じてデータベースから実行する必要のあるタスクを取得し、実行するためにワーカーに渡します。マルチノード モードでは、スケジューラは Celery を介して複数のワーカーにタスクを分散します。注意すべき点の 1 つは、マルチノード モードであっても、スケジューラ自体が単一障害点になるということです。
アズカバン/ウジー
Azkaban と Oozie は、それぞれ LinkedIn と Apache によって開発されたオープン ソース スケジューリング システムであり、Hadoop Batch のスケジューリングに重点を置き、Hadoop 関連機能をより適切に統合することで、ユーザーが Spark/Hive やその他のタスクを簡単に実行できるようにします。Airflow との違いは、Azkaban と Oozie が構成/DSL を通じて DAG を構成することです。コミュニティ活動という点では、Airflow と比較すると一定のギャップがあります。
その他のオープンソース システム
他のオープン ソース システムには、DolphinScheduler などがあります。オープン ソース システムは非常にたくさんあるのに、なぜ独自のホイール - FlowX を構築することにしたのでしょうか?
-
私たちが必要とするスケジューリング システムは、複数のノード タイプを処理できるユニバーサル スケジューリング システムとして位置付けられています。
-
可用性が高く、スケーラブルです。このスケジューリング システムには、基本的なデータ ウェアハウスなどのいくつかのコア リンクが含まれており、スケジューリングの高可用性を確保する必要があります。同時に、会社のビジネスが発展し続けるにつれて、スケジュールされたタスクの数が急速に増加すると予想され、水平方向の拡張が必要になります。
-
二次開発が容易: この会社のビジネスには、カスタム ミラーリングのサポート、制御ノードの追加、時間の経過に伴う自動再試行の追加など、スケジューリング システムに対するいくつかのカスタマイズ要件があり、システムを低コストで変更できる必要があります。
-
統合が容易. 集中スケジューリング システムとして、会社の他のシステムと統合される予定です. たとえば、データ マップ ツールで使用するタスクの依存関係に基づいたデータ リネージ機能を提供できます。
スケジュール機能の概要
機能的
-
定期的なスケジュールのサポート (分レベル、時間レベル、日レベル、特定の曜日または月)
-
依存関係の実行のサポート - タスク間の依存関係 - 外部 HDFS/Hive パーティションの依存関係 - タスクの自己依存性 (前の営業時間のインスタンスに応じて) - さまざまな期間のタスクの依存関係をサポートします。たとえば、時間レベルのタスクは日に依存する可能性があります。レベル タスク タスク -- ビジネス タイム オフセットへの依存をサポートします (たとえば、現在のインスタンスは、n 日前の上流タスク インスタンス、または履歴の特定期間中の上流タスク インスタンスに依存します)。
-
実行中のインスタンスの一時停止とキャンセル、自動再試行、失敗時のアラームをサポートします。
-
履歴データの補充
-
Worflow およびすべてのダウンストリームで指定したノードを再実行して、データ品質に起因する問題を修正できます。
-
タスクの並列性の制御
-
依存関係の推奨 - システムは、ユーザーの SQL ロジックに基づいて必要な上流テーブルを自動的に抽出します。上流テーブルがスケジューリング システム内のタスクによって生成された場合、上流タスクが推奨されます。上流テーブルが生成されていない場合は、上流テーブルが推奨されます。システム内でタスク出力が生成されると、センサー プローブ タスクが推奨されます。
機能しない
-
スケジューリングの欠落や重複を発生させずに、高可用性、スケーラビリティ、障害回復の精度を確保します。
-
スケジュール遅延 (秒単位)
-
UIとAPIの複数の設定方法
技術的な実現
基本的な考え方
日
DAG の正式名は、有向非巡回グラフです。スケジューリング システムでは、DAG は関連するタスクのセットを表し、タスク間の依存関係は有向辺で表されます。次の図に示すように、A から B へのエッジがあります。これは、A が B の先行タスクであること、つまり、タスク B がタスク A の実行に依存していることを意味します。
図に示すように、有効な実行シーケンスは A -> G -> B -> D -> C -> E -> F です。
タスク
スケジューリング システムの DAG の各ノードは、タスクとロジックの一部を表しており、ユーザーはタスクにさまざまなビジネス ロジックを実装できます。
例
システムは、各タスクに指定された営業日に基づいてインスタンスを生成します。インスタンスは、スケジュールの基本単位です。同時に、タスク間の依存関係は、最終的にはインスタンス間の依存関係に変換されます。
システム構成図
モジュールの解析
ウェブサービス
WebService は外部システムがユーザーと対話するためのメインの入り口として機能し、ユーザーは UI/API を介してタスクを作成するなどの操作を通じて WebService を介して対話します。主な機能は次のとおりです。
-
権限チェック
-
タスクの開発と運用保守
-
インスタンスの運用と保守
-
ログ情報の取得
-
プロジェクト管理
マスター
マスターはシステムの「心臓」です。現在、マスターの災害復旧は ZK を通じて実行されます。Master の主な機能には、タスク依存関係グラフ管理、スケジュール優先度管理、クォータ管理、インスタンス配布、スケジューラーとワーカーの監視などがあります。
-
タスク依存関係グラフ管理
-
タスク間の依存関係を維持し、タスクの上流および下流情報のクエリなどのサービスを他のモジュールに提供します。
-
計画/再実行インスタンスを生成し、INSTANCE_CREATE イベントをスケジューラに送信します。同時に、マスターは将来実行する必要があるインスタンスを事前に定期的に生成します。
-
-
スケジュール優先度管理
-
高負荷条件下でのスケジューリング順序の問題を解決するには、yarn の公平なスケジューリング アルゴリズムを参照として使用します。タスク属性によって優先キューを分割し、フロー制御と重み付けバランスを達成するためにタスクが優先度に従って順序正しくスケジュールされるようにします。
-
-
クォータ管理
-
多次元指標 + 順方向/逆方向マッチング + 時間間隔制限により、対象タスクを柔軟に照合し、対応する同時実行性を制限することで、「早朝のシステム スケジューリング リソースの確保と、日中のデータ リソースのバックトラッキングと再実行の確保」を実現します。または「評価タスクの占有を制限する」「複数のリソース」およびシステム リソースの使用率を向上させるその他の目的。
-
-
インスタンスの分散
-
依存関係チェックに合格し、予定時刻に達したインスタンスはマスターによって配布されます。
-
タスクの種類に応じて、マスターはタスクを実行のためにワーカーに渡すか、K8s に直接送信するかを決定します。
-
-
モジュール監視
-
現在アクティブなスケジューラ リストを維持すると、作成されたインスタンスが、スケジュール チェックのために対応するスケジューラに渡されます。
-
現在アクティブなワーカー リストを維持し、実行のために対応するワーカー/k8 にインスタンスを配布します。
-
スケジューラやワーカーの状態を監視し、状態が異常な場合にはアクティブに他のノードにインスタンスを配布します。
-
スケジューラ
スケジューラ部分には主に 3 つのサブモジュールが含まれています
-
依存関係チェッカー
-
マスターが配信するイベントをイベントキューから取得し、対応するインスタンスの上流の依存関係を確認します。すべての依存関係が満たされると、イベントは次のキューにスローされます。
-
この時点で依存関係が満たされていない場合、イベントは破棄され、現在のインスタンスはアップストリームのステータスをポーリングするために大量のリソースを消費することを避けるために、アップストリームの成功イベントによってアクティブにトリガーされます。
-
-
タイムチェッカー
-
依存関係チェックを通過し、実行時に到達したイベント (インスタンス) をキュー (DelayedQueue) から削除します。通常のタスクタイプの場合はマスターに渡されて配布・実行され、センサープローブタイプのタスクの場合は外部データの準備状況を確認するためにセンサープロセッサーにスローされます。
-
-
センサープロセッサー
-
現在、HDFS パスと Hive テーブル/パーティションの 2 種類のセンサー チェックが実装されています。
-
センサーは、対応する HDFS/Hive データの準備ができているかどうかを確認し、準備ができている場合は、ダウンストリーム プロセスをトリガーします。準備ができていない場合、Sensor は検出中にポーリングを継続せず、代わりに自動タスク再試行メカニズムを使用し、指定された時間 (現在は 5 分) 待ってから再度チェックします。外部データの準備ができるか、再試行回数を超えるまで。
-
スケジューラも ZK に自身を登録します。マスターは Zk を使用して、どのスケジューラが使用可能であるかを検出します。スケジューラが再起動されると、スケジューラによって処理されているタスクがリカバリのためにデータベースから取得されます。
ワーカー
ワーカーは、特にタスクの実行を担当するモジュールです。依存関係チェックに合格したインスタンスは、タスクの実行と実行ステータスの監視のためにマスターによってワーカーに配布されます。ワーカーはサブスレッドを開始してタスクを送信および監視し、ステータスをマスターに積極的に報告し、失敗などの操作を再試行します。ワーカーはまた、マスターが認識できるように自分自身を ZK に登録します。
動物園の飼育員
システムで使用される ZK は主に次の目的に使用されます。
-
マスターの選択: マスターは、高システム可用性を実現するためにマスターとバックアップを実装するために ZK によって選択されます。
-
探索: マスターは ZK を使用して、スケジューラとワーカーの利用可能なリストを認識します。
-
サービス検出: スケジューラとワーカーは、ZK を通じてマスターのリスニング IP とポートを検出します。
これからの計画
今後、このスケジュールシステムは「機能強化」と「使いやすさ」を中心に改良を行ってまいります。主に以下が含まれます：
-
CLI や設定ファイルなど、より対話型のメソッドを提供する
-
ノードタイプの改善(制御ノードなど)
-
会社の Cronjob や FaaS プラットフォームなど、より多くのシステムに接続します
-
軽量の導入
要約する
現在の自社開発スケジューリングシステム「FlowX」は、すでに機能が比較的完成しており、火山エンジン「DataLeap」を通じて外部に提供されており、1年以上のブラッシュアップを経て、システムの安定性が保証されています。このシステムにはすでに多くの基本的なデータ リンクと多方向のビジネス アプリケーションが搭載されています。ビジネスにおいては、「データ生成、データ送信、データ処理、ビジネスプロセス」を真に統合します。インタラクションモードに関しては、Web UI 操作によるアクセスに加えて、特定の API アクセス機能も備えています。
クリックするとビッグ データ R&D ガバナンス スイート DataLeap
にジャンプし 、詳細を確認できます
{{名前}}
{{名前}}