Masalah Pernyataan Saya membina dan mengendalikan platform data masa nyata / ML, dan satu kesakitan yang kerap saya lihat di dalam mana-mana org data adalah ini: "Mengapa atribut ini mempunyai nilai ini?" Apabila nama syarikat, industri, atau pendapatan kelihatan salah, siasatan sering berhenti tanpa bantuan kejuruteraan. Ini adalah rancangan yang saya hantar: Perkhidmatan pelacakan tanpa pelayan, pemeliharaan yang rendah yang menyiasat terabytes dalam hitungan saat dan kos kacang-kacangan. Apa alat ini perlu dilakukan (untuk bukan jurutera) 
 
 
 
 
 Menjelaskan nilai: Mengapa atribut X untuk syarikat Y sama dengan Z pada masa ini? Tunjukkan sejarah: bila ia berubah? apa versi terdahulu? Tunjukkan bukti: Sumber dan peraturan mana yang menghasilkan nilai itu? Berkhidmat sendiri: API + UI mudah supaya pasukan boleh menyiasat tanpa jurutera Arsitektur (serverless pada tujuan) 
 
 
 
 
 
 Amazon API Gateway: pintu depan yang selamat untuk API AWS Lambda: pemproses permintaan tanpa status (tidak ada pengkomputeran kosong untuk dibayar) Amazon S3 + Apache Hudi: penyimpanan murah dengan perjalanan masa dan upserts AWS Glue Data Catalog: skim dan metadata partisi Amazon Athena: SQL di atas S3/Hudi, pay-per-data-scanned, zero infra Mengapa pilihan ini? 
 
 
 
 Kos: penyimpanan pada S3 adalah murah; Athena dikenakan bayaran hanya untuk bajet yang dipindai; Lambda adalah pay-per-invocation Skala: S3/Hudi trivially menyokong TB→PB, dan Athena skala secara horisontal Penyelenggaraan: tiada armada untuk dilipat; jejak inframerah kekal kecil apabila penggunaan meningkat 
 
 Reka bentuk data: prestasi adalah masalah data (bukan masalah pengiraan) Athena adalah cepat apabila ia membaca hampir apa-apa, dan lambat apabila ia merancang atau memindai terlalu banyak. Reka bentuk data: prestasi adalah masalah data (bukan masalah pengiraan) Athena adalah cepat apabila ia membaca hampir apa-apa, dan lambat apabila ia merancang atau memindai terlalu banyak. Strategi pemisahan (berdasarkan corak pertanyaan) 
 
 
 
 created_date (date): kebanyakan pertanyaan terhad kepada masa atribute_name (enum): pekerja, pendapatan, linkedin_url, founded_year, industri, dan lain-lain entity_id_mod (bucket integral): mod(entity_id, N) untuk menyebarkan kunci panas secara merata Ini mengehadkan data yang dipindai dan, yang lebih penting, mempersempit metadata partisi yang Athena perlu pertimbangkan. Tiga perkara yang membuatkan ia cepat: 
 
 
 
 
 
 
 : 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'
)
 Mengapa ini berfungsi 
 
 
 
 Athena tidak lagi mengambil senarai partisi yang besar daripada Glue; ia mengira partisi pada fly daripada peraturan di atas Pemindaian jatuh kepada "hanya fail yang sesuai dengan sekatan" Tempoh perancangan menjadi tidak penting, walaupun data dan partisi bertambah Apa yang mengejutkan saya (dan apa yang sukar) 
 
 
 
 
 "Gotcha" ialah perancangan pertanyaan, bukan pengiraan.Kami sering mengoptimumkan enjin, tetapi di sini bahagian yang paling lambat ialah mengira partisi. Memilih kunci partition adalah separuh seni, separuh sains. over-partition dan anda tenggelam dalam metadata; under-partition dan anda membayar setiap pemindaian. Mulakan dari 3 pencarian teratas anda dan bekerja ke belakang. Untuk domain rendah-kardinality (attribute_name), projeksi enum mudah dan cepat. Sokongan bucketing sebenar terhad di Athena, tetapi partisi nombor keseluruhan berasaskan mod memberi anda kebanyakan faedah. Kos & latency (jumlah sebenar) 
 
 
 
 
 Pertanyaan biasa: 1–2 saat akhir-ke-akhir (Lambda bermula sejuk tidak termasuk) Saiz data: beberapa TB dalam S3/Hudi Kos: sen per 100s permintaan (Athena scan + Lambda invocations) Ops: berhampiran nol – tiada pelayan, tiada kompaksi manual di luar kaden penyelenggaraan Hudi Perangkap biasa (sebab anda boleh melepaskan mereka) 
 
 
 
 
 Jangan membahagikan secara langsung oleh medan yang tinggi kardinality (contohnya, raw entity_id); anda akan meletupkan bilangan partition Jangan terlepas projeksi jika anda mengharapkan partisi untuk berkembang; indeks sahaja tidak akan menyelamatkan anda Jangan simpan metadata partisi untuk setiap kunci jika peraturan boleh menjanainya (proyeksi wujud untuk alasan itu) Jangan biarkan skim Glue mengalir; versi mereka dan mengesahkan dalam CI Cuba ini di rumah (sebuah senarai cek minimum) 
 
 
 
 
 
 
 
 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 Apa ini membuka kunci untuk pengguna saya 
 
 
 
 
 Analis dan sokongan boleh menjawab "mengapa" tanpa jurutera Produk boleh mengaudit perubahan atribut mengikut masa dan sebab Kejuruteraan menghabiskan lebih banyak masa untuk memperbaiki dan kurang masa untuk forensik org percaya data lebih kerana bukti adalah satu klik jauh Penutupan pemikiran Prestasi yang baik biasanya merupakan cerita tata letak data.Sebelum anda mengukur pengiraan, pastikan cara anda menyimpan dan mencari byte.Dalam analisis tanpa pelayan, pertanyaan yang paling cepat ialah yang merancang secara instan dan tidak membaca hampir apa-apa, dan projeksi partisi adalah lever yang membawa anda ke sana.

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

Audio ini dihasilkan dalam bahasa asal cerita!

Di dalam sistem Lineage Data Serverless berbiaya rendah yang dibina pada AWS

About Author

KOMEN

GANTUNG TANDA

ARTIKEL INI DIBENTANGKAN DALAM

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps