Problema de declaración Construyo y opero plataformas de datos/ML en tiempo real, y un dolor recurrente que veo dentro de cualquier organización de datos es este: “¿Por qué este atributo tiene este valor?”Cuando un nombre de empresa, industria o ingresos parecen equivocados, las investigaciones a menudo se detienen sin ayuda de ingeniería. Este es el plan que envié: un servicio de trazabilidad sin servidor, de bajo mantenimiento que consulta terabytes en segundos y cuesta arañas. Lo que esta herramienta necesitaba hacer (para no ingenieros) 
 
 
 
 
 Explicar un valor: ¿Por qué el atributo X para la empresa Y es igual a Z en este momento? Mostrar la historia: ¿Cuándo cambió? ¿Cuáles fueron las versiones pasadas? Mostrar evidencia: ¿Qué fuentes y reglas produjeron ese valor? Ser autosuficiente: una API + UI simple para que los equipos puedan investigar sin ingenieros La arquitectura (servidor sin propósito) 
 
 
 
 
 
 Amazon API Gateway: una puerta de entrada segura para la API AWS Lambda: gestores de solicitudes sin estado (no hay computación inútil para pagar) Amazon S3 + Apache Hudi: almacenamiento barato con viajes en el tiempo y mejoras Catálogo de datos de AWS Glue: metadatos de esquema y partición Amazon Athena: SQL sobre S3/Hudi, pago por datos escaneado, cero infra ¿Por qué estas opciones? 
 
 
 
 Costos: el almacenamiento en S3 es barato; Athena solo cobra por bytes escaneados; Lambda es pago por invocación Escala: S3/Hudi soporta trivialmente TB→PB, y Athena escala horizontalmente Mantenimiento: no hay flota para patchar; la huella infrarroja permanece pequeña a medida que crece el uso 
 
 Layout de datos: el rendimiento es un problema de datos (no un problema de computación) Athena es rápido cuando no lee casi nada, y lento cuando planifica o escanea demasiado. : el rendimiento es un problema de datos (no un problema de computación) Athena es rápido cuando no lee casi nada, y lento cuando planifica o escanea demasiado. . Data layout getting partitions and projection right Estrategia de particionamiento (basada en patrones de consulta) 
 
 
 
 creado_date (fecha): la mayoría de las consultas están limitadas por el tiempo atribute_name (enum): empleados, ingresos, linkedin_url, funded_year, industria, etc. entity_id_mod (bucket integral): mod(entity_id, N) para distribuir las claves calientes uniformemente Esto limita los datos escaneados y, más importante, restringe qué metadatos de partición Athena necesita considerar. Las tres cosas que lo hicieron rápido: 
 
 
 
 
 
 
 : Partitioning 
 
 
 
 
 Put only frequently filtered columns in the partition spec. 
 
 Use integer bucketing (mod) for high‑cardinality keys like  entity_id. 
 
 
 Partition Indexing (first win, partial): 
 
 
 
 
 We enabled partition indexing so Athena could prune partition metadata faster during planning. 
 
 This helped until the partition count grew large; planning was still the dominant cost. 
 
 
 Partition Projection (the actual game‑changer): 
 
 
 Instead of asking Glue to store millions of partitions, we taught Athena how partitions are shaped. Result: planning time close to zero; queries jumped from “slow-ish with growth” to consistently 1–2 seconds for typical workloads. Athena TBLPROPERTIES (minimal example) TBLPROPERTIES (
  'projection.enabled'='true',

  'projection.attribute_name.type'='enum',
  'projection.attribute_name.values'='employees,revenue,linkedin_url,founded_year,industry',

  'projection.entity_id_mod.type'='integer',
  'projection.entity_id_mod.interval'='1',
  'projection.entity_id_mod.range'='0,9',

  'projection.created_date.type'='date',
  'projection.created_date.format'='yyyy-MM-dd',
  'projection.created_date.interval'='1',
  'projection.created_date.interval.unit'='days',
  'projection.created_date.range'='2022-01-01,NOW'
)
 ¿Por qué funciona esto 
 
 
 
 Athena ya no recoge una enorme lista de particiones de Glue; calcula las particiones en el vuelo de las reglas anteriores Escanear cae a "sólo los archivos que coinciden con las restricciones" El tiempo de planificación se vuelve insignificante, incluso a medida que crecen los datos y las particiones Lo que me sorprendió (y lo que fue difícil) 
 
 
 
 
 El “gotcha” era la planificación de consultas, no la computación. A menudo optimizamos motores, pero aquí la parte más lenta era enumerar particiones. Seleccionar las claves de partición es mitad arte, mitad ciencia. sobre-partición y te ahogas en metadatos; sub-partición y pagas por escaneo. Para los dominios de baja cardinalidad (attribute_name), la proyección de enum es simple y rápida. El soporte de bucketing verdadero es limitado en Atenas, pero una partición de números enteros basada en mod te da la mayoría de los beneficios. Costo y latencia (números reales) 
 
 
 
 
 Preguntas típicas: 1–2 segundos de final a final (Lambda comienza frío excluido) Tamaño de datos: múltiples TB en S3/Hudi Costos: centavos por cada 100 solicitudes (escaneo de Atenas + invocaciones de Lambda) Opciones: cerca de cero —sin servidores, sin compactación manual más allá de la cadencia de mantenimiento de Hudi Las trampas comunes (por lo que puedes saltarlas) 
 
 
 
 
 No particiones por campos de alta cardinalidad directamente (por ejemplo, raw entity_id); explotará el número de particiones No salgas la proyección si esperas que las particiones crezcan; la indexación sola no te salvará No guarde metadatos de partición para cada clave si una regla puede generarlo (la proyección existe precisamente por esa razón) No dejes que los esquemas de Glue se deslizen; Versión y validación en CI Pruebe esto en casa (una lista de verificación mínima) 
 
 
 
 
 
 
 
 Model your top 3 queries; pick partitions that match those predicates 
 
 Use enum projection for low‑cardinality fields; date projection for time; integer ranges for buckets 
 
 Store data in columnar formats (Parquet/ORC) via Hudi to keep scans small and enable time travel 
 
 Add a thin API (API Gateway + Lambda) to turn traceability SQL into JSON for your UI 
 
 Measure planning vs. scan time; optimize the former first Lo que esto desbloqueó para mis usuarios 
 
 
 
 
 Los analistas y el soporte pueden responder “por qué” sin ingenieros El producto puede revisar los cambios de atributos por tiempo y causa Ingeniería gasta más tiempo en correcciones y menos tiempo en forense El org confía más en los datos porque la evidencia está a un clic de distancia Cierra el pensamiento El gran rendimiento suele ser una historia de diseño de datos. Antes de escalar la computación, fija cómo almacenas y encuentras bytes.En la analítica sin servidor, la consulta más rápida es la que planea de inmediato y no lee casi nada, y la proyección de particiones es la herramienta que te lleva allí.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Este audio es producido en el idioma original de la historia!

Dentro de un sistema de lineado de datos sin servidor de bajo costo basado en AWS

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Telegram: el puente de Crypto Island hacia el continente

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

El modelo Bitcoin UTXO, impulsando un ecosistema único

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Telegram: el puente de Crypto Island hacia el continente

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

El modelo Bitcoin UTXO, impulsando un ecosistema único

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps