Pratiquer data lake iceberg La leçon 36 est basée sur l'architecture d'intégration flux-batch data lake icerberg --update mysql select from icberg syntax est un test de mise à jour incrémentielle

Répertoire des articles de la série

Pratiquer Data Lake iceberg Leçon 1 Mise en route
Pratiquer Data Lake iceberg Leçon 2 Iceberg est basé sur le format de données sous-jacent de hadoop
Pratiquer data lake
iceberg Dans sqlclient, utiliser SQL pour lire des données de Kafka à iceberg (mettre à niveau la version vers flink1.12.7)
pratiquer data lake iceberg Leçon 5 caractéristiques du catalogue de la ruche
pratiquer les données lac iceberg Leçon 6 écrire de kafka à l'échec de l'iceberg résolution de problèmes
pratiquer les données lac iceberg Leçon 7 écrire sur l'iceberg
pratiquer les données lac iceberg en temps réel Leçon 8 intégration de la ruche et de l'iceberg
pratiquer les données lac iceberg Leçon 9 fusionner petit fichiers
pratique data lake iceberg Leçon 10 snapshot delete
pratique data lake iceberg Leçon 11 tester l'intégrité de la table de partition Processus (création de nombres, création de tables, fusion et suppression d'instantanés)
Pratique data lake iceberg Leçon 12 Qu'est-ce qu'un catalogue
Pratique data lake iceberg Leçon 13 Métadonnées est plusieurs fois plus volumineux que les fichiers de données Pratiquez l'iceberg du
lac de données Leçon 14 Fusion de données (pour résoudre le problème de l'expansion des métadonnées au fil du temps) reconnaissance de l'iceberg grâce à la porte spark3


Entraînez-vous à l'iceberg du lac de données Leçon 17 Hadoop2.7, spark3 sur la configuration de l'iceberg de la course de fils Entraînez-vous à l'
iceberg du lac de données Leçon 18 Plusieurs clients interagissent avec les commandes de démarrage de l'iceberg (commandes couramment utilisées) Entraînez-vous à l'
iceberg du lac de données Leçon 19 iceberg de nombre de clignotements , aucun problème de résultat
pratiquez le lac de données iceberg Leçon 20 flink + iceberg Scénario CDC (problème de version, test échoué)
pratique data lake iceberg Leçon 21 flink1.13.5 + iceberg0.131 CDC (test réussi INSERT, opération de modification échouée)
Practice data lake iceberg Leçon 22 flink1.13.5 + iceberg0. 131 CDC (test CRUD réussi)
données de pratique lac iceberg Leçon 23 redémarrage de flink-sql
données de pratique lac iceberg à partir du point de contrôle Leçon 24 détails des métadonnées de l'iceberg Analyse
de la pratique données lac iceberg Leçon 25 Exécution de flink sql en arrière-plan L'effet de l'ajout, de la suppression et de la modification
Entraînez-vous à l'iceberg du lac de données Leçon 26 Méthode de configuration des points de contrôle Entraînez-vous à l'iceberg du lac de données Leçon 27 Redémarrage du
programme de test Flink cdc: peut redémarrer à partir du dernier point de contrôle pour continuer à travailler
entrepôt
pratique data lake iceberg Leçon 29 comment obtenir flink jobId élégamment et efficacement
pratiquer data lake iceberg leçon 30 mysql -> iceberg, différents clients ont parfois des problèmes de zone
Pratiquer le lac de données iceberg Leçon 31 utiliser l'outil flink-streaming-platform-web de github pour gérer le flux de tâches flink, tester le scénario de redémarrage cdc pratiquer le lac de données iceberg leçon 32 Déclaration DDL pratiquer le lac de données
via la méthode de persistance du catalogue de ruche pratique data lake iceberg La leçon 34 est basée sur l'architecture intégrée stream-batch de data lake iceberg test d'architecture stream data lake iceberg La leçon 35 est basée sur l'architecture intégrée stream-batch de data lake icerberg - testez si la lecture incrémentielle est complet ou seulement pratique incrémentielle data lake iceberg La leçon 36 est basée sur l'architecture intégrée flux-batch de data lake icerberg - mettre à jour mysql sélectionner à partir de la syntaxe icberg est une mise à jour incrémentale test pratique data lake iceberg plus de répertoire de contenu





avant-propos

En continuant avec la leçon précédente, calculez un PV, un cas, et enfin mettez à jour le résultat vers MYSQL
Cet article teste si la syntaxe suivante est mise à jour de manière incrémentielle
insert into default_catalog.default_database.mysql_pv select dt, cast(count( ) as int) as pv from hive_iceberg_catalog.ods_base .IcebergSink_XXZH / + OPTIONS('streaming'='true', 'monitor-interval'='1s')*/ où dt n'est pas null group by dt;


1. Idée de mise en œuvre

insérez la description de l'image ici
L'idée est comme le montre la figure ci-dessus, de gauche à droite, les données arrivent de kafka, statistiques pv, vues de db

2. Cas d'essai

1. Créer un tableau

DROP TABLE IF EXISTS `mysql_pv`;
CREATE TABLE `mysql_pv` (
  `dt` int(255) NOT NULL,
  `pv` int(255) DEFAULT NULL,
  PRIMARY KEY (`dt`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

2. Écrivez le code mentionné

CREATE TABLE IF NOT EXISTS KafkaTableSource_XXZH (
    `log` STRING,
	`dt` STRING
) WITH (
    'connector' = 'kafka',
    'topic' = 'test_xxzh',
    'properties.bootstrap.servers' = 'hadoop101:9092,hadoop102:9092,hadoop103:9092',
    'properties.group.id' = 'testGroup',
    'scan.startup.mode' = 'earliest-offset',
    'csv.ignore-parse-errors'='true',
    'format' = 'csv'
);
CREATE TABLE if not exists mysql_pv(
  `dt`  INT NOT NULL,
  `pv`    INT NOT NULL,
   PRIMARY KEY(dt) NOT ENFORCED
) with(
  'connector' = 'jdbc',
  'url' = 'jdbc:mysql://hadoop103:3306/xxzh_stock',
  'username' = 'hive',
  'password' = '123456',
  'table-name' = 'mysql_pv'
);


CREATE CATALOG hive_iceberg_catalog WITH (
    'type'='iceberg',
    'catalog-type'='hive',
    'uri'='thrift://hadoop101:9083',
    'clients'='5',
    'property-version'='1',
    'warehouse'='hdfs:///user/hive/warehouse/hive_iceberg_catalog'
);
use catalog hive_iceberg_catalog;
CREATE TABLE IF NOT EXISTS ods_base.IcebergSink_XXZH (
    `log` STRING,
	`dt` INT
)with(
    'write.metadata.delete-after-commit.enabled'='true',
    'write.metadata.previous-versions-max'='5',
    'format-version'='2'
 );
 

 
 insert into  hive_iceberg_catalog.ods_base.IcebergSink_XXZH select log, cast(dt as int) as dt from default_catalog.default_database.KafkaTableSource_XXZH;
 
insert into default_catalog.default_database.mysql_pv  select dt, cast(count(*) as int) as pv from hive_iceberg_catalog.ods_base.IcebergSink_XXZH /*+ OPTIONS('streaming'='true', 'monitor-interval'='1s')*/ where dt is not null group by dt;

3. Testez

1.mysql, les données de test existantes

insérez la description de l'image ici

2. Ajouter un morceau de données 20220617 au producteur

a,20220617

Trouvé : table de résultats mysql : ajout d'un
insérez la description de l'image ici

3. Analyser le binglog

[root@hadoop103 mysql]# mysqlbinlog -v --base64-output=decode-rows mysql-bin.000004 |tail -n 100
BEGIN
/*!*/;
# at 28356
#220617 14:11:14 server id 1  end_log_pos 28414 CRC32 0xfcdda6c9        Table_map: `xxzh_stock`.`mysql_pv` mapped to number 181
# at 28414
#220617 14:11:14 server id 1  end_log_pos 28458 CRC32 0xb0c17384        Write_rows: table id 181 flags: STMT_END_F
### INSERT INTO `xxzh_stock`.`mysql_pv`
### SET
###   @1=20220617
###   @2=1
# at 28458
#220617 14:11:14 server id 1  end_log_pos 28489 CRC32 0xdb5dca0c        Xid = 17793262
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file

A trouvé qu'un @1=20220617, @2=1 a été inséré

4. Envoyez un message à b, 20220617, et constatez que le pv du tableau de résultats 20220617 devient 2

insérez la description de l'image ici

5. Analysez le binglog mysql :

Regardez la commande binlog :

[root@hadoop103 mysql]# mysqlbinlog -v --base64-output=decode-rows mysql-bin.000004 |tail -n 100
### INSERT INTO `xxzh_stock`.`mysql_pv`
### SET
###   @1=20220617
###   @2=1
# at 28458
#220617 14:11:14 server id 1  end_log_pos 28489 CRC32 0xdb5dca0c        Xid = 17793262
COMMIT/*!*/;
# at 28489
#220617 14:13:25 server id 1  end_log_pos 28554 CRC32 0xadfe9011        Anonymous_GTID  last_committed=101      sequence_number=102     rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 28554
#220617 14:13:25 server id 1  end_log_pos 28632 CRC32 0xd07997a1        Query   thread_id=588   exec_time=0     error_code=0
SET TIMESTAMP=1655446405/*!*/;
BEGIN
/*!*/;
# at 28632
#220617 14:13:25 server id 1  end_log_pos 28690 CRC32 0x75154cc2        Table_map: `xxzh_stock`.`mysql_pv` mapped to number 181
# at 28690
#220617 14:13:25 server id 1  end_log_pos 28744 CRC32 0xf4ff361c        Update_rows: table id 181 flags: STMT_END_F
### UPDATE `xxzh_stock`.`mysql_pv`
### WHERE
###   @1=20220617
###   @2=1
### SET
###   @1=20220617
###   @2=2
# at 28744
#220617 14:13:25 server id 1  end_log_pos 28775 CRC32 0xfe2b874e        Xid = 17799053
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file

On constate que seules les données incrémentales sont mises à jour

Résumer

La mise à jour d'ICEBERG est une mise à jour incrémentale. Si l'ancien résultat n'a pas changé, aucune mise à jour ne sera générée.

おすすめ

転載: blog.csdn.net/spark_dev/article/details/125332540