Amazon Data FirehoseでApache Icebergテーブルに配信する際の「一意のキー設定」と「JSONQuery式（JQ式）」の違いについて | DevelopersIO
お疲れさまです。とーちです。 前回、Firehoseを使ったAmazon S3 Tablesへのレコード配信の記事を書きました。今回は、その続編として、Amazon Data Firehose（以下、Firehose）でApache Icebergテーブルにデータを配信する際の設定の中の「一意のキー設定」と「JQ式」の違いについて詳しく解説したいと思います。この2つの設定は似ているようで役割が異なり、使い分けや併用のポイントを押さえておくことが重要です。 JQ式と一意キー設定の関係 JQ式と一意キー設定の関係を簡単に書くと以下のようになります。 JQ式：どのデータベース、どのテーブルに、どの操作（insert/update/delete）を行うかを決定します 一意キー設定：更新・削除操作時に、対象レコードを特定するためのキーを定義します また、これらは併用可能である点がポイントです。それぞ
Amazon AthenaのIcebergテーブルのメタデータと使い所 | DevelopersIO
データ事業本部の鈴木です。 Icebergテーブルはさまざまなエンジンから利用できる特徴から、とても注目されていますが、Amazon Athenaでも以前から利用可能です。 例えばタイムトラベル機能を利用する際、メタデータを確認することでどのタイミングでどのスナップショットだったかなどを簡単に確認でき、メタデータの確認方法を知っているととても便利です。今回は現時点でAthenaのIcebergテーブルが提供しているメタデータ情報を確認しました。 Athenaでクエリできるメタデータ 現状、以下のテーブルメタデータを簡単にAthenaからクエリできるようになっています。 $files：現在のデータファイルを表示 $manifests：現在のマニフェスト情報を表示 $history：テーブルの履歴を表示 $partitions：現在のパーティションを表示 $snapshots：スナップショット
Amazon S3 Tables の Iceberg テーブルに Amazon Athenaから更新クエリを試す！（今更だったらゴメンね） | DevelopersIO
クラウド事業本部コンサルティング部の石川です。本日は、Amazon S3 TablesのIcebergテーブルに対するAmazon Athenaからの更新クエリの実行可能性と、Amazon S3 TablesとIceberg Tables on Amazon S3のパフォーマンス比較について解説します。 Amazon Athenaから更新クエリを試す！って今更？ re:Invent2024で Amazon S3 Tablesが発表になった直後は、ワクワクして一番最初にAmazon Athenaで様々なクエリの実行を試していたはずでした。私の記憶が正しければ、Amazon S3 Tables の Iceberg テーブルに Amazon Athenaから更新クエリはエラーになっていたと思います。 ところが、亀田さんが、「Amazon S3 Tables のハンズオンを今度やるので簡単な手順を
How Amazon S3 Tables use compaction to improve query performance by up to 3 times | Amazon Web Services
AWS Storage Blog How Amazon S3 Tables use compaction to improve query performance by up to 3 times Today businesses managing petabytes of data must optimize storage and processing to drive timely insights while being cost-effective. Customers often choose Apache Parquet for improved storage and query performance. Additionally, customers use Apache Iceberg to organize Parquet datasets to take advan
Amazon S3 Tables と Iceberg Tables on Amazon S3 のパフォーマンス比較 #AWSreInvent | DevelopersIO
AWS事業本部コンサルティング部の石川です。 この記事は AWS Analytics Advent Calendar 2024 の 22 日目の記事です。 Amazon S3 Tables は、「クエリパフォーマンスが最大 3 倍高速になり、1 秒あたりのトランザクション数が最大 10 倍」と言われています。本日は、「Amazon S3 Tables vs Iceberg Tables on Amazon S3 」と題して、パフォーマンスを比較したいと思います。 どのようなクエリが速くなるのか 具体的にどのようなクエリが速くなるのかについて考察します。 セルフマネージドテーブルストレージと比較すると、クエリパフォーマンスが最大 3 倍高速になり、1 秒あたりのトランザクション数が最大 10 倍になる 引用: Amazon Web Services ブログ の Amazon S3 の新しいテ
Amazon S3 Tables の Iceberg テーブルを Amazon QuickSight で可視化する #AWSreInvent | DevelopersIO
クラウド事業本部コンサルティング部の石川です。本日は、Amazon S3 Tables の Iceberg テーブルに Amazon QuickSight から可視化してみます。クエリを実行するIcebergテーブルは、以前のブログで作成したものを用います。 Amazon QuickSight からアクセスの概要 Amazon QuickSight からAmazon S3 Tables の Iceberg テーブルは、直接参照できないためリソースリンクを作成します。リソースリンクというのがデータベースの代わりになるものだとイメージしてください。 また、Amazon QuickSight サービスロール（aws-quicksight-service-role-v0）にIAM権限付与しますが、実際のリソースリンクやテーブルにアクセスするのは、Amazon QuickSight 管理者ユーザーの
Apache Iceberg の CoW と MoR 〜 データの読み取りと書き込みのパフォーマンスのバランスを取るための2つの戦略 | DevelopersIO
CoW と MoR の選択基準 データのアクセスの要件に応じて、読み取り重視ならCoW、書き込み重視ならMoRを選択することをお勧めします。ユースケースに応じて最適なパフォーマンスを実現するためにテーブルごとにCoWとMoRを適切に組み合わせることができます。 MoR: 頻繁な更新が必要な場合 ストリーミングデータ処理 IoTデバイスからのリアルタイムデータストリーム オンラインプラットフォームからの継続的なイベントデータ 頻繁な更新が必要なデータ ユーザープロファイル情報 リアルタイムの分析ダッシボード CoW: 読み取り性能が重要な場合 読み取り重視のワークロード データウェアハウスの分析クエリ ビジネスインテリジェンスレポート 履歴データの分析 大規模な一括更新 日次バッチジョブ 定期的なデータアーカイブ 履歴データの分析 CoW と MoR のサポート状況 Amazon Athen
Amazon S3 Tables の Iceberg テーブルにS3上のデータファイルをロードしてみる #AWSreInvent | DevelopersIO
AWS事業本部コンサルティング部の石川です。本日は、Amazon S3 Tables のIcebergテーブルにサンプルデータ「SSB」のcustomerデータ（GZIP圧縮100MB、300万レコード）をロードする方法を紹介します。データファイルは以下のブログで紹介しているファイルです。 なお、先日のブログでは、Amazon S3 Tables を AWS Glue 用いてNamespaceとテーブルの作成、データ追加・削除までやってみました。基本的な動きは、こちらのブログを参照してください。 AWS Glue でNamespaceとテーブルの作成、データ追加 以降の検証は、US East (N. Virginia) us-east-1 リージョンで実施しました。 マネジメントコンソールからテーブルバケットを作成 [Table buckets New ]のメニューを選び、[Create
Amazon Athena Icebergテーブルで100パーティションの壁を超えてみた | DevelopersIO
AWS事業本部コンサルティング部の石川です。Amazon Athena は、INSERTなど一度に100パーティションを超える書き込みができません。ある時、「あれ、100パーティション超えてるやん」って事があり、それをきっかけに、何ができて何ができないのか、悶々と検証した結果、100パーティションの壁を超える方法をご紹介したいと思います。 先に結論 100パーティション超えたい場合は、Icebergテーブルフォーマとを用いて、パーティションの指定をbucket(100, <指定したいカラム名>)とする。 bucket(100, <指定したいカラム名>)は、ハッシュに基づき100のパーティションに分類されるため、パーティション内ではスキャンが発生する この方法を使用すると処理時間が長くなる傾向があり、バーティション数によっては、100パーティションの制限とは異なる理由で、エラーになる可能性が
Amazon AthenaのIcebergのVACUUM・OPTIMIZE実行時のS3上のデータファイルについて確認してみた | DevelopersIO
データ事業本部 インテグレーション部 機械学習チームの鈴木です。 Amazon Athenaでは、Icebergテーブル向けにVACUUMとOPTIMIZEのメンテナンスコマンドが提供されていますが、これらを実行すると実際のところS3上のデータファイルがどのように変わるのか確認してみました。 Icebergテーブルをメンテナンスコマンドなしで運用していると、S3上でファイルがたくさんできることで性能低下やコスト増につながります。意図せぬパフォーマンス低下や課金が起こった際に、適切に対応ができるよう、簡単な例でメンテナンスコマンド実行時にどのようなことが起こるのか把握していると便利です。 メンテナンスコマンドについて Amazon Athenaでは、Icebergテーブル向けにVACUUMとOPTIMIZEのメンテナンスコマンドが提供されています VACUUMはスナップショットの期限切れと孤
Amazon AthenaとAWS Glueを使ってHiveテーブルからIcebergテーブルに移行する | DevelopersIO
データアナリティクス事業本部インテグレーション部機械学習チーム・新納（にいの）です。 Amazon Athenaで利用可能なテーブルフォーマットのひとつであるIcebergでは、ACIDトランザクションやタイムトラベル機能をサポートしたりスキーマ変更に追従できたりと、さまざまな便利な機能が提供されています。UPDATE/DELETE/MERGEといったデータ編集もSQLを経由して行えますので、AthenaとStep Functionsを組み合わせたETLフローも作りやすくなりました。 こうした便利な機能を利用するため、既存のHive形式のテーブルをIcebergに移行したいケースも出てくるかもしれません。 今回はそんなケースを想定していくつか移行方法をご紹介します。 気をつけるポイント Athenaでは、CREATE TABLE AS SELECT（CTAS）を使ってテーブルを作成する際に
【資料公開】Iceberg で Amazon Athena をデータウェアハウスぽく使おう #midosuji_tech | DevelopersIO
データアナリティクス事業本部インテグレーション部機械学習チーム・新納（にいの）です。 2024/6/12にクラスメソッド大阪オフィスで開催された勉強会、Midosuji Techにて「Iceberg で Amazon Athena をデータウェアハウスぽく使おう」というタイトルで登壇をしました。ご参加いただいた皆様、ありがとうございました！ワイワイガヤガヤタイムでもたくさんのご質問をいただき、楽しい時間を過ごすことができました！ 本エントリでは登壇資料と内容のまとめをお届けします。 スライド 内容まとめ Icebergの概要と、その特徴の中から特にSchema Evolutionとパーティション管理の便利さをお話ししました。 テーブルフォーマットとは Icebergはテーブルフォーマットのひとつです。テーブルフォーマットについて順を追って説明します。 データレイクはデータファイルをストレー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
S3 Tables 向けの Iceberg REST Catalog API が追加されたので、PyIcebergからアクセスしてみた。 | DevelopersIO