[SPARK-30434][PYTHON][SQL] Move pandas related functionalities into 'pandas' sub-package
### What changes were proposed in this pull request?
This PR proposes to move pandas related functionalities into pandas package. Namely:
```bash
pyspark/sql/pandas
├── __init__.py
├── conversion.py # Conversion between pandas <> PySpark DataFrames
├── functions.py # pandas_udf
├── group_ops.py # Grouped UDF / Cogrouped UDF + groupby.apply, groupby.cogroup.apply
├── map_ops.py # Map Iter UDF + mapInPandas
├── serializers.py # pandas <> PyArrow serializers
├── types.py # Type utils between pandas <> PyArrow
└── utils.py # Version requirement checks
```
In order to separately locate `groupby.apply`, `groupby.cogroup.apply`, `mapInPandas`, `toPandas`, and `createDataFrame(pdf)` under `pandas` sub-package, I had to use a mix-in approach which Scala side uses often by `trait`, and also pandas itself uses this approach (see `IndexOpsMixin` as an example) to group related functionalities. Currently, you can think it's like Scala's self typed trait. See the structure below:
```python
class PandasMapOpsMixin(object):
def mapInPandas(self, ...):
...
return ...
# other Pandas <> PySpark APIs
```
```python
class DataFrame(PandasMapOpsMixin):
# other DataFrame APIs equivalent to Scala side.
```
Yes, This is a big PR but they are mostly just moving around except one case `createDataFrame` which I had to split the methods.
### Why are the changes needed?
There are pandas functionalities here and there and I myself gets lost where it was. Also, when you have to make a change commonly for all of pandas related features, it's almost impossible now.
Also, after this change, `DataFrame` and `SparkSession` become more consistent with Scala side since pandas is specific to Python, and this change separates pandas-specific APIs away from `DataFrame` or `SparkSession`.
### Does this PR introduce any user-facing change?
No.
### How was this patch tested?
Existing tests should cover. Also, I manually built the PySpark API documentation and checked.
Closes #27109 from HyukjinKwon/pandas-refactoring.
Authored-by: HyukjinKwon <gurwls223@apache.org>
Signed-off-by: HyukjinKwon <gurwls223@apache.org>
2020-01-08 20:22:50 -05:00
|
|
|
#
|
|
|
|
# Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
# contributor license agreements. See the NOTICE file distributed with
|
|
|
|
# this work for additional information regarding copyright ownership.
|
|
|
|
# The ASF licenses this file to You under the Apache License, Version 2.0
|
|
|
|
# (the "License"); you may not use this file except in compliance with
|
|
|
|
# the License. You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
|
|
def require_minimum_pandas_version():
|
|
|
|
""" Raise ImportError if minimum version of Pandas is not installed
|
|
|
|
"""
|
|
|
|
# TODO(HyukjinKwon): Relocate and deduplicate the version specification.
|
|
|
|
minimum_pandas_version = "0.23.2"
|
|
|
|
|
|
|
|
from distutils.version import LooseVersion
|
|
|
|
try:
|
|
|
|
import pandas
|
|
|
|
have_pandas = True
|
|
|
|
except ImportError:
|
|
|
|
have_pandas = False
|
|
|
|
if not have_pandas:
|
|
|
|
raise ImportError("Pandas >= %s must be installed; however, "
|
|
|
|
"it was not found." % minimum_pandas_version)
|
|
|
|
if LooseVersion(pandas.__version__) < LooseVersion(minimum_pandas_version):
|
|
|
|
raise ImportError("Pandas >= %s must be installed; however, "
|
|
|
|
"your version was %s." % (minimum_pandas_version, pandas.__version__))
|
|
|
|
|
|
|
|
|
|
|
|
def require_minimum_pyarrow_version():
|
|
|
|
""" Raise ImportError if minimum version of pyarrow is not installed
|
|
|
|
"""
|
|
|
|
# TODO(HyukjinKwon): Relocate and deduplicate the version specification.
|
2020-09-10 01:16:19 -04:00
|
|
|
minimum_pyarrow_version = "1.0.0"
|
[SPARK-30434][PYTHON][SQL] Move pandas related functionalities into 'pandas' sub-package
### What changes were proposed in this pull request?
This PR proposes to move pandas related functionalities into pandas package. Namely:
```bash
pyspark/sql/pandas
├── __init__.py
├── conversion.py # Conversion between pandas <> PySpark DataFrames
├── functions.py # pandas_udf
├── group_ops.py # Grouped UDF / Cogrouped UDF + groupby.apply, groupby.cogroup.apply
├── map_ops.py # Map Iter UDF + mapInPandas
├── serializers.py # pandas <> PyArrow serializers
├── types.py # Type utils between pandas <> PyArrow
└── utils.py # Version requirement checks
```
In order to separately locate `groupby.apply`, `groupby.cogroup.apply`, `mapInPandas`, `toPandas`, and `createDataFrame(pdf)` under `pandas` sub-package, I had to use a mix-in approach which Scala side uses often by `trait`, and also pandas itself uses this approach (see `IndexOpsMixin` as an example) to group related functionalities. Currently, you can think it's like Scala's self typed trait. See the structure below:
```python
class PandasMapOpsMixin(object):
def mapInPandas(self, ...):
...
return ...
# other Pandas <> PySpark APIs
```
```python
class DataFrame(PandasMapOpsMixin):
# other DataFrame APIs equivalent to Scala side.
```
Yes, This is a big PR but they are mostly just moving around except one case `createDataFrame` which I had to split the methods.
### Why are the changes needed?
There are pandas functionalities here and there and I myself gets lost where it was. Also, when you have to make a change commonly for all of pandas related features, it's almost impossible now.
Also, after this change, `DataFrame` and `SparkSession` become more consistent with Scala side since pandas is specific to Python, and this change separates pandas-specific APIs away from `DataFrame` or `SparkSession`.
### Does this PR introduce any user-facing change?
No.
### How was this patch tested?
Existing tests should cover. Also, I manually built the PySpark API documentation and checked.
Closes #27109 from HyukjinKwon/pandas-refactoring.
Authored-by: HyukjinKwon <gurwls223@apache.org>
Signed-off-by: HyukjinKwon <gurwls223@apache.org>
2020-01-08 20:22:50 -05:00
|
|
|
|
|
|
|
from distutils.version import LooseVersion
|
|
|
|
import os
|
|
|
|
try:
|
|
|
|
import pyarrow
|
|
|
|
have_arrow = True
|
|
|
|
except ImportError:
|
|
|
|
have_arrow = False
|
|
|
|
if not have_arrow:
|
|
|
|
raise ImportError("PyArrow >= %s must be installed; however, "
|
|
|
|
"it was not found." % minimum_pyarrow_version)
|
|
|
|
if LooseVersion(pyarrow.__version__) < LooseVersion(minimum_pyarrow_version):
|
|
|
|
raise ImportError("PyArrow >= %s must be installed; however, "
|
|
|
|
"your version was %s." % (minimum_pyarrow_version, pyarrow.__version__))
|
|
|
|
if os.environ.get("ARROW_PRE_0_15_IPC_FORMAT", "0") == "1":
|
|
|
|
raise RuntimeError("Arrow legacy IPC format is not supported in PySpark, "
|
|
|
|
"please unset ARROW_PRE_0_15_IPC_FORMAT")
|