データ処理およびジョブスケジューリング用のApache AirflowまたはApache Beam
有用な情報を提供しようとしていますが、データエンジニアには程遠いです。
現在、python library pandas=を使用して、多くの入力（現在はCSVおよびExcelファイル）を含むデータに長い変換を実行しています。出力は複数のExcelファイルであるため、スケジュールされた監視対象バッチジョブを並列計算で実行できるようにしたい（パンダで行っているようにシーケンシャルではない）。
BeamやAirflowのことはよくわからないので、すぐにドキュメントを読んでみれば、両方とも達成できるようです。どちらを使用すればよいですか？
Apache Airflow はデータ処理エンジンではありません。
Airflowは、プログラムでワークフローを作成、スケジュール、および監視するためのプラットフォームです。
Cloud Dataflow は、データ処理に使用できるGoogle Cloud上の完全に管理されたサービスです。 Dataflowコードを記述してから、Airflowを使用してDataflowジョブをスケジュールおよび監視できます。 Airflowでは、失敗したジョブを再試行することもできます（再試行の回数は構成可能です）。 Dataflowパイプラインが失敗した場合にSlackまたは電子メールでアラートを送信する場合は、Airflowで構成することもできます。
Apache AirflowとApache Beamは、表面上は非常に似ています。どちらの場合も、データを処理する一連のステップを整理し、ステップが正しい順序で実行され、依存関係が満たされるようにすることができます。どちらも、ステップと依存関係をGUIで有向非巡回グラフ（DAG）として視覚化できます。
しかし、少し深く掘り下げると、その機能とサポートするプログラミングモデルに大きな違いがあります。
気流はタスク管理システムです。 DAGのノードはタスクであり、Airflowはそれらを適切な順序で実行し、1つのタスクが依存タスクが終了した後にのみ開始されるようにします。依存タスクは同時に実行されず、次々に実行されます。独立したタスクを同時に実行できます。
Beamはデータフローエンジンです。 DAGのノードは（分岐する可能性のある）パイプラインを形成します。 DAG内のすべてのノードは同時にアクティブであり、データ要素を次々に渡し、それぞれが何らかの処理を実行します。
この2つには重複するユースケースがいくつかありますが、2つのうち1つだけがうまくいくことができることがたくさんあります。
Airflowは、互いに依存するタスクを管理します。この依存関係は、データを次のタスクに渡す1つのタスクで構成できますが、これは要件ではありません。実際、Airflowはタスクが何をするかさえ気にせず、タスクを開始し、タスクが終了したか失敗したかを確認するだけです。タスクが互いにデータを渡す必要がある場合は、自分で調整し、各タスクにそのデータの読み取りと書き込みの場所を指示する必要があります。ローカルファイルパスまたはどこかのWebサービス。タスクはPythonコードで構成できますが、外部プログラムまたはWebサービス呼び出しでもかまいません。
Beamでは、ステップ定義がエンジンと緊密に統合されています。サポートされているプログラミング言語でステップを定義し、Beamプロセス内で実行します。外部プロセスでの計算の処理は、可能であればまったく困難であり、* Beamが使用されるはずの方法ではありません。あなたのステップは、データの保存や転送についてではなく、実行中の計算についてのみ心配する必要があります。異なるステップ間でのデータの転送は、フレームワークによって完全に処理されます。
Airflowでは、タスクがデータを処理する場合、通常、単一のタスク呼び出しがデータセット全体に対して何らかの変換を行います。 Beamでは、データ処理はコアインターフェイスの一部であるため、他には何もできません。 Beamステップの呼び出しは、通常、完全なデータセットではなく、単一または少数のデータ要素を処理します。このため、Beamは無制限の長さのデータセットもサポートしますが、これはAirflowがネイティブに対応できるものではありません。
もう1つの違いは、Airflowはそれ自体がフレームワークですが、Beamは実際には抽象化レイヤーです。ビームパイプラインは、Apache Spark、Apache Flink、Google Cloud Dataflowなどで実行できます。これらはすべて、ほぼ同様のプログラミングモデルをサポートしています。また、GoogleはAirflowをGoogle Cloud Composeとしてサービスにクラウド化しています。
* Apache SparkのPython=のサポートは、サブプロセスで完全なPythonインタープリターを実行することにより実際に実装されますが、これはフレームワークレベルで実装されます。