spark3.0の新機能

転載ドキュメント：ほぼ2年後
、Apache Spark 3.0.0の公式バージョンがついにリリースされました

動的パーティションプルーニング（動的パーティションプルーニング）

いわゆる動的パーティションカットは、実行時（実行時）に推測された情報に基づいて、さらにパーティションカットを行います。たとえば、次のクエリがあります。

SELECT * FROM dim_iteblog 
JOIN fact_iteblog 
ON (dim_iteblog.partcol = fact_iteblog.partcol) 
WHERE dim_iteblog.othercol > 10

dim_iteblogテーブルのdim_iteblog.othercol> 10がフィルタリングするデータが少ないと仮定しますが、以前のバージョンのSparkはコストを動的に計算できないため、fact_iteblogテーブルが大量の無効なデータをスキャンする可能性があります。動的パーティション削減により、fact_iteblogテーブル内の不要なデータを実行時に除外できます。この最適化の後、クエリスキャンのデータは大幅に削減され、パフォーマンスが33倍向上します。

アダプティブクエリ実行（アダプティブクエリ実行）

アダプティブクエリ実行（アダプティブクエリ最適化またはアダプティブ最適化とも呼ばれます）はクエリ実行プランの最適化であり、Spark Plannerが実行時にオプションの実行プランを実行できるようにします。これらのプランはランタイム統計に基づいて最適化されます。
2015年には、Sparkコミュニティがアダプティブ実行の基本的なアイデアを提案しました。SparkのDAGSchedulerでは、単一のマップステージを送信するためのインターフェイスが追加され、実行時にシャッフルパーティションの数を調整する試みが行われました。ただし、現在の実装には一定の制限があります。一部のシナリオでは、より多くのシャッフル、つまりより多くのステージが導入され、同じステージで結合する3つのテーブルの状況を処理できません。フレームワークでは、実行計画の変更や実行時の傾斜した結合の処理など、アダプティブ実行の他の機能を柔軟に実装することは困難です。

AQEフレームワークは現在3つの機能を提供します。

シャッフルパーティションを動的にマージします。
結合戦略を動的に調整します。
スキュー結合の動的最適化（スキュー結合）。

統計のない1TB TPC-DSベンチマークに基づくと、Spark 3.0はq77の速度を8倍、q5の速度を2倍、その他の26のクエリの速度を1.1倍以上高速化できます。AQEは、SQL設定spark.sql.adaptive = trueを設定することで有効にできます。このパラメーターのデフォルト値はfalseです。
ここに画像の説明を挿入

アクセラレータ対応のスケジューリング

現在、ビッグデータと機械学習は大きく組み合わされています。機械学習では、計算の反復時間が非常に長くなる可能性があるため、開発者は通常、GPU、FPGA、またはTPUを使用して計算を高速化します。Apache Hadoop 3.1バージョンでは、GPUおよびFPGAのネイティブサポートが開始されました。汎用コンピューティングエンジンとして、Sparkは確かにそれほど遅れていません。Databricks、NVIDIA、Google、およびAlibabaのエンジニアは、Apache SparkにネイティブGPUスケジューリングサポートを追加しています。このソリューションは、SparkのGPUリソースのタスクスケジューリングのギャップを有機的に埋めます。ビッグデータ処理とAIアプリケーションを統合し、ディープラーニング、信号処理、およびさまざまなビッグデータアプリケーションにおけるSparkのアプリケーションシナリオを拡張します。
ここに画像の説明を挿入
現在、Apache SparkでサポートされているリソースマネージャーYARNおよびKubernetesは、すでにGPUをサポートしています。SparkがGPUもサポートするためには、技術レベルで2つの大きな変更を行う必要があります。

クラスターマネージャーレベルでは、GPUをサポートするためにクラスターマネージャーをアップグレードする必要があります。また、ユーザーに関連APIを提供して、ユーザーがGPUリソースの使用と割り当てを制御できるようにします。
Spark内で、スケジューラーがユーザータスクリクエストでGPUの需要を識別し、エグゼキューターのGPU供給に従って割り当てを完了することができるように、スケジューラーレベルで変更を行う必要があります。
Apache SparkがGPUをサポートするのは比較的大きな機能であるため、プロジェクトはいくつかの段階に分かれています。Apache Spark 3.0バージョンでは、スタンドアロン、YARN、およびKubernetesリソースマネージャーでのGPUサポートをサポートし、既存の通常の操作には基本的に影響しません。TPUのサポート、Mesos ExplorerでのGPUサポート、およびWindowsプラットフォームでのGPUサポートは、このバージョンの目標ではありません。さらに、GPUカード内のきめ細かなスケジューリングはこのバージョンではサポートされません。ApacheSpark 3.0バージョンは、GPUカードとそのメモリを切り離せないユニットとして扱います。

Apache Spark DataSource V2

データソースAPIは、HadoopのInputFormat / OutputFormat、HiveのSerdeなど、関連するAPIインターフェイスをストレージシステムから読み書きする方法を定義します。これらのAPIは、ユーザーがSparkでRDDプログラミングを使用するのに非常に適しています。これらのAPIを使用したプログラミングで問題を解決できますが、ユーザーのコストは依然として非常に高く、Sparkはそれらを最適化できません。これらの問題を解決するために、Spark 1.3バージョンはData Source API V1を導入し始めました。このAPIを通じて、さまざまなソースからデータを簡単に読み取ることができます。Sparkは、SQLコンポーネントの最適化エンジンを使用して、データソースの読み取りを最適化します。カラムのトリミング、フィルタリングプッシュダウンなど。
ここに画像の説明を挿入
Data Source API V1は一連のインターフェースを抽象化し、ほとんどのシナリオはこれらのインターフェースを使用して実現できます。ただし、ユーザーの数が増えるにつれて、いくつかの問題が徐々に発生しました。

インターフェースの一部はSQLContextとDataFrameに依存します
拡張能力に限界があり、他のオペレーターを倒すのが難しい
カラム型ストレージの読み取りがサポートされていない
パーティション化とソート情報の欠如
書き込み操作はトランザクションをサポートしていません
ストリーム処理をサポートしていません

Apache Spark 2.3.0バージョンから始まるデータソースV1のいくつかの問題を解決するために、コミュニティはデータソースAPI V2を導入しました。元の機能を保持することに加えて、もはやなくなったなど、データソースAPI V1のいくつかの問題を解決しました上位APIに依存して、拡張機能が強化されています。

詳細については、https：
//www.iteblog.com/archives/2578.html https://www.iteblog.com/archives/2579.htmlを参照してください
。

豊富なAPIと機能

拡張パンダUDF
結合ヒントの完全なセット
コミュニティーはコンパイラーのインテリジェンスを改善し続けていますが、コンパイラーが常に各状況に最適な決定を行えるとは限りません。結合アルゴリズムの選択は、統計とヒューリスティックに基づいています。コンパイラが最良の選択を行えない場合でも、ユーザーは結合ヒントを使用してオプティマイザに影響を与え、より良いプランを選択できます。Apache Spark 3.0は、SHUFFLE_MERGE、SHUFFLE_HASH、SHUFFLE_REPLICATE_NLの新しいヒントを追加することにより、既存の結合ヒントを拡張します
新しい組み込み関数
Scala APIには、32個の新しい組み込み関数と高階関数が追加されています。これらの組み込み関数の中で、MAPのデータ型の処理を簡素化するために、MAPの特定の組み込み関数のセット[transform_key、transform_value、map_entries、map_filter、map_zip_with]が追加されました。

強化された監視機能

構造化ストリーミングUIの再設計
構造化ストリーミングはもともとSpark 2.0で導入されました。Spark 3.0は、これらのストリーミングジョブを監視するためのUIを再設計しました
拡張されたEXPLAINコマンド
読み取りプランは、クエリを理解および調整するために非常に重要です。既存のソリューションは非常に混乱しているように見えます。各演算子の文字列表現は非常に幅が広く、切り捨てられる場合さえあります。Spark 3.0バージョンは、新しいフォーマット（FORMATTED）モードを使用して拡張し、プランをファイルにダンプする機能も提供します。
観察可能な指標
データ品質の変化を継続的に監視することは、データパイプラインを管理するために非常に必要な機能です。Sparkバージョン3.0では、バッチおよびストリーム処理アプリケーションにこの機能が導入されました。監視可能なインジケーターは、クエリで定義できる任意の集計関数（データフレーム）として名前が付けられます。データフレームの実行が完了ポイントに到達すると（たとえば、バッチクエリが完了すると）、最後の完了ポイント以降に処理されたデータのインジケーターを含む名前付きイベントが発行されます。

ANSI SQL互換性の向上

PostgreSQLは、最も先進的なオープンソースデータベースの1つであり、SQL：2011の主な機能のほとんどをサポートしています。SQL：2011の要件を完全に満たす179個の関数のうち、PostgreSQLは少なくとも160個を満たしています。Sparkコミュニティには現在、機能的な機能の補足やバグの修正など、Spark SQLとPostgreSQLの違いを解決する特別なISSUE SPARK-27764があります。関数の補足には、ANSI SQLをサポートするいくつかの関数が含まれ、SQL予約キーワードと組み込み関数を区別します。このISSUEは231のサブISSUEに対応しています。ISSUEのこの部分が解決されると、Spark SQLとPostgreSQLまたはANSI SQL：2011の違いはさらに小さくなります。

その他の

SparkRベクトル化読み取りおよび書き込み
KafkaストリーミングincludeHeadersは、メッセージ内の一部のヘッダー情報の構成をサポートしています
K8S上のSpark：バージョン2.3から始まったKubernetesのSparkサポート、Spark 2.4が改善され、Spark 3.0はKerberosおよび動的リソース割り当てのサポートを追加します。
リモートシャッフルサービス：現在のシャッフルには、柔軟性の低下などの多くの問題があり、NodeManagerに大きな影響を与え、クラウド環境には適していません。上記の問題を解決するために、リモートシャッフルサービスが導入されます。詳細については、SPARK-25299を参照してください
JDK 11のサポート：SPARK-24417を参照してください。JDK11を直接選択する理由は、JDK 8がEOL（サポート終了）に近づいており、JDK9とJDK10はすでにEOLであるため、コミュニティはJDK9とJDK10をスキップし、JDK11を直接サポートします。ただし、Spark 3.0プレビューバージョンでは、デフォルトでJDK 1.8が引き続き使用されます。
Scala 2.11のサポートを削除し、デフォルトでScala 2.12をサポートします。詳細は、SPARK-26132を参照してください。
Hadoop 3.2をサポート、詳細はSPARK-23534を参照Hadoop 3.0は2年間リリースされており（Apache Hadoop 3.0.0-beta1が正式にリリースされ、次のバージョン（GA）をオンラインで使用できます）、Hadoop 3.0をサポートするのは当然です。ただし、Spark 3.0プレビューバージョンは、デフォルトで引き続きHadoop 2.7.4を使用します。
Python 2.xサポートの削除：2019年6月には、Spark 3.0でのPython 2サポートの削除に関してコミュニティで関連する議論がありました。現在、Spark 3.0.0はデフォルトでPython 3.xをサポートしています。SPARK-27884を参照してください。
Spark GraphはCypherをサポートしています。Cypherは人気のあるグラフクエリ言語であり、現在はSpark 3.0でCypherを直接使用できます。
Sparkイベントログはロールをサポートします。「Spark 3.0は最終的にイベントログのローリングをサポートします」を参照してください