Dans un environnement d'entreprise où différentes technologies de bases de données coexistent, l'intégration de ressources devient un enjeu majeur. Cet article présente les considérations essentielles lors de la migration de tables depuis ClickHouse et Doris vers StarRocks, en se concentrant spécifiquement sur les aspects de création de tables.

Migration de Tables ClickHouse vers StarRocks

Problèmes liés aux types de données

1. Le type VARCHAR nécessite une spécification de longueur ; par défaut, celle-ci est de 1, ce qui entraîne des données vides lors de l'importation.
2. Voici la correspondance entre les types de données ClickHouse et StarRocks : ``` { 'Date': 'DATE', 'Nullable(Date)': 'DATE NULL', 'DateTime': 'DATETIME', 'Nullable(DateTime)': 'DATETIME NULL', 'Float64': 'FLOAT', 'Float32': 'FLOAT', 'Nullable(Float32)': 'FLOAT NULL', 'Nullable(Float64)': 'FLOAT NULL', 'Int32': 'INT', 'UInt32': 'INT', 'UInt16': 'INT', 'Int64': 'INT', 'Nullable(Int32)': 'INT NULL', 'Nullable(Int8)': 'INT NULL', 'Nullable(UInt32)': 'INT NULL', 'Nullable(Int64)': 'INT NULL', 'String': 'varchar(65535)', 'Nullable(String)': 'varchar(65535) NULL' }

Phase d'exportation des données

1. La décompsoition de grands fichiers par la commande SELECT * FROM table_nom LIMIT num OFFSET offset_num peut générer des données dupliquées si aucun tri n'est spécifié. Pour éviter ce problème, il convient de trier les données selon un champ spécifique avant de les partitionner. Cette approche nécessite une connaissance préalable de la structure de la table, notamment des clés primaires.
2. Lors de l'exportation de fichiers Parquet via clickhouse-client, les types date/heure sont convertis en timestamps si une conversion explicite CAST(champ AS datetime) n'est pas effectuée.

Migration de Tables Doris vers StarRocks

Problèmes liés aux propriétés (properties)

Le principal problème lors de la migration de DDL Doris vers StarRocks concerne l'adaptation des propriétés. Les types de champs sont généralement compatibles et ne nécessitent pas de modification.

Propriétés non supportées (à supprimer directement) :

"is_being_synced" = "false",
"disable_auto_compaction" = "false",
"enable_single_replica_compaction" = "false",
"light_schema_change" = "true",
"dynamic_partition.create_history_partition" = "false",
"dynamic_partition.storage_medium" = "HDD",
"dynamic_partition.storage_policy" = "",
"dynamic_partition.hot_partition_num" = "0",
"dynamic_partition.reserved_history_periods" = "NULL",
"enable_mow_light_delete" = "false",
"light_schema_change" = "true"

Propriétés à modifier :

"replication_allocation" = "tag.location.default: 3"     				→ "replication_num" = "3",
"dynamic_partition.replication_allocation" = "tag.location.default: 3"  → "dynamic_partition.replication_num" = "3" 
"dynamic_partition.history_partition_num" = "1200"                      → À supprimer (StarRocks limite à 500 partitions dynamiques par défaut)

Configuration des partitions :

• Les détails de partitionnement après PARTITION BY RANGE(champ) doivent être supprimés mais la parenthèse doit être conservée : PARTITION BY RANGE(champ)()
• La propriété "dynamic_partition.start" = "-2147483648" doit être supprimée

Problèmes de configuration du partitionnement

• Paramètres de bucketing : DISTRIBUTED BY HASH(champ) BUCKETS AUTO n'est pas supporté dans StarRocks. Il faut spécifier un nombre exact : DISTRIBUTED BY HASH(champ) BUCKETS 10
• Paramètres d'index : Le type d'index INDEX idx_champ (champ) USING INVERTED n'est pas supporté. Il doit être modifié en : INDEX idx_champ (champ) USING BITMAP

Programme Python de résolution des problèmes

Un script Python peut être développé pour automatiser ces transformations de DDL lors de la migration, en appliquant les règles de conversion décrites précédemment.