Problem izjava Izgradim i upravljam platformama podataka/ML u realnom vremenu, a jedna ponavljajuća bol koju vidim unutar bilo kojeg org podataka je ova: „Zašto ovaj atribut ima tu vrijednost?“ Kada ime kompanije, industrija ili prihodi izgledaju pogrešno, istrage često zaustavljaju bez inženjerske pomoći. Ovo je plan koji sam isporučio: usluga sljedivosti bez servera, niskog održavanja koja traži terabajte u sekundama i košta arašide. Šta je ovaj alat trebao učiniti (za ne-inženjere) 
 
 
 
 
 Objasnite vrijednost: Zašto je atribut X za kompaniju Y jednako Z upravo sada? Prikaži istoriju: Kada se to promenilo? Koje su bile prethodne verzije? Pokaži dokaze: Koji su izvori i pravila stvorili tu vrednost? Budite samostalni: API + jednostavno korisničko okruženje kako bi timovi mogli istražiti bez inženjera Arhitektura (serverless na svrhu) 
 
 
 
 
 
 Amazon API Gateway: sigurna prednja vrata za API AWS Lambda: rukovatelji zahteva bez statusa (bez praznog računanja za plaćanje) Amazon S3 + Apache Hudi: jeftino skladištenje s putovanjem kroz vrijeme i poboljšanja AWS Glue Data Catalog: metapodatci o shemama i particijama Amazon Athena: SQL preko S3/Hudi, pay-per-data-scanned, zero infra Zašto ovi izbori? 
 
 
 
 Trošak: skladištenje na S3 je jeftino; Athena naplaćuje samo za skenirane bajte; Lambda je plaćena po pozivu Skala: S3/Hudi trivijalno podržava TB→PB, a Athena skala horizontalno Održavanje: nema flote za patch; infra otisak ostaje mali kako se upotreba povećava 
 
 Raspored podataka: performanse su problem podataka (ne problem računanja) Athena je brz kada čita gotovo ništa, a spor kada planira ili skenira previše. : performanse je problem podataka (ne računarski problem) Athena je brz kada čita gotovo ništa, i spor kada planira ili skenira previše. . Data layout getting partitions and projection right Strategija particioniranja (na osnovu uzoraka upita) 
 
 
 
 created_date (datum): većina upita je vremenski ograničena atribute_name (enum): zaposlenici, prihodi, linkedin_url, founded_year, industrija, itd entity_id_mod (integer bucket): mod(entity_id, N) za ravnomjerno širenje vrućih ključeva To ograničava podatke skenirane i, što je još važnije, sužava koje metapodatke particije Athena treba uzeti u obzir. Tri stvari koje su ga učinile brzim: 
 
 
 
 
 
 
 : 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'
)
 Zašto ovo radi 
 
 
 
 Athena više ne dobija veliku listu particija od Glue-a; izračunava particije na mlazu iz gore navedenih pravila Skeniranje pada na "samo datoteke koje odgovaraju ograničenjima" Planiranje vremena postaje zanemarljivo, čak i kada se podaci i particije povećavaju Što me je iznenadilo (i što je bilo teško) 
 
 
 
 
 "Gotcha" je bilo planiranje upita, a ne izračunavanje. Mi često optimizujemo motore, ali ovdje je najsporiji deo bio navođenje particija. Odabir ključeva za particije je pola umetnosti, pola nauke. Prekomjerna particija i utopljeni ste u metapodatcima; ispod particija i plaćate po skeniranju. Počnite od vaših top 3 upita predikata i radite nazad. Za domene niske kardinalnosti (attribute_name), enum projekcija je jednostavna i brza. Prava podrška za bucketing je ograničena u Ateni, ali čitava particija zasnovana na mod-u dobija većinu prednosti. Troškovi i latencija (realni brojevi) 
 
 
 
 
 Tipične upite: 1–2 sekunde od kraja do kraja (Lambda hladni početak je isključen) Veličina podataka: više TB u S3/Hudi Trošak: penije po 100 zahteva (Athena skeniranje + Lambda invocations) Ops: blizu nule – nema servera, nema ručnog komprimiranja izvan kadence održavanja Hudi Uobičajene zamke (tako da ih možete preskočiti) 
 
 
 
 
 Nemojte direktno particionirati polja visoke kardinalnosti (npr. raw entity_id); eksplodira broj particija Nemojte preskočiti projekciju ako očekujete da će particije rasti; samo indeksiranje vas neće spasiti Nemojte čuvati metapodatke particije za svaki ključ ako ga pravilo može generisati (projekcija postoji upravo iz tog razloga) Nemojte dozvoliti da Glue sheme drift; verzija ih i potvrditi u CI Pokušajte ovo kod kuće (minimalna kontrolna lista) 
 
 
 
 
 
 
 
 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 Šta je to otključano za moje korisnike 
 
 
 
 
 Analitičari i podrška mogu odgovoriti "zašto" bez inženjera Proizvod može revidirati promene atributa po vremenu i uzroku Inženjerstvo troši više vremena na popravke i manje vremena na forenziku Org više veruje podacima jer su dokazi udaljeni jednim klikom Završetak misli Velike performanse su obično priče o postavljanju podataka. Prije nego što proširite izračunavanje, popravite kako pohranjujete i pronađete bajte. U serverless analitici, najbrži upit je onaj koji planira odmah i ne čita gotovo ništa, a projekcija particija je poluga koja vas tamo dovodi.

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

Ovaj audio je proizveden na originalnom jeziku priče!

Unutar jeftinog, beservernog sistema za lineiranje podataka zasnovanog na AWS-u

About Author

KOMENTARI

HANG TAGS

OVAJ ČLANAK JE PREDSTAVLJEN U

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps