Anleitung zur Übersetzung von Teradata SQL

In diesem Dokument werden die Gemeinsamkeiten und Unterschiede in der SQL-Syntax zwischen Teradata und BigQuery beschrieben, damit Sie die Migration planen können. Verwenden Sie die Batch-SQL-Übersetzung, um Ihre SQL-Skripts im Bulk zu migrieren, oder die interaktive SQL-Übersetzung, um Ad-hoc-Abfragen zu übersetzen.

Datentypen

In diesem Abschnitt werden die Entsprechungen zwischen den Datentypen in Teradata und BigQuery beschrieben.

Teradata BigQuery Hinweise
INTEGER INT64
SMALLINT INT64
BYTEINT INT64
BIGINT INT64
DECIMAL

NUMERIC, DECIMAL

BIGNUMERIC, BIGDECIMAL

Verwenden Sie NUMERIC (Alias-DECIMAL) von BigQuery, wenn die Skala (Ziffern nach dem Dezimalzeichen) <= 9 ist.
Verwenden Sie BIGNUMERIC (Alias BIGDECIMAL) von BigQuery, wenn die Skalierung > 9 ist.

Verwenden Sie die parametrisierten Dezimaldatentypen von BigQuery, wenn Sie benutzerdefinierte Ziffern- oder Skalierungsgrenzen erzwingen (Einschränkungen) müssen.

Mit Teradata können Sie Werte mit höherer Genauigkeit durch Runden des gespeicherten Werts einfügen. Für Berechnungen behält Teradata jedoch die hohe Genauigkeit bei. Dies kann im Vergleich zum ANSI-Standard zu unerwartetem Rundungsverhalten führen.

FLOAT FLOAT64
NUMERIC

NUMERIC, DECIMAL

BIGNUMERIC, BIGDECIMAL

Verwenden Sie NUMERIC (Alias-DECIMAL) von BigQuery, wenn die Skala (Ziffern nach dem Dezimalzeichen) <= 9 ist.
Verwenden Sie BIGNUMERIC (Alias BIGDECIMAL) von BigQuery, wenn die Skalierung > 9 ist.

Verwenden Sie die parametrisierten Dezimaldatentypen von BigQuery, wenn Sie benutzerdefinierte Ziffern- oder Skalierungsgrenzen erzwingen (Einschränkungen) müssen.

Mit Teradata können Sie Werte mit höherer Genauigkeit durch Runden des gespeicherten Werts einfügen. Für Berechnungen behält Teradata jedoch die hohe Genauigkeit bei. Dies kann im Vergleich zum ANSI-Standard zu unerwartetem Rundungsverhalten führen.

NUMBER

NUMERIC, DECIMAL

BIGNUMERIC, BIGDECIMAL

Verwenden Sie NUMERIC (Alias-DECIMAL) von BigQuery, wenn die Skala (Ziffern nach dem Dezimalzeichen) <= 9 ist.
Verwenden Sie BIGNUMERIC (Alias BIGDECIMAL) von BigQuery, wenn die Skalierung > 9 ist.

Verwenden Sie die parametrisierten Dezimaldatentypen von BigQuery, wenn Sie benutzerdefinierte Ziffern- oder Skalierungsgrenzen erzwingen (Einschränkungen) müssen.

Mit Teradata können Sie Werte mit höherer Genauigkeit durch Runden des gespeicherten Werts einfügen. Für Berechnungen behält Teradata jedoch die hohe Genauigkeit bei. Dies kann im Vergleich zum ANSI-Standard zu unerwartetem Rundungsverhalten führen.

REAL FLOAT64
CHAR/CHARACTER STRING

Verwenden Sie den parametrisierten STRING-Datentyp von BigQuery, wenn Sie eine maximale Zeichenlänge erzwingen müssen.

VARCHAR STRING

Verwenden Sie den parametrisierten STRING-Datentyp von BigQuery, wenn Sie eine maximale Zeichenlänge erzwingen müssen.

CLOB STRING
JSON JSON
BLOB BYTES
BYTE BYTES
VARBYTE BYTES
DATE DATE BigQuery unterstützt keine benutzerdefinierte Formatierung, die Teradata mit DataForm in SDF unterstützt.
TIME TIME
TIME WITH TIME ZONE TIME Teradata speichert den Datentyp TIME in UTC und ermöglicht die Übergabe eines Offsets von UTC mit der Syntax WITH TIME ZONE. Der Datentyp TIME in BigQuery stellt eine Zeit dar, die unabhängig von einem Datum oder einer Zeitzone ist.
TIMESTAMP TIMESTAMP Der Datentyp TIMESTAMP ist sowohl in Teradata als auch in BigQuery auf Mikrosekunden genau. Teradata unterstützt Schaltsekunden, BigQuery hingegen nicht.

Sowohl in Teradata als auch in BigQuery ist dieser Datentyp normalerweise mit einer UTC-Zeitzone verknüpft. Weitere Informationen
TIMESTAMP WITH TIME ZONE TIMESTAMP Für Teradata TIMESTAMP kann systemweit, pro Nutzer oder pro Spalte (mit WITH TIME ZONE) eine andere Zeitzone festgelegt werden.

Für den BigQuery-TIMESTAMP-Typ wird UTC angenommen, wenn Sie keine Zeitzone angeben. Achten Sie darauf, dass Sie entweder die Zeitzoneninformationen korrekt exportieren (ohne den DATE- und TIME-Wert ohne Zeitzoneninformationen zu verketten), damit BigQuery sie beim Import konvertieren kann. Sie können die Zeitzoneninformationen auch vor dem Export in UTC konvertieren.

BigQuery verfügt über DATETIME für eine Abstraktion zwischen amtlicher Zeit, die bei der Ausgabe keine Zeitzone anzeigt, und TIMESTAMP, einem genauen Zeitpunkt, an dem immer die UTC-Zeitzone angezeigt wird.
ARRAY ARRAY
MULTI-DIMENSIONAL ARRAY ARRAY Verwenden Sie in BigQuery ein Array von Struct-Werten, in dem jeder Struct-Wert ein Feld vom Typ ARRAY enthält. Weitere Informationen finden Sie in der BigQuery-Dokumentation.
INTERVAL HOUR INT64
INTERVAL MINUTE INT64
INTERVAL SECOND INT64
INTERVAL DAY INT64
INTERVAL MONTH INT64
INTERVAL YEAR INT64
PERIOD(DATE) DATE, DATE PERIOD(DATE) sollte in zwei DATE-Spalten konvertiert werden, die das Startdatum und Enddatum enthalten, damit sie mit Fensterfunktionen verwendet werden können.
PERIOD(TIMESTAMP WITH TIME ZONE) TIMESTAMP, TIMESTAMP
PERIOD(TIMESTAMP) TIMESTAMP, TIMESTAMP
PERIOD(TIME) TIME, TIME
PERIOD(TIME WITH TIME ZONE) TIME, TIME
UDT STRING
XML STRING
TD_ANYTYPE STRING

Weitere Informationen zur Typumwandlung finden Sie im nächsten Abschnitt.

Teradata-Formatierung

Teradata SQL verwendet eine Reihe von Standardformaten für die Anzeige von Ausdrücken und Spaltendaten sowie für die Konvertierung zwischen Datentypen. Beispiel: Ein PERIOD(DATE)-Datentyp im INTEGERDATE-Modus ist standardmäßig als YY/MM/DD formatiert. Wir empfehlen Ihnen, nach Möglichkeit den ANSIDATE-Modus zu verwenden, um die ANSI-SQL-Konformität zu gewährleisten, und diese Gelegenheit zu nutzen, um ältere Formate zu bereinigen.

Teradata ermöglicht die automatische Anwendung benutzerdefinierter Formate mit der FORMAT-Klausel, ohne den zugrunde liegenden Speicher zu ändern, entweder als Datentypattribut, wenn Sie eine Tabelle mit DDL erstellen, oder in einem abgeleiteten Ausdruck. Zum Beispiel rundet eine FORMAT-Spezifikation 9.99 einen beliebigen FLOAT-Wert auf zwei Ziffern. In BigQuery muss diese Funktion mithilfe der Funktion ROUND() konvertiert werden.

Diese Funktion erfordert die Bearbeitung komplizierter Grenzfälle. Wenn beispielsweise die FORMAT-Klausel auf eine NUMERIC-Spalte angewendet wird, müssen Sie spezielle Rundungs- und Formatierungsregeln berücksichtigen. Mit einer FORMAT-Klausel kann ein INTEGER-Epochenwert implizit in ein DATE-Format umgewandelt werden. Oder eine FORMAT-Spezifikation X(6) für eine VARCHAR-Spalte kürzt den Spaltenwert und muss daher in eine SUBSTR()-Funktion konvertiert werden. Dieses Verhalten ist nicht ANSI SQL-konform. Daher empfehlen wir, Spaltenformate nicht zu BigQuery zu migrieren.

Wenn Spaltenformate unbedingt erforderlich sind, verwenden Sie Ansichten oder benutzerdefinierte Funktionen (UDFs).

Informationen zu den Standardformaten, die Teradata SQL für jeden Datentyp verwendet, finden Sie in der Dokumentation zur Teradata-Standardformatierung.

Formatierung von Zeitstempel und Datumstyp

Die folgende Tabelle fasst die Unterschiede bei Elementen der Zeitstempel- und Datumsformatierung zwischen Teradata SQL und GoogleSQL zusammen.

Teradata-Format Teradata-Beschreibung BigQuery
CURRENT_TIMESTAMP
CURRENT_TIME
TIME- und TIMESTAMP-Informationen in Teradata können unterschiedliche Zeitzoneninformationen haben, die mit WITH TIME ZONE definiert werden. Verwenden Sie nach Möglichkeit CURRENT_TIMESTAMP(), formatiert im ISO-Format. Das Ausgabeformat zeigt jedoch immer die UTC-Zeitzone an. (Intern hat BigQuery keine Zeitzone.)

Beachten Sie die folgenden Details zu den Unterschieden im ISO-Format.

DATETIME wird basierend auf den Ausgabekanalkonventionen formatiert. Im BigQuery-Befehlszeilentool und in der BigQuery Console wird es mit einem T-Trennzeichen gemäß RFC 3339 formatiert. In Python und Java JDBC wird jedoch ein Leerzeichen als Trennzeichen verwendet.

Wenn Sie ein explizites Format nutzen möchten, verwenden Sie FORMAT_DATETIME(), wodurch eine explizite Umwandlung eines Strings erfolgt. Der folgende Ausdruck gibt beispielsweise immer ein Leerzeichen als Trennzeichen zurück:

CAST(CURRENT_DATETIME() AS STRING)

Teradata unterstützt ein DEFAULT-Keyword in TIME-Spalten, um die aktuelle Zeit festzulegen (Zeitstempel). Dies wird in BigQuery nicht verwendet.
CURRENT_DATE Datumsangaben werden in Teradata mithilfe der folgenden Formel als INT64-Werte gespeichert:

(YEAR - 1900) * 10000 + (MONTH * 100) + DAY

Datumsangaben können als Ganzzahlen formatiert werden.
BigQuery hat ein separates DATE-Format, das immer ein Datum im ISO 8601-Format zurückgibt.

DATE_FROM_UNIX_DATE kann nicht verwendet werden, da es auf 1970 basiert.

Teradata unterstützt ein DEFAULT-Keyword in DATE-Spalten, um das aktuelle Datum festzulegen. Dies wird in BigQuery nicht verwendet.
CURRENT_DATE-3 Datumswerte werden als Ganzzahlen dargestellt. Teradata unterstützt arithmetische Operatoren für Datumstypen. Verwenden Sie für Datumstypen DATE_ADD() oder DATE_SUB().

BigQuery verwendet arithmetische Operatoren für die Datentypen INT64, NUMERIC und FLOAT64.
SYS_CALENDAR.CALENDAR Teradata bietet eine Ansicht für Kalendervorgänge, die über Ganzzahlvorgänge hinausgehen. Wird in BigQuery nicht verwendet.
SET SESSION DATEFORM=ANSIDATE Setzen Sie das Sitzungs- oder Systemdatumsformat auf ANSI (ISO 8601). BigQuery verwendet immer ISO 8601. Gewährleisten Sie daher, dass Sie Teradata-Datums- und Zeitangaben konvertieren.

Abfragesyntax

In diesem Abschnitt werden Unterschiede in der Abfragesyntax zwischen Teradata und BigQuery behandelt.

SELECT-Anweisung

Die meisten Teradata-SELECT-Anweisungen sind mit BigQuery kompatibel. Die folgende Tabelle enthält eine Liste der geringfügigen Unterschiede.

Teradata BigQuery
SEL Zu SELECT konvertieren. BigQuery verwendet nicht die Abkürzung SEL.
SELECT
  (subquery) AS flag,
  CASE WHEN flag = 1 THEN ...
In BigQuery können Spalten nicht auf die Ausgabe anderer Spalten verweisen, die in derselben Auswahlliste definiert sind. Ziehen Sie daher in Betracht, eine Unterabfrage in eine WITH-Klausel zu verschieben.

WITH flags AS (
  subquery
),
SELECT
  CASE WHEN flags.flag = 1 THEN ...
SELECT * FROM table
WHERE A LIKE ANY ('string1', 'string2')
BigQuery verwendet nicht das logische Prädikat ANY.

Dieselbe Funktionalität kann mit mehreren OR-Operatoren erreicht werden:

SELECT * FROM table
WHERE col LIKE 'string1' OR
      col LIKE 'string2'


In diesem Fall unterscheidet sich der Stringvergleich ebenfalls. Siehe Vergleichsoperatoren.
SELECT TOP 10 * FROM table BigQuery verwendet LIMIT am Ende einer Abfrage anstelle von TOP n nach dem Keyword SELECT.

Vergleichsoperator

Die folgende Tabelle zeigt Teradata-Vergleichsoperatoren, die für Teradata spezifisch sind und in die in BigQuery verwendeten ANSI SQL:2011-kompatiblen Operatoren konvertiert werden müssen.

Informationen zu Operatoren in BigQuery finden Sie im Abschnitt Operatoren der BigQuery-Dokumentation.

Teradata BigQuery Hinweise
exp EQ exp2
exp IN (exp2, exp3)
exp = exp2
exp IN (exp2, exp3)

Wenn Sie die Nicht-ANSI-Semantik für NOT CASESPECIFIC beibehalten möchten, verwenden Sie
RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))
Wenn Strings auf Gleichheit verglichen werden, ignoriert Teradata möglicherweise nachgestellte Leerzeichen, während BigQuery sie als Teil des Strings betrachtet. Beispiel: 'xyz'=' xyz' ist in Teradata TRUE, in BigQuery jedoch FALSE.

Teradata bietet auch ein NOT CASESPECIFIC-Spaltenattribut, das Teradata anweist, die Groß- und Kleinschreibung beim Vergleich von zwei Strings zu ignorieren. BigQuery beachtet beim Vergleich von Strings immer Groß- und Kleinschreibung. Beispiel: 'xYz' = 'xyz' ist in Teradata TRUE, in BigQuery jedoch FALSE.
exp LE exp2 exp <= exp2
exp LT exp2 exp < exp2
exp NE exp2 exp <> exp2
exp != exp2
exp GE exp2 exp >= exp2
exp GT exp2 exp > exp2

JOIN Bedingungen

BigQuery und Teradata unterstützen dieselben JOIN-, ON- und USING-Bedingungen. Die folgende Tabelle enthält eine Liste der geringfügigen Unterschiede.

Teradata BigQuery Hinweise
FROM A LEFT OUTER JOIN B ON A.date > B.start_date AND A.date < B.end_date FROM A LEFT OUTER JOIN (SELECT d FROM B JOIN UNNEST(GENERATE_DATE_ARRAY(B.start_date, B.end_date)) d) B ON A.date = B.date BigQuery unterstützt Ungleichheits-JOIN-Klauseln für alle internen Joins oder wenn mindestens eine Gleichheitsbedingung angegeben ist (=). Aber nicht nur eine Ungleichheitsbedingung (= und <) in einem OUTER JOIN. Solche Konstrukte werden manchmal verwendet, um Datums- oder Ganzzahlbereiche abzufragen. BigQuery verhindert, dass Nutzer versehentlich große Cross Joins erstellen.
FROM A, B ON A.id = B.id FROM A JOIN B ON A.id = B.id Die Verwendung eines Kommas zwischen Tabellen in Teradata entspricht einem INNER JOIN, in BigQuery einem CROSS JOIN (kartesisches Produkt). Da das Komma in BigQuery Legacy-SQL als UNION behandelt wird, sollten Sie den Vorgang explizit machen, um Verwechslungen zu vermeiden.
FROM A JOIN B ON (COALESCE(A.id , 0) = COALESCE(B.id, 0)) FROM A JOIN B ON (COALESCE(A.id , 0) = COALESCE(B.id, 0)) Kein Unterschied bei Skalarfunktionen (konstante Funktionen).
FROM A JOIN B ON A.id = (SELECT MAX(B.id) FROM B) FROM A JOIN (SELECT MAX(B.id) FROM B) B1 ON A.id = B1.id BigQuery verhindert, dass Nutzer Unterabfragen, korrelierte Unterabfragen oder Aggregationen in Join-Prädikaten verwenden. Dadurch kann BigQuery Abfragen parallelisieren.

Typkonvertierung und -umwandlung

BigQuery hat weniger, aber breitere Datentypen als Teradata, wodurch BigQuery beim Umwandeln strenger sein muss.

Teradata BigQuery Hinweise
exp EQ exp2
exp IN (exp2, exp3)
exp = exp2
exp IN (exp2, exp3)

Wenn Sie die Nicht-ANSI-Semantik für NOT CASESPECIFIC beibehalten möchten, verwenden Sie
RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))
Wenn Strings auf Gleichheit verglichen werden, ignoriert Teradata möglicherweise nachgestellte Leerzeichen, während BigQuery sie als Teil des Strings betrachtet. Beispiel: 'xyz'=' xyz' ist in Teradata TRUE, in BigQuery jedoch FALSE.

Teradata bietet auch ein NOT CASESPECIFIC-Spaltenattribut, das Teradata anweist, die Groß- und Kleinschreibung beim Vergleich von zwei Strings zu ignorieren. BigQuery beachtet beim Vergleich von Strings immer Groß- und Kleinschreibung. Beispiel: 'xYz' = 'xyz' ist in Teradata TRUE, in BigQuery jedoch FALSE.
CAST(long_varchar_column AS CHAR(6)) LPAD(long_varchar_column, 6) Die Umwandlung einer Zeichenspalte in Teradata wird manchmal als nicht standardmäßige und nicht optimale Methode zum Erstellen eines aufgefüllten Teilstrings verwendet.
CAST(92617 AS TIME) 92617 (FORMAT '99:99:99') PARSE_TIME("%k%M%S", CAST(92617 AS STRING))
Teradata führt viel mehr implizite Typkonvertierungen und Rundungen durch als BigQuery, das in der Regel strenger ist und ANSI-Standards durchführt.
(In diesem Beispiel wird 09:26:17 zurückgegeben)
CAST(48.5 (FORMAT 'zz') AS FLOAT) CAST(SUBSTR(CAST(48.5 AS STRING), 0, 2) AS FLOAT64)
Für Gleitkomma- und numerische Datentypen können spezielle Rundungsregeln erforderlich sein, wenn sie auf Formate wie Währungen angewendet werden.
(In diesem Beispiel werden 48 zurückgegeben)

Siehe auch Vergleichsoperatoren und Spaltenformate. Sowohl Vergleiche als auch Spaltenformatierungen können sich wie Typumwandlungen verhalten.

Klausel QUALIFY, ROWS

Mit der QUALIFY-Klausel in Teradata können Sie Ergebnisse für Fensterfunktionen filtern. Alternativ kann für dieselbe Aufgabe eine ROWS-Wortgruppe verwendet werden. Diese funktionieren ähnlich wie eine HAVING-Bedingung für eine GROUP-Klausel und schränken die Ausgabe dessen ein, was in BigQuery als aggregierte Fensterfunktionen bezeichnet wird.

Teradata BigQuery
SELECT col1, col2
FROM table
QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;
TeradataQUALIFY Klausel mit einer Fensterfunktion wieROW_NUMBER() ,SUM() ,COUNT() und mitOVER PARTITION BY wird in BigQuery alsWHERE Klausel für eine Unterabfrage, die einen Analysewert enthält.

Verwendung von ROW_NUMBER():

SELECT col1, col2
FROM (
  SELECT col1, col2,
  ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) RN
  FROM table
) WHERE RN = 1;


Verwendung von ARRAY_AGG, das größere Partitionen unterstützt:

SELECT
  result.*
FROM (
  SELECT
    ARRAY_AGG(table ORDER BY table.col2
      DESC LIMIT 1)[OFFSET(0)]
  FROM table
  GROUP BY col1
) AS result;
SELECT col1, col2
FROM table
AVG(col1) OVER (PARTITION BY col1 ORDER BY col2 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW);
SELECT col1, col2
FROM table
AVG(col1) OVER (PARTITION BY col1 ORDER BY col2 RANGE BETWEEN 2 PRECEDING AND CURRENT ROW);


In BigQuery können sowohl RANGE als auch ROWS in der Window Frame-Klausel verwendet werden. Window-Klauseln können jedoch nur mit Fensterfunktionen wie AVG() und nicht mit Nummerierungsfunktionen wie ROW_NUMBER() verwendet werden.

Keyword NORMALIZE

Teradata stellt das Keyword NORMALIZE für SELECT-Klauseln zur Verfügung, um überschneidende Zeiträume oder Intervalle zu einem einzelnen Zeitraum oder Intervall zusammenzufassen, der alle Werte einzelner Zeiträume umfasst.

BigQuery unterstützt den Typ PERIOD nicht. Daher muss jede Spalte des Typs PERIOD in Teradata als zwei separate DATE- oder DATETIME-Felder in BigQuery eingefügt werden, die dem Beginn und dem Ende des Zeitraums entsprechen.

Teradata BigQuery
SELECT NORMALIZE
    client_id,
    item_sid,
    BEGIN(period) AS min_date,
    END(period) AS max_date,
  FROM
    table;
SELECT
  t.client_id,
  t.item_sid,
  t.min_date,
  MAX(t.dwh_valid_to) AS max_date
FROM (
  SELECT
    d1.client_id,
    d1.item_sid,
    d1.dwh_valid_to AS dwh_valid_to,
    MIN(d2.dwh_valid_from) AS min_date
  FROM
    table d1
  LEFT JOIN
    table d2
  ON
    d1.client_id = d2.client_id
    AND d1.item_sid = d2.item_sid
    AND d1.dwh_valid_to >= d2.dwh_valid_from
    AND d1.dwh_valid_from < = d2.dwh_valid_to
  GROUP BY
    d1.client_id,
    d1.item_sid,
    d1.dwh_valid_to ) t
GROUP BY
  t.client_id,
  t.item_sid,
  t.min_date;

Funktionen

In den folgenden Abschnitten werden Zuordnungen zwischen Teradata-Funktionen und BigQuery-Entsprechungen aufgeführt.

Aggregatfunktionen

In der folgenden Tabelle werden gängige Teradata-Aggregatfunktionen, statistische Aggregatfunktionen und ungefähre Aggregatfunktionen ihren BigQuery-Entsprechungen zugeordnet. BigQuery bietet die folgenden zusätzlichen Aggregatfunktionen:

Teradata BigQuery
AVG AVG
BITAND BIT_AND
BITNOT Bitweiser Not-Operator (~)
BITOR BIT_OR
BITXOR BIT_XOR
CORR CORR
COUNT COUNT
COVAR_POP COVAR_POP
COVAR_SAMP COVAR_SAMP
MAX MAX
MIN MIN
REGR_AVGX AVG(
  IF(dep_var_expression is NULL
     OR ind_var_expression is NULL,
     NULL, ind_var_expression)
)
REGR_AVGY AVG(
  IF(dep_var_expression is NULL
     OR ind_var_expression is NULL,
     NULL, dep_var_expression)
)
REGR_COUNT SUM(
  IF(dep_var_expression is NULL
     OR ind_var_expression is NULL,
     NULL, 1)
)
REGR_INTERCEPT AVG(dep_var_expression) - AVG(ind_var_expression) * (COVAR_SAMP(ind_var_expression,
              dep_var_expression)
   / VARIANCE(ind_var_expression))
REGR_R2 (COUNT(dep_var_expression)*
 SUM(ind_var_expression * dep_var_expression) -
 SUM(dep_var_expression) * SUM(ind_var_expression))
SQRT(
     (COUNT(ind_var_expression)*
      SUM(POWER(ind_var_expression, 2))*
      POWER(SUM(ind_var_expression),2))*
     (COUNT(dep_var_expression)*
      SUM(POWER(dep_var_expression, 2))*
      POWER(SUM(dep_var_expression), 2)))
REGR_SLOPE - COVAR_SAMP(ind_var_expression,
            dep_var_expression)
/ VARIANCE(ind_var_expression)
REGR_SXX SUM(POWER(ind_var_expression, 2)) - COUNT(ind_var_expression) *
  POWER(AVG(ind_var_expression),2)
REGR_SXY SUM(ind_var_expression * dep_var_expression) - COUNT(ind_var_expression)
  * AVG(ind_var_expression) * AVG(dep_var_expression)
REGR_SYY SUM(POWER(dep_var_expression, 2)) - COUNT(dep_var_expression)
  * POWER(AVG(dep_var_expression),2)
SKEW Benutzerdefinierte Funktion
STDDEV_POP STDDEV_POP
STDDEV_SAMP STDDEV_SAMP, STDDEV
SUM SUM
VAR_POP VAR_POP
VAR_SAMP VAR_SAMP, VARIANCE

Analysefunktionen und Fensterfunktionen

In der folgenden Tabelle werden gängige Teradata-Analysefunktionen und aggregierte Analysefunktionen ihren BigQuery-Fensterfunktionsäquivalenten zugeordnet. BigQuery bietet die folgenden zusätzlichen Funktionen:

Teradata BigQuery
ARRAY_AGG ARRAY_AGG
ARRAY_CONCAT, (|| operator) ARRAY_CONCAT_AGG, (|| operator)
BITAND BIT_AND
BITNOT Bitweiser Not-Operator (~)
BITOR BIT_OR
BITXOR BIT_XOR
CORR CORR
COUNT COUNT
COVAR_POP COVAR_POP
COVAR_SAMP COVAR_SAMP
CUME_DIST CUME_DIST
DENSE_RANK (ANSI) DENSE_RANK
FIRST_VALUE FIRST_VALUE
LAST_VALUE LAST_VALUE
MAX MAX
MIN MIN
PERCENT_RANK PERCENT_RANK
PERCENTILE_CONT, PERCENTILE_DISC PERCENTILE_CONT, PERCENTILE_DISC
RANK (ANSI) RANK
ROW_NUMBER ROW_NUMBER
STDDEV_POP STDDEV_POP
STDDEV_SAMP STDDEV_SAMP, STDDEV
SUM SUM
VAR_POP VAR_POP
VAR_SAMP VAR_SAMP, VARIANCE

Datums-/Zeitfunktionen

In der folgenden Tabelle werden gängige Teradata-Datums-/Zeitfunktionen ihren BigQuery-Entsprechungen zugeordnet. BigQuery bietet die folgenden zusätzlichen Datums-/Zeitfunktionen:

Teradata BigQuery
ADD_MONTHS DATE_ADD, TIMESTAMP_ADD
CURRENT_DATE CURRENT_DATE
CURRENT_TIME CURRENT_TIME
CURRENT_TIMESTAMP CURRENT_TIMESTAMP
DATE + k DATE_ADD(date_expression, INTERVAL k DAY)
DATE - k DATE_SUB(date_expression, INTERVAL k DAY)
EXTRACT EXTRACT(DATE), EXTRACT(TIMESTAMP)
FORMAT_DATE
FORMAT_DATETIME
FORMAT_TIME
FORMAT_TIMESTAMP
LAST_DAY LAST_DAY Hinweis: Diese Funktion unterstützt die Eingabeausdrücke DATE und DATETIME.
MONTHS_BETWEEN DATE_DIFF(date_expression, date_expression, MONTH)
NEXT_DAY DATE_ADD(
  DATE_TRUNC(
    date_expression,
    WEEK(day_value)
  ),
  INTERVAL 1 WEEK
)
OADD_MONTHS DATE_SUB(
  DATE_TRUNC(
    DATE_ADD(
      date_expression,
      INTERVAL num_months MONTH
    ),
    MONTH
  ),
  INTERVAL 1 DAY
)
td_day_of_month EXTRACT(DAY FROM date_expression)
EXTRACT(DAY FROM timestamp_expression)
td_day_of_week EXTRACT(DAYOFWEEK FROM date_expression)
EXTRACT(DAYOFWEEK FROM timestamp_expression)
td_day_of_year EXTRACT(DAYOFYEAR FROM date_expression)
EXTRACT(DAYOFYEAR FROM timestamp_expression)
td_friday DATE_TRUNC(
  date_expression,
  WEEK(FRIDAY)
)
td_monday DATE_TRUNC(
  date_expression,
  WEEK(MONDAY)
)
td_month_begin DATE_TRUNC(date_expression, MONTH)
td_month_end DATE_SUB(
  DATE_TRUNC(
    DATE_ADD(
      date_expression,
      INTERVAL 1 MONTH
    ),
    MONTH
  ),
  INTERVAL 1 DAY
)
td_month_of_calendar (EXTRACT(YEAR FROM date_expression) - 1900) * 12 + EXTRACT(MONTH FROM date_expression)
td_month_of_quarter EXTRACT(MONTH FROM date_expression)
- ((EXTRACT(QUARTER FROM date_expression) - 1) * 3)
td_month_of_year EXTRACT(MONTH FROM date_expression)
EXTRACT(MONTH FROM timestamp_expression)
td_quarter_begin DATE_TRUNC(date_expression, QUARTER)
td_quarter_end DATE_SUB(
  DATE_TRUNC(
    DATE_ADD(
      date_expression,
      INTERVAL 1 QUARTER
    ),
    QUARTER
  ),
  INTERVAL 1 DAY
)
td_quarter_of_calendar (EXTRACT(YEAR FROM date_expression)
- 1900) * 4
+ EXTRACT(QUARTER FROM date_expression)
td_quarter_of_year EXTRACT(QUARTER FROM date_expression)
EXTRACT(QUARTER FROM timestamp_expression)
td_saturday DATE_TRUNC(
  date_expression,
  WEEK(SATURDAY)
)
td_sunday DATE_TRUNC(
  date_expression,
  WEEK(SUNDAY)
)
td_thursday DATE_TRUNC(
  date_expression,
  WEEK(THURSDAY)
)
td_tuesday DATE_TRUNC(
  date_expression,
  WEEK(TUESDAY)
)
td_wednesday DATE_TRUNC(
  date_expression,
  WEEK(WEDNESDAY)
)
td_week_begin DATE_TRUNC(date_expression, WEEK)
td_week_end DATE_SUB(
  DATE_TRUNC(
    DATE_ADD(
      date_expression,
      INTERVAL 1 WEEK
    ),
    WEEK
  ),
  INTERVAL 1 DAY
)
td_week_of_calendar (EXTRACT(YEAR FROM date_expression) - 1900) * 52 + EXTRACT(WEEK FROM date_expression)
td_week_of_month EXTRACT(WEEK FROM date_expression)
- EXTRACT(WEEK FROM DATE_TRUNC(date_expression, MONTH))
td_week_of_year EXTRACT(WEEK FROM date_expression)
EXTRACT(WEEK FROM timestamp_expression)
td_weekday_of_month CAST(
  CEIL(
    EXTRACT(DAY FROM date_expression)
    / 7
  ) AS INT64
)
td_year_begin DATE_TRUNC(date_expression, YEAR)
td_year_end DATE_SUB(
  DATE_TRUNC(
    DATE_ADD(
      date_expression,
      INTERVAL 1 YEAR
    ),
    YEAR
  ),
  INTERVAL 1 DAY
)
td_year_of_calendar EXTRACT(YEAR FROM date_expression)
TO_DATE PARSE_DATE
TO_TIMESTAMP PARSE_TIMESTAMP
TO_TIMESTAMP_TZ PARSE_TIMESTAMP

Stringfunktionen

In der folgenden Tabelle werden Teradata-Stringfunktionen ihren BigQuery-Entsprechungen zugeordnet. BigQuery bietet die folgenden zusätzlichen Stringfunktionen:

Teradata BigQuery
ASCII TO_CODE_POINTS(string_expression)[OFFSET(0)]
CHAR2HEXINT TO_HEX
CHARACTER LENGTH CHAR_LENGTH
CHARACTER LENGTH CHARACTER_LENGTH
CHR CODE_POINTS_TO_STRING(
  [mod(numeric_expression, 256)]
)
CONCAT, (|| operator) CONCAT, (|| operator)
CSV Benutzerdefinierte Funktion
CSVLD Benutzerdefinierte Funktion
FORMAT FORMAT
INDEX STRPOS(string, substring)
INITCAP INITCAP
INSTR Benutzerdefinierte Funktion
LEFT SUBSTR(source_string, 1, length)
LENGTH LENGTH
LOWER LOWER
LPAD LPAD
LTRIM LTRIM
NGRAM Benutzerdefinierte Funktion
NVP Benutzerdefinierte Funktion
OREPLACE REPLACE
OTRANSLATE Benutzerdefinierte Funktion
POSITION STRPOS(string, substring)
REGEXP_INSTR STRPOS(source_string,
REGEXP_EXTRACT(source_string, regexp_string))


Hinweis: Gibt das erste Vorkommen zurück.
REGEXP_REPLACE REGEXP_REPLACE
REGEXP_SIMILAR IF(REGEXP_CONTAINS,1,0)
REGEXP_SUBSTR REGEXP_EXTRACT,
REGEXP_EXTRACT_ALL
REGEXP_SPLIT_TO_TABLE Benutzerdefinierte Funktion
REVERSE REVERSE
RIGHT SUBSTR(source_string, -1, length)
RPAD RPAD
RTRIM RTRIM
STRTOK

Hinweis: Jedes Zeichen im Argument des Trennzeichenstrings wird als separates Trennzeichen betrachtet. Das Standardtrennzeichen ist ein Leerzeichen.
SPLIT(instring, delimiter)[ORDINAL(tokennum)]

Hinweis: Das gesamte delimiter-Stringargument wird als einzelnes Trennzeichen verwendet. Das Standardtrennzeichen ist ein Komma.
STRTOK_SPLIT_TO_TABLE Benutzerdefinierte Funktion
SUBSTRING, SUBSTR SUBSTR
TRIM TRIM
UPPER UPPER

Mathematische Funktionen:

In der folgenden Tabelle werden die mathematischen Funktionen von Teradata ihren BigQuery-Entsprechungen zugeordnet. BigQuery bietet die folgenden zusätzlichen mathematischen Funktionen:

Teradata BigQuery
ABS ABS
ACOS ACOS
ACOSH ACOSH
ASIN ASIN
ASINH ASINH
ATAN ATAN
ATAN2 ATAN2
ATANH ATANH
CEILING CEIL
CEILING CEILING
COS COS
COSH COSH
EXP EXP
FLOOR FLOOR
GREATEST GREATEST
LEAST LEAST
LN LN
LOG LOG
MOD (%-Operator) MOD
NULLIFZERO NULLIF(expression, 0)
POWER (**-Operator) POWER, POW
RANDOM RAND
ROUND ROUND
SIGN SIGN
SIN SIN
SINH SINH
SQRT SQRT
TAN TAN
TANH TANH
TRUNC TRUNC
ZEROIFNULL IFNULL(expression, 0), COALESCE(expression, 0)

DML-Syntax

In diesem Abschnitt werden Unterschiede in der Syntax der Datenverwaltungssprache zwischen Teradata und BigQuery behandelt.

INSERT-Anweisung

Die meisten Teradata-INSERT-Anweisungen sind mit BigQuery kompatibel. Die folgende Tabelle enthält Ausnahmen.

DML-Skripts in BigQuery haben eine etwas andere Konsistenzsemantik als die entsprechenden Anweisungen in Teradata. Eine Übersicht über die Snapshot-Isolation sowie die Sitzungs- und Transaktionsbehandlung finden Sie im Abschnitt CREATE INDEX an anderer Stelle in diesem Dokument.

Teradata BigQuery
INSERT INTO table VALUES (...); INSERT INTO table (...) VALUES (...);

Teradata bietet das Keyword DEFAULT für Spalten, die keine Nullwerte zulassen.

Hinweis: In BigQuery funktioniert das Weglassen von Spaltennamen in der Anweisung INSERT nur, wenn Werte für alle Spalten in der Zieltabelle auf der Grundlage ihrer ordinalen Positionen in aufsteigender Reihenfolge enthalten sind.
INSERT INTO table VALUES (1,2,3);
INSERT INTO table VALUES (4,5,6);
INSERT INTO table VALUES (7,8,9);
INSERT INTO table VALUES (1,2,3),
                         (4,5,6),
                         (7,8,9);

Teradata verwendet das Konzept der Anfrage mit mehreren Anweisungen, die mehrere INSERT-Anweisungen gleichzeitig sendet. In BigQuery wird dies aufgrund der impliziten Transaktionsgrenze zwischen Anweisungen nicht empfohlen. Verwenden Sie stattdessen INSERT mit mehreren Werten.

BigQuery lässt gleichzeitige INSERT-Anweisungen zu, kann jedoch eine Warteschlange UPDATE enthalten. Ziehen Sie zur Verbesserung der Leistung die folgenden Ansätze in Betracht:
  • Kombinieren Sie mehrere Zeilen in einer einzigen INSERT-Anweisung anstelle einer Zeile pro INSERT-Vorgang.
  • Kombinieren Sie mehrere DML-Anweisungen (einschließlich INSERT) mit einer MERGE-Anweisung.
  • Verwenden Sie CREATE TABLE ... AS SELECT zum Erstellen und Ausfüllen neuer Tabellen anstelle von UPDATE oder DELETE, insbesondere beim Abfragen von partitionierten Feldern oder Rollback oder Wiederherstellung.

UPDATE-Anweisung

Die meisten Teradata UPDATE-Anweisungen sind bis auf die folgenden Elemente mit BigQuery kompatibel:

  • Wenn Sie eine FROM-Klausel verwenden, wird die Reihenfolge der FROM- und SET-Klauseln in Teradata und BigQuery umgekehrt.
  • In GoogleSQL muss jede UPDATE-Anweisung das Keyword WHERE, gefolgt von einer Bedingung, enthalten. Zum Aktualisieren aller Zeilen in der Tabelle verwenden Sie WHERE true.

Als Best Practice sollten Sie mehrere DML-Mutationen statt einzelner UPDATE- und INSERT-Anweisungen gruppieren. DML-Skripts in BigQuery haben eine etwas andere Konsistenzsemantik als entsprechende Anweisungen in Teradata. Eine Übersicht über die Snapshot-Isolation sowie die Sitzungs- und Transaktionsbehandlung finden Sie im Abschnitt CREATE INDEX an anderer Stelle in diesem Dokument.

Die folgende Tabelle zeigt Teradata-UPDATE-Anweisungen und BigQuery-Anweisungen, die dieselben Aufgaben ausführen.

Weitere Informationen zu UPDATE in BigQuery finden Sie in den BigQuery-UPDATE-Beispielen in der DML-Dokumentation.

Teradata BigQuery
UPDATE table_A
FROM table_A, table_B
SET
  y = table_B.y,
  z = table_B.z + 1
WHERE table_A.x = table_B.x
  AND table_A.y IS NULL;
UPDATE table_A
SET
  y = table_B.y,
  z = table_B.z + 1
FROM table_B
WHERE table_A.x = table_B.x
  AND table_A.y IS NULL;
UPDATE table alias
SET x = x + 1
WHERE f(x) IN (0, 1);
UPDATE table
SET x = x + 1
WHERE f(x) IN (0, 1);
UPDATE table_A
FROM table_A, table_B, B
SET z = table_B.z
WHERE table_A.x = table_B.x
  AND table_A.y = table_B.y;
UPDATE table_A
SET z = table_B.z
FROM table_B
WHERE table_A.x = table_B.x
  AND table_A.y = table_B.y;

DELETE- und TRUNCATE-Anweisungen

Sowohl mit der DELETE- als auch mit der TRUNCATE-Anweisung können Zeilen aus einer Tabelle entfernt werden, ohne dass sich dies auf das Tabellenschema oder die Indexe auswirkt. TRUNCATE wird weder in Teradata noch in BigQuery verwendet. Sie können jedoch DELETE-Anweisungen verwenden, um den gleichen Effekt zu erzielen.

In BigQuery muss die DELETE-Anweisung eine WHERE-Klausel enthalten. Verwenden Sie WHERE true, um alle Zeilen in der Tabelle (gekürzt) zu löschen. Um Vorgänge für sehr große Tabellen schneller zu kürzen, empfehlen wir die Verwendung der Anweisung CREATE OR REPLACE TABLE ... AS SELECT, wobei LIMIT 0 für dieselbe Tabelle verwendet wird, um sich selbst zu ersetzen. Achten Sie jedoch darauf, bei der Verwendung manuell Partitionierungs- und Clustering-Informationen hinzuzufügen.

Teradata entfernt gelöschte Zeilen später. Das bedeutet, dass DELETE-Vorgänge anfangs schneller als in BigQuery sind, später aber Ressourcen benötigen, insbesondere umfangreiche DELETE-Vorgänge, die sich auf den Großteil einer Tabelle auswirken. Um einen ähnlichen Ansatz in BigQuery zu verwenden, empfehlen wir, die Anzahl der DELETE-Vorgänge zu reduzieren, z. B. indem die Zeilen, die nicht gelöscht werden sollen, in eine neue Tabelle kopiert werden. Alternativ können Sie ganze Partitionen entfernen. Beide Optionen sind auf schnellere Vorgänge ausgelegt als atomare DML-Mutationen.

Weitere Informationen zu DELETE in BigQuery finden Sie in den DELETE-Beispielen in der DML-Dokumentation.

Teradata BigQuery
BEGIN TRANSACTION;
LOCKING TABLE table_A FOR EXCLUSIVE;
DELETE FROM table_A;
INSERT INTO table_A SELECT * FROM table_B;
END TRANSACTION;
Das Ersetzen des Inhalts einer Tabelle durch die Abfrageausgabe entspricht einer Transaktion. Sie können dazu entweder einen Abfragevorgang oder einen Kopiervorgang verwenden.

Abfragevorgang verwenden:

bq query --replace --destination_table table_A 'SELECT * FROM table_B';

Kopiervorgang verwenden:

bq cp -f table_A table_B
DELETE database.table ALL; DELETE FROM table WHERE TRUE;

Oder für sehr große Tabellen:
CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;

MERGE-Anweisung

Die MERGE-Anweisung kann die Vorgänge INSERT, UPDATE und DELETE in einer einzigen "upsert" -Anweisung kombinieren und die Vorgänge in kleinstmöglichen Schritten ausführen. Der MERGE-Vorgang muss mit maximal einer Quellzeile für jede Zielzeile übereinstimmen. BigQuery und Teradata folgen beide der ANSI-Syntax.

Der MERGE-Vorgang von Teradata ist auf den Abgleich von Primärschlüsseln innerhalb eines Zugriffsmodulprozessors (AMP) beschränkt. Im Gegensatz dazu gibt es in BigQuery keine Größen- oder Spaltenbeschränkung für MERGE-Vorgänge. Daher ist die Verwendung von MERGE eine nützliche Optimierung. Wenn es sich bei MERGE jedoch hauptsächlich um einen großen Löschvorgang handelt, lesen Sie die Optimierungen für DELETE an anderer Stelle in diesem Dokument.

DML-Skripts in BigQuery haben eine etwas andere Konsistenzsemantik als entsprechende Anweisungen in Teradata. Beispielsweise können die SET-Tabellen von Teradata im Sitzungsmodus während eines MERGE-Vorgangs Duplikate ignorieren. Eine Übersicht über die Verarbeitung von MULTISET- und SET-Tabellen, die Snapshot-Isolation sowie die Sitzungs- und Transaktionsbehandlung finden Sie im Abschnitt CREATE INDEX an anderer Stelle in diesem Dokument.

Von "ROWS" betroffene Variablen

In Teradata ist die ACTIVITY_COUNT-Variable eine ANSI-SQL-Erweiterung von Teradata, die mit der Anzahl der von einer DML-Anweisung betroffenen Zeilen gefüllt wird.

Die Systemvariable @@row_count in der Skriptfunktion hat eine ähnliche Funktionalität. In BigQuery ist es üblicher, den Rückgabewert numDmlAffectedRows in den Audit-Logs oder in den Ansichten INFORMATION_SCHEMA zu prüfen.

DDL-Syntax

In diesem Abschnitt werden Unterschiede in der Syntax der Datendefinitionssprache zwischen Teradata und BigQuery behandelt.

CREATE TABLE-Anweisung

Die meisten Teradata-CREATE TABLE-Anweisungen sind mit BigQuery kompatibel, mit Ausnahme der folgenden Syntaxelemente, die in BigQuery nicht verwendet werden:

Weitere Informationen zu CREATE TABLE in BigQuery finden Sie in den BigQuery CREATE-Beispielen in der DML-Dokumentation.

Optionen und Attribute für Spalten

Die folgenden Spaltenspezifikationen für die Anweisung CREATE TABLE werden in BigQuery nicht verwendet:

Teradata erweitert den ANSI-Standard um eine Spaltenoption TITLE. Diese Funktion kann in BigQuery auf ähnliche Weise mithilfe der Spaltenbeschreibung implementiert werden, wie in der folgenden Tabelle dargestellt. Diese Option ist für Ansichten nicht verfügbar.

Teradata BigQuery
CREATE TABLE table (
col1 VARCHAR(30) TITLE 'column desc'
);
CREATE TABLE dataset.table (
  col1 STRING
OPTIONS(description="column desc")
);

Temporäre Tabellen

Teradata unterstützt flüchtige Tabellen, die häufig zum Speichern von Zwischenergebnissen in Skripts verwendet werden. Es gibt mehrere Möglichkeiten, flüchtige Tabellen in BigQuery zu erstellen:

  • CREATE TEMPORARY TABLE kann in Skripts verwendet werden und ist während der Laufzeit des Skripts gültig. Wenn die Tabelle über ein Skript hinaus vorhanden sein muss, können Sie die anderen Optionen in dieser Liste verwenden.

  • Dataset-TTL: Erstellen Sie ein Dataset mit einer kurzen Lebensdauer (z. B. 1 Stunde), damit alle im Dataset erstellten Tabellen praktisch temporär sind, da sie nicht länger als die Lebensdauer des Datasets beibehalten werden. Sie können allen Tabellennamen in diesem Dataset temp voranstellen, um deutlich zu machen, dass die Tabellen temporär sind.

  • Tabellen-TTL: Erstellen Sie eine Tabelle mit einer tabellenspezifischen Kurzlebigkeitsdauer mithilfe von DDL-Anweisungen wie der folgenden:

    CREATE TABLE temp.name (col1, col2, ...)
    OPTIONS(expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
    
  • WITH-Klausel: Wenn eine temporäre Tabelle nur im selben Block benötigt wird, verwenden Sie ein temporäres Ergebnis mithilfe einer WITH-Anweisung oder -Unterabfrage. Dies ist die effizienteste Option.

Ein in Teradata-Skripts (BTEQ) häufig verwendetes Muster besteht darin, eine permanente Tabelle zu erstellen, einen Wert einzufügen, diesen wie eine temporäre Tabelle in laufenden Anweisungen zu verwenden und die Tabelle anschließend zu löschen oder zu kürzen. In diesem Fall wird die Tabelle als konstante Variable (Semaphore) verwendet. Dieser Ansatz ist in BigQuery nicht effizient. Wir empfehlen, stattdessen echte Variablen in der Skripterstellung oder CREATE OR REPLACE mit der AS SELECT-Abfragesyntax zu verwenden, um eine Tabelle zu erstellen, die bereits Werte enthält.

CREATE VIEW-Anweisung

Die folgende Tabelle zeigt Entsprechungen zwischen Teradata und BigQuery für die Anweisung CREATE VIEW. Die Klauseln für die Tabellensperre wie LOCKING ROW FOR ACCESS werden in BigQuery nicht benötigt.

Teradata BigQuery Hinweise
CREATE VIEW view_name AS SELECT ... CREATE VIEW view_name AS SELECT ...
REPLACE VIEW view_name AS SELECT ... CREATE OR REPLACE VIEW
view_name AS
SELECT ...
Nicht unterstützt CREATE VIEW IF NOT EXISTS
OPTIONS(view_option_list)
AS SELECT ...
Erstellt nur dann eine neue Ansicht, wenn die Ansicht derzeit im angegebenen Dataset nicht vorhanden ist.

CREATE [UNIQUE] INDEX-Anweisung

Teradata erfordert Indexe für alle Tabellen und spezielle Problemumgehungen wie MULTISET-Tabellen und NoPI-Tabellen, um mit nicht eindeutigen oder nicht indexierten Daten zu arbeiten.

BigQuery erfordert keine Indexe. In diesem Abschnitt werden Ansätze in BigQuery beschrieben, die das Erstellen von Funktionen ermöglichen, ähnlich wie Indexe in Teradata verwendet werden, wenn es eine echte Geschäftslogik gibt.

Indexierung aus Gründen der Leistung

Da es sich um eine spaltenorientierte Datenbank mit Abfrage- und Speicheroptimierung handelt, benötigt BigQuery keine expliziten Indexe. BigQuery bietet Funktionen wie Partitionierung und Clustering sowie verschachtelte Felder, die durch Optimierung der Datenspeicherung die Effizienz und Leistung von Abfragen erhöhen können.

Teradata unterstützt keine materialisierten Ansichten. Es bietet jedoch Join-Indexe mit der CREATE JOIN INDEX-Anweisung, die im Wesentlichen Daten materialisiert, die für ein Join benötigt werden. BigQuery benötigt keine materialisierten Indexe, um die Leistung zu beschleunigen, und auch keinen dedizierten Spool-Bereich für Joins.

Für andere Optimierungsfälle können materialisierte Ansichten verwendet werden.

Indexierung aus Konsistenzgründen (UNIQUE, PRIMARY INDEX)

In Teradata kann ein eindeutiger Index verwendet werden, um Zeilen mit nicht eindeutigen Schlüsseln in einer Tabelle zu verhindern. Wenn ein Prozess versucht, Daten mit einem Wert einzufügen oder zu aktualisieren, der bereits im Index enthalten ist, schlägt der Vorgang entweder mit einem Indexverstoß fehl (MULTISET-Tabellen) oder ignoriert ihn (SET-Tabellen).

Da BigQuery keine expliziten Indexe bereitstellt, kann stattdessen eine MERGE-Anweisung verwendet werden, um nur eindeutige Einträge aus einer Staging-Tabelle in eine Zieltabelle einzufügen, während doppelte Einträge verworfen werden. Es gibt jedoch keine Möglichkeit, zu verhindern, dass ein Nutzer mit Bearbeitungsberechtigungen einen doppelten Eintrag einfügt, da BigQuery während INSERT-Vorgängen niemals gesperrt wird. Zum Generieren eines Fehlers für doppelte Einträge in BigQuery können Sie eine MERGE-Anweisung aus einer Staging-Tabelle verwenden, wie im folgenden Beispiel gezeigt.

Teradata BigQuery
CREATE [UNIQUE] INDEX name; MERGE `prototype.FIN_MERGE` t
USING `prototype.FIN_TEMP_IMPORT` m
ON t.col1 = m.col1
  AND t.col2 = m.col2
WHEN MATCHED THEN
  UPDATE SET t.col1 = ERROR(CONCAT('Encountered error for ', m.col1, ' ', m.col2))
WHEN NOT MATCHED THEN
  INSERT (col1,col2,col3,col4,col5,col6,col7,col8) VALUES(col1,col2,col3,col4,col5,col6,CURRENT_TIMESTAMP(),CURRENT_TIMESTAMP());

Häufiger ziehen es Nutzer vor, Duplikate unabhängig zu entfernen, um Fehler in nachgelagerten Systemen zu finden.
BigQuery unterstützt die Spalten DEFAULT und IDENTITY (Sequenzen) nicht.

Indexierung, um eine Sperre zu erreichen

Teradata stellt Ressourcen im Zugriffsmodulprozessor (AMP) bereit. Abfragen können All-AMP-, Single-AMP- oder Gruppen-AMP-Ressourcen verbrauchen. DDL-Anweisungen sind vollständig AMP-ähnlich und ähneln daher einer globalen DDL-Sperre. BigQuery hat keinen solchen Sperrmechanismus und kann gleichzeitig Abfragen und INSERT-Anweisungen bis zu Ihrem Kontingent ausführen. Nur gleichzeitige UPDATE-DML-Anweisungen haben bestimmte Auswirkungen auf die Gleichzeitigkeit: UPDATE-Vorgänge für dieselbe Partition werden in die Warteschlange gestellt, um die Snapshot-Isolation zu gewährleisten. Sie müssen also nicht sperren, um fiktive Lesevorgänge oder verlorene Aktualisierungen zu verhindern.

Aufgrund dieser Unterschiede werden die folgenden Teradata-Elemente in BigQuery nicht verwendet:

  • ON COMMIT DELETE ROWS;
  • ON COMMIT PRESERVE ROWS;

Prozedurale SQL-Anweisungen

In diesem Abschnitt wird beschrieben, wie Sie prozedurale SQL-Anweisungen, die in gespeicherten Verfahren, Funktionen und Triggern verwendet werden, von Teradata in BigQuery-Skripts, Verfahren oder benutzerdefinierte Funktionen (UDFs) konvertieren. All dies können Systemadministratoren in der Ansicht INFORMATION_SCHEMA prüfen.

CREATE PROCEDURE-Anweisung

Gespeicherte Verfahren werden im Rahmen der Skripterstellung von BigQuery unterstützt.

In BigQuery bezieht sich die Skripterstellung auf die Verwendung von Kontrollanweisungen, während Verfahren benannte Skripts sind (bei Bedarf mit Argumenten), die von anderen Skripts aufgerufen und bei Bedarf dauerhaft gespeichert werden können. Eine benutzerdefinierte Funktion (UDF) kann auch in JavaScript geschrieben werden.

Teradata BigQuery
CREATE PROCEDURE CREATE PROCEDURE, wenn ein Name erforderlich ist, verwenden Sie andernfalls inline mit BEGIN oder in einer einzigen Zeile mit CREATE TEMP FUNCTION.
REPLACE PROCEDURE CREATE OR REPLACE PROCEDURE
CALL CALL

In den folgenden Abschnitten wird beschrieben, wie vorhandene prozedurale Teradata-Anweisungen in BigQuery-Skript-Anweisungen mit ähnlicher Funktionalität konvertiert werden.

Variablendeklaration und -zuweisung

BigQuery-Variablen sind während der Lebensdauer des Skripts gültig.

Teradata BigQuery
DECLARE DECLARE
SET SET

Fehlerbedingungs-Handler

Teradata verwendet Handler für Statuscodes in Verfahren zur Fehlerkontrolle. In BigQuery ist die Fehlerbehandlung eine Kernfunktion des Hauptsteuerungsablaufs, ähnlich wie in anderen Sprachen mit TRY ... CATCH-Blöcken.

Teradata BigQuery
DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ... EXCEPTION WHEN ERROR THEN
SIGNAL sqlstate RAISE message
DECLARE CONTINUE HANDLER FOR SQLSTATE VALUE 23505; Ausnahme-Handler, die für bestimmte Fehlerbedingungen ausgelöst werden, werden von BigQuery nicht verwendet.

Wir empfehlen die Verwendung von ASSERT-Anweisungen, bei denen Exit-Bedingungen für Vorabprüfungen oder Debugging verwendet werden, da dies ANSI SQL:2011-konform ist.

Die Variable SQLSTATE in Teradata ähnelt der Systemvariablen @@error in BigQuery. In BigQuery werden Fehler häufiger mit dem Audit-Logging oder der Ansicht INFORMATION_SCHEMA untersucht.

Cursor-Deklarationen und -Vorgänge

Da BigQuery keine Cursor oder Sitzungen unterstützt, werden die folgenden Anweisungen in BigQuery nicht verwendet:

Dynamische SQL-Anweisungen

Die Skriptfunktion in BigQuery unterstützt dynamische SQL-Anweisungen, die in der folgenden Tabelle dargestellt sind.

Teradata BigQuery
EXECUTE IMMEDIATE sql_str; EXECUTE IMMEDIATE sql_str;
EXECUTE stmt_id [USING var,...]; EXECUTE IMMEDIATE stmt_id USING var;

Die folgenden dynamischen SQL-Anweisungen werden in BigQuery nicht verwendet:

Anweisungen zum Kontrollfluss

Die Skriptfunktion in BigQuery unterstützt Ablaufsteuerungsanweisungen, wie sie in der folgenden Tabelle dargestellt sind.

Teradata BigQuery
IF condition THEN stmts ELSE stmts END IF IF condition THEN stmts ELSE stmts END IF
label_name: LOOP stmts END LOOP label_name; Blockkonstruktionen im GOTO-Stil werden in BigQuery nicht verwendet.

Wir empfehlen, sie als benutzerdefinierte Funktionen (UDFs) umzuschreiben oder ASSERT-Anweisungen zu verwenden, bei denen sie für die Fehlerbehandlung verwendet werden.
REPEAT stmts UNTIL condition END REPEAT; WHILE condition DO stmts END WHILE
LEAVE outer_proc_label; LEAVE wird nicht für GOTO-Blöcke verwendet. Es wird als Synonym für BREAK verwendet, um eine WHILE-Schleife zu verlassen.
LEAVE label; LEAVE wird nicht für GOTO-Blöcke verwendet. Es wird als Synonym für BREAK verwendet, um eine WHILE-Schleife zu verlassen.
WITH RECURSIVE temp_table AS ( ... ); Rekursive Abfragen, die auch als rekursive allgemeine Tabellenausdrücke (common table expressions, CTE) bezeichent werden, werden in BigQuery nicht verwendet. Sie können mit Arrays von UNION ALL umschrieben werden.

Die folgenden Anweisungen zum Kontrollfluss werden in BigQuery nicht verwendet, da BigQuery keine Cursor oder Sitzungen verwendet:

Metadaten- und Transaktions-SQL-Anweisungen

Teradata BigQuery
HELP TABLE table_name;
HELP VIEW view_name;
SELECT
 * EXCEPT(is_generated, generation_expression, is_stored, is_updatable)
FROM
 mydataset.INFORMATION_SCHEMA.COLUMNS;
WHERE
 table_name=table_name


Die gleiche Abfrage ist gültig, um Spalteninformationen für Ansichten abzurufen.
Weitere Informationen finden Sie in der Spaltenansicht in BigQuery INFORMATION_SCHEMA.
SELECT * FROM dbc.tables WHERE tablekind = 'T';

(Teradata-DBC-Ansicht)
SELECT
 * EXCEPT(is_typed)
FROM
mydataset.INFORMATION_SCHEMA.TABLES;


Weitere Informationen finden Sie unter Einführung in BigQuery INFORMATION_SCHEMA.
HELP STATISTICS table_name; APPROX_COUNT_DISTINCT(col)
COLLECT STATS USING SAMPLE ON table_name column (...); Wird in BigQuery nicht verwendet.
LOCKING TABLE table_name FOR EXCLUSIVE; BigQuery verwendet immer die Snapshot-Isolation. Weitere Informationen finden Sie an anderer Stelle in diesem Dokument unter Konsistenzgarantien.
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ... BigQuery verwendet immer die Snapshot-Isolation. Weitere Informationen finden Sie an anderer Stelle in diesem Dokument unter Konsistenzgarantien.
BEGIN TRANSACTION;
SELECT ...
END TRANSACTION;
BigQuery verwendet immer die Snapshot-Isolation. Weitere Informationen finden Sie an anderer Stelle in diesem Dokument unter Konsistenzgarantien.
EXPLAIN ... Wird in BigQuery nicht verwendet.

Ähnliche Funktionen sind die Erläuterung des Abfrageplans in der BigQuery-Web-UI und die in den INFORMATION_SCHEMA-Ansichten sowie im Audit-Logging in Cloud Monitoring sichtbare Slot-Zuweisung.

Mehrfachanweisungen und mehrzeilige SQL-Anweisungen

Sowohl Teradata als auch BigQuery unterstützen Transaktionen (Sitzungen) und unterstützen daher durch Semikolons getrennte Anweisungen, die konsistent zusammen ausgeführt werden. Weitere Informationen finden Sie unter Transaktionen mit mehreren Anweisungen.

Fehlercodes und -meldungen

Teradata-Fehlercodes und BigQuery-Fehlercodes sind unterschiedlich. Bei der Bereitstellung einer REST API stützt sich BigQuery hauptsächlich auf HTTP-Statuscodes sowie detaillierte Fehlermeldungen.

Wenn Ihre Anwendungslogik derzeit die folgenden Fehler erkennt, versuchen Sie, die Fehlerquelle zu beheben, da BigQuery nicht die gleichen Fehlercodes zurückgibt.

  • SQLSTATE = '02000' — "Zeile nicht gefunden"
  • SQLSTATE = '21000' — "Kardinalitätsverstoß (Unique Index)"
  • SQLSTATE = '22000' — "Datenverstoß (Datentyp)"
  • SQLSTATE = '23000' — "Verstoß gegen die Beschränkung"

In BigQuery ist es üblicher, die INFORMATION_SCHEMA-Ansichten oder das Audit-Logging zur Aufschlüsselung von Fehlern zu verwenden.

Informationen zum Umgang mit Fehlern in der Skripterstellung finden Sie in den folgenden Abschnitten.

Konsistenzgarantien und Transaktionsisolation

Sowohl Teradata als auch BigQuery sind unteilbar, d. h. ACID-konform auf Mutationsebene über viele Zeilen hinweg. Zum Beispiel ist ein MERGE-Vorgang vollständig unteilbar, auch wenn mehrere eingefügte und aktualisierte Werte vorhanden sind.

Transaktionen

Teradata bietet beim Ausführen im Sitzungsmodus (nicht im automatischen Commit-Modus) entweder die Isolationsebene "Read Uncommitted" (Lesen ohne Commit – schmutzige Lesevorgänge möglich) oder serialisierbare Transaktionen. Im besten Fall erreicht Teradata eine strikt serialisierbare Isolation durch eine pessimistische Sperrung eines Zeilen-Hash in allen Spalten von Zeilen in allen Partitionen. Deadlocks sind möglich. DDL erzwingt immer eine Transaktionsgrenze. Teradata Fastload-Jobs werden unabhängig, aber nur für leere Tabellen ausgeführt.

BigQuery unterstützt auch Transaktionen. BigQuery sorgt mit der Snapshot-Isolation für eine optimistische Gleichzeitigkeitserkennung (der erste Commit erhält Vorrang), bei der eine Abfrage die letzten übergebenen Daten liest, bevor die Abfrage beginnt. Dieser Ansatz garantiert die gleiche Konsistenz auf Zeilen- und Mutationsbasis sowie zeilenübergreifend innerhalb derselben DML-Anweisung, vermeidet dabei jedoch Deadlocks. Bei mehreren UPDATE-Anweisungen für dieselbe Tabelle wechselt BigQuery zu pessimistischer Gleichzeitigkeitserkennung und stellt mehrfache UPDATE-Anweisungen in die Warteschlange. Bei Konflikten werden die Anweisungen automatisch wiederholt. INSERT-DML-Anweisungen und Ladejobs können gleichzeitig und unabhängig ausgeführt werden, um Daten an Tabellen anzuhängen.

Rollback

Teradata unterstützt je nach gewünschtem Rollback-Modus zwei Sitzungs-Rollback-Modi, den ANSI-Sitzungsmodus und den Teradata-Sitzungsmodus (SET SESSION CHARACTERISTICS und SET SESSION TRANSACTION). Bei Fehlern wird für die Transaktion möglicherweise kein Rollback durchgeführt.

BigQuery unterstützt die Anweisung ROLLBACK TRANSACTION. In BigQuery gibt es keine ABORT-Anweisung.

Datenbanklimits

Die aktuellen Kontingente und Limits finden Sie immer in der öffentlichen BigQuery-Dokumentation . Viele Kontingente für Nutzer mit hohem Datenvolumen können durch Kontaktaufnahme mit dem Cloud-Supportteam erhöht werden. Die folgende Tabelle zeigt einen Vergleich der Teradata- und BigQuery-Datenbanklimits.

Limit Teradata BigQuery
Tabellen pro Datenbank Uneingeschränkt Uneingeschränkt
Spalten pro Tabelle 2.048 10.000
Maximale Zeilengröße 1 MB 100 MB
Länge des Spalten- und Tabellennamens 128 Unicode-Zeichen 16.384 Unicode-Zeichen
Zeilen pro Tabelle Unbegrenzt Unbegrenzt
Maximale Länge von SQL-Anfragen 1 MB 1 MB (maximale Länge ungelöster GoogleSQL-Abfragen)
12 MB (maximale Länge der gelösten Legacy- und GoogleSQL-Abfragen)

Streaming:
    .
  • 10 MB (Größenbeschränkung für HTTP-Anfragen)
  • 10.000 (maximale Zeilen pro Anfrage)
Maximale Anfrage- und Antwortgröße 7 MB (Anfrage), 16 MB (Antwort) 10 MB (Anfrage) und 10 GB (Antwort) oder praktisch unbegrenzt, wenn Sie den Seitenumbruch oder die Cloud Storage API verwenden.
Maximale Anzahl gleichzeitiger Sitzungen 120 pro Parsing-Engine (PE) 100 gleichzeitige Abfragen (kann mit einer Slot-Reservierung erhöht werden), 300 gleichzeitige API-Anfragen pro Nutzer
Maximale Anzahl gleichzeitiger (schneller) Ladevorgänge 30 (Standardeinstellung 5) Keine Beschränkung der Gleichzeitigkeit; Jobs werden in die Warteschlange gestellt. 100.000 Ladejobs pro Projekt und Tag.