Problemi i deklaratës Unë ndërtoj dhe operoj platforma të të dhënave në kohë reale / ML, dhe një dhimbje e përsëritur që shoh brenda çdo org të të dhënave është kjo: “Pse ky atribut ka këtë vlerë?”Kur një emër i kompanisë, industria ose të ardhurat duken gabim, hetimet shpesh bllokohen pa ndihmë inxhinierike. Ky është modeli që dërgova: Një shërbim i gjurmueshmërisë pa server, me mirëmbajtje të ulët që pyet në terabajt në sekonda dhe kushton arabe. Çfarë duhet të bëjë ky mjet (për jo-inxhinierët) 
 
 
 
 
 Shpjegoni një vlerë: Pse atributi X për kompaninë Y është i barabartë me Z tani? Shih historinë: Kur ka ndryshuar? Trego dëshmi: Cilat burime dhe rregulla prodhuan atë vlerë? Bëhuni vetë-shërbim: Një API + UI e thjeshtë në mënyrë që ekipet të mund të hetojnë pa inxhinierë Arkitektura (serverless në qëllim) 
 
 
 
 
 
 Amazon API Gateway: një derë e sigurt për API AWS Lambda: trajtuesit e kërkesave pa status (nuk ka kompjuterë të zbrazët për të paguar) Amazon S3 + Apache Hudi: ruajtje e lirë me udhëtim në kohë dhe upserts AWS Glue Data Catalog: Metadat e skemës dhe ndarjes Amazon Athena: SQL mbi S3/Hudi, me pagesë për të dhënat, zero infra Pse këto zgjedhje? 
 
 
 
 Kostoja: ruajtja në S3 është e lirë; Athena ngarkon vetëm për bajtët e skanuar; Lambda është paguar-per-invocation Shkalla: S3/Hudi trivialisht mbështet TB→PB, dhe Athena shkallë horizontalisht Mirëmbajtja: nuk ka flotë për të patch; gjurmë infra mbetet e vogël si përdorimi rritet 
 
 Layout i të dhënave: Performanca është një problem i të dhënave (jo një problem kompjuterik) Athena është e shpejtë kur lexon pothuajse asgjë, dhe e ngadaltë kur planifikon ose skan shumë. : performanca është një problem i të dhënave (jo një problem kompjuterik) Athena është e shpejtë kur lexon pothuajse asgjë, dhe e ngadaltë kur planifikon ose skan shumë. . Data layout getting partitions and projection right Strategjia e ndarjes (bazuar në modelet e pyetjes) 
 
 
 
 created_date (date): shumica e pyetjeve janë të kufizuara në kohë atribute_name (enum): punonjësit, të ardhurat, linkedin_url, founded_year, industrinë, etj entity_id_mod (bucket integrale): mod(entity_id, N) për të shpërndarë çelësat e nxehtë në mënyrë të barabartë Kjo kufizon të dhënat e skanuara dhe, më e rëndësishmja, kufizon se çfarë metadata të ndarjes Athena duhet të marrë parasysh. Tre gjërat që e bëjnë atë të shpejtë: 
 
 
 
 
 
 
 : 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'
)
 Pse funksionon kjo 
 
 
 
 Athena nuk merr më një listë të madhe të ndarjeve nga Glue; ajo llogarit ndarjet në fluturim nga rregullat e mësipërme Skanimi bie në "vetëm skedarët që përputhen me kufizimet" Koha e planifikimit bëhet e parëndësishme, edhe kur të dhënat dhe ndarjet rriten Çfarë më befasoi (dhe çfarë ishte e vështirë) 
 
 
 
 
 “Gotcha” ishte planifikimi i pyetjeve, jo llogaritja.Ne shpesh optimizojmë motorët, por këtu pjesa më e ngadaltë ishte numërimi i ndarjeve. Picking partition keys është gjysmë art, gjysmë shkencë. over-partition dhe ju të mbytur në metadata; under-partition dhe ju paguani për skanimin. Për domenet me kardinalitet të ulët (attribute_name), projektimi i enum është i thjeshtë dhe i shpejtë. Mbështetja e vërtetë e bucketing është e kufizuar në Athinë, por një ndarje e tërë e bazuar në mod ju merr shumicën e përfitimeve. Kostoja dhe vonesa (numrat e vërtetë) 
 
 
 
 
 Pyetjet tipike: 1–2 sekonda fund-për-fund (Lambda fillon ftohtë përjashtuar) Madhësia e të dhënave: shumë TB në S3/Hudi Kostoja: pennies për 100s e kërkesave (Athena scan + Lambda invocations) Ops: afër-zero – pa serverë, pa ngjeshje manuale përtej periudhës së mirëmbajtjes së Hudi Trap të zakonshëm (në mënyrë që ju mund të kaloni ato) 
 
 
 
 
 Mos ndarje nëpërmjet fushave me kardinalitet të lartë drejtpërdrejt (p.sh., raw entity_id); ju do të shpërthejë numri i ndarjes Mos e kaloni projektimin nëse prisni që ndarjet të rriten; vetëm indeksimi nuk do t'ju shpëtojë Mos ruani metadat e ndarjes për çdo çelës nëse një rregull mund ta gjenerojë atë (projektimi ekziston pikërisht për këtë arsye) Mos lejoni që skemat Glue të lundrojnë; versiononi ato dhe validoni në CI Provoni këtë në shtëpi (një listë minimale e kontrollit) 
 
 
 
 
 
 
 
 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 Çfarë kjo zbuloi për përdoruesit e mi 
 
 
 
 
 Analistët dhe mbështetja mund të përgjigjen "pse" pa inxhinierë Produkti mund të auditojë ndryshimet e atributeve sipas kohës dhe shkakut Inxhinierët shpenzojnë më shumë kohë në riparime dhe më pak kohë në forensikë Org i beson të dhënave më shumë sepse dëshmitë janë një klik larg Mbyllja e mendimit Performanca e madhe është zakonisht një histori e vendosjes së të dhënave. Para se të shkallëzoni llogaritjen, rregulloni mënyrën se si ruani dhe gjeni bytes.Në analitikën pa server, pyetja më e shpejtë është ajo që planifikon menjëherë dhe nuk lexon pothuajse asgjë, dhe projektimi i ndarjes është levë që ju merr atje.

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

Kjo audio është prodhuar në gjuhën origjinale të tregimit!

Brenda një sistemi me kosto të ulët të linjës së të dhënave pa server të ndërtuar në AWS

About Author

KOMENTE

VARUR TAGS

KY ARTIKU U PARAQIT NË

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps