Spark SQL アップグレード ガイド
- Spark SQL 2.3から2.4へのアップグレード
- Spark SQL 2.3.0から2.3.1以上へのアップグレード
- Spark SQL 2.2 から 2.3 へのアップグレード
- Spark SQL 2.1から2.2へのアップグレード
- Spark SQL 2.0から2.1へのアップグレード
- Spark SQL 1.6から2.0へのアップグレード
- Spark SQL 1.5から1.6へのアップグレード
- Spark SQL 1.4から1.5へのアップグレード
- Spark SQL 1.3から1.4へのアップグレード
- Spark SQL 1.0-1.2 から 1.3 へのアップグレード
Spark SQL 2.3から2.4へのアップグレード
- Sparkバージョン 2.3以前では、array_contains関数の2つ目のパラメータは暗黙的に最初の配列の型のパラメータの要素の型に昇格されます。この型の昇格は失われやすいもので、
array_contains
関数が間違った結果を返すことになるかもしれません。この問題はより安全な型昇格の仕組みを採用することで2.4で解決されました。これは挙動に幾らかの違いを起こすかもしれません。以下の表で説明されます。
Query | Spark 2.3 以前の結果 | Spark 2.4の結果 | Remarks |
---|---|---|---|
SELECT array_contains(array(1), 1.34D); |
true | false | Spark2.4では、左と右のパラメータがそれぞれ配列(double)とdouble型に昇格されます。 |
SELECT array_contains(array(1), '1'); |
true | integerの型は損失が少ないやり方でstring型に昇格できないため、AnalysisExceptionが投げられます。 | ユーザは明示的なcastを使うことができます |
SELECT array_contains(array(1), 'anystring'); |
null | integerの型は損失が少ないやり方でstring型に昇格できないため、AnalysisExceptionが投げられます。 | ユーザは明示的なcastを使うことができます |
-
Spark 2.4から、サブクエリの前のINオペレータの前にstructフィールドがある場合、内部のクエリもstructフィールドを含まなければなりません。前のバージョンでは、structのフィールドは変わりに内部のクエリの出力と同等と見なされていました。例えば、もし
a
がstruct(a string, b int)
の場合、Spark 2.4 ではa in (select (1 as a, 'a' as b) from range(1))
が有効なクエリで、a in (select 1, 'a' from range(1))
はそうではありません。前のバージョンでは逆でした。 -
バージョン 2.2.1+ と 2.3 では、もし
spark.sql.caseSensitive
がtrueに設定された場合、CURRENT_DATE
とCURRENT_TIMESTAMP
関数は間違って大文字と小文字を区別し、カラムに帰着していました (小文字の型有りではない場合)。Spark 2.4では、これは修正され、関数はもう大文字と小文字を区別しません。 -
Spark 2.4 から SparkはSQL標準により優先ルールに従ってクエリ内で参照されるsetオペレータを評価するでしょう。括弧によって順番が指定されない場合、UNION, EXCEPT あるいはMINUS操作の前に全てのINTERSECT操作が行われるという例外付きの左から右へsetオペレーションが行われます。新しく追加された設定
spark.sql.legacy.setopsPrecedence.enabled
がデフォルトの値false
の場合、全てのset操作に同等の優先順位を与える古い挙動が維持されます。このプロパティがtrue
に設定される場合、sparkは括弧の使用によって明示的な順番が強制されないクエリ内でset操作が現れるため左から右へset操作を評価するでしょう。 -
Spark 2.4から、Sparkは値が Jan 01 1970 であった時にテーブルの説明カラム Last Access 値をUNKNOWNとして表示するでしょう。
-
Spark 2.4 から、SparkはデフォルトでORCファイルのためのベクトル化されたORCリーダーの使用を最大化します。そうするために、
spark.sql.orc.impl
とspark.sql.orc.filterPushdown
はそれらのデフォルトの値をそれぞれnative
とtrue
に変更します。 -
In PySpark, when Arrow optimization is enabled, previously
toPandas
just failed when Arrow optimization is unable to be used whereascreateDataFrame
from Pandas DataFrame allowed the fallback to non-optimization. 今では、PandasデータフレームのtoPandas
とcreateDataFrame
の両方でデフォルトでフォールバックが可能です。これはspark.sql.execution.arrow.fallback.enabled
によって切ることができます。 -
Spark 2.4から、データフレームが物理的にパーティションを持たない場合でも、空のデータフレームのディレクトリへの書き込みは少なくとも1つの書き込みタスクを起動します。This introduces a small behavior change that for self-describing file formats like Parquet and Orc, Spark creates a metadata-only file in the target directory when writing a 0-partition dataframe, so that schema inference can still work if users read that directory later. 新しい挙動は空のデータフレームの書き込みに関してより合理的でより一貫性があります。
-
Spark 2.4から、UDF引数でのIDの表現はカラム名には表示されません。例えば、Spark 2.4のカラム名は
UDF:f(col0 AS colA#28)
ではなくUDF:f(col0 AS `colA`)
です。 -
Spark 2.4から、任意のファイル形式 (parquet, orc, json, text, csv など)を使った空あるいは入れ子になった空のスキーマを持つデータフレームを書き込むことができません。空のスキーマでデータフレームを書き込もうとすると例外が投げられます。
-
Spark 2.4から、SparkはDATE型とTIMESTAMP型をTIMESTAMPに昇格した後で比較をします。
spark.sql.legacy.compareDateTimestampInTimestamp
をfalse
に設定することで以前の挙動を回復します。このオプションはSpark 3.0で削除されるでしょう。 -
Spark 2.4から、空では無い場所の管理されたテーブルの作成は許可されません。空では無い場所に管理されたテーブルを作成しようとすると例外が投げられます。
spark.sql.legacy.allowCreatingManagedTableUsingNonemptyLocation
をtrue
に設定することで以前の挙動を回復します。このオプションはSpark 3.0で削除されるでしょう。 -
Spark 2.4から、既存の場所に管理されたテーブルを移動することは許可されません。既存の場所に管理されたテーブルを移動しようとする例外が投げられます。
-
Since Spark 2.4, the type coercion rules can automatically promote the argument types of the variadic SQL functions (e.g., IN/COALESCE) to the widest common type, no matter how the input arguments order. In prior Spark versions, the promotion could fail in some specific orders (e.g., TimestampType, IntegerType and StringType) and throw an exception.
-
Since Spark 2.4, Spark has enabled non-cascading SQL cache invalidation in addition to the traditional cache invalidation mechanism. The non-cascading cache invalidation mechanism allows users to remove a cache without impacting its dependent caches. This new cache invalidation mechanism is used in scenarios where the data of the cache to be removed is still valid, e.g., calling unpersist() on a Dataset, or dropping a temporary view. This allows users to free up memory and keep the desired caches valid at the same time.
-
In version 2.3 and earlier, Spark converts Parquet Hive tables by default but ignores table properties like
TBLPROPERTIES (parquet.compression 'NONE')
. This happens for ORC Hive table properties likeTBLPROPERTIES (orc.compress 'NONE')
in case ofspark.sql.hive.convertMetastoreOrc=true
, too. Since Spark 2.4, Spark respects Parquet/ORC specific table properties while converting Parquet/ORC Hive tables. As an example,CREATE TABLE t(id int) STORED AS PARQUET TBLPROPERTIES (parquet.compression 'NONE')
would generate Snappy parquet files during insertion in Spark 2.3, and in Spark 2.4, the result would be uncompressed parquet files. -
Since Spark 2.0, Spark converts Parquet Hive tables by default for better performance. Since Spark 2.4, Spark converts ORC Hive tables by default, too. It means Spark uses its own ORC support by default instead of Hive SerDe. As an example,
CREATE TABLE t(id int) STORED AS ORC
would be handled with Hive SerDe in Spark 2.3, and in Spark 2.4, it would be converted into Spark’s ORC data source table and ORC vectorization would be applied. To setfalse
tospark.sql.hive.convertMetastoreOrc
restores the previous behavior. -
In version 2.3 and earlier, CSV rows are considered as malformed if at least one column value in the row is malformed. CSV parser dropped such rows in the DROPMALFORMED mode or outputs an error in the FAILFAST mode. Since Spark 2.4, CSV row is considered as malformed only when it contains malformed column values requested from CSV datasource, other values can be ignored. As an example, CSV file contains the “id,name” header and one row “1234”. In Spark 2.4, selection of the id column consists of a row with one column value 1234 but in Spark 2.3 and earlier it is empty in the DROPMALFORMED mode. To restore the previous behavior, set
spark.sql.csv.parser.columnPruning.enabled
tofalse
. -
Since Spark 2.4, File listing for compute statistics is done in parallel by default. This can be disabled by setting
spark.sql.statistics.parallelFileListingInStatsComputation.enabled
toFalse
. -
Since Spark 2.4, Metadata files (e.g. Parquet summary files) and temporary files are not counted as data files when calculating table size during Statistics computation.
-
Since Spark 2.4, empty strings are saved as quoted empty strings
""
. In version 2.3 and earlier, empty strings are equal tonull
values and do not reflect to any characters in saved CSV files. For example, the row of"a", null, "", 1
was writted asa,,,1
. Since Spark 2.4, the same row is saved asa,,"",1
. To restore the previous behavior, set the CSV optionemptyValue
to empty (not quoted) string. -
Since Spark 2.4, The LOAD DATA command supports wildcard
?
and*
, which match any one character, and zero or more characters, respectively. Example:LOAD DATA INPATH '/tmp/folder*/'
orLOAD DATA INPATH '/tmp/part-?'
. Special Characters likespace
also now work in paths. Example:LOAD DATA INPATH '/tmp/folder name/'
. -
In Spark version 2.3 and earlier, HAVING without GROUP BY is treated as WHERE. This means,
SELECT 1 FROM range(10) HAVING true
is executed asSELECT 1 FROM range(10) WHERE true
and returns 10 rows. This violates SQL standard, and has been fixed in Spark 2.4. Since Spark 2.4, HAVING without GROUP BY is treated as a global aggregate, which meansSELECT 1 FROM range(10) HAVING true
will return only one row. To restore the previous behavior, setspark.sql.legacy.parser.havingWithoutGroupByAsWhere
totrue
.
Spark SQL 2.3.0から2.3.1以上へのアップグレード
- As of version 2.3.1 Arrow functionality, including
pandas_udf
andtoPandas()
/createDataFrame()
withspark.sql.execution.arrow.enabled
set toTrue
, has been marked as experimental. These are still evolving and not currently recommended for use in production.
Spark SQL 2.2 から 2.3 へのアップグレード
-
Spark 2.3 から、参照されるカラムが内部的に汚いレコードカラム(デフォルトでは
_corrupt_record
という名前)のみを含む場合、生の JSON/CSV ファイルからのクエリは許可されません。例えば、spark.read.schema(schema).json(file).filter($"_corrupt_record".isNotNull).count()
とspark.read.schema(schema).json(file).select("_corrupt_record").show()
. 代わりに、パースされた結果をキャッシュあるいは保存し、同じクエリを送信することができます。例えば、val df = spark.read.schema(schema).json(file).cache()
とdf.filter($"_corrupt_record".isNotNull).count()
。 -
percentile_approx
関数は以前は数値型の入力と2つの型の結果の出力を受け付けていました。今では、date型、タイムスタンプ型 および 数値型を入力型としてサポートします。結果の型も入力の型と同じに変更されました。これはパーセンタイル値によってはより意味があります。 -
Since Spark 2.3, the Join/Filter’s deterministic predicates that are after the first non-deterministic predicates are also pushed down/through the child operators, if possible. 前のSparkのバージョンでは、これらのフィルタは断定の急降下の四角がありません。
- Partition column inference previously found incorrect common type for different inferred types, for example, previously it ended up with double type as the common type for double type and date type. 今では、そのような衝突についての正しい一般的な型を見つけます。衝突の解決法は以下の表に従います:
InputA \ InputB NullType IntegerType LongType DecimalType(38,0)* DoubleType DateType TimestampType StringType NullType NullType IntegerType LongType DecimalType(38,0) DoubleType DateType TimestampType StringType IntegerType IntegerType IntegerType LongType DecimalType(38,0) DoubleType StringType StringType StringType LongType LongType LongType LongType DecimalType(38,0) StringType StringType StringType StringType DecimalType(38,0)* DecimalType(38,0) DecimalType(38,0) DecimalType(38,0) DecimalType(38,0) StringType StringType StringType StringType DoubleType DoubleType DoubleType StringType StringType DoubleType StringType StringType StringType DateType DateType StringType StringType StringType StringType DateType TimestampType StringType TimestampType TimestampType StringType StringType StringType StringType TimestampType TimestampType StringType StringType StringType StringType StringType StringType StringType StringType StringType StringType 現在のところ
BigInteger
/BigInt
のような10進数の型のみを推論するため、DecimalType(38,0)*については、上の表は意図的にスケールと精度の全ての他の組み合わせをカバーしません。例えば、1.1はdouble型として推論されます。 -
PySparkでは、Pandasデータフレームなどからの
toPandas
,createDataFrame
のようなPandasに関係する機能を使いたい場合はPandas 0.19.2以上が必要です。 -
PySparkでは、Pandasに関係する機能のタイムスタンプの値の挙動はセッションのタイムゾーンを留意するように変更されました。古い挙動を使いたい場合は、
spark.sql.execution.pandas.respectSessionTimeZone
をFalse
に設定する必要があります。詳細はSPARK-22395を見てください。 -
PySpark では、
na.fill()
あるいはfillna
もbooleanを受け付け、nullはbooleanで置き換えられます。前のSparkのバージョンでは、PySparkは単にそれを無視し元のデータセット/データフレームを返します。 -
Spark 2.3 から、ブロードキャスト ハッシュのjoinあるいはブロードキャストの入れ子になったループのjoinが適用可能な場合、ブロードキャストのヒントの中で明示的に指定された表をブロードキャストすることを好みます。詳細は、ブロードキャストのヒントの章とSPARK-22489を見てください。
-
Spark 2.3から、全ての入力が二進の場合、
functions.concat()
は二進として出力を返します。そうでなければ、文字列として返します。Spark 2.3まで、それは入力の型に関係なく、常に文字列として返ます。古い挙動を続けるには、spark.sql.function.concatBinaryAsString
をtrue
に設定してください。 -
Spark 2.3から、全ての入力が二進の場合、SQL
elt()
は二進として出力を返します。そうでなければ、文字列として返します。Spark 2.3まで、それは入力の型に関係なく、常に文字列として返ます。古い挙動を続けるには、spark.sql.function.eltOutputAsString
をtrue
に設定してください。 -
Spark 2.3から、もし正確な表現ができない(NULLを返す代わりに)場合は、10進数の間での数学的な操作はデフォルトで丸められた値を返します。これはSQL ANSI 2011 の仕様とHiveのHive2.2 (HIVE-15331)で導入された新しい挙動に準拠します。これは以下の変更を意味します。
-
数学的な操作の結果の型を決定するルールが更新されました。得に、もし必要とされる精度/スケールが利用可能な値の範囲外の場合、小数の整数部分を切り捨てることを避けるためにスケールは6まで減らされます。全ての数学的な操作はこの変更に影響を受けます。つまり、addition (
+
), subtraction (-
), multiplication (*
), division (/
), remainder (%
) および正の module (pmod
)。 -
SQL文で使われる文字の値はそれらによって必要とされる正確な精度とスケールを持つDECIMALに変換されます。
-
設定
spark.sql.decimalOperations.allowPrecisionLoss
が導入されました。それはデフォルトがtrue
です。それはここで説明される新しい挙動を意味します; もしfalse
に設定されたバイアは、Sparkは以前のルールを使います。つまり、値を表現するために必要とするスケールを調整せず、値の正確な表現が不可能な場合はNULLを返します。
-
-
PySparkでは、
df.replace
はto_replace
が辞書型の時にvalue
を省略することができません。Previously,value
could be omitted in the other cases and hadNone
by default, which is counterintuitive and error-prone. -
Un-aliased subquery’s semantic has not been well defined with confusing behaviors. Since Spark 2.3, we invalidate such confusing cases, for example:
SELECT v.i from (SELECT i FROM v)
, Spark will throw an analysis exception in this case because users should not be able to use the qualifier inside a subquery. See SPARK-20690 and SPARK-21335 for more details. - When creating a
SparkSession
withSparkSession.builder.getOrCreate()
, if there is an existingSparkContext
, the builder was trying to update theSparkConf
of the existingSparkContext
with configurations specified to the builder, but theSparkContext
is shared by allSparkSession
s, so we should not update them. Since 2.3, the builder comes to not update the configurations. If you want to update them, you need to update them prior to creating aSparkSession
.
Spark SQL 2.1から2.2へのアップグレード
-
Spark 2.1.1 は新しい設定キーを導入しました:
spark.sql.hive.caseSensitiveInferenceMode
.NEVER_INFER
のデフォルトの設定を持っていて、2.1.0 と同一の挙動を維持します。しかし、Spark 2.2.0 は背後にあるファイルシステムが大文字小文字が混じったカラム名を持つHive メタストアのテーブルの読み込みとの互換性を復元するために、このデフォルトの値の設定をINFER_AND_SAVE
に変更しました。INFER_AND_SAVE
設定値を使って、Sparkの最初のアクセスは、推測されたスキーマにまだ保存されていないHiveメタストア テーブル上のスキーマの推測を実施します。Note that schema inference can be a very time-consuming operation for tables with thousands of partitions. 大文字小文字が混じったカラム名の互換性が重要では無い場合は、スキーマ推測の初期のオーバーヘッドを避けるためにspark.sql.hive.caseSensitiveInferenceMode
をNEVER_INFER
に設定することができます。新しいデフォルトのINFER_AND_SAVE
設定を使って、スキーマ推測の結果が将来使うためにメタストア キーとして保存されることに注意してください。従って、初期のスキーマ推測はテーブルの最初のアクセス時のみに起こります。 -
Spark 2.2.1 と 2.3.0 から、データソース テーブルが分割スキーマとデータスキーマの両方に存在するカラムを持つ場合は、実行時に常にスキーマを推測します。推測されたスキーマは分割されたカラムを持ちません。テーブルを読む時に、Sparkはデータソースファイル内に格納されている値の代わりに、これらのオーバーラップするカラムの区分の値を尊重します。2.2.0 と 2.1.x リリースでは、推測されたスキーマは分割されますが、テーブルのデータはユーザに見えません (つまり、結果セットは空です)。
-
Since Spark 2.2, view definitions are stored in a different way from prior versions. This may cause Spark unable to read views created by prior versions. In such cases, you need to recreate the views using
ALTER VIEW AS
orCREATE OR REPLACE VIEW AS
with newer Spark versions.
Spark SQL 2.0から2.1へのアップグレード
-
Datasource テーブルは今ではHive metastore にパーティション metaデータを格納します。このことは
ALTER TABLE PARTITION ... SET LOCATION
のようなHive DDLが今ではDatasource APIを使って作成されたテーブルに利用可能であることを意味します。-
従来のデータソース テーブルは
MSCK REPAIR TABLE
コマンドを使ってこの形式に移行することができます。従来のテーブルの移行はHive DDLサポートを利用するためにお勧めで、プランのパフォーマンスが改善されます。 -
テーブルが移行されたかどうかを決定するために、テーブル上で
DESCRIBE FORMATTED
を発行する時にPartitionProvider: Catalog
属性を調べてください。
-
-
データソース テーブルのための
INSERT OVERWRITE TABLE ... PARTITION ...
の挙動に変更します。-
以前のSparkのバージョンでは、
INSERT OVERWRITE
はパーティションの使用を与えられた場合でもデータソーステーブル全体を上書きしました。今では仕様に合致するパーティションだけが上書きされます。 -
これはまだHiveテーブルの挙動と異なることに注意してください。新しく挿入されたデータと重なるパーティションのみ上書きします。
-
Spark SQL 1.6から2.0へのアップグレード
-
SparkSession
is now the new entry point of Spark that replaces the oldSQLContext
andHiveContext
. 古いSQLContextとHiveContextは後方互換性のために残されていることに注意してください。A newcatalog
interface is accessible fromSparkSession
- existing API on databases and tables access such aslistTables
,createExternalTable
,dropTempView
,cacheTable
are moved here. -
データベースAPIとデータフレームAPIは統合されます。Scalaでは、
DataFrame
はDataset[Row]
のタイプエイリアスになりますが、Java APIユーザはDataFrame
をDataset<Row>
に置き換える必要があります。型有り変換 (例えばmap
,filter
とgroupByKey
) と 型無し変換 (例えばselect
とgroupBy
) の両方がデータセットクラスで利用可能です。PythonとRのコンパイル時の型セーフティは言語的な機能では無いため、データセットの概念はこれらの言語のAPIに適用されません。代わりに、DataFrame
は主要なプログラミング抽象を維持します。これはこれらの言語での1ノードのデータフレームの概念に類似しています。 -
データセットとデータフレームAPIの
unionAll
は非推奨になり、union
に置き換えられました。 -
データセット とデータフレーム APIの
explode
は非推奨になりました。代わりのものとして、select
あるいはflatMap
付きのfunctions.explode()
を使ってください。 -
データセットおよびデータフレームAPI
registerTempTable
はcreateOrReplaceTempView
と置き換えられるために非推奨になりました。 -
Hiveテーブルのための
CREATE TABLE ... LOCATION
に代わりました。-
Spark 2.0から、
CREATE TABLE ... LOCATION
はCREATE EXTERNAL TABLE ... LOCATION
に等価になり、ユーザが提供した場所での既存のデータを偶然にdropすることを避けます。このことは、ユーザが定義した場所のSpark SQL内のHiveテーブルは常にHive外部テーブルであることを意味します。外部テーブルのdropはデータを削除しないでしょう。ユーザはHiveが管理するテーブルの場所を指定することができません。これはHiveの挙動とは異なることに注意してください。 -
結果として、これらのテーブル上の
DROP TABLE
文はデータを削除しないでしょう。
-
-
spark.sql.parquet.cacheMetadata
はもう使われません。詳細は SPARK-13664 を見てください。
Spark SQL 1.5から1.6へのアップグレード
- From Spark 1.6, by default, the Thrift server runs in multi-session mode. つまり、各JDBC/ODBC 接続はそれら独自のSQL設定および一次的な関数の登録のコピーを持つことを意味します。キャッシュされたテーブルはまだ共有されています。古い1つのセッションモードでThriftサーバを実行したい場合、オプション
spark.sql.hive.thriftServer.singleSession
をtrue
に設定してください。このオプションをspark-defaults.conf
に追加するか、それを--conf
を使ってstart-thriftserver.sh
に渡すかのどちらかかも知れません。
-
1.6.1から、SparkRの withColumn メソッドは新しいカラムの追加、あるいはデータフレームの同じ名前の既存のカラムの置き換えをサポートします。
-
Spark 1.6から、TimestampType への LongType キャストはマイクロ秒ではなく秒を期待します。この変更は、数値型からTimestampTypeへの矛盾のない型のキャストのためにHive1.2の挙動に一致させるために行われました。詳細は SPARK-11724 を見てください。
Spark SQL 1.4から1.5へのアップグレード
-
今は、表現の評価のためのコード生成と一緒に、手動メモリ管理(Tungsten)を使った実行の最適化がデフォルトで有効です。これらの機能は
spark.sql.tungsten.enabled
をfalse
に設定することで両方とも無効にすることができます。 -
Parquet スキーマのマージはデフォルトでもう有効にされません。
spark.sql.parquet.mergeSchema
をtrue
に設定することで再有効化することができます。 -
カラムを限定するあるいは入れ子の値にアクセスするためにdots(
.
)を使ったPythonでの文字列のカラムへの変換が今はサポートされます。例えば、df['table.column.nestedField']
。しかし、このことは、もしカラム名がドットを含む場合、今はバックチックを使ってエスケープしなければならないことを意味します(例えば、`column.with.dots`.nested)。 -
メモリ内カラムストレージパーティションの切り詰めはデフォルトで有効です。
spark.sql.inMemoryColumnarStorage.partitionPruning
をfalse
に設定することで無効にすることができます。 -
精度の制限無しの数値カラムはもうサポートされません。代わりにSparkSQLを最大の精度38に強制してください。
BigDecimal
オブジェクトからスキーマを推測する場合、今は精度 (38,18) が使われます。DDLで精度が指定されない場合、デフォルトはDecimal(10, 0)
のままです。 -
今はタイムスタンプは1nsではなく1msで格納されます。
-
sql
の方言では、今は浮動小数点数が10進としてパースされます。HiveQL のパースは変更されないままです。 -
SQL/DataFrame関数の正式名は今は小文字です(例えば、sum と SUM)。
-
JSONデータソースは他のアプリケーションによって生成された新しいファイル(つまり、SparkSQLによってデータセットに挿入されていないファイル)を自動的にロードしないでしょう。JSON永続化ファイル(つまり、テーブルのメタデータはHive Metastorに格納されます)に関しては、ユーザはそれらの新しいファイルをテーブルに含めるために
REFRESH TABLE
SQL コマンド、あるいはHiveContext
のrefreshTable
メソッドを使うことができます。JSONデータセットを表す DataFrame については、ユーザはDataFrameを再生成する必要があり、新しいDataFrameは新しいファイルに含まれるでしょう。 -
pySparkの DataFrame.withColumn メソッドは新しいカラムの追加、あるいは同じ名前の既存のカラムの置き換えをサポートします。
Spark SQL 1.3から1.4へのアップグレード
DataFrame データの reader/writer インタフェース
ユーザのフィードバックにより、(SQLContext.read
)の中のデータを読み込み、(DataFrame.write
)へ書き込むための新しくもっと柔軟なAPIを作成しました。古いAPIは非推奨にされました (例えば、SQLContext.parquetFile
, SQLContext.jsonFile
)。
SQLContext.read
( Scala, Java, Python ) および DataFrame.write
( Scala, Java, Python ) についての詳細な情報はAPIドキュメントを見てください。
グルーピング カラムを保持するDataFrame.groupBy
ユーザフィードバックに基づいて、DataFrame
の結果のグルーピング カラムを保持するためにDataFrame.groupBy().agg()
のデフォルトの挙動を変更しました。1.3での挙動を維持するためには、spark.sql.retainGroupColumns
を false
に設定してください。
DataFrame.withColumn上での挙動の変更
1.4より前は、DataFrame.withColumn() はカラムの追加のみをサポートします。同じ名前の既存のカラムがあったとしても、結果のデータフレーム内の指定された名前を持つ新しいカラムとして、そのカラムが常に追加されるでしょう。1.4から、DataFrame.withColumn() は既存のすべてのカラムの名前と異なるカラム名の追加、あるいは同じ名前の既存のカラムの置きかえをサポートします。
この変更はScala APIだけのもので、PySparkあるいはSparkRのものでは無いことに注意してください。
Spark SQL 1.0-1.2 から 1.3 へのアップグレード
Spark 1.3. では、Spark SQLから "Alpha"のラベルが取り除かれ、この一環として利用可能なAPIの整理が行われました。Spark1.3以降は、Spark SQLは1.Xシリーズの他のリリースとバイナリ互換性を提供するでしょう。この互換性の保証には、明示的に安定していないと印を付けられている(つまり、DeveloperAPI あるいは Experimental)APIは含まれません。
SchemaRDDからデータフレームへの変更
Spark SQL 1.3にアップグレードした時にユーザが気づく最も大きな変更は、SchemaRDD
が DataFrame
に名前が変更されることです。これは、データフレームがもはやRDDから直接継承されないが、RDD自身の実装でRDDが提供するほとんどの機能を代わりに提供するため、重要です。データフレームは.rdd
メソッドを呼ぶことでRDDに変換することも可能です。
In Scala, there is a type alias from SchemaRDD
to DataFrame
to provide source compatibility for some use cases. それでもDataFrame
を代わりに使うためにコードを更新することをお勧めします。Java および Python ユーザはコードを更新する必要は無いでしょう。
JavaとScala APIの統一
Spark 1.3 以降には、Scala APIを模倣した別個のJava互換クラス (JavaSQLContext
および JavaSchemaRDD
) があります。Spark 1.3 ではJavaAPIおよびScala APIは統合されました。どちらかの言語のユーザは SQLContext
および DataFrame
を使用しなければなりません。In general these classes try to use types that are usable from both languages (i.e. Array
instead of language-specific collections). 一般的なタイプが無い場合(例えば、クロージャーあるいはMapを渡す)、代わりに関数の上書きが使われます。
Additionally, the Java specific types API has been removed. ScalaおよびJavaのユーザはプログラム的にスキーマを説明するためにorg.apache.spark.sql.types
にあるクラスを使わなければなりません。
dslパッケージの明示的な交換と削除の分離 (Scalaのみ)
import sqlContext._
から始まるSpark 1.3より前の多くのコード例、sqlContextからの全ての関数はスコープに入れられました。Spark 1.3では、RDD
から DataFrame
への変換のための暗黙的な変換は、SQLContext
の中に隔離しました。今はユーザは import sqlContext.implicits._
を書かなければなりません。
Additionally, the implicit conversions now only augment RDDs that are composed of Product
s (i.e.,
case classes or tuples) with a method toDF
, instead of applying automatically.
When using function inside of the DSL (now replaced with the DataFrame
API) users used to import org.apache.spark.sql.catalyst.dsl
. 代わりに公開データフレーム関数APIが使われるべきです: import org.apache.spark.sql.functions._
.
DataTypeのための org.apache.spark.sql 内のタイプエイリアスの削除 (Scala のみ)
Spark 1.3 は、DataType
のための基本sqlパッケージにあったタイプのエイリアスを削除しました。ユーザはorg.apache.spark.sql.types
にあるクラスを代わりにインポートしなければなりません。
UDF 登録はsqlContext.udf
に移動しました (Java & Scala)
UDFを登録するために使われる関数、データフレーム DSLあるいはSQLの両方で使われる、は、SQLContext
内のudfオブジェクトに移動されました。
Python のUDF登録は変更されません。
Python DataType はもうシングルトンではありません
Pythonでデータタイプを使う場合は、シングルトンを参照する代わりにそれら(つまり StringType()
) を構築する必要があるでしょう。