bowang0911/databricks-qa-ja huggingface dataset:
機械学習エンジニア、データエンジニア及びデータサイエンティストが、実験やモデルの管理からさまざまなデプロイ方式と本番環境に関連する様々な課題対応まで、機械学習のライフサイクル全体管理のベストプラクティスを学びます。MLflowを使用してデータ管理、実験追跡、モデル管理などを含むエンドツーエンドでの機械学習モデルの再現性から始め、バッチ、ストリーミング、リアルタイムでモデルのデプロイ、そして監視、アラート、CI/CDへの対応対策を学びます。サンプルコードはすべてのモジュールに付属しています。このコースでは、
 ・まず、データ、モデル、実験の追跡などを含むエンドツーエンドでの再現性に焦点を当て、MLflowを使用した実験プロセスの管理について説明します。
 ・次に、MLflowモデルレジストリへのモデルの登録、artifactsと環境の管理、モデルテストの自動化など、さまざまなダウンストリームのデプロイツールと統合することにより、モデルの運用を学びます。
 ・その次に、バッチ、ストリーミング、およびリアルタイム推論のためのモデルデプロイを実装します。最後に、継続的なインテグレーション、継続的なデプロイメント、モニタリングおよびアラートを含めた本番環境で必要な取組もカバーします。
 このコースを修了すると、機械学習モデルのログ記録、デプロイ、監視を含めたエンドツーエンドのパイプラインの構築が可能になります。
Feature Storeは、 企業における全ての特徴量を管理する中央管理型リポジトリ になります。これにより、組織内で 特徴量の共有と探索 が可能になり、モデルのトレーニングと推論をするために、特徴量を算出するための同じコードが使用されていることが確保できます。
Delta tableは、新しいデータが書き込まれるたびに自動的にバージョン管理されます。旧バージョンのテーブルへのアクセスは、 display(spark.sql(f'DESCRIBE HISTORY delta.{delta_path}')) を使って戻してほしいバージョンを見つけ、そのバージョンのデータをロードするぐらいに簡単にできます。タイムスタンプを使用して以前のバージョンに戻すこともできます。
MLflow Trackingとは、
 1. 機械学習に特有のLogging API。
 2. トレーニングを行うライブラリや環境に縛られない。
 3 データサイエンスコードの実行であるrunの概念を中心に整備されている。
 4 Runは実験(Experiments)の中に集約され、一つの実験に多数のrunが含まれます。
 5 MLflow Serverは多数の実験をホストできます。
MLflow Trackingで各runに関して次の情報を記録できます。
 ・Parameters: 入力パラメータのキーと値のペア。例：ランダムフォレストモデルの木の本数。
 ・Metric: 評価指標。例：RMSE、AUC。
 ・Artifacts: 任意形式の任意の出力ファイルで、実験の過程で出力された作成物。 例：画像、モデルのpickleファイル、データファイル。
 ・Source: runした時のソースコード。
MLflowは以下のものをログとして取得できます。
 ・Parameter(パラメータ): モデルへの入力　
 ・Metrixs(評価指標): モデルのパフォーマンス　
 ・Artifact(作成物): データ、モデル、画像などあらゆるオブジェクト　
 ・Source（ソースコード）: runした時のコード。gitにリンクされている場合はコミットハッシュを含む
Hyperoptはハイパーパラメーターチューニングを自動化するためのツールです。以下のものを介してApache Sparkと統合できるようになりました。
 ・Trials: シングルノードまたは分散のMLモデルの逐次トレーニング (例:MLlib) 
 ・SparkTrials: シングルノードモデルの並列トレーニング (例: sklearn)。並列処理の数は、 parallelism パラメータで制御されます。
オートロギングを有効にするには、次の2つの方法があります。1. トレーニングコードの前にmlflow.autolog()を呼び出します。これにより、インストールしたサポート対象のライブラリをインポートするとすぐに、オートロギングが有効になります。サポートされているライブラリのリストはここにあります。2. コードで使用するライブラリごとに、ライブラリ固有のオートロギング機能を使用します。例えば、 mlflow.sklearn.autolog() を使用してsklearnのMLflow Autologging 機能を有効にします。
MLflow modelsは、機械学習モデルをパッケージングするための約束事のようなものであり、自己完結するコード、環境、モデルを提供します。
 このパッケージに主な抽象化されたのはフレーバーという概念です。フレーバーとはモデルの異なる使い方です。たとえば、TensorFlowモデルはTensorFlow DAG またはPython関数として読み込むことができます。MLflow modelsとして使用すると、両方のフレーバーが利用可能になります。
 python_functionまたはpyfuncというモデルのフレーバーは、モデルを使用する一般的な方法を提供します。
 これにより、モデルのフォーマットを気にせず、Python関数を使用してモデルをデプロイできます。
フレーバーは、デプロイツールがモデルを理解するために使用する約束事です。これらフレーバーにより、各ライブラリを実装しなくても、任意のMLライブラリのモデルを適用できるデプロイツールを開発できます。 各トレーニング環境をデプロイ環境にマッピングする代わりに、MLモデルフレーバーがこのマッピングを管理・実施してくれます。
MLflow Model Registry (モデル・レジストリ)は、MLflow Modelの完全なライフサイクルを共同で管理するための一元化されたモデルストア、APIのセット、およびUIを揃えているコンポーネントです。モデル・リネージ(どのMLflow Experiment、どのRunで構築されたモデルか)、モデルのバージョン管理、ステージの移行(「Staging」から「Production」への移行など)、アノテーション(コメント、タグなど)、デプロイ管理(どの本番用ジョブが特定のモデルバージョンをリクエストしたかなど)を提供します。
モデルレジストリには以下の機能があります。
 ・中央リポジトリ: モデルをMLflowモデル・レジストリに登録します。登録済みモデルには、一意の名前、バージョン、ステージ、およびその他のメタデータがあります。
 ・モデルのバージョン管理: 更新時に、登録済みモデルのバージョンを自動的に追跡します。
 ・モデルのステージ: モデルのライフサイクルを表す「Staging」や「Production」など、各モデルバージョンに割り当てられたものです。
 ・モデルステージの移行: モデルを別のステージへ変更することです。その際に、新しいモデルの登録またはモデルのステージの変更を行動履歴として記録し、ユーザー名、変更点、およびコメントなどの追加メタデータを自動的にログに記録します。
 ・CI/CDワークフロー統合: より良い制御とガバナンスを行うため、ステージの移行・変更・レビュー・承認をCI/CDパイプラインの一部として記録します。
MLflow model registryでは、 None , Staging , Production と Archived という4つのモデルステージが定義されています。各ステージには固有の意味があります。例えば、 Staging はモデルテスト用、 Production はテストまたはレビュープロセスを完了し、アプリケーションにデプロイされたモデル用です。
トラッキングは、実験と開発のプロセスの追跡です。 モデル・レジストリは、トラッキングからモデルを取得し、ステージングを経て本番稼働に移行するように設計されています。 これは、データエンジニアや機械学習エンジニアがよくデプロイプロセスに担当することです。
MLflow trackingが機械学習トレーニング・プロセスのエンドツーエンドの再現性を提供するのと同じように、モデル・レジストリはデプロイプロセスの再現性とガバナンスを提供します。 本番システムはミッションクリティカルなので、コンポーネントはACLで分離できるため、特定のユーザーしかが本番モデルを変更できません。 バージョン管理とCI/CDワークフロー統合は、モデルを本番環境にデプロイする際の重要な役割でもあります。
ほとんどの操作はUIまたは純粋なPythonで行うことができます。 モデルのトラッキングはPythonで実施する必要がありますが、それ以降の処理はどちらの方法でも実行できます。 例えば、MLflow tracking APIを使用してログに記録されたモデルをUIで登録し、「Production」にプロモートすることができます。
モデル・レジストリのWebhookにより、テストやデプロイ・パイプラインの実行、通知を送信するプッシュメカニズムの提供が可能になり、CI/CDプロセスを円滑に実行できます。モデルレジストリのWebhookは、新たなモデルバージョンの作成、新規コメントの追加、モデルバージョンのステージ移行などによって起動します。
MLflowモデル・レジストリのWebhookは以下2つのタイプがあります。1. ジョブトリガー付きのWebhook: Databricksワークスペースでジョブをトリガーします。2. HTTPエンドポイントを持つWebhook: 任意のHTTPエンドポイントにトリガーを送信します。
以下の事項か、推論結果をバッチ処理でデプロイする最適な方法を決定するのに役に立ちます。1. データがどのようにクエリされるか。 2. データがどのように書き込まれるか。3. トレーニングとデプロイ環境。4. 最終モデルがどのようなデータでトレーニングされるか
モデルをデプロイする方法はいくつもあります。1. 多くはRESTを使用。2. 基本的なプロトタイプの場合、MLflowは開発時のデプロイ用のサーバーとし利用することができます。MLflowの実装はPythonのライブラリであるFlaskによって支えられています。本番環境での利用を想定したものではありません。 
 さらに、Databricksはマネージドなサービスとして　MLflow Model Serving を提供しています。このソリューションでは、モデルのバージョンとそのステージの可用性に基づいて自動的に更新されるRESTエンドポイントとして、Model Registryから機械学習モデルをホストすることができます。
これは、何を望むかに大きく依存します。 考慮すべき主なツールは、コードをコンテナ化する方法と、RESTエンドポイントまたは埋め込みモデルのいずれかです。 これらの方法で、リアルタイムのデプロイメントオプションの大部分をカバーしています。
主要なクラウドプロバイダーはすべて、それぞれのデプロイに関する選択肢を持っています。 Azure環境では、Azure MLは、Dockerイメージを使用してデプロイメントを管理します。これは、あなたのインフラの様々なサブシステムから問い合わせることができるRESTエンドポイントを提供します。
応答時間は、いくつかの要因の関数と考えられます。 バッチ予測は、REST接続のオーバーヘッドを下げることによってスループットを向上させるので、必要なときに使用されるべきです。 地理的な位置も、サーバーの負荷と同様に問題です。 これは、どの地理的場所にデプロイするかと、より多くのリソースによるロードバランシングで対処できます。
ドリフトを監視するためには、ドリフトの原因毎にを監視する必要があります。ドリフトはいくつかの種類があります。1. データのドリフト：データ変化、特徴量のドリフト、ラベルのドリフト、予測値のドリフト。2. コンセプトのドリフト: 入力変数と目的変数ラベルの相関の変化、P(Y∣X)の分布の変化、現行モデルが無効になる可能性が高い
機械学習でCI/CDを実践すると、完全に自動化された開発とデプロイのループを閉じることができ、様々な利点が得られます。1. 時間短縮 (Time Savings)。CI/CDがなければ、本番の機械学習アプリケーションの更新は、時間がかかり、人に依存したプロセスになります。
 ・データサイエンティストが新しいモデルを構築することを決定します。
 ・データサイエンティストが手作業で新しいモデルを構築します。
 ・データサイエンティストによるモデルの性能評価を行います。
 ・データサイエンティストが新しいモデルを本番に稼動させるべきと判断します。
 ・データサイエンティストは、機械学習エンジニアに新しいモデルを本番稼動させるべきと伝えます。
 ・機械学習エンジニアが手作業でモデルをテスト環境に移動させます。
 ・機械学習エンジニアがテスト環境内にモデルをデプロイします。
 ・機械学習エンジニアは、テスト環境内でモデルに対して一連の手動テストを実行します。
 ・機械学習エンジニアが手動でモデルを本番環境に移行させます。
 ・機械学習エンジニアが本番環境にモデルを展開します。
 ・データサイエンティストは、モデルのパフォーマンスを繰り返しテストし、アップデートが必要なタイミングを判断します。
 これには、工数がかかります。CI/CDプロセスに従うことで、この時間のかかるワークフローを自動化することができます。これにより、より速いアップデートサイクルができるようになります。
 ・もっと多い最新モデル。
 ・モデル不良などの不具合による悪影響を抑えることができます。
 2. 一貫性 (Consistency)。自動化された統合とデプロイに従うことで、プロセスの決定ポイントは、一貫性と再現性になります。これはつまり、
 ・各モデルは同じターゲットで作られています。
 ・各モデルに全く同じテストを実施します。
 ・各モデルは、ステージング環境と本番環境に同じように統合されます。
 ・各モデルは全く同じ方法でデプロイされます。
 ・各モデルは、ドリフトを検出するために同じ基準で継続的に評価されます。
 これにより、担当のデータサイエンティストと機械学習エンジニアが異なる（または同じ担当者で工数が異なる）ことによるバイアスが、機械学習アプリケーションに悪影響を与えないようにすることができます。
 3. ホットフィックスとロールバック (Hotfixes and Rollbacks)　
 ・新コードの統合とデプロイを継続的に行うことのもう一つの利点は、ミスや問題を迅速に修正できることです。これには2つの方法があります。
 ・ホットフィックス(Hotfixes): 実稼働中のソフトウェアアプリケーションのバグを迅速に修正するために書かれた小さなコードの断片。
 ・ロールバック(Rollbacks)：ソフトウェアアプリケーションを、正しく機能した最後のバージョンに戻すこと。
機械学習にCI/CDを採用する場合、役立つツールがいろいろとあります。一般に、次のようなカテゴリに分類されます。
・オーケストレーション：アプリケーションのフローを制御します。
・Git Hooks: Gitリポジトリで特定のイベントが発生したときに自動的にコードを実行します。
・アーティファクト管理：パッケージソフトや機械学習モデルなどのアーティファクトを管理します。
・環境管理：アプリケーションで利用可能なソフトウェアリソースを管理します。
・テスト：モデルの妥当性と有効性を評価するためのテストを開発します。
・アラート：特定のイベントやテスト結果が発生したときに、該当のステークホルダーに通知します。
アラートツールには、さまざまなレベルのものがあります。1. PagerDuty。本番システムの停止を監視する最も人気なツールの1つです。テキストメッセージや電話で問題をチーム間にエスカレーションすることができます。2. SlackまたはMicrosoft。3. Teams。4. Twilio。5. メール通知。ほとんどのアラートフレームワークは、REST統合によってカスタムアラートを出すことができます。
Spark Streamingでできることは主に以下の２つです。1. スケーラブルかつ耐障害性な運用により、入力データに対して継続的に推論を行います。2. ストリーミングアプリケーションは、ETLやその他のSparkの機能を組み込んで、リアルタイムにアクションを起こすことも可能です。
ストリーミングには、特別な課題がいくつもあります。具体的には次のようなものがあります。1. エンドツーエンドの信頼性と正確性： ネットワークの問題、トラフィックの急増、および/またはハードウェアの誤動作によって引き起こされるパイプラインの任意の要素の障害に対する回復力がなければなりません。2. 複雑な変換を処理する： よく複雑なビジネスロジックかつ形式の異なるデータを入力として処理しなければなりません。3. データの遅延と到着順序の外れ： ネットワークの問題により、データの到着が遅れたり、意図した順序から外れたりすることがあります。4. 他のシステムとの統合： アプリケーションは、データインフラストラクチャの他の部分と統合する必要があります。
Apache Kafkaや、AWS KinesisやAzure Event Hubsなどのクラウド管理型ソリューションが一般的なデータストリームです。 さらに、受信ファイルが入ってくるディレクトリを監視するのもよくあります。 新しいファイルが入ると、そのファイルをストリームに取り込んで処理します。
Databricks AutoML は、UIとプログラムのいずれで機械学習モデルを自動的に構築するのに役立ちます。モデル トレーニング用のデータセットを準備し、一連の試行 (HyperOpt を使用して) を実行して記録し、複数のモデルを作成、チューニング、および評価します。
一言で言えば、Delta Lakeは、データレイクに信頼性とパフォーマンスをもたらす、オープンソースのストレージレイヤーです。Delta Lakeは、ACIDトランザクション、スケーラブルなメタデータ処理を提供し、ストリーミングとバッチデータを統一的に処理します。
DeltaのTransaction Logは、ユーザーがDelta Lakeテーブルを作成すると、そのテーブルのトランザクションログは自動的に_delta_logというサブディレクトリに作成されるものです。そのテーブルを変更すると、全ての変更はトランザクションログとして、順序付きでアトミックにコミットとして記録されます。各コミットは、000000.jsonで始まるJSONファイルとして書き出されます。テーブルを追加変更すると、さらにJSONファイルが生成されます。
欠損を処理するいくつかの方法があります。1. 欠損を含むレコードはすべて削除する。2. 数値型の場合は平均値/中央値/ゼロ/その他で置き換える。3. カテゴリカル変数の場合は最頻値に置き換えるか欠損を表す表現を用意する。4. 欠損値補完のために設計された ALS (Alternating Least Squares) のようなテクニックを使用する。
Sparkでは、データは行で分割されます。そのため、分割を行う必要がある場合、各Workerは分割点ごとに各特徴の要約統計量を計算する必要があります。そして、分割するためにこれらの統計情報を（tree reduceによって）集約する必要があります。考えてみてください。Worker1が値 32 を持っているが、他のどのWorkerもその値を持っていなかったとしたらどうなるでしょうか。どれだけ良い分割になるのかどうやって分かりますか。そこで、Sparkには連続変数を離散化してバケットにするためのmaxBinsパラメータを使います。しかし、バケット数は最も基数の多いカテゴリ型変数と同じ大きさでなければなりません。
Hyperoptは、「実数値、離散、条件付き次元を含む、厄介な探索空間上でのシリアルおよびパラレル最適化」のためのPythonライブラリです。機械学習ワークフローにおいて、hyperoptは、他のライブラリで利用可能なものより高度な最適化戦略を用いてハイパーパラメータ最適化プロセスを分散/並列化するために使用することができます。
Apache Sparkでhyperoptをスケールさせるには、2つの方法があります。1. シングルマシンのhyperoptで、分散学習アルゴリズム（MLlibなど）を使う。2. 分散hyperoptで、SparkTrialsクラスと一緒にシングルマシンの学習アルゴリズム（scikit-learnなど）を使う。
Hyperoptでは、ランダムサーチまたはTree of Parzen Estimators（TPE）を用いて、ハイパーパラメータのチューニングを並行して行うことができます。TPEはハイパーパラメータ空間を繰り返し探索します。テストされる新しいハイパーパラメータ設定は、過去の結果に基づいて選択される。なのでtpe.suggest はベイジアンの探索方法です。
Apache Arrowは、Sparkで使用されてJVM と Python プロセス間のデータをほぼゼロの（デ）シリアライズコストで効率的に転送するためのインメモリ列型データ形式です。詳しくはこちらをご覧ください。https://spark.apache.org/docs/latest/sql-pyspark-pandas-with-arrow.html
pandas API on Sparkプロジェクトは、Apache Sparkにおけるpandas DataFrame APIを実装することにより、データサイエンティストがビッグデータを扱う際の生産性を高めることを目的としています。2つのエコシステムを使い慣れたAPIに統一することで、pandas API on Sparkは小規模データと大規模データの間のシームレスな切り替えを提供します。PySpark 3.2にマージされたKoalasプロジェクトについてご存知の方もいるかもしれません。Apache Spark 3.2以降では、スタンドアローンのKoalasプロジェクトがメンテナンスモードに入ったため、PySparkを直接ご利用ください。
Pandas DataFrames は ミュータブル(変更可能) で、強制的に評価され、行の順序を維持します。これらは1台のマシンに限定され、a)に示すようにデータセットが小さい場合に非常に高い性能を出します。
 Spark DataFrameは、分散的、遅延評価され、不変であり、行の順序を維持しません。b)とc)に示したように、大規模データの場合の性能は非常に高いです。
 Pandas API on Sparkは、pandas APIとSparkの性能上の利点という、両者の利点を提供します。しかし、Sparkでネイティブにソリューションを実装するのに比べれば、速度は劣ります。
時系列とは、時間順に索引付け（またはリスト化、グラフ化）された一連のデータポイントのことです。最も一般的な時系列は、時間的に等間隔に連続して取得されたデータ系列です。したがって、これは離散時間データのシーケンスです。時系列の例：海洋潮汐の高さ、太陽黒点の数、ダウ・ジョーンズ工業の平均株価の日次終値
ARIMAとは、Auto-Regressive (AR) Integrated (I) Moving Average (MA)の略です。ARIMAモデルは回帰分析の一種で、データ系列のある点とその直近時点の値との関係性を分析する手法です。
 ARIMAは、Prophetと同様に、データセットの過去の値に基づいて将来の値を予測します。ARIMAはプロフェットと違い、設定作業が多くなりますが、様々な時系列に適用することが可能です。
 ARIMAモデルを作成するために、以下のパラメータを求める必要があります。
 ・p (自己回帰パラメータ) :モデルに含まれるラグ観測の数で、ラグ次数とも呼ばれる。
 ・d (差分の階数):生の観測値が差分される回数で、差分化の度合いとも呼ばれます。
 ・q (移動平均パラメータ):移動平均の窓の大きさで、移動平均の次数とも呼ばれる。
指数平滑化とは、指数窓関数を用いて時系列データを平滑化する経験則の手法です。単純移動平均では過去の観測値が均等に重み付けされるのに対し、指数関数は時間の経過とともに指数的に減少する重みを割り当てるために使用されます。季節性など、ユーザーによる事前の想定に基づいて何らかの判断を行うための手順で、簡単に習得でき、簡単に適用できます。時系列データの解析には、指数平滑化がよく使われます。
指数平滑化には3つのタイプがあります。1. 単純指数平滑化(SES), トレンドや季節性のないデータセットに使用します。2. 二重指数平滑化（別名：ホルトの線形平滑化）, トレンドはあるが季節性がないデータセットに使用します。3. 三重指数平滑化（ホルト・ウィンタース指数平滑化とも呼ばれる）, トレンドと季節性の両方を持つデータセットに使用されます。
ジョブの実行速度が遅い場合の最も一般的な要因：1. Spill (スピル、メモリ溢れ): メモリーからディスクにデータが溢れること。解決策：より多くのメモリを持つクラスタを使用する。2. Shuffle : 大量データがクラスタ間で転送されていること。 解決策：Joinを最適化するか、シャッフルを回避するためにコードをリファクタリングする。3. スキュー/ストラグラー : パーティショニングされたデータ（ファイルまたはメモリ内）が均等に分散されていない、一部のパーティションの実行に時間がかかる「最後のreducerの呪い」が発生します。 解決策：使用可能なコアの倍数に再分割するか、スキューヒントを使用する。4. Small/Large Files : 小さなファイルが多すぎて、各ファイルの読み込みに専用のスレッドが必要なため、クラスタのリソースが枯渇しているか、大きなファイルのせいで未使用のスレッドが発生しています。 解決策：より最適な方法でデータを書き直すか、Deltaファイルのコンパクションを実行する。
ジョブの実行速度が遅いなどの場合のデバックツールはいくつあります。1. CPU、ネットワーク、メモリのリソースをクラスタまたはノードレベルで管理するGanglia, 2. その他を監視するSpark UI（特にストレージとエグゼキュータータブ）, 3. ドライバやワーカーのログにエラーがないか（特にバックグラウンドプロセスの場合）, 4. クラスタ・セクションのノートブックタブで、インターンが再びクラスタを占拠しているかどうか
クタスターの構成について一般的な経験則は以下です。1. 機械学習用に大きなマシンタイプの小型クラスタ, 2. 本番ワークロードごとに1クラスタ, 3. ML学習用のクラスタを共有しない（開発中であっても）。詳しくはドキュメントをご覧ください。https://docs.databricks.com/clusters/configure.html
以下はライブラリインストールのベストプラクティスです。1. Notebook-scoped Python libraries は、同じクラスタのユーザが異なるライブラリを持つことができることを保証します。 また、ライブラリに依存するノートブックを保存するのにも便利です。2. 初期化スクリプトは、JVMの起動前にコードが実行されることを保証します（特定のライブラリまたは環境構成に適しています）。3. いくつかの構成変数は、クラスタ起動時に設定する必要があります。
以下はジョブのベストプラクティスです。1. ノートブックワークフローを使用します。2. ウィジェットはパラメータ渡しのために使用します。3. jars や wheelsも実行することができます。4. オーケストレーションツール（Airflowなど）のCLIを利用します。5. 詳しくはドキュメントをご覧ください。https://docs.databricks.com/workflows/jobs/jobs.html 6. 無限にジョブが実行されるのを防ぐため、必ずタイムアウト時間を指定します。
Gitの統合は、いくつかの方法で実現できます:1. CLIを使ってノートブックをインポート/エクスポートし、gitに手動でチェックインする。2. ビルドインの git統合機能を使用する。3. プロジェクト統合の代替に次世代ワークスペースを使用する。
Resilient Distributed Dataset (RDD) は、Spark クラスターによって処理されるデータセットの低レベルのものです。 Spark の初期のバージョンでは、RDD を直接操作するコードを書く必要がありました。 最新バージョンのSpark では、代わりに高レベルの DataFrame API を使用する必要があります。Spark は自動的に低レベルの RDD 操作にコンパイルします。
DataFrame のunion メソッドは、標準SQLのように、列の位置によってデータをユニオンします。2 つのDataFrame のスキーマが、列の順序も含めてまったく同じである場合にのみ使用してください。これに対して、DataFrame unionByName メソッドは、列の名前によってデータをユニオンします。 これは、SQLのUNION ALLと同じです。 どちらも重複を削除しません。
データフレームのjoinメソッドにより、与えられた結合条件に基づいて2つのデータフレームを結合することができます。

