本記事は 2026 年 8 月 28 日 に公開された「 Razor Group’s journey to a modern data lakehouse on AWS 」を翻訳したものです。 Razor Group は、複数のグローバルマーケットプレイスで 250 以上のブランドを展開する、欧州有数の EC アグリゲーターです。売上高は 4 億ドルを超え、ダイナミックプライシングや在庫最適化から広告費の配分、サプライチェーンの制御に至るまで、あらゆる重要な経営判断をデータで支えています。 事業の中心にあるのが、独自プラットフォームの Razor Operating System (ROS) です。9,300 以上のデータパイプラインを通じて月間 3 億 7,000 万件を超える API 呼び出しを処理し、マーケットプレイスのシグナルを大規模な自動アクションへと変換しています。 本記事では、Razor Group が AWS 上に レイクハウスアーキテクチャ を構築し、データプラットフォームを最適化した方法を紹介します。アーキテクチャ上の意思決定、段階的な移行アプローチ、そして測定可能なビジネス成果を取り上げます。ワークロードのパフォーマンス向上、インフラコストの削減、分析基盤でのマルチエンジン対応、いずれを目指す場合でも、本記事の設計図から自社に合わせて応用できる具体的な知見が得られます。 ビジネス課題: 急成長を支えるデータ基盤のスケーリング Razor Group のブランドポートフォリオが急速に拡大するにつれ、データプラットフォームへの要求も大きく高まりました。価格決定、在庫補充、広告入札がほぼリアルタイムで行われる EC のスピードに、分析基盤を追随させる必要があったのです。 Amazon Redshift のプロビジョンドクラスターで構築した既存アーキテクチャは、初期の成長段階では十分に役割を果たしていました。しかしワークロードが多様化しデータ量が急増すると、いくつかの最適化の余地が見えてきました。 図 1: 移行前の Razor Operating System データアーキテクチャ ワークロードの競合 : ETL、変換、分析用の 1,000 を超える SQL モデルが同じコンピューティングリソースを取り合い、処理のピーク時に競合が発生していました。 コストと使用率のミスマッチ : クラスターは 24 時間 365 日稼働し続けていましたが、ワークロードを分析すると、コンピューティング需要の 98% はインタラクティブな分析ではなくバッチ ETL によるものでした。その結果、オフピーク時に大量のアイドル容量が生じていました。 データ鮮度のギャップ : バッチ中心のパイプラインではデータの反映に 4〜6 時間の遅延があり、動きの速いマーケットプレイスの状況にチームが対応しきれませんでした。 スケーリングの制約 : 同時利用ユーザーとパイプラインの複雑さが増すなか、垂直スケーリングだけでは、ワークロードを分離したい、容量を柔軟に調整したいというニーズには応えられませんでした。 いずれも特定のサービスの欠陥ではありません。Razor Group のワークロードの規模と多様性に合わせて、アーキテクチャを進化させる時期に来ていることを示すものでした。 なぜレイクハウスアーキテクチャなのか Razor Group は既存の投資を置き換えるのではなく、モダンなレイクハウスアーキテクチャを採用して ワークロードの配置を最適化する 機会があると捉えました。意思決定を後押しした基本原則は次のとおりです。 オープンテーブルフォーマット : Apache Iceberg は ACID トランザクション、タイムトラベル、スキーマ進化を備えています。データは一度だけ保存され、互換性のあるどのエンジンからも重複なくアクセスできます。 ワークロード単位の柔軟なスケーリング : データを Amazon Simple Storage Service (Amazon S3) に永続化することで、各エンジンが自身のワークロードに合わせて独立してコンピューティングをスケールできます。各エンジンはピーク処理時に起動し、アイドル時にはゼロまでスケールダウンするため、共有インフラを過剰にプロビジョニングせずに済みます。 マルチエンジンの柔軟性 : ワークロードごとに要件は異なります。負荷の高い ETL は分散 Spark 処理、アドホックな探索はサーバーレスクエリ、ビジネスインテリジェンス (BI) ダッシュボードは高性能なウェアハウスエンジンと、それぞれの目的に最適なエンジンを活用できます。 こうした方針により、Razor Group はプラットフォーム全体からアクセスできる、ガバナンスの効いた単一のデータコピーを維持しつつ、 各ワークロードを最適なエンジンに適正配置 できるようになりました。 ソリューションの概要 Razor Group は AWS と協力し、複数の AWS サービスがそれぞれ補完的な役割を担う包括的なレイクハウスアーキテクチャを構築しました。 図 2: AWS 上のエンドツーエンドのレイクハウスアーキテクチャ スケールを見据えた設計: レイクハウスのビジョン Razor Group の新アーキテクチャを支えた核心はシンプルでした。どのエンジンからもクエリできる、単一のオープンフォーマットデータレイクを構築することです。旧モデルでは、ツールごとに独自のデータコピーを保持していました。新モデルでは、Amazon S3 上の単一のオープンフォーマットデータレイクが信頼できる唯一の情報源となり、目的別に用意した複数のコンピューティングエンジンが、その時々のワークロードに応じてそこからデータを読み取ります。 一般にレイクハウスアーキテクチャと呼ばれるこの転換は、データレイクのコスト効率とスケーラビリティに、データウェアハウスのクエリ性能とガバナンスを組み合わせたものです。レイクハウスのオープンテーブルフォーマットである Apache Iceberg は、ACID トランザクション、スキーマ進化、タイムトラベルを提供し、ベンダーロックインもありません。 ストレージとガバナンス: オープンなデータ基盤 Apache Iceberg を用いた Amazon S3 Tables (Amazon S3 の機能) — 主要なストレージレイヤーであり、ACID トランザクション、パーティション進化、タイムトラベルを備えたオープンフォーマットのテーブルを提供します。データは一度だけ保存され、Iceberg 互換のどのエンジンからもアクセスできます。 AWS Glue Data Catalog — すべてのコンピューティングエンジンで一貫したデータ探索を実現する、統合メタデータリポジトリです。 AWS Lake Formation — 列レベル・行レベルのセキュリティによるきめ細かなアクセス制御を提供し、ガバナンスをプラットフォームの成長に合わせてスケールさせます。 コンピューティング: 適切なワークロードに適切なエンジンを Amazon Elastic Compute Cloud (Amazon EC2) 上の Apache Spark — 負荷の高い ETL や変換ワークロード向けの、柔軟な分散コンピューティングです。コスト最適化のために AWS Graviton インスタンスと Amazon EC2 スポットインスタンスを利用します。 Amazon Athena — アドホックな探索や軽量なクエリを、Iceberg テーブルに対して直接実行できるサーバーレス SQL です。管理すべきインフラはありません。 Amazon Redshift Serverless — BI ダッシュボード、Tableau のワークロード、インタラクティブ分析向けの高性能なサービングレイヤーです。Amazon Redshift Serverless は需要に応じて自動的にスケールし、アイドル時には一時停止するため、最も得意とする分析ワークロードでコスト効率を保ちます。 オーケストレーションとオブザーバビリティ Apache Airflow — 依存関係の追跡とサービスレベルアグリーメント (SLA) の監視により、9,300 を超えるデータパイプラインを管理するパイプラインオーケストレーションです。 包括的なオブザーバビリティスタック — すべてのレイヤーにわたるコスト配賦、パイプラインの正常性監視、データ品質チェックを実現します。 注: このアーキテクチャを当初設計した時点では、Amazon Redshift が Iceberg への書き込みに対応していなかったため、セルフマネージドの Spark が唯一実現可能な取り込み経路でした。この制約はすでに解消されています。 Amazon Redshift は現在、Apache Iceberg の DML (UPDATE、DELETE、MERGE) を完全にサポート しており、従来の CREATE/INSERT 機能や AWS Glue の Iceberg マテリアライズドビューを補完します。これにより、読み書きの両方に対応した完全な Iceberg エンジンとなりました。 移行アプローチ Razor Group は、リスクの高い一括切り替えではなく、5 つのステージからなる段階的な移行を採用しました。各ステージはそれ単体で価値を生みながら、次のステージの土台を築きます。移行期間中は Amazon Redshift と Spark の両パイプラインを並行稼働させ、事業継続性を保ちつつ、チームが出力を確実に比較できるようにしました。本番パイプラインが停止したり、ダッシュボードが利用できなくなったりする瞬間は一度もありませんでした。 移行の道のり: 5 つのフェーズ 移行は体系化された 5 つのフェーズで進み、各フェーズが前段を土台としつつ、次に進む前に段階的な価値を提供しました。 フェーズ 1: レイクハウスの基盤を確立する クエリを 1 つ移行する前に、Razor Group は 3 つの問いに答える必要がありました。データはどこに置くのか、どう管理するのか、そしてどうクエリするのか、という問いです。 セルフマネージドの Iceberg ではなく S3 Tables を選んだ理由 Razor Group はすでに、テーブルフォーマットとして Apache Iceberg の採用を決めていました。オープンでエンジンに依存せず、ACID トランザクションとタイムトラベルを備えているためです。残る問いは、標準の S3 バケット上で Iceberg をセルフマネージドで運用するか、Amazon S3 Tables を使うかでした。 セルフマネージドの Iceberg は強力ですが、運用コストがかさみます。スモールファイルの増殖を防ぐためにコンパクションジョブを回す担当者が必要です。メタデータの肥大化がクエリプランニングを劣化させる前に、古いスナップショットを期限切れにする担当者も必要です。書き込みが中断した後に残る孤立したデータファイルを片付ける担当者も要ります。40 以上のスキーマにまたがる 700 以上のモデルが稼働し、その多くが 1 日に複数回マテリアライズされる環境では、こうした保守負荷はプラットフォームの成長とともに縮小するどころか拡大してしまいます。 S3 Tables は、こうした一連の作業をまるごと不要にしました。コンパクション、スナップショット管理、参照されないファイルの削除が、継続的かつ自動的に実行されます。統合された Iceberg REST Catalog API により、Spark、Trino、Athena、Amazon Redshift、Flink など互換性のあるエンジンは、個別のメタストアを維持することなくテーブルを検出してクエリできます。探索は AWS Glue Data Catalog を通じて統一されており、同カタログは現在、Iceberg REST Catalog プロトコルをアクセスインターフェイスとして公開しています。テーブルがファーストクラスの AWS リソースであるため、アクセス制御、暗号化、ライフサイクルポリシーは、ファイルパスの命名規則の上に複雑な S3 バケットポリシーを重ねるのではなく、テーブルレベルで機能します。 オープンテーブルフォーマットの保守をセルフマネージドで抱え込みたくない企業にとって、これが決め手となりました。 AWS Glue Data Catalog は、すべての階層にわたる統合メタデータ探索を提供します。Lake Formation は列レベル・テーブルレベルのアクセス制御を担い、最小権限の原則に従う AWS Identity and Access Management (IAM) ロールと、完全な監査証跡のために有効化した AWS CloudTrail を組み合わせています。 クエリプロトコルの選択 アーキテクチャの再設計前、Amazon Redshift クラスターの処理は 98% が ETL で、アナリストの SELECT クエリはコンピューティング時間のごく一部にすぎませんでした。置き換えるエンジンには、負荷の高いバッチ変換と、インタラクティブなアドホッククエリの両方に対応できることが求められました。 従来の Spark (spark-submit) はバッチ ETL をうまく処理しますが、クライアントとクラスターが密結合になります。ジョブごとにドライバー JAR のパッケージング、クラスパスの管理、クラスター内部からの投入が必要です。日々膨大なデータ量を処理する 200 以上の本番用有向非巡回グラフ (DAG) を運用するプラットフォームにとって、こうした運用上の摩擦は受け入れがたいものでした。 Spark Connect は、Spark 3.4 で導入された gRPC ベースのクライアント/サーバープロトコルであり、この密結合の問題を完全に解決しました。クラスターは永続的な gRPC エンドポイントを稼働させます。クライアントはリモートで接続し、クエリをネットワーク越しに投入します。Airflow のオペレーターはシンクライアントになります。セッションを開き、SQL を投入して結果を受け取り、成功と失敗がそのままタスクの状態に対応します。ドライバー JAR もポーリングも不要です。パイプラインのオーケストレーター、ウェブアプリケーション、開発者のノートブックなど複数の利用者が、いずれもローカルに Spark をインストールすることなく 1 つのクラスターを共有できます。 Spark Connect のデプロイ Razor Group は、Amazon EC2 上にセルフホストの Spark クラスターをデプロイしました。オンデマンドの AWS Graviton リーダーノード、約 70% のコスト削減となるスポットワーカー、そして内部の Network Load Balancer を通じて公開した Spark Connect エンドポイントで構成されています。カスタムの Amazon マシンイメージ (AMI) に Spark、Iceberg、S3 Tables の一式を組み込んであるため、プライベートサブネットのノードは実行時にインターネットへアクセスしなくても必要なものをすべて備えています。 このフェーズ自体は直ちにビジネス価値を生むものではありませんでしたが、その後のすべてを可能にしました。 フェーズ 2: データ取り込みを移行する Razor Group の取り込みレイヤーは、Amazon Selling Partner API、Seller Central ポータル、NetSuite ERP、そして独自のウェブスクレイパーからデータを取得します。旧アーキテクチャでは、これらすべてが COPY コマンドを通じて Amazon Redshift に取り込まれていました。そのためデータ鮮度はバッチジョブのスケジュールに左右され、分析クエリを処理するのと同じクラスター上でリソースを奪い合っていました。 Razor Group は取り込みパイプラインを、Apache Airflow がオーケストレーションする AWS Lambda 関数へ移行し、データを Iceberg 形式で S3 Tables に直接書き込むようにしました。スケジュール駆動からイベント駆動への転換により、鮮度が大幅に向上しました。Lambda 関数は処理すべきデータがあるときにのみ起動し、Airflow のセンサーは新しいデータが到着した瞬間に下流の変換をトリガーします。その結果、1 時間ごとの固定的なバッチウィンドウは、分単位で測れるデータ鮮度に置き換わりました。 オーケストレーションレイヤーは、90 以上のフローにまたがる 200 以上の DAG を管理し、数十のソースからのデータを大規模に処理します。移行にあたっては、書き込み先を Amazon Redshift の COPY から Iceberg 書き込みへ配線し直す必要がありましたが、オーケストレーションのロジック自体は最小限の変更で引き継げました。 このフェーズだけで、取り込みにおける常時稼働クラスターへの依存を断ち切り、コンピューティングコストを約 40% 削減しました。 フェーズ 3: 処理パイプラインを変換する フェーズ 3 は技術的に最も難易度が高く、Razor Group が最も多くを学んだフェーズでもありました。チームは 1,000 以上の SQL モデルを Amazon Redshift から Apache Spark へ移行し、40 以上のスキーマにまたがる依存関係の連鎖を段階的にたどりながら進めました。モデルはメダリオン構造に沿って移行しました。取り込んだ生データの Bronze、クレンジングして整形したデータの Silver、そしてビジネスで即利用できる集計データの Gold です。 Razor Group は自動変換ツールと検証フレームワークを構築し、Amazon Redshift と Spark の出力を並行して実行して、何かを廃止する前に結果を 1 行ずつ比較しました。いくつかの種類の変換は、自動化で対応できる限界を試すものでした。 ウィンドウ関数 : Amazon Redshift の QUALIFY 句には Spark に相当するものがありません。使用箇所ごとに明示的な行番号付けを伴うサブクエリでラップする必要があり、在庫スキーマだけでも数十のモデルに影響しました。 JSON のシリアライズ : 最も時間を要したカテゴリです。Amazon Redshift で JSON STRING として格納されていた複雑な列は、Spark では手書きの STRUCT 定義を伴う from_json() が必要でした。広告、注文、取引の各パイプラインにわたるネストされたペイロード列はいずれもスキーマの調査を要し、近道はありませんでした。 関数の方言 : NVL から COALESCE、DATEADD からインターバル演算、LISTAGG から ARRAY_JOIN(COLLECT_LIST()) など、20 を超える関数レベルの変換がありました。 スナップショットの排除 : 最大の隠れたコストでした。ある時点の状態を保存するためだけに 1 日に複数回実行されるテーブル全体のコピーは、週あたり 35 時間を超える Amazon Redshift のコンピューティングを消費していました。Iceberg のネイティブなタイムトラベルにより、これらは一夜にしてコストゼロの操作になりました。 1,000 以上の SQL モデルを移行する際、機械的な構文変換は自動化ツールでうまく処理できます。しかしモデルの約 30% は人間の判断を必要としました。複雑な JSON ペイロード、深くネストされたウィンドウ関数、スキーマをまたぐスナップショット依存を含むモデルです。これらのモデルが移行工数の 70% を占めました。 Razor Group は、この作業を加速するために Claude を活用した構造化された移行ワークフローを構築しました。ソース SQL を読み取り、依存関係を特定し、構文を変換し、不足しているベーステーブルを解決し、JSON パースを追加し、出力を検証してレイクハウスに書き込む、という流れです。このシステムは単に SQL を変換するだけではありませんでした。スキーマのコンテキストを適用し、モデル間の依存関係をたどり、エンジニアが手作業で見つけるには何時間もかかるようなエッジケースを検出しました。数年がかりになりかねなかった取り組みが、数週間で測れる体系的かつ再現可能なプロセスになったのです。このアプローチは移行のスピードを根本から変えました。 フェーズ 4: サービングレイヤーを統一する データが Iceberg テーブルを流れるようになったことで、Razor Group はサービングレイヤーを 1 つに集約しました。エンドユーザーは Amazon Redshift Serverless を通じて Gold レイヤーの Iceberg テーブルにクエリを実行し、社内の探索や機械学習 (ML) のワークロードは Spark Connect を通じて同じテーブルを読み取ります。利用者ごとに別々のデータコピー、マテリアライズドビュー、抽出ジョブを維持する必要はなくなりました。 これがオープンテーブルフォーマットの戦略的な成果です。S3 上の Iceberg テーブルはエンジンに依存しません。今日はバッチ変換に Spark、明日はインタラクティブクエリに Trino、来四半期はストリーミングに Flink といった具合です。Iceberg を扱えるエンジンであれば、変換や移行なしにデータを読み取れます。Razor Group は単一ベンダーの SQL 方言に縛られていた状態から、ストレージレイヤーに手を加えることなく新しいエンジンを採用できる自由を手に入れました。 フェーズ 5: 運用体制とオブザーバビリティを整える 最後のフェーズで、レイクハウスを本番グレードに仕上げました。Razor Group は、すべてのパイプラインコンポーネントからメトリクス、トレース、ログを集約し、統一されたビューにまとめる包括的なオブザーバビリティスタックを構築しました。このビューは、一元的なログ検索、異常検知、そしてデータプラットフォーム全体にわたる障害を関連付ける自動アラートを支えます。 このオブザーバビリティレイヤーは、単に可視性を提供する以上のものでした。チームに自信をもたらしたのです。1 日に何千ものパイプライン実行を回しているとき、何かが壊れたら数分以内に、それが何によって引き起こされ、どの下流の利用者が影響を受けるのかを把握する必要があります。それが、後手に回る火消しと、先手を打つ運用との違いです。 パイプラインのオーケストレーションは 3 つのパターンに集約されました。日次パイプライン (取り込みからマテリアライズ、エクスポート、AI エージェントによる分析まで)、15 分ごとにポーリングする運用ワーカー、そして週次のスクレイパージョブです。 切り替えは設計上ゼロダウンタイムでした。2 週間にわたって両方のスケジューラーを並行稼働させ、旧アーキテクチャのシステムを無効化する前に、すべてのパイプラインが同一の出力を生成することを自動比較チェックで検証しました。 成果とビジネスインパクト レイクハウスアーキテクチャは、あらゆる面で測定可能な改善をもたらしました。 指標 移行前 移行後 改善 P95 クエリ実行時間 180 秒 63 秒 65% 高速化 インフラコスト 常時稼働のプロビジョンドクラスター 柔軟でワークロード最適化された構成 63% 削減 データ鮮度 4〜6 時間のバッチサイクル イベント駆動のパイプライン 15 分の鮮度 同時処理容量 クラスターサイズによる制約 柔軟で独立したスケーリング 無制限 エンジンの柔軟性 単一エンジン マルチエンジン (Spark、Athena、Amazon Redshift) オープンフォーマットによる移植性 63% の削減は、レイクハウス稼働後のコスト (2026 年 1〜3 月) と、再設計前のコスト (直前の 3 か月間にあたる 2025 年 10〜12 月) を比較したものです。この数値は、両アーキテクチャのコンピューティングとストレージを含む、同一条件で比較したインフラの総合値です。移行前の列は Amazon Redshift クラスターのコンピューティングとマネージドストレージを対象としています。移行後の列は Amazon EC2 (オンデマンドとスポットの両方の Spark ワーカー)、AWS Lambda、AWS Glue、Amazon Athena、Amazon Redshift Serverless、S3 Tables のストレージを対象としています。データ転送や付随サービスは、2 つの期間で大きな差がなかったため除外しています。ワークロードの構成 (パイプライン数、モデル数、エンドユーザーのクエリ量) は、2 つの期間でおおむね同等に保ちました。 学んだこと ツールではなく意思決定のループから始め、ウェアハウスを置き換える前に自社のワークロードを把握する。 移行全体で最も価値のあった活動は、コードを 1 行書くことではありませんでした。アーキテクチャ上の意思決定を下す前に実施した、Amazon Redshift のワークロード分析です。コンピューティングの 98% が ETL で、アナリストのクエリに回っているのはごくわずかだと判明したことが、オンデマンドの Spark への移行を裏付けました。同時に、ほとんど存在しないインタラクティブワークロードのために置き換え先のインフラを過剰にプロビジョニングすることも防げました。アーキテクチャの意思決定は常に、価格精度、プロモーションへの即応性、日中の損益の可視性といった、事業の根幹にある要件にさかのぼるべきです。テクノロジーではなく、そこから始めましょう。 複数のコンピューティングエンジンを前提に設計し、ワークロードごとに適切なエンジンを選ぶ。 単一エンジンのアーキテクチャを運用して得られた最も明確な教訓は、それによって何を手放すことになるかということです。BI、取り込み、バックフィル、ML のすべてを 1 つのコンピューティングレイヤーに縛りつけるのは避けましょう。それぞれコストとパフォーマンスの特性が根本的に異なるからです。いったん移行してしまえば、Iceberg、Spark、S3 Tables は最初から問題なく連携します。難しいのはテクノロジーではありません。難しいのは、40 以上のスキーマにまたがる 1,000 以上のモデルを対応付け、200 以上の DAG を通じて依存関係をたどり、ある列が実は 2 つのエンジン間で密かに異なる形でシリアライズされた JSON 文字列だったと突き止めることです。移行は、エンジニアリングであると同時に発掘プロジェクトでもあります。 変換は自動化しつつ、残る 30% を見込んでおく。 自動化ツールは機械的な構文変換をうまく処理するので、まず手を伸ばすべきツールです。しかし複雑な JSON ペイロード、深くネストされたウィンドウ関数、スキーマをまたぐスナップショット依存を含むモデルは人間の判断を要し、その作業は圧縮できません。当社のモデルの約 30% が大幅な手作業を必要とし、それらが移行工数全体の 70% を占めました。最初から正直に見込んでおきましょう。 オブザーバビリティにはコスト配賦を含めなければならない。そして思わぬコストの落とし穴に注意する。 スナップショット操作は最大の想定外でした。ある時点の状態を保存するために 1 日に複数回実行されるテーブル全体のコピーが、週 35 時間を超えるコンピューティングを消費していたのですが、「スナップショットとはそういうもの」だと誰も疑いませんでした。Iceberg のタイムトラベル機能がそのコストを解消し、この 1 つの機能だけで移行のかなりの部分が正当化できました。より広く言えば、見えないものは最適化できないので、クエリレベルの使用状況を追跡し、チームや機能に配賦しましょう。コストのオブザーバビリティはあれば嬉しいものではなく、基盤そのものです。 ガバナンスは任意ではない。基盤に組み込み、初日からステークホルダーの足並みをそろえる。 カタログとアクセス制御は、採用を拡大した後ではなく、その前に整える必要があります。同じ原則が人にも当てはまります。移行はインフラプロジェクトではなく、部門横断のプログラムです。当社の 2 週間の並行稼働は、行レベルの検証ではまったく捉えられなかったエッジケースを検出しました。Amazon Redshift と Spark の間のタイムゾーンの違い、同時書き込み時のパーティションプルーニングの挙動、非決定的なウィンドウ関数における微妙な並び順の違いです。並行稼働は単なるセーフティネットではありませんでした。移行の真価が実証された場そのものでした。適切なステークホルダーが最初から関与し、足並みをそろえていなければ、何ひとつ成り立ちません。 まとめ Razor Group の道のりは、データアーキテクチャの最適化を目指す組織に貴重な教訓を提供します。 まずワークロードの構成を分析する。 コンピューティングの 98% がインタラクティブクエリではなく ETL だと理解できたことが、負荷の高い処理を柔軟な Spark にオフロードしつつ、最も得意とするインタラクティブ分析には Amazon Redshift Serverless を残すという判断を導きました。 マルチエンジンの柔軟性を前提に設計する。 Apache Iceberg のようなオープンテーブルフォーマットは、単一エンジンを選ぶ必要をなくします。各ワークロードは、アクセスパターン、コスト特性、パフォーマンス要件に最も適したエンジンで動きます。 移行を自動化しつつ、複雑さを見込む。 自動トランスパイルは SQL モデルの 70% を処理しましたが、残る 30% がエンジニアリング工数の 70% を占めました。それを踏まえて計画しましょう。 オブザーバビリティにはコスト配賦を含める。 ワークロード単位のコストが見えなければ、最適化は当て推量になります。Razor Group は、Iceberg のスナップショット保守だけで週 35 時間を超えるコンピューティングを消費していたことを突き止めました。オブザーバビリティが表面化させ、自動化が解決した隠れたコストです。 ガバナンスを基盤に組み込む。 AWS Lake Formation と AWS Glue Data Catalog は、移行後に後付けするのではなく、初日からきめ細かなアクセス制御を提供しました。 並行システムで検証する。 新旧アーキテクチャの 2 週間の並行稼働は、自動テストが見逃したエッジケースを検出し、自信をもった本番切り替えを支えました。 今後の展望 レイクハウスの基盤が整ったことで、Razor Group は AWS 上の統一されたオープンでガバナンスの効いたデータプラットフォームを原動力に、リアルタイムの価格モデルから AI 主導の在庫最適化まで、イノベーションを加速できる体制になりました。 同社の変革は、モダンなデータアーキテクチャがサービスの二者択一ではないことを示しています。それは 各ワークロードを最もパフォーマンスの高い場所に配置し 、オープンフォーマットでサイロを解消し、ビジネスの成長に応じて各レイヤーを独立してスケールさせることなのです。 他の組織が AWS 上で同様のレイクハウスアーキテクチャをどう実装しているかについては、 How BigBasket uses the Iceberg-based lakehouse architecture on AWS to power lightning-fast grocery delivery across India を参照してください。 著者について Yaswanth Kothainti Yaswanth は、売上高 4 億ドル超の EC 企業 Razor Group で VP of Data Engineering & Platform を務めています。同社のデータプラットフォームをゼロから構築し、65 名からなるグローバルなエンジニアリング組織を率いています。専門はエンタープライズデータプラットフォーム、データガバナンス、FinOps、エージェント型 AI システムで、複雑なプラットフォーム投資を測定可能なビジネス成果へと結びつけてきた実績があります。 Shubham Purwar Shubham は、AWS の Analytics Specialist Solutions Architect です。スケーラブルでセキュア、かつ高性能な分析ソリューションを AWS 上で設計・実装し、組織がデータの潜在能力を最大限に引き出せるよう支援しています。余暇には家族と過ごしたり、世界各地を旅したりするのが好きです。 Ravi Kompella Ravi は Principal Analytics Specialist です。インドの多様な業界において、スタートアップや SaaS プロバイダーを含むあらゆるセグメントを対象に、モダンなデータアーキテクチャ、エンタープライズデータレイクハウス、リアルタイムデータシステムの採用を推進してきた経験があります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 4 月 15 日 に公開された「 Get to insights faster using Notebooks in Amazon SageMaker Unified Studio 」を翻訳したものです。 本記事では、Amazon SageMaker Unified Studio のノートブックがインフラの設定を簡素化し、インサイト獲得までの時間を短縮する仕組みを紹介します。住宅価格データの分析、スケーラブルなデータテーブルの作成、分散プロファイリング、機械学習 (ML) モデルの学習を、単一のノートブック環境で行う流れをご覧いただけます。 データサイエンティストやアナリストは、分析を始めるまでにインフラ設定と複数データソースの認証管理に何日も費やすことがしばしばあります。Amazon Simple Storage Service (Amazon S3)、Amazon Redshift、Snowflake、ローカルファイルにまたがるデータを扱う場合、認証設定の繰り返し、コンピュートスケーリングの手動判断、ツール切り替えの手間が積み重なり、インサイト獲得が遅れます。 Amazon SageMaker Unified Studio のノートブックは、12 以上のデータソースへの即時アクセス、ローカルから分散処理までのコンピュートスケーリング、AI によるコード生成を、単一のブラウザベース環境で提供します。ポリグロットプログラミング、マルチエンジンコンピュート、AI 支援による開発を活用し、疑問からインサイトまでの道のりを短縮する方法を解説します。 Amazon SageMaker Unified Studio のノートブックとは Amazon SageMaker Unified Studio のノートブックは、データ分析、探索、エンジニアリング、機械学習ワークフローのためのインタラクティブな環境を提供します。統合された 5 つの機能を備えています。 ポリグロットプログラミング : 同じノートブック環境で Python と SQL を相互に切り替えながらコードを書けます 統合されたデータアクセス : Amazon S3、AWS Glue Data Catalog、Apache Iceberg テーブル、Snowflake や BigQuery などのサードパーティソースに保存されたデータへ即座に接続できます ネイティブな可視化 : Python や SQL の結果から直接チャートを作成し、没入感のあるデータ分析ができます AI による開発支援 : SageMaker Data Agent を通じて自然言語プロンプトでコードを生成できます。データ分析、データサイエンス、ML タスク向けの的確なチャットインターフェイスを備えています 柔軟なコンピュート : ニーズの拡大に応じて、基本的なインスタンスから GPU 搭載環境までスケールできます アーキテクチャ 本セクションでは、ノートブックのアーキテクチャを説明します。ノートブックは、複数のコンピュートエンジン、多様なデータソース、AI アシスタントを統合したクラウドネイティブアーキテクチャにより、ブラウザベースのシンプルさでエンタープライズ規模の分析を実現します。 プレゼンテーション層 Amazon SageMaker Unified Studio 経由でノートブックインターフェイスにアクセスします。コード実行用のコードセル、ドキュメント用のマークダウンセル、チャートやテーブル用の可視化セルを備えた、使い慣れたインターフェイスで操作できます。 コンピュート層 専用のノートブックサーバーがカーネルのライフサイクルとセッション状態を管理します。主要コンポーネントには、コード補完用の Language Server、データサイエンスライブラリをプリロードした Python 3.11 ランタイム、Python、PySpark、SQL の実行を同じノートブック内で処理する Polyglot Kernel が含まれます。作成した各ノートブックは、永続的な Amazon Elastic Block Store (Amazon EBS) ストレージにバックアップされます。 実行層 ノートブックは複数の実行エンジンをサポートし、コードを最適な処理エンジンに自動的にルーティングします。インメモリ実行は、小規模なデータセットや迅速なプロトタイピングを処理します。Amazon Athena 経由の Apache Spark は、Spark Connect を介した大規模分析向けの分散処理を提供します。Amazon Athena (Trino)、Amazon Redshift、Snowflake、BigQuery へのネイティブ接続により、SQL クエリを処理します。 データ統合 AWS ネイティブ (Amazon S3、AWS Glue、Amazon Athena、Amazon Redshift) とサードパーティ (Snowflake、BigQuery、PostgreSQL、MySQL) を含む 12 以上のデータソースに統一的にアクセスできます。サポートされている最新のデータソースについては、 Connect to data sources を参照してください。 AI 層 SageMaker Data Agent は、2 つのモードで利用できます。複数ステップの分析ワークフロー向けの Agent Panel と、セル単位のコード生成に特化した Inline Assistance です。詳細は Accelerate context-aware data analysis and ML workflows with Amazon SageMaker Data Agent を参照してください。 作業を保護するため、セキュリティはアーキテクチャ全体に組み込まれています。データアクセスは AWS Identity and Access Management (AWS IAM) の権限に従います。ノートブックとエージェントは、利用が許可されたデータソースにのみアクセスできます。コンポーネント間の通信は暗号化チャネルを使用し、ノートブックのストレージは保存時に暗号化されます。AI エージェントには、破壊的な操作を防ぐガードレールが組み込まれており、コンプライアンスと監査のためにやり取りをログに記録します。 前提条件 始める前に、以下が必要です。 Amazon SageMaker Unified Studio のリソースを作成する権限を持つ AWS アカウント。必要な権限の詳細は、 Set up IAM-based domains を参照してください。 Python プログラミングと SQL クエリの基本的な知識 データ分析の概念と ML ワークフローの理解 サンプルの住宅データセットへのアクセス (ウォークスルー内で提供) ノートブックを使い始める まず、 Amazon SageMaker コンソール を開き、 Get started を選択します。 データとコンピュートへのアクセス権を持つ既存の AWS Identity and Access Management (AWS IAM) ロールを選択するか、新規ロールを作成するかを求められます。本ウォークスルーでは、 Create a new role を選択し、他のオプションはデフォルトのままにします。 Set up を選択します。環境の準備には数分かかります。 ユースケース 本記事では、ノートブックと SageMaker Data Agent を使って以下を実行します。 データセットの操作: サンプルデータセット housing.csv をアップロードし、データエクスプローラーで探索 ポリグロットプログラミング: DuckDB 経由で SQL によるデータフレームのクエリ AWS Glue によるマルチエンジンアクセス: AWS Glue テーブルを作成し、Athena SQL/Spark エンジンで分散処理を実行 高度な分析: Athena Spark でデータプロファイリング AI 支援による開発: Data Agent でプロファイリングと ML のコードを生成 ML ワークフロー: Random Forest モデルを学習し、結果を評価 まずインターフェイスを見て、コア機能を確認しましょう。 インターフェイスの理解 ノートブックのインターフェイスは、コード実行用のセルとドキュメント用のマークダウンという、使い慣れたノートブック規約に従っています。ノートブック内では、現在のプログラミング環境 (Python 3.11 など) とコンピュートプロファイルの仕様を確認できます。このインターフェイスでは以下ができます。 ファイルの参照、データカタログの探索、サードパーティ接続の管理を通じてデータにアクセス ノートブックのコンテキスト内で作成された変数を監視 ワークロード要件に応じて仮想 CPU と RAM を調整し、GPU インスタンスまでオンデマンドでコンピュートリソースをスケール Python パッケージを必要に応じてインストールおよび設定してパッケージを管理 データセットの操作 本ウォークスルーでは、 このページ からダウンロードできる housing.csv サンプルデータセットを使用します (リンク先ではファイル名が canvas-sample-housing.csv になっています)。左パネルの Files アイコンを選択し、 Local タブを選択します。 Local タブでノートブックに CSV ファイルをアップロードします。 ノートブックはデータ資産への即時アクセスを提供します。データエクスプローラーを使えば、AWS Glue Data Catalog、Amazon S3 テーブルカタログ、Amazon S3 バケット、設定済みのサードパーティ接続を参照できます。 3 点リーダーのオプションメニューを選択します。 Read as dataframe を選択し、ノートブックに挿入されたセルを実行して結果を確認します。 import pandas as pd <<df_csv_xxxx>> = pd.read_csv('housing.csv') <<df_csv_xxxx>> データフレームを返すと、ノートブックは自動的なデータプロファイリングを備えたリッチなテーブル形式で表示します。 ポリグロットプログラミング: Python と SQL を同時に ノートブックのもっとも強力な機能の 1 つが、Python と SQL の相互運用性です。データを Python のデータフレームに読み込んだ後、すぐに SQL でクエリできます。たとえば、海への近さ別に人口と世帯数の合計を計算するには、次のように実行します。 select sum(population) ,sum(households),ocean_proximity from<<df_csv_xxxx>> group byocean_proximity ノートブックのオートコンプリート機能はコンテキスト内のデータフレームを認識するため、SQL クエリを直感的に書けます。 この SQL クエリは DuckDB (インメモリの SQL データベースエンジン) 上で実行され、個別のインストールやサーバー保守は不要です。DuckDB は軽量な設計で、Python、Java、その他の環境に組み込めるため、迅速な対話型データ分析に適しています。分散処理が必要な場合は、データセット用の AWS Glue テーブルを作成した後、Apache Spark や Trino などのエンジンを使用できます。 データセット用の AWS Glue テーブルを作成する AWS Glue テーブルを作成すると、Amazon Athena SQL (Trino) や Amazon Athena Spark など、AWS Glue カタログ対応のさまざまなエンジンでデータセットをクエリできます。これらのエンジンは、それぞれのワークロード要件に対して最適な価格性能比を提供します。 まず AWS Glue データベースを作成します。ノートブックで新しいセルを作成するために SQL を選択し、 Amazon Athena (SQL) を選びます。 次の SQL を実行してデータベースを作成します: create database demo; 次に、データエクスプローラーに移動し、左上の +Add を選択して Create table を選びます。先ほど作成したデータベースを選択し、テーブル名を入力します。先ほど使用した housing.csv データセットファイルをアップロードします。サイドパネルで Next を選択して、テーブルを作成します。 次に、Amazon Athena SQL を使って新しいセルでサンプル SQL クエリを実行してみましょう。 select sum(population) , sum(households), ocean_proximity fromdemo.housing group by ocean_proximity Athena Spark による高度な機能 住宅価格を予測する ML モデルを構築する前に、データセットをさらに分析し、追加のインサイトを得るためにデータプロファイリングを実行しましょう。高度な探索には、ノートブック内で Amazon Athena Spark を使用できます。そのために、組み込みの Spark セッションを持つ新しい Python セルを作成します。次のコードを実行して Spark のバージョンを確認します。 # Verify Spark version spark.version SageMaker Data Agent によるデータプロファイリング 定型的なコードを手動で書く代わりに、組み込みの生成 AI 機能を活用できます。 プロンプト : 「Perform data profiling and create visualization for housing table」 AI アシスタントは、基本統計の算出、列単位のプロファイリング、データ型の分析、欠損値の検出を含む、包括的なプロファイリングコードを生成します。 エージェントは AWS Glue Data Catalog にアクセスし、housing テーブルの構造を把握したうえで、対象の列とデータ型に合わせたプロファイリングコードを生成しました。この文脈認識により、汎用的なコードスニペットを自環境向けに調整する際にありがちな試行錯誤が減ります。生成されたコードを確認して実行します。応答が速いため、分析を効率的に反復できます。 エラーが発生した場合は、次の図のように Fix with AI で解決できます。実行時にエラーが発生すると、 Fix with AI 機能がトレースバックを分析し、根本原因を診断して修正済みコードを生成するため、分析を止めずに進められます。 ML モデルの学習 次に、Data Agent を使って住宅価格を予測するモデルの学習コードを生成します。 プロンプト: 「Generate code to train a model that predicts housing prices. Use table housing.」 AI アシスタントは、次のようなエンドツーエンドのコードを生成します。 Amazon Athena Spark を使って AWS Glue カタログから住宅データを読み込み、pandas に変換 文字列型の列を数値化し、One-Hot エンコーディングでエンコードし、欠損値を除去 Random Forest モデルを学習して住宅価格の中央値を予測 モデル性能を評価 (RMSE、MAE、R-square) 予測に対する重要度が高い上位 10 個の特徴量を表示 この複数ステップのオーケストレーションにより、データアクセスからモデル評価までのワークフロー全体を任せられ、開発時間を数時間短縮できます。 エラーが発生した場合は、結果のトレースバックセクションにある Fix with AI で解決できます。 このワークフローでは、ノートブックの統合機能を紹介しました。ローカルからファイルをアップロードし、マルチエンジンアクセス用に AWS Glue テーブルを作成し、Amazon Athena Spark で分散プロファイリングを実行し、AI 支援による ML 開発で住宅価格を予測しました。これらすべてを、ツールを切り替えずに 1 つのノートブック環境で行いました。 主なメリットとベストプラクティス Amazon SageMaker Unified Studio のノートブックには、いくつかの利点があります。 インサイト獲得までの時間短縮 : 従来の環境では、分析を始める前に設定に数時間かかることもあります。ノートブックはこうした負荷を回避し、すぐに作業を始められます。 コラボレーションの向上 : 一貫した環境でノートブックを共有でき、再現性が確保され、「自分の環境では動く」問題が減ります。 複雑性の低減 : データソースや処理エンジンごとに別々のツールを使い分けるのではなく、複数のデータソースとコンピュートエンジンに 1 つのインターフェイスからアクセスできます。 AI による開発の加速 : タスク特化型のコードを生成し、的確な提案を受けられるため、繰り返しのコーディング作業にかかる時間を減らせます。 スケーラブルな性能 : メガバイトからペタバイト規模のデータセットを、適切なコンピュートリソースで処理できます。データ量の増加に応じてシステムが自動的にスケールします。 ベストプラクティス まずは小さめのインスタンスから始め、ニーズの拡大に合わせてスケールアップする形で、適切な コンピュートプロファイル で開始する。 繰り返し作業や複雑な操作には、自然言語プロンプトで AI アシスタントを活用する 。 大規模処理には Amazon Athena Spark、データウェアハウスには Amazon Redshift、その他特定のワークロードには専用エンジンを使うなど、 エンジンを戦略的に組み合わせる 。 マークダウンセルを使い、コードと並行して 作業内容を文書化する ことで、生きたドキュメントを作る。 複雑なワークフローを論理的なステップに分割し、 複数のセルで整理する ことで、可読性とデバッグ性を高める。 クリーンアップ 今後の課金を避けるため、本ウォークスルーで作成したリソースを削除します。 Amazon SageMaker Unified Studio コンソールで、Notebook ページに移動する ノートブックを削除する AWS Glue Data Catalog から demo データベースと housing テーブルを削除する 本ウォークスルーで作成した Amazon SageMaker Unified Studio ドメインを削除する 本ウォークスルー用に新しい IAM ロールを作成した場合は、IAM コンソールから削除する まとめ 本記事では、Amazon SageMaker Unified Studio のノートブックが作業効率を高め、インサイトをより速く提供する仕組みを紹介しました。使い慣れたノートブックインターフェイスに、エンタープライズ規模のコンピュート、マルチエンジンサポート、生成 AI 支援を組み合わせることで、チームはデータと AI のワークフローを効率化できます。 Python と SQL の統合、多様なデータソースへの即時アクセス、的確なコード生成機能により、ノートブックは現代のデータチームにとって価値あるツールになります。探索的データ分析、複雑なデータパイプラインの構築、ML モデルの学習を、単一の直感的な環境で必要な柔軟性とパワーを備えて実行できます。 使い始める準備はできましたか? Amazon SageMaker Unified Studio で最初のノートブックを作成 し、数分でデータ分析を始めましょう。 追加機能を探る: 季節分解と予測を用いた時系列分析ワークフロー テキスト分類や感情分析のための自然言語処理パイプライン ML モデルのバージョン管理のための Amazon SageMaker Model Registry との統合 ペタバイト規模の処理に対応する高度な Spark 最適化手法 詳細情報: Amazon SageMaker Unified Studio Administrator Guide Amazon SageMaker Unified Studio User Guide Notebooks in SageMaker Unified Studio Use the SageMaker Data Agent Pricing information 著者について Praveen Kumar Praveen Kumar は AWS の Principal Analytics Solutions Architect で、クラウドベースのサービスを用いた最新のデータおよび分析アプリケーションの設計、構築、実装に精通しています。関心領域はサーバーレステクノロジー、データガバナンス、データドリブンな AI アプリケーションです。 Majisha Namath Parambath Majisha Namath Parambath は Amazon SageMaker の Principal Engineer で、AWS で 10 年以上の経験を積んでいます。エージェント型システムを重視した包括的なデータ分析とインタラクティブな機械学習機能を提供する次世代サービス、Amazon SageMaker Unified Studio の重要な取り組みを主導しています。専門はシステム設計、アーキテクチャ、部門横断の実行で、エンタープライズ規模でのセキュリティ、パフォーマンス、信頼性に注力しています。エンジニアリング以外では、読書、料理、スキーを楽しんでいます。 Siddharth Gupta Siddharth Gupta は SageMaker の Unified Experiences で生成 AI を率いており、AI システムが複雑なタスクをユーザーに代わって自律的に実行する、エージェント型体験の推進に注力しています。以前は AWS でエッジ機械学習ソリューションを率いていました。彼の仕事は、開発者やデータサイエンティストが AI とやり取りする方法の改善、より直感的なデータ統合の実現、機械学習モデルを構築・デプロイするためのより良いツール作りに焦点を当てています。University of Illinois at Urbana-Champaign 出身で、Yahoo、Glassdoor、Twitch で豊富な経験を積んでいます。 LinkedIn で連絡できます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

本記事は 2026 年 8 月 26 日 に公開された「 AWS and DuckLabs: Building the future of analytics together 」を翻訳したものです。 本日、 Amazon が DuckLabs を買収する最終契約を締結したこと を発表します。DuckLabs はオープンソースの分析データベース DuckDB を開発する、アムステルダム拠点の企業です。取引は通常のクロージング条件が満たされ次第、まもなく完了する見込みです。DuckDB を開発し DuckLabs を共同創業した Hannes Mühleisen と Mark Raasveldt は、AWS の一員として引き続きチームとオープンソースプロジェクトの技術的方向性を率いていきます。DuckDB オープンソースプロジェクトも引き続き DuckLabs チームが推進し、独立した Foundation (DuckDB を統括する非営利団体) の下でオープンソースとして維持され、現在と同様に MIT ライセンスで利用可能です ( DuckLabs ブログ を参照)。 データは常に企業の中核となる資産であり、差別化の源泉でした。組織が自社のデータで推論をカスタマイズし AI エージェントを構築する今、その重要性はこれまで以上に高まっています。AWS は 20 年間、データの最前線を切り拓いてきました。あらゆるビジネスにデータレイクをもたらした Amazon S3 のローンチに始まり、初のクラウド分析サービスである Amazon EMR、初のクラウドデータウェアハウスである Amazon Redshift、さらに Athena や Glue ETL などで導入してきた数々の機能があります。S3 Tables で直接利用できる Apache Iceberg 機能、データレイク内のベクトルストレージ、新しく最適化された Graviton ベースの Redshift クラスターなど、AWS のお客様のためにデータ領域での革新を続けています。 DuckDB もまた、世界のデータの扱い方を変える最前線に立ってきました。Hannes と Mark は、Python を生み出したことでも知られるオランダの国立研究機関 Centrum Wiskunde & Informatica (CWI) 在籍中に DuckDB を開発しました。DuckDB の創業者たちは、従来のデータベースや Spark のような分析エンジンが超大規模データ処理のパフォーマンスに注力する一方で、多くのお客様が SQL 分析で行う作業の中心を占める、より小さなサイズのデータクエリに効果的に「スケールダウン」する手段を持っていないと気づきました。 DuckDB が取り組んだのは、今日のデータクエリの 90% 以上を占める、分析やダッシュボード作成で 1 テラバイト以下のデータを扱うクエリを圧倒的な速度で処理する課題です。DuckDB のアーキテクチャは「日常的な SQL クエリを超高速にする」という前提に基づいており、他のアプリケーションのインプロセスで動作するため、アプリケーションとのデータのやり取りが簡単かつ高速になります。DuckDB はベクトル化実行によって大きなパフォーマンス向上を実現しています。 SELECT * FROM table のような単純な文の実行に重たいコンパイラを必要としないためです。日常的なクエリでうまく機能する仕組みは、当然ながらエージェントでもうまく機能します。エージェントはデータと対話するときに人間とよく似た振る舞いをするからです。軽く探ってみる。試してみる。本当にやりたいことを見極める前に、小さなデータセットで探索的な分析を行う。DuckDB は AI エージェントが使うのに自然と最適化された形になっています。学術プロジェクトとして始まったものが、今ではデータエンジニアリング、データサイエンス、分析、そして AI エージェントに至るまで、使いやすさと純粋なパフォーマンスの点で広く採用されています。私たちは、1 テラバイト以下の日常的なクエリにおける DuckDB の強みを、エクサバイト超のエンタープライズ規模で実績のある S3 と、数百テラバイトからペタバイト級のデータで分析を支える Redshift、Athena、EMR、Glue-ETL、SageMaker プラットフォームなどの AWS 分析サービスと組み合わせる計画です。AWS の Distinguished Engineer である Andy Warfield が、Werner Vogels の All Things Distributed ブログで DuckDB and the Changing Physics of Analytics について語っています。 お客様は現在、DuckDB を AWS サービスと組み合わせて活用しており、その速度とシンプルさを高く評価しています。たとえば DuckDB は現在、ローカルや S3 などのクラウドストレージに保存された Parquet、CSV、JSON といった外部ファイルに対して SQL を直接実行し、他に類を見ないパフォーマンスと大幅に低いコストを実現しています。 Allen Institute の Scientific Computing 担当 Executive Director である David Feng 氏は次のように述べています。 「Allen Institute は、生物学における最大級の問いに大規模に取り組むことで、より健康な世界のための科学を加速しています。そこには、大規模でマルチモーダルなデータの広範な分析が伴います。私たちは 2025 年に数テラバイトの科学データを分析するために DuckDB を使い始め、大変気に入っています。神経生理学および行動データのリアルタイム品質管理と分析のためにデータを S3 に保存しており、これは次のデータ取得を進める上で欠かせません。数分かかっていたクエリが 1 秒未満で返るようになり、データとのまったく新しい対話方法が可能になりました。」DuckDB は AWS Lambda 関数のインプロセスで実行することもできます。 DuckDB アプリケーションが AWS で最高のパフォーマンスを発揮するようにし、DuckDB と AWS のビルディングブロックサービスとの深い統合に引き続き投資していきます。 AWS 自身のインフラでも DuckDB を活用しています。Amazon Quick は独自のダッシュボードエンジンのパフォーマンスを強化するにあたり、S3 Tables のデータへのクエリに DuckDB を選びました。Quick チームは、DuckDB エンジンが CPU 数に応じてスムーズにスケールし、単一のライブラリを Quick の内部コントロールプレーンサブシステムに簡単に組み込めることを確認しました。2025 年 10 月に Quick を提供開始して以来、DuckDB との統合と最適化を組み込んだ独自の Quick クエリエンジンで 25 億件を超えるクエリを処理してきました。DuckDB との統合と最適化により、Amazon Quick は平均クエリレイテンシーを 30% 削減できました。データと分析領域の他の AWS サービスでも、DuckDB のパフォーマンスとシンプルさをどのように取り込めるかを検討していきます。 DuckLabs と AWS が、アプリケーション、データエンジニア、AI のためにデータの最前線をどう再定義していくのか、そしてお客様の現状に寄り添いながら AWS の中で DuckDB のイノベーションの恩恵をどのように届けていくのか。続報にご期待ください。 著者について Mai-Lan Tomsen Bukovec AWS の Technology Vice President である Mai-Lan Tomsen Bukovec は、デジタル変革、ビジネス分析、機械学習、生成 AI、次世代のカスタマーエクスペリエンスにおいて数百万人の AWS のお客様が信頼を寄せる Amazon のクラウドデータサービスを率いています。テクノロジー業界で 25 年以上の経験を持ち、クラウド技術を活用してビジネスを変革するお客様の取り組みを支援するパイオニアです。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。