Un indexeur est il un ETL?

J’avais croisé dans ma carrière un logiciel open source nommé Talend qui se présentait comme un outil ETL (Extract Transform Load).

En voyant passer un message disant que @ManUtopiK allait refaire un subsquid (la partie indexation seulement, l’api Graphql étant assurée par Hasura), je me suis rappelé de ce terme de ETL.

En fait, un indexeur (comme subsquid) c’est deux parties :

  • La partie extraction depuis une base de données Substrate, transformation, et chargement dans une base de données relationnel (c’est du ETL en fait)
  • L’API de requête sur la base de données d’arrivée

La première partie c’est la phase ETL :

  • Extraction des données de la base de données Subtrate (Extract)
  • Transformation des données (Transform)
  • Chargement des données dans la base de données relationnelle (Load)

Je pense qu’on peut jeter un œil sur ce genre de logiciels, maintenant bien rodés, qui adresse un problème connu depuis de nombreuses années. Si ça peut nous éviter des efforts.

Je me demandais justement comment appeler ce machin :slight_smile:
Merci pour les infos, ça donne des pistes !

2 Likes

J’ai utilisé Talend dans un de mes anciens boulot et pour moi ça n’a rien à voir avec un indexeur de blockchain.

Talend c’est du scrapping discret, genre 1 fois par jour, ou toutes les 12h, ce qui ne nous sert à rien.

Un indexeur blockchain à besoin les récupérer les blocs au fil de l’eau en continu, et le fait en tapant une API avec souscription, pas une DB.

Ah dommage. Comme il fonctionne en plugins, je pensais qu’on pouvait faire un plugin Substrate avec un flux de données (stream) en entrée.
Il faut qu’il puisse fonctionner en mode statique (blocs archivés) et en mode flux (stream) pour suivre les blocs effectivement. Et aussi vérifier la synchro entre les deux.

Il y a des subtilités pour un indexeur substrate qu’on risque de ne pas trouver dans un ETL classique, c’est la synchronisation entre la base de données en entrée et celle en sortie. Dans les premières versions de Talend, on parlait de migration de base de données, source vers sortie, mais pas vraiment de contrôle ou de maintient d’une synchronisation entre les deux.

L’idée c’est surtout de donner des idées à Manutopik.

AWS Glue supporte les données de type flux… :wink:

J’ai utilisé Apache Camel (framework Java) ces 3 dernières années, alors oui il est possible de l’utiliser au sein d’un indexeur mais bon vu la complexité d’utilisation (il faut monter en compétences sur le framework, coût non négligeable, et le débugging est difficile) je ne le conseille pas.

Nous l’utilisions au sein de mon équipe principalement en mode discret, c’est-à-dire plusieurs fois par jour à des horaires précis pour livrer du contenu à un client. Mais il est tout à fait possible de l’utiliser en mode continu, aucun problème.

1 Like

Question toute bête sur l’indexer à venir:
Si l’indexer commence au bloc 20 000, tous les événements qui se sont produits avant le bloc 20 000 sont perdus à jamais ?
Si l’indexer est down pendant 4 heures, tous les événements déroulés pendants ces 4h sont perdus à jamais ?

Non, j’enregistre l’index du dernier bloc traité.
Au démarrage, j’index depuis le bloc 0.
Si le server est down et repart 4h après, je repart depuis le dernier index traité.

Ça fonctionne avec ma blockchain locale que je créé manuellement bloc par bloc, et j’enregistre les identités et certifications :

Par contre, j’ai testé avec gdev et je n’arrive pas à obtenir les anciens blocs :
UnknownBlock, State already discarded for BlockId::Hash, 0x83ab84588a2d6f26138b451cf3f437364edcf59e18e5915331e3c3d3a3795230

@elois une idée ?

4 Likes

Je pense pouvoir répondre : c’est parce que ton nœud est « juste » un Full Node, il faudrait que tu le lances avec l’option --pruning archive (en supprimant la BDD avant avec une commande purge-chain au préalable).

2 Likes

Ah mais oui. J’essayais directement avec le ws d’éloïs. N’importe quoi. Il faut que je tape sur mon noeud qui est en mode miroir. Je retente et je vais essayer avec ton option.
Merci !

1 Like

Oui @cgeek à raison, chaque indexeur aura besoin de son nœud duniter-v2s privé en mode archive.

3 Likes

Extra ça ! Bravo @ManUtopiK

En fait, les clients ont juste besoin d’une API type BMA (en terme de contenu) et GraphQL (pour la forme).
Ensuite, n’importe quel outil pourra se synchroniser dessus, retriturer les données, etc.

@ManUtopiK est-ce que des websocket permettront de s’abonner à un flux ?
Est-ce que les blocs seront dispo en juin,cavec toutes les données du bloc, quelque part ?

Et enfin, as tu moyen de publier un accès à ton indexeur, même si tu fais des raz souvent. C’est pour qu’on puisse tester au fur et à mesure, en mode PoC. :slight_smile:
Merci

1 Like

Merci :slight_smile:

Les clients utiliseront l’api RPC pour tout ce qui est écriture dans la blockchain, et l’api graphQL des indexer pour tout ce qui est lecture. @elois a fait un schéma expliquant tout ça ici.

Hasura expose des subscriptions pour toutes les tables (qui ont un accès public) :

2022-06-03-120916427178560

Il y a cet article qui explique comment ils tiennent 1 million de connexions !

Pour l’instant je n’index pas les blocs, je les décode pour extraire les extrinsics, lire les données et les charger dans la bdd. ETL quoi :slight_smile:

1 Like

Pour l’instant je n’arrive pas à indexer la gdev. Mais dès que j’y arrive je met en ligne en mode POC !

1 Like

Pour la continuité des outils de la G1, je réfléchis à produire des blocs JSON proches de Duniter v1.
Penses tu qu’ajouter ce format en sortie de l’API soit possible ?

Évidemment les hash ne seraient plus bons, mais on pourrait imaginer que l’indexeur les recalcule et les signe avec sa propre clef (en as t’il une ?).
Ainsi, il agirait comme une autorité de confiance, donnant accès aux blocs.
Il n’y aurait pas de hash du précédent bloc non plus. A moins de simplement recopié ceux de Substrate, et les signatures, même si les client de cette API ne pourrait pas le vérifier.

Du style de ce format : https://g1.cgeek.fr/blockchain/block/530491 ?
En théorie c’est possible car il est possible de créer des “vue” en postgresql permettant d’aggréger des données de plusieurs tables. Hasura créé automatiquement les queries graphql pour ces vues.
Après je ne sais pas du tout si c’est pertinent et possible avec substrate…

1 Like

Ah ben je viens de réussir avec pruning archive !
Ça voulait pas sync. Je suis passé à la version image: duniter/duniter-v2s:v0.1.0 et ça sync :slight_smile:

2 Likes

Non pas possible.

Je propose une autre solution qui me parait plus simple à réaliser: remplir la DB postgresQL avec les données passées de la Ğ1, avec dex je peux faire ça, j’extrais la DB de duniter v1 en une fois et j’écris le tout dans la nouvelle DB. Une sorte d’ETL qui ne servira qu’une fois en prod, mais faut d’abord maturer le schema de la DB postgres :slight_smile:

2 Likes

Au cas où vous voudriez jeter un œil sur ETL open-source voici la liste

1 Like