Проблема заяви Я будую і працюю з реальними даними / платформами ML, і один з повторних болів, які я бачу всередині будь-якого органу даних, це: "Чому цей атрибут має цю цінність?"Коли ім'я компанії, галузь або доходи виглядають неправильно, розслідування часто зупиняються без інженерної допомоги. Це план, який я відправив: серверна послуга відстеження з низьким рівнем обслуговування, яка запитує терабайти за секунди і коштує арахіси. Що потрібно для цього інструменту (для неінженерів) 
 
 
 
 
 Поясніть значення: Чому атрибут X для компанії Y дорівнює Z прямо зараз? Показати історію: Коли це змінилося? Які були попередні версії? Покажіть докази: Які джерела і правила створили цю цінність? Будьте самообслуговуючими: API + простий інтерфейс, щоб команди могли досліджувати без інженерів Архітектура (сервер без наміру) 
 
 
 
 
 
 Amazon API Gateway: захищені двері для API AWS Lambda: обробники запитів без статусу (без зайвих обчислень, за які потрібно платити) Amazon S3 + Apache Hudi: дешеве зберігання з подорожами в часі та оновленнями Каталог даних AWS Glue: метадані схеми та розділів Amazon Athena: SQL над S3/Hudi, платіж за даними, нульовий інфрачервоний Чому ці вибори? 
 
 
 
 Вартість: зберігання на S3 є дешевим; Athena оплачує тільки скановані байти; Lambda платить за виклик Шкала: S3/Hudi тривіально підтримує TB→PB, а Athena шкала горизонтально Підтримка: немає флоту, щоб налаштувати; інфрачервоний відбиток залишається невеликим, оскільки використання зростає 
 
 Розклад даних: продуктивність - це проблема даних (не обчислювальна проблема) Athena швидко читає майже нічого, і повільно, коли планує або сканує занадто багато. Розклад даних: продуктивність - це проблема даних (не обчислювальна проблема) Athena швидко читає майже нічого, і повільно, коли планує або сканує занадто багато. Стратегія розділення (заснована на шаблонах запитів) 
 
 
 
 created_date (дата): більшість запитів обмежені часом attribute_name (enum): співробітники, доходи, linkedin_url, founded_year, промисловість і т.д. entity_id_mod (integer bucket): mod(entity_id, N) для рівномірного поширення гарячих клавіш Це обмежує скановані дані і, що більш важливо, звужує те, які метадані розділів 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; він обчислює розділи на флай з правил вище Сканування падає до "лише ті файли, які відповідають обмеженням" Час планування стає незначним, навіть коли зростають дані та розділи Що мене здивувало (а що було важко) 
 
 
 
 
 «Готча» – це планування запитів, а не обчислення.Ми часто оптимізуємо двигуни, але тут найповільнішою частиною було перерахування розділів. Вибір роздільних клавіш - це наполовину мистецтво, наполовину наука. Надрозділ і ви потонули в метаданих; підрозділ і ви платите за сканування. Для доменів з низькою кардинальністю (attribute_name) проекція enum є як простою, так і швидкою. Підтримка справжнього букетування обмежена в Афінах, але цілісний розділ на основі моде отримає більшість переваг. Вартість та затримка (реальні цифри) 
 
 
 
 
 Типові запити: 1-2 секунди від кінця до кінця (Ламбда не включає холодний старт) Розмір даних: кілька ТБ в S3/Hudi Вартість: пенни на 100 запитів (сканування Athena + виклики Lambda) 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 Що це розблокувало для моїх користувачів 
 
 
 
 
 Аналітики та підтримка можуть відповісти «чому» без інженерів Продукт може перевіряти зміни атрибутів за часом і причиною Інженери витрачають більше часу на виправлення і менше часу на криміналістику Орган довіряє даним більше, тому що докази віддалені одним кліком Закриття думки Велика продуктивність зазвичай є історією розміщення даних. Перш ніж масштабувати обчислення, виправити, як ви зберігаєте і знаходите байти. У безсерверній аналітиці, найшвидший запит - це той, який планує миттєво і майже нічого не читає, а проекція розділів - це важель, який вас там.

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

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps