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
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 sí 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
- Para la muestra del 10% de Posts entregada en el Decahose, el stream incluye el 100% de los likes públicos aplicables
- Particiones: 2
- Estructura de URL
Ejemplo de respuesta
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.- 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.
- 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.
- 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.