Προβληματική δήλωση Κατασκευάζω και λειτουργώ πλατφόρμες δεδομένων/ML σε πραγματικό χρόνο και ένας επαναλαμβανόμενος πόνος που βλέπω μέσα σε οποιαδήποτε οργάνωση δεδομένων είναι αυτός: «Γιατί αυτό το χαρακτηριστικό έχει αυτή την αξία;» Όταν ένα όνομα εταιρείας, βιομηχανία ή έσοδα φαίνονται λάθος, οι έρευνες συχνά σταματούν χωρίς μηχανική βοήθεια. Αυτό είναι το σχέδιο που έστειλα: Μια υπηρεσία ιχνηλασιμότητας χωρίς διακομιστή, χαμηλής συντήρησης που αναζητά terabytes σε δευτερόλεπτα και κοστίζει φιστίκια. Τι έπρεπε να κάνει αυτό το εργαλείο (για μη μηχανικούς) 
 
 
 
 
 Εξηγήστε μια τιμή: Γιατί το χαρακτηριστικό X για την εταιρεία Y είναι ίσο με το Z αυτή τη στιγμή; Εμφάνιση ιστορικού: Πότε άλλαξε; Ποιες ήταν οι προηγούμενες εκδόσεις; Εμφάνιση αποδείξεων: Ποιες πηγές και κανόνες παρήγαγαν αυτή την αξία; Να είστε αυτοεξυπηρετούμενοι: Ένα API + απλή UI, έτσι ώστε οι ομάδες να μπορούν να διερευνήσουν χωρίς μηχανικούς Η αρχιτεκτονική (serverless on purpose) 
 
 
 
 
 
 Amazon API Gateway: μια ασφαλής μπροστινή πόρτα για το API AWS Lambda: επεξεργαστές αιτημάτων χωρίς κατάσταση (χωρίς άδικο υπολογιστή για να πληρώσετε) Amazon S3 + Apache Hudi: φθηνή αποθήκευση με ταξίδια στο χρόνο και αναβαθμίσεις Κατάλογος δεδομένων AWS Glue: μεταδεδομένα σχήματος και διαχωρισμού Amazon Athena: SQL πάνω από S3/Hudi, pay-per-data-scanned, zero infra Γιατί αυτές οι επιλογές; 
 
 
 
 Κόστος: η αποθήκευση στο S3 είναι φθηνή· η Athena χρεώνει μόνο για τα σαρωμένα bytes· η Lambda είναι pay-per-invocation Σκάλα: S3/Hudi υποστηρίζει trivially TB→PB, και Athena κλίμακες οριζόντια Συντήρηση: Δεν υπάρχει στόλος για να επισκευαστεί, το ινφράν αποτύπωμα παραμένει μικρό καθώς αυξάνεται η χρήση 
 
 Διαμόρφωση δεδομένων: η απόδοση είναι ένα πρόβλημα δεδομένων (όχι ένα πρόβλημα υπολογισμού) Η Athena είναι γρήγορη όταν δεν διαβάζει σχεδόν τίποτα και αργή όταν σχεδιάζει ή σαρώνει πάρα πολύ. Η Athena είναι γρήγορη όταν δεν διαβάζει σχεδόν τίποτα και αργή όταν σχεδιάζει ή σαρώνει πάρα πολύ. . Data layout getting partitions and projection right Στρατηγική διαχωρισμού (με βάση τα πρότυπα ερωτήματος) 
 
 
 
 created_date (ημερομηνία): τα περισσότερα ερωτήματα είναι χρονικά περιορισμένα attribute_name (enum): εργαζόμενοι, έσοδα, linkedin_url, founded_year, βιομηχανία κ.λπ. entity_id_mod (integer bucket): mod(entity_id, N) για να διανείμετε ομοιόμορφα τα hot keys Αυτό περιορίζει τα δεδομένα που σαρώνονται και, το πιο σημαντικό, περιορίζει τα μεταδεδομένα διαχωρισμού που πρέπει να εξετάσει η Athena. Τα τρία πράγματα που το έκαναν γρήγορο: 
 
 
 
 
 
 
 : 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'
)
 Γιατί αυτό λειτουργεί 
 
 
 
 Η Athena δεν παίρνει πλέον μια τεράστια λίστα διαχωρισμών από το Glue. υπολογίζει διαχωρισμούς στην πτήση από τους κανόνες που αναφέρονται παραπάνω Η σάρωση πέφτει σε "μόνο τα αρχεία που ταιριάζουν με τους περιορισμούς" Ο χρόνος προγραμματισμού γίνεται αμελητέος, ακόμη και καθώς τα δεδομένα και οι διαχωρισμοί αυξάνονται Τι με εξέπληξε (και τι ήταν δύσκολο) 
 
 
 
 
 Το «gotcha» ήταν ο προγραμματισμός των ερωτήσεων, όχι ο υπολογισμός.Συχνά βελτιστοποιούμε τους κινητήρες, αλλά εδώ το πιο αργό μέρος ήταν η απαρίθμηση των διαμερισμάτων. Η επιλογή των κλειδιών διαίρεσης είναι μισή τέχνη, μισή επιστήμη. υπερ-διαίρεση και βυθίζεστε σε μεταδεδομένα. υπο-διαίρεση και πληρώνετε ανά σάρωση. Για τους τομείς χαμηλής καρδινικότητας (attribute_name), η προβολή του enum είναι τόσο απλή όσο και γρήγορη. Η υποστήριξη του πραγματικού bucketing είναι περιορισμένη στην Αθήνα, αλλά ένας διαχωρισμός ακέραιων αριθμών βασισμένος σε mod σας δίνει τα περισσότερα οφέλη. Κόστος και καθυστέρηση (πραγματικοί αριθμοί) 
 
 
 
 
 Τυπικά ερωτήματα: 1-2 δευτερόλεπτα end-to-end (εκτός των κρύων αρχών της Lambda) Μέγεθος δεδομένων: πολλαπλά TB σε S3/Hudi Κόστος: σεντς ανά 100 αιτήματα (Athena scan + Lambda invocations) Ops: κοντά στο μηδέν – χωρίς διακομιστές, χωρίς χειροκίνητη συμπίεση πέρα από τη διάρκεια συντήρησης της Hudi Κοινές παγίδες (για να μπορείτε να τις παρακάμψετε) 
 
 
 
 
 Μην διαχωρίζετε τα πεδία υψηλής καρδινικότητας απευθείας (π.χ. raw entity_id), θα εκραγεί ο αριθμός των διαχωρισμών Μην παραλείπετε την προβολή εάν αναμένετε ότι οι διαχωρισμοί θα αυξηθούν. η ευρετηρίαση από μόνη της δεν θα σας σώσει Μην αποθηκεύετε μεταδεδομένα διαχωρισμού για κάθε κλειδί εάν ένας κανόνας μπορεί να το δημιουργήσει (η προβολή υπάρχει ακριβώς γι 'αυτό) Μην αφήνετε τα σχήματα Glue να κυλήσουν. εκδοχή τους και επικύρωση σε CI Δοκιμάστε το στο σπίτι (μια ελάχιστη λίστα ελέγχου) 
 
 
 
 
 
 
 
 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 Τι αποκλείει αυτό για τους χρήστες μου 
 
 
 
 
 Οι αναλυτές και η υποστήριξη μπορούν να απαντήσουν «γιατί» χωρίς μηχανικούς Το προϊόν μπορεί να ελέγξει τις αλλαγές χαρακτηριστικών από το χρόνο και την αιτία Η μηχανική ξοδεύει περισσότερο χρόνο σε διορθώσεις και λιγότερο χρόνο στην εγκληματολογία Ο οργανισμός εμπιστεύεται τα δεδομένα περισσότερο επειδή η απόδειξη είναι ένα κλικ μακριά Κλείσιμο σκέψης Η υψηλή απόδοση είναι συνήθως μια ιστορία διάταξης δεδομένων. Πριν κλιμακώσετε τον υπολογισμό, διορθώστε τον τρόπο αποθήκευσης και εύρεσης των bytes. Στην ανάλυση χωρίς διακομιστή, το ταχύτερο ερώτημα είναι αυτό που σχεδιάζει αμέσως και δεν διαβάζει σχεδόν τίποτα και η προβολή διαχωρισμού είναι η μόχλευση που σας φέρνει εκεί.

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

Αυτός ο ήχος παράγεται στην αρχική γλώσσα της ιστορίας!

Μέσα σε ένα χαμηλού κόστους, χωρίς διακομιστή σύστημα γραμμής δεδομένων που βασίζεται στο AWS

About Author

ΣΧΟΛΙΑ

ΚΡΕΜΑΣΤΕ ΕΤΙΚΕΤΕΣ

ΑΥΤΟ ΤΟ ΑΡΘΡΟ ΠΑΡΟΥΣΙΑΣΤΗΚΕ ΣΤΟ

Related Stories

The Pros and Cons of Electric Cars

Elon Musk to ChatGPT: Please Stop

With Virgin's Collapse, Musk is Left With the Bigger Rocket 🚀

Refactoring 021 - Remove Dead Code

The Pros and Cons of Electric Cars

Elon Musk to ChatGPT: Please Stop

With Virgin's Collapse, Musk is Left With the Bigger Rocket 🚀

Refactoring 021 - Remove Dead Code

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps