Reddit Data Stream

Planifier des lots historiques avec un suivi local et des limites explicites

Préparez votre tâche ETL : récupérer une page, conserver la réponse, écrire du JSONL local et consigner limites, échecs et coût des nouveaux appels.

Obtenir une clé API

Définir la tâche exécutée par votre ordonnanceur

L'intégration de données Reddit dans un pipeline ETL nécessite une approche méthodique pour extraire efficacement les archives. En utilisant l'API dédiée, vous pouvez récupérer des publications et des commentaires de manière systématique. Cette méthode permet de structurer les données brutes pour une analyse ultérieure sans dépendre des flux en direct de la plateforme.

Reddit Data Stream est indépendant de Reddit et ne fournit pas de mises à jour en direct. Des appels périodiques ne transforment pas l’API en flux d’événements, SSE, WebSocket ou canal de changements. Il n’y a ni nouveautés promises entre deux exécutions ni ordre temporel permettant de détecter tous les ajouts. L’horaire et l’exécution sont des choix de votre infrastructure, pas un service de planification fourni par l’API.

Définissez les destinations de la réponse originale et du JSONL dérivé, ainsi qu’un maximum local d’appels par exécution. Gardez route, filtres, limit et page avec votre identifiant de lot. Ce journal appartient à l’ETL, pas à un curseur émis par les archives. Distinguez réponse conservée, transformation en attente et fichier terminé. N’utilisez pas le dernier created_utc comme repère d’ingestion nouvelle : from et to filtrent la création en YYYY-MM-DD UTC, dernier jour entier inclus, pas l’arrivée ou la modification dans les archives.

Conserver la page avant d’écrire le JSONL

L’exemple de l’accueil est GET https://api.redditdatastream.com/v1/posts?subreddit=apacheairflow&limit=3&page=3. Il demande des publications de cette communauté, au plus trois enregistrements de la troisième page, pas les publications les plus récentes. Pour les commentaires, utilisez comments, ou search avec les filtres documentés. Authentifiez côté serveur avec X-API-Key: <clé> ou Authorization: Bearer <clé>. La page Obtenir une clé API explique l’accès avant paiement ; excluez les secrets des fichiers et journaux.

Vérifiez le statut HTTP et gardez la réponse reçue avant de normaliser les champs. Validez ensuite data et écrivez chaque enregistrement retenu comme un objet JSON par ligne avec votre code. Si un texte contient des sauts de ligne, sérialisez-le en JSON pour les échapper dans l’objet. Gardez pagination et credits comme métadonnées séparées. La route livre du JSON, pas un fichier JSONL, une exportation massive ou une destination de stockage administrée.

Des champs facultatifs peuvent manquer ou référencer des données non reçues. parent_id et link_id présents permettent des relations locales, sans arbres complets ni filtres sur ces identifiants. Définissez le traitement des enregistrements que votre transformation refuse et conservez les motifs. Si la réponse est déjà sauvegardée, retraitez cette copie pour réparer le fichier ; cela n’appelle pas l’API et ne restitue pas le crédit de la réussite initiale.

Terminer les lots et distinguer leurs coûts

Pour les routes de contenu, limit et page vont de 1 à 100, avec un appel par page. _doc ne trie ni par temps, ni par pertinence ou score ; min_score est seulement un seuil numérique. Lisez total avec relation : eq est exact pour la requête, gte une borne inférieure et unknown un total non fiable, éventuellement null. Conservez has_more et window_exhausted, respectez les limites et notez le point d’arrêt. Ne promettez ni exhaustivité ni enregistrements uniques.

Une réponse vide réussie ne produit pas de lignes de data, mais nécessite une entrée de lot et coûte un crédit. Corrigez les paramètres avec 400, vérifiez clé et domaine avec 401, le solde avec 402 et prévoyez attentes et tentatives limitées pour 429. /v1/status est public et non facturé, mais déclare seulement le périmètre et confirme la réponse HTTP ; il ne teste ni la recherche ni vos fichiers ou tâches. Une page sauvegardée n’assure pas une reprise distante stable.

Chaque récupération réussie coûte un crédit, même vide ou répétée : $1 pour 1000 appels. L’achat minimal est de $50 pour 50000 crédits, et les 100 crédits d’essai sont conditionnels. Les requêtes invalides ne débitent pas ; les échecs en amont restituent la réservation. Une déconnexion peut masquer une réussite facturée ; une autre récupération réussie coûte un nouveau crédit. Un échec local ne rembourse pas ce coût. Consultez tarifs et documentation pour séparer pages, tests et nouveaux appels du traitement local. Découpage des dates et déduplication ne prouvent pas l’exhaustivité.