Zarządzanie typami danych
Zmiana typu danych lub rozmiaru typu danych kolumny może mieć wpływ na zadania korzystające z zestawu danych.
Obsługiwane typy danych i konwersje różnią się w zależności od platformy docelowej. Dokumentację dla platformy docelowej zawiera temat Konfigurowanie połączeń z miejscami docelowymi.
Omówienie wpływu zmiany typu danych
Istnieją dwa typowe uzasadnienia zmiany rozmiaru typu danych lub przełączenia na inny typ danych:
- Pozyskiwanie danych, które nie mieszczą się w bieżącym typie danych.
- Wymóg większej dokładności liczbowej. Na przykład zmiana SMALLINT na DECIMAL (p,s).
W większości przypadków zmiana typu danych spowoduje operację ALTER TABLE, zapobiegając w ten sposób utracie danych. Na przykład, jeśli poprzedni typ danych to STRING (25), a nowy typ danych to STRING (50), dane w kolumnie z nowym typem danych zostaną zaktualizowane bez żadnego problemu. Jednak w niektórych przypadkach zmiana typu danych spowoduje usunięcie tabeli i jej ponowne utworzenie. Na przykład, jeśli typ danych poprzedniej kolumny to NUMBER i zmienisz go na DATE, tabela zostanie usunięta i utworzona od nowa, ponieważ konwersja liczb na daty nie jest możliwa. Podobnie, jeśli platforma docelowa nie obsługuje operacji ALTER TABLE (np. Databricks), tabela zostanie usunięta i utworzona na nowo.
W niektórych przypadkach teoretycznie możliwa jest modyfikacja tabeli, ale ze względu na złożoność zadania danych zostanie ona usunięta i ponownie utworzona. Wreszcie istnieją przypadki, w których potencjalna, a nie faktyczna utrata danych, spowoduje operację usunięcia i odtworzenia. Jeżeli na przykład zmienisz STRING(25) na STRING(1), nastąpi utrata danych, jeśli pobrane dane nie będą się mieścić w STRING(1). STRING(25) może jednak zawsze zawierać tylko jeden znak, więc w praktyce nie nastąpi utrata danych, ale tabela i tak zostanie usunięta i utworzona na nowo ze względu na potencjalną utratę danych.
Zmiany w typach danych wymagające usunięcia i ponownego utworzenia tabeli, niezależnie od platformy docelowej
Zmiana następujących typów danych spowoduje usunięcie i ponowne utworzenie tabeli:
- BYTES
- BLOB
- CLOB
- NCLOB
Platformy docelowe obsługujące zmiany rozmiaru typu danych bez usuwania i ponownego tworzenia tabeli
Pracując ze Snowflake, Google BigQuery, Amazon Redshift, Microsoft SQL Server i Azure Synapse Analytics, możesz zmienić rozmiar niektórych typów danych bez usuwania i ponownego tworzenia tabeli. W poniższej tabeli przedstawiono listę obsługiwanych typów danych dla wszystkich wymienionych powyżej platform.
| Typ danych | Snowflake | Google BigQuery | Azure Synapse Analytics | Microsoft SQL Server | Amazon Redshift |
|---|---|---|---|---|---|
|
INT1 |
Nie |
Tak |
Tak |
Tak |
Nie |
|
INT2 |
Nie |
Tak |
Tak |
Tak |
Nie |
|
INT4 |
Nie |
Tak |
Tak |
Tak |
Nie |
|
INT8 |
Nie |
Tak |
Tak |
Tak |
Nie |
|
REAL4 |
Nie |
Nie |
Tak |
Tak |
Nie |
|
REAL8 |
Nie |
Nie |
Tak |
Tak |
Nie |
|
UINT1 |
Nie |
Tak |
Tak |
Tak |
Nie |
|
UINT2 |
Nie |
Tak |
Tak |
Tak |
Nie |
|
UNIT4 |
Nie |
Tak |
Tak |
Tak |
Nie |
|
UNIT8 |
Nie |
Tak |
Tak |
Tak |
Nie |
|
NUMERIC |
Tak |
Tak |
Tak |
Tak |
Nie |
|
STRING |
Tak |
Tak |
Tak |
Tak |
Tak |
|
WSTRING |
Nie |
Tak |
Tak |
Tak |
Nie |
Platformy docelowe obsługujące zmiany typu danych na STRING bez usuwania i ponownego tworzenia tabeli
Podczas przenoszenia danych na platformy Microsoft SQL Server i Azure Synapse Analytics możesz zmienić następujące typy danych na STRING bez usuwania i ponownego tworzenia tabeli:
- BOOLEAN
- DATE
- TIME
- DATETIME
- INT1
- INT2
- INT4
- INT8
- REAL4
- REAL8
- UINT1
- UINT2
- UNIT4
- UNIT8
- NUMERIC
- WSTRING (obsługiwane tylko w przypadku Azure Synapse Analytics)
Zarządzanie danymi JSON
Firma Qlik wprowadziła obsługę typu danych JSON w 2025 roku. Obsługa typu danych JSON nie jest dostępna w zadaniach utworzonych przed jej wprowadzeniem. W nowych zadaniach kolumny z danymi JSON zostaną przekonwertowane na typ danych określony dla platformy docelowej. Brama Data Movement gateway w wersji 2024.11.78 lub nowszej jest wymagana do wykrywania typu danych JSON w zadaniach umieszczania, jeśli używana jest brama Client-Managed.
Podczas konwersji danych JSON mogą zostać utworzone nowe globalne reguły transformacji.
-
QLIK__PARSE_TO_JSON
Ta reguła jest tworzona w projektach Snowflake, w których umieszczanie polega na ładowaniu danych do umieszczania w jeziorze danych. Reguła jest dodawana w zadaniu pamięci masowej po umieszczaniu, aby sparsować wszystkie kolumny JSON do JSON w Snowflake.
-
QLIK__JSON_AS_VARCHAR
Ta reguła jest tworzona w projektach Snowflake, w których dane są umieszczane w Snowflake, a pamięć masowa tworzy tabele Iceberg zarządzane przez Snowflake. Reguła konwertuje JSON na Varchar, ponieważ Iceberg nie obsługuje typu Variant.
Zarządzanie istniejącymi danymi JSON w zadaniach utworzonych przed wprowadzeniem obsługi typów danych JSON
-
Jeśli masz istniejące zadania z danymi JSON, VARIANT lub SUPER na platformie danych przekonwertowanymi na inny typ danych, na przykład BLOB, możesz rozważyć konwersję kolumn na typ danych używany dla JSON na platformie docelowej. Można to zrobić za pomocą reguły transformacji. Może to być wymagane w przypadku konieczności użycia nowych kolumn wraz z istniejącymi kolumnami w zadaniach podrzędnych.
-
Inną opcją jest przekonwertowanie kolumn w nowym zadaniu na ten sam typ danych używany w istniejących typach danych w celu zachowania kompatybilności wstecznej.