Skip to main content
Este endpoint se ha actualizado para incluir metadatos de edición de Posts. Aprende más sobre estos metadatos en la página de fundamentos “Editar Posts”.

Stream Decahose

Enterprise Esta es una API enterprise disponible únicamente dentro de nuestros niveles de acceso gestionado. Para usar esta API, primero debes configurar una cuenta con nuestro equipo de ventas enterprise. Más información El Decahose entrega una muestra aleatoria del 10% del Firehose de X en tiempo real a través de una conexión de streaming. Esto se logra mediante un algoritmo de muestreo en tiempo real que selecciona los datos aleatoriamente, permitiendo aún la entrega de datos con baja latencia esperada tal como los envía el firehose de X. A continuación se muestran algunas de las funciones disponibles con Decahose:
  • URLs expandidas y enriquecidas: - desdobla completamente las URLs acortadas y proporciona metadatos adicionales (título y descripción de la página)
  • Particionamiento del stream - 2 particiones, cada una conteniendo el 50% del volumen del stream Decahose
  • Fiabilidad mejorada - diversidad geográfica de los sistemas backend
Nota: Estos datos se entregan en bloque y no admiten filtrado adicional (por ejemplo, por palabras clave). ENTERPRISE

Streaming de likes

Esta es una API enterprise disponible únicamente dentro de nuestros niveles de acceso gestionado. Para usar esta API, primero debes configurar una cuenta con nuestro equipo de ventas enterprise. Más información Los Likes permiten conocer quién da like a los Posts y entregan conteos precisos de likes. El Firehose y el Decahose de Gnip pueden entregar likes públicos relacionados con los Posts entregados vía Gnip. Esto da como resultado métricas públicas de engagement y audiencia en tiempo real asociadas a un Post. Primeros pasos con Likes Al prepararte para consumir datos de likes, debes saber que:
  • Los likes se entregan a través de un stream independiente y separado
  • Históricamente, a los likes se les llamaba “Favorites”. La carga útil en formato nativo enriquecido mantiene esta nomenclatura
  • Los streams incluyen únicamente likes públicos
    • Público significa que el usuario que da like, el creador del Post y el Post son todos públicos en la plataforma
  • Los likes son muy similares a los Retweets y representan una señal pública de engagement
  • Los elementos de la carga útil incluyen:
    • Objeto Post original
    • Objeto Actor que creó el Post original
    • Objeto Actor que realizó la acción de like
  • Solo se puede dar like al contenido original
    • Los Retweets no pueden recibir like. Un like a un Retweet se aplica al Post original
    • Los Quoted Tweets pueden recibir like
  • Las actividades de like incluyen los Gnip Enrichments aplicables (donde se hayan comprado/aplicado)
  • Productos / Funciones admitidos
    • Los streams de likes admiten Backfill (donde se haya comprado/aplicado)
    • No hay soporte de Replay para streams de likes
    • No hay soporte de Search ni Historical para likes
    • No hay planes inmediatos para agregar soporte de likes a PowerTrack
Decahose Carga útil en formato nativo enriquecido
Ejemplo de respuesta
Carga útil de eliminación de Like / “Unlike”

Guías

Recuperación y redundancia

Introducción Al transmitir Posts en tiempo real de gran volumen, existe un conjunto de buenas prácticas que fomentan tanto la fiabilidad como la fidelidad total de los datos. Al consumir datos en tiempo real, maximizar tu tiempo de conexión es un objetivo fundamental. Cuando ocurren desconexiones, es importante detectarlas automáticamente y reconectarse. Después de reconectarse, es importante evaluar si hay períodos que requieran backfill de datos. El componente que gestiona estos detalles y consume los Posts en tiempo real es solo una parte de un sistema que involucra red, almacén de datos, servidor y almacenamiento. Dada la complejidad de estos sistemas, otra buena práctica es tener diferentes entornos de streaming, con al menos streams separados para desarrollo/pruebas y producción. Decahose viene con un conjunto de funciones que ayudan con estos esfuerzos.
  1. Para admitir múltiples entornos, podemos desplegar Streams adicionales para tu cuenta. Estos streams son independientes entre sí y tienen un stream_label diferente para ayudar a diferenciarlos.
  2. Para ayudar a mantener una conexión, cada stream Decahose admite Conexiones redundantes. La arquitectura más común es que un stream tenga dos conexiones y, del lado del cliente, haya dos consumidores independientes — idealmente en diferentes redes. Con este diseño, puede haber redundancia entre las redes del cliente, los servidores y los caminos de almacenamiento de datos. Ten en cuenta que en cada conexión se sirve una copia completa de los datos y el lado del cliente debe tolerar y gestionar los datos duplicados.
  3. Se proporcionará un ‘heartbeat’ cada 10 segundos; sin embargo, con el stream Decahose, el volumen de datos es lo suficientemente alto como para que incluso una pequeña duración (por ejemplo, unos segundos) sin Posts pueda indicar un problema de conexión. Por lo tanto, tanto un ‘silencio de datos’ como la falta de un heartbeat pueden usarse para detectar una desconexión.
Dado que las desconexiones ocurrirán, el stream Decahose tiene una función dedicada de Recuperación y una función Backfill para ayudar a recuperar los datos que se perdieron debido a desconexiones y otros problemas operativos.

Streams adicionales

Tener streams Decahose adicionales es otra manera de ayudar a construir fiabilidad en tu solución. Cualquier stream adicional es completamente independiente, teniendo su endpoint único. A cada stream se le asigna su propio stream_label, y esta etiqueta, junto con el nombre de tu cuenta, forman parte de la URL de ese stream. Consulta el ejemplo a continuación: https://gnip-stream.x.com/stream/sample10/accounts/:account\_name/publishers/twitter/:stream\_label.json La convención más común es tener un stream en tiempo real dedicado para tu sistema de producción y un stream adicional disponible para desarrollo y pruebas. Tener un stream de test/desarrollo permite a los clientes de Decahose tener un stream para probar actualizaciones del consumidor cliente. Aunque a un stream se le puede asignar cualquier etiqueta (única), una convención es usar ‘prod’ para el stream de producción, y ‘dev’ o ‘sandbox’ para un stream adicional de desarrollo. El número de streams y sus etiquetas únicas es configurable por tu representante de cuenta. Conexiones redundantes Una conexión redundante simplemente te permite establecer más de una conexión simultánea al stream de datos. Esto proporciona redundancia al permitirte conectarte al mismo stream con dos consumidores separados, recibiendo los mismos datos a través de ambas conexiones. Así, tu app tiene un failover en caliente para diversas situaciones, por ejemplo, cuando un stream se desconecta