Z iskrem

val df = sqlContext
.read()
.format("jdbc")
.option("url", "jdbc:mysql://127.0.0.1:3306/test?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true")
.option("user", "root")
.option("password", "password")
.option("dbtable", sql)
.schema(customSchema)
.load();

Jednak używając iskr.Read.jdbc, nie mogę zrobić tego samego lub znaleźć składnię, aby zrobić to samo co dla powyższego. Co mi brakuje lub zmieniłem w iskry 2.x? Przeczytałem to w podręczniku: ... Spark automatycznie odczytuje schemat z tabeli bazy danych i mapuje swoje typy powrót do typów iskrowych SQL. ... przypuszczalnie, co próbuję zrobić, nie jest już możliwe jak w powyższym przykładzie.

val dataframe_mysql = spark.read.jdbc(jdbcUrl, "(select k, v from sample) e ", connectionProperties)

Skończyło się na to:

val dataframe_mysql = spark.read.schema(openPositionsSchema).jdbc(jdbcUrl, "(select k, v from sample) e ", connectionProperties)

I dostałem to:

org.apache.spark.sql.AnalysisException: User specified schema not supported with `jdbc`;

Wydaje się krok w określony sposób wsteczny.

1
thebluephantom 4 czerwiec 2018, 12:25

3 odpowiedzi

Najlepsza odpowiedź

. Co mi brakuje lub zmieniłem w iskry 2.x?

Nic nie przegapisz. Modyfikowanie schematu odczytu z źródłami JDBC nigdy nie był obsługiwany. Wejście jest już wpisane, więc nie ma miejsca dla schema.

Jeśli typy nie są satysfakcjonujące, tylko cast wyniki do żądanych typów.

3
user9891428 4 czerwiec 2018, 09:31

Nie zgadzam się z odpowiedzią.

Możesz dostarczyć niestandardowy schemat za pomocą metody lub ustawienie właściwości:

 connectionProperties.put("customSchema", schemachanges);

Gdzie schemat zmienia się w formatu "Nazwa pola" "Nowy typ danych", ...:

 "key String, value DECIMAL(20, 0)"

Jeśli klucz był liczbą w oryginalnej tabeli, wygeneruje zapytanie SQL "Key :: Character Varying, Value :: Numeryczne (20, 0)"

Jest lepszy niż odlewanie, ponieważ odlew jest operacją mapowania wykonaną po wybraniu oryginalnego typu, niestandardowy schemat nie jest.

Miałem przypadek, gdy iskier nie może wybrać NAN z numerycznych Postgres, ponieważ mapuje numerykę w Javie BigDecimal, który nie pozwala na NAN, więc zawodowa praca iskra nie powiodła się za każdym razem podczas czytania tych wartości. Rzut wytworzył ten sam wynik. Jednak po zmianie schematu do ciągów lub podwójnych, było w stanie go przeczytać prawidłowo.

Dokumentacja iskra: https://spark.apache.org/docs /latest/sql-data-sources-jdbc.html.

1
Volodymyr Zubariev 3 kwiecień 2019, 16:07

Możesz użyć niestandardowego schematu i umieścić w parametrach właściwości. Możesz czytać więcej w https://spark.apache.org /docs/latest/sql-data-sources-jdbc.html.

Utwórz zmienną: c_schema = 'id_type int'

Właściwości Conf: config = {"user": "xxx", "Hasło": "YYY", "kierowca": "com.mysql.jdbc.driver", "CustomSchema": c_schema}

Przeczytaj tabelę i utwórz DF: DF = Spark.Read.jdbc (URL = JDBC_URL, Tabela = '' Table_Name ', Właściwości = Config)

Musisz użyć tej samej nazwy kolumny i zmienia się tylko kolumnę umieszczoną wewnątrz dostosowanego schematu.

1
Hugo Pitta 15 styczeń 2020, 22:16