いくつかの異なるタイプのjoinがサポートされています:

'name'という共通の列の値が等しい場合に内部結合(inner join)する(つまり、等結合)
df1.join(df2, 'name')

'name'と'age'という共通の列の値が等しい場合に内部結合する
df1.join(df2, ['name', 'age'])

'name'という共通の列の値が等しい場合に完全外部結合（Full outer join)する
df1.join(df2, 'name', 'outer')

明示的な列の等式に基づいて左外部結合(Left outer join)する
df1.join(df2, df1['customer_name'] == df2['account_name'], 'left_outer')
ユーザー定義関数 (User-Defined Function、UDF)はカスタマイズされた列変換の関数です。いくつの特徴があります。
Catalystオプティマイザでは最適化されない
関数はシリアライズされてエグゼキューターに送信される
行のデータはSparkのネイティブフォーマットからデシリアライズされてUDFに渡され、その結果はSparkのネイティブフォーマットにシリアアイズされる
Python UDFでは、各ワーカーノードでエグゼキューターとPythonインタプリタの間でのプロセス間通信のオーバーヘッドが追加で発生する。
Pandas UDFは以下を利用して動作します:

Apache Arrowは、 Sparkで使われるオンメモリの列指向データフォーマットで、JVMとPythonの間のシリアライズ/デシリアライズの処理時間をほぼ0にすることでデータ転送を効率化します。
関数内ではPandasとして動作し、PandasのインスタンスやAPIが使われます。
デフォルトで、データフレームのデータは、クエリーのデータ処理がされている間しかSparkクラスター上に存在しません。クエリーの後に自動的にクラスター上に保持されることはありません。（Sparkはデータ処理のエンジンでありデータストレージのシステムではないので。) cache メソッドを実行することにより、Sparkに対してデータフレームを保持するように明示的にリクエストすることができます。もしデータフレームをキャッシュした後、それ以上必要なくなったらunpersistを実行することにより常に明示的にそれをキャッシュから削除すべきです。
coalescesではより少ない数のパーティションが要求された場合、正確にn個のパーティションを持つ新しいデータフレームを返します。

より大きな数のパーティションが要求された場合、現在のパーティション数のままになります。

ナロートランスフォーメーションであり、いくつかのパーティションが効果的に結合されます
長所: シャッフルが必要ない
短所:
パーティション数を増やすことはできない
パーティションの大きさが不均等になることがある。
パーティショニングの指針です。
パーティション数がコア数の倍数になるようにします
約200MBが、パーティションの推奨サイズです
デフォルトのシャッフルパーティション数を決めるために、最大のシャッフルステージのインプットを、目標とするパーティションサイズで割ります （例: 4TB / 200MB = 2万 シャッフルパーティション数)
AQEは実行時にシャッフルパーティションを動的に減少させることができます。これはspark.sql.shuffle.partitionsをアプリケーションが処理する最大のデータセットに基づいて決めることができ、処理するデータ数がより少ない場合はAQEが自動的にパーティション数を減少させることができることを意味します。