問題声明 私はリアルタイムのデータ/ML プラットフォームを構築し、運営し、あらゆるデータ機関の内部で繰り返し見られる痛みの一つは、「なぜこの属性がこの価値を持っているのですか?」 会社の名前、業界、または収益が間違っているように見えると、調査はしばしばエンジニアの助けなしに止まります。 これは私が配信したブループロジェクトです:サーバーなしで、メンテナンスが低い追跡性のサービスで、テラバイトを数秒でクエリし、サラダにコストがかかります。 このツールが何をすべきか(非エンジニア向け) 
 
 
 
 
 値を説明する:なぜ会社 Y の属性 X が現在 Z に等しいのか? 過去のバージョンは? いつ変わった? 過去のバージョンは? 証拠を示す:どのソースやルールがその価値を生み出したか? 自己サービス:API+シンプルなUIで、エンジニアなしでチームが調査できる アーキテクチャ(serverless on purpose) 
 
 
 
 
 
 Amazon API Gateway:APIのセキュアなフロントゲート AWS Lambda: stateless request handlers (no idle compute to pay for) Amazon S3 + Apache Hudi:安価なストレージとタイムトラベル AWS Glue Data Catalog: スケジュールとパーティションメタデータ Amazon Athena: SQL over S3/Hudi, pay-per-data‐scanned, zero infra なぜこれらの選択? 
 
 
 
 コスト:S3のストレージは安い; Athena はスキャンされたバイトのみを請求します; Lambda は呼び出しごとに有料です。 スケール:S3/HudiはTB→PBをサポートし、Athenaは水平スケールをサポートします。 メンテナンス: パッチするフロートはありません; 使用量が増加するにつれてインフラ足跡は小さく残ります。 
 
 データレイアウト:パフォーマンスはデータの問題(コンピューティングの問題ではない) Athena は、ほとんど何も読まないときに速く、あまり計画したりスキャンしたりしたときに遅い。 : パフォーマンスはデータの問題(コンピューティングの問題ではない) Athena は、ほとんど何も読まないときに速く、あまり計画したりスキャンしたりしたときに遅い。 . Data layout getting partitions and projection right 分割戦略(クエリパターンに基づく) 
 
 
 
 created_date (date): ほとんどのクエリは時間制限付きです。 attribute_name (enum):従業員、収入、linkedin_url、founded_year、業界など entity_id_mod (integer bucket): mod(entity_id, N) to spread hot keys evenly これは、スキャンされたデータを制限し、さらに重要なことに、Athena が考慮する必要があるパーティションメタデータを狭めます。 それを速くする3つの事柄: 
 
 
 
 
 
 
 : 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から巨大なパーティションリストを取得しませんが、上記のルールからフライのパーティションを計算します。 スキャンは「制約に合ったファイルのみ」に下がります。 プランニング時間は、データやパーティションが伸びるにつれてさえ無視される 何が私を驚かせたのか(そして何が辛かったのか) 
 
 
 
 
 「ゴッチャ」は、クエリの計画ではなく、コンピューティングでした。我々はしばしばエンジンを最適化しましたが、ここで最も遅い部分はパーティションの列挙でした。 Partition keys picking is half art, half science. Over-partition and you drown in metadata; under-partition and you pay per scan. あなたのトップ3クエリの予測から始め、後ろ向きに作業します。 Enum パーティションは過小評価されています. For low‐cardinality domains (attribute_name), enum projection is both simple and fast. Enum パーティションは低 cardinality ドメイン (attribute_name) の場合、enum プロジェクションはシンプルで高速です。 True bucketing サポートは Athena では限られていますが、mod ベースの整数パーティションはほとんどの利点を提供します。 コストと遅延(現実数字) 
 
 
 
 
 一般的なクエリ:1～2秒(Lambdaの冷たいスタートを除く) データサイズ: 複数の TB in S3/Hudi コスト: 100 件のリクエストごとにペニー(Athena scan + Lambda invocations) Ops: near-zero — no servers, no manual compression beyond Hudi maintenance cadence (サーバーなし、Hudiのメンテナンスカデンスを超えるマニュアル圧縮なし) 共通の落とし穴(あなたはそれらを逃すことができます) 
 
 
 
 
 High-cardinality fields directly (e.g., raw entity_id) によるパーティションを直接作成しないでください; you will explode the partition count パーティションが成長することを期待する場合は、投影を逃さないでください; indexing alone won't save you ルールがそれを生成できる場合、各キーのパーティションメタデータを保存しないでください(プロジェクションはその理由で存在します) Glue スケジュールをドリフトすることを許さないでください; version them and validate in 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 What this unlocked for my users (これが私のユーザーに何を解除したか) 
 
 
 
 
 アナリストとサポートは、エンジニアなしで「なぜ」と答えることができます。 Product can audit attribute changes by time and cause. 製品は、時間と原因による属性の変化を監査することができます。 エンジニアリングは修正により多くの時間を費やし、法医学により少ない時間を費やす orgはデータをより信頼しているので、証拠は1クリック離れたところにあります。 閉鎖思考 優れたパフォーマンスは通常、データレイアウトストーリーです。スケールアップする前に、バイトを保存して見つける方法を修正します。サーバーレスアナリティクスでは、最速のクエリは、すぐに計画し、ほとんど何も読まないクエリであり、パーティションプロジェクションはあなたをそこに導くリバーです。

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

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps