Problema dichiarazione Ho costruito e gestito piattaforme di dati in tempo reale / ML, e un dolore ricorrente che vedo all'interno di qualsiasi organo di dati è questo: "Perché questo attributo ha questo valore?"Quando un nome di azienda, industria o ricavi sembrano sbagliati, le indagini spesso si fermano senza assistenza ingegneristica. Questo è il progetto che ho inviato: un servizio di tracciabilità senza server, a bassa manutenzione che richiede terabyte in secondi e costa arachidi. Cosa questo strumento doveva fare (per i non ingegneri) 
 
 
 
 
 Spiegare un valore: Perché l'attributo X per la società Y è uguale a Z in questo momento? Mostra la storia: quando è cambiata? quali sono state le versioni precedenti? Mostra la prova: quali fonti e regole hanno prodotto quel valore? Essere self-service: un'API + un'interfaccia utente semplice in modo che i team possano indagare senza ingegneri L’architettura (serverless on purpose) 
 
 
 
 
 
 Amazon API Gateway: una porta anteriore sicura per l'API AWS Lambda: gestori di richieste senza stato (no idle computing da pagare) Amazon S3 + Apache Hudi: archiviazione economica con viaggi nel tempo e aggiornamenti AWS Glue Data Catalog: metadati di schema e partizione Amazon Athena: SQL su S3/Hudi, pay-per-data-scanned, zero infra Perché queste scelte? 
 
 
 
 Costo: lo storage su S3 è economico; Athena paga solo per i byte scansionati; Lambda è pay-per-invocation Scala: S3/Hudi supporta trivialmente TB→PB, e Athena scala orizzontalmente Manutenzione: nessuna flotta da patchare; l'impronta infrarossa rimane piccola man mano che l'utilizzo aumenta 
 
 Layout dei dati: le prestazioni sono un problema di dati (non un problema di calcolo) Athena è veloce quando non legge quasi nulla, e lento quando pianifica o scansiona troppo. Layout dei dati: le prestazioni sono un problema di dati (non un problema di calcolo) Athena è veloce quando non legge quasi nulla, e lento quando pianifica o scansiona troppo. Strategia di partizionamento (in base a modelli di query) 
 
 
 
 created_date (data): la maggior parte delle query è limitata al tempo attribute_name (enum): dipendenti, ricavi, linkedin_url, founded_year, industria, ecc. entity_id_mod (bucket integrale): mod(entity_id, N) per distribuire le chiavi calde in modo uniforme Questo limita i dati scansionati e, ancora più importante, restringe i metadati di partizione che Athena deve considerare. Le tre cose che lo hanno reso veloce: 
 
 
 
 
 
 
 : 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'
)
 Perché questo funziona 
 
 
 
 Athena non raccoglie più un enorme elenco di partizioni da Glue; calcola le partizioni sulla mossa dalle regole di cui sopra La scansione cade a "solo i file che corrispondono alle restrizioni" Il tempo di pianificazione diventa trascurabile, anche quando i dati e le partizioni crescono Cosa mi ha colpito (e cosa mi ha colpito) 
 
 
 
 
 Il “gotcha” era la pianificazione delle query, non il calcolo. Spesso ottimizziamo i motori, ma qui la parte più lenta era l’enumerazione delle partizioni. Scegliere le chiavi di partizione è metà arte, metà scienza. Over-partition e ti affoghi nei metadati; under-partition e paghi per scansione. Per i domini a bassa cardinalità (attribute_name), la proiezione enum è semplice e veloce. Il bucketing (via mod) è pragmatico.Il supporto per il bucketing vero è limitato in Atene, ma una partizione intera basata su mod ti offre la maggior parte dei vantaggi. Costo e latenza (numeri reali) 
 
 
 
 
 Domande tipiche: 1–2 secondi fine-fine (esclusi gli inizi freddi di Lambda) Dimensione dei dati: più TB in S3/Hudi Costo: centesimi per 100 richieste (scansione Athena + invocazioni Lambda) Ops: quasi zero – nessun server, nessuna compressione manuale al di là della cadenza di manutenzione di Hudi Trappole comuni (perché puoi saltarle) 
 
 
 
 
 Non partizionare direttamente dai campi ad alta cardinalità (ad esempio, raw entity_id); si esploderà il conteggio delle partizioni Non saltare la proiezione se si prevede che le partizioni crescano; l'indice da solo non vi salverà Non salvare i metadati di partizione per ogni chiave se una regola può generarlo (la proiezione esiste esattamente per questo motivo) Non lasciare che gli schemi di Glue scorrano; Versione e convalida in CI Prova questo a casa (una lista di controllo minima) 
 
 
 
 
 
 
 
 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 Cosa questo ha sbloccato per i miei utenti 
 
 
 
 
 Gli analisti e il supporto possono rispondere al “perché” senza ingegneri Il prodotto può controllare i cambiamenti di attributi in base al tempo e alla causa Ingegneria spende più tempo su correzioni e meno tempo su forense Gli org si fidano più dei dati perché la prova è a un clic di distanza Il pensiero chiuso Prima di scalare il calcolo, fissare come si memorizzano e trovano i byte.Nell'analisi senza server, la query più veloce è quella che pianifica istantaneamente e non legge quasi nulla, e la proiezione di partizione è la leva che ti porta lì.

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

Questo audio è prodotto nella lingua originale della storia!

All'interno di un sistema di lineatura dei dati a basso costo, senza server, costruito su AWS

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

Meet Dealscard, Winner of Startups of The Year 2024 in Ghaziabad/Deal Aggregator

Meet the HackerNoon Top Writers: Nebojsa Nesha Todorovic - Upwork, Freelancing, and Future of Work

Streamlining Network Policy Management - Interview with Startups of the Year Nominee, Otterize

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

Meet Dealscard, Winner of Startups of The Year 2024 in Ghaziabad/Deal Aggregator

Meet the HackerNoon Top Writers: Nebojsa Nesha Todorovic - Upwork, Freelancing, and Future of Work

Streamlining Network Policy Management - Interview with Startups of the Year Nominee, Otterize

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps