Japan AWS Jr. ChampionsAdvent Calendar 2024

2024 re:InventでのAnalytics関連の注目アップデートのまとめとBedrockのNL2SQLを触ってみた

Last updated at 2024-12-23Posted at 2024-12-22

本記事は2024 AWS Jr. Championsの23日目の記事です。
NTTドコモ R&Dイノベーション本部サービスイノベーション部
ビッグデータ基盤担当 4年目社員の小澤です。
2023年に続いて2年連続で、ラスベガス現地にて2024 AWS re:Inventに参加させていただきました。

本記事では2024 AWS re:Inventで発表されたアップデートの中でも、注目しているBedrock Knowledge Basesで構造化データの取得をサポートするようになった機能(NL2SQL)の解説と触ってみた感想やAnalytics関連サービスの注目アップデートについてまとめております！
ドコモ開発者ブログのアドベントカレンダーでは、S3 TablesとApche Icebergの詳細についても述べておりますので、ご覧ください。

AWS利用の若手エンジニア代表である2024 Japan AWS Jr. Championsと全資格保有者である2024 Japan AWS All Certifications Engineersとして、任期1年の活動にも取り組んでいます。NTTドコモの2024アドベントカレンダーにも参加しておりますので、興味のある方はご覧ください！以下の画像はAWS認定者ラウンジを中心に、いただいたお気に入りのグッズ等です。

普段の業務

1日数百TBにわたる弊社の4G、5G基地局の通信制御信信号をリアルタイムで分析可能とし、ネットワークエリア品質向上に役立つデータへ変換するシステム(=MINADEN)の研究、開発、運用業務に携わっており、いわゆるデータエンジニア的な業務に携わっております。チームでの取り組みは社外勉強会でも発表しておりますので、興味のある方はご覧ください！

「社外勉強会資料」
大規模通信制御信号 ETL システムにおける大幅なコスト削減・意識改革の取り組み

 大規模な通信制御信号処理の環境下における Athena のパフォーマンス比較

 Introduction of "Minaden", Which Processes 200TB of Japanese Cell Phone Base Station Data Per Day

大規模データ処理基盤における MLOps について

Bedrock Knowledge Basesが構造化データをサポート(NL2SQL)を触ってみた！

Amazon Bedrock Knowledge Basesで自然言語の入力に対して構造化データの情報を取得できるようになりました。構造化データを用いてRAGを作成できるようになしました。つまり、自然言語を用いて内部的にSQLを生成し(NL2SQL)、結果が得られるというものです。 AWS re:InventではChalk Talkに参加してきました！今までBedrock Knowledge BasesではS3のデータを用いてベクトル変換し、マネージドにRAGを生成することができました。今回のアップデートにより、Redshift、Sagemaker Lakehouseを対象に構造化データ(表形式のデータ)を用いてRAGをマネージドに生成することが可能になりました。 DBの中身を確認して、自然言語から中身に対する回答が得られることは非常に面白い機能だと思いますので、検証してみたいと思います！

Redshift Serverlessの用意とTICKIT データベースの利用

検証を容易とするため、通常のRedshiftではなくRedshift Serverlessを容易します。その上で以下の画像に示すように、Redshiftのquery editorでTICKITデータベースを選択します。架空のWebサイト「TICKIT」上で販売されたスポーツイベント、ショー、コンサート等のチケットの購入者や販売者、開催場所、開催地域等を確認することができます。

BedrockでのRedshiftの同期とRAG生成

以下の図に示すように、Knowledge Basesの画面に遷移しRedshift上のデータベースと同期してあげる必要があります。先ほど示したTICKIT データベースが存在するデータベースを選択しましょう。その後、同期ボタンを押します。

同期ボタンを押そうとすると、対象のテーブルにSELECT権限を付与するように警告されるため、以下の図のように、Redshift上で以下のクエリを打ち込む必要があります。全てのテーブルに対して権限を与えてあげる必要があるかと思いきや、適当に1つのテーブル(sales)に対して権限を付与すると上手く同期できました。。。

GRANT SELECT ON [データベース名].tickit.[テーブル名] TO "IAMR:[Bedrock上で表示されているサービスロール名]";

Nl2SQLの実践① (成功編)

まずは、自然言語を用いてTICKIT データベースにどんなテーブルが存在するのかを聞いてみたいと思います。使用したモデルはClaude3.5 Sonnetになります。すると以下の結果が得られました。

データベースの一覧は完璧ですね！データの中身を知らない場合に、気軽に自然言語で問い合わせたい場合には有効な機能なのではないかと感じました。また、カラムの説明についても良くできていると感じていて、全てのカラムの説明をせずに上手く伝わるように丸め込んでくれています。(以下は実際のテーブルとカラムの情報)

Nl2SQLの実践② (成功編)

続いて、salesテーブルで販売数量が最も多いイベントIDとイベント名を教えてもらおうと思います。入力と出力結果は以下になります。イベントIDが1602でイベント名が、Phantom of the Operaと答えてくれました。この回答が正確なものなのか、実際にSQLを叩いて検証してみます。

まずは、Redshiftでsalesテーブルに対して販売数量が最も多かったイベントIDを抽出します。

SELECT EVENTID, 
       SUM(QTYSOLD) AS TotalQtySold,
       RANK() OVER (ORDER BY SUM(QTYSOLD) DESC) AS Rank
FROM tickit.sales
GROUP BY EVENTID
ORDER BY Rank;

すると結果は以下のように得られました。イベントIDが1602であることは正しそうですね！

イベント名を抽出するには、別のテーブル(event)を参照する必要があるためIDからイベント名を抽出します。

SELECT EVENTID, EVENTNAME
FROM tickit.event
WHERE eventid=1602;

すると以下の結果が得られました。Bedrockが回答してくれた内容と完全に一致しました！すごい・・・

Nl2SQLの実践③ (失敗編)

続いて、以下の画像に示すように特定のユーザ(username: VAG08HKW、userid:43632)の総売上に関する質問をしてみます。

以下の画像に示すように、VAG08HKWの売り上げに関する質問をしてみました。2通りの質問をしておりますが、同様の結果が返されます。PRICEPAIDはSALESテーブルのカラム名として存在するため、意図を掴みやすいように明示的に指定しております。

しかし、上記の結果は正確な返答ではありません。Redshift上でSQLを打ち込んで答え合わせをします。合計売り上げは、$4,868です。

SELECT sellerid, SUM(PRICEPAID) AS total_sales
FROM tickit.sales
WHERE sellerid=43632
GROUP BY sellerid;

SALESテーブルには、usernameではなくuseridが存在しております。LLM側が判断しやすくなることを期待して、useridを用いて質問をし直します。更に、他のユーザ(seller)と比較して、多いのか少ないのかを聞いてみました。

上記の結果に対する答え合わせをします。売り上げ合計額に関しては、先ほど示したように正確な値を返しています！ 続いて、他のユーザとの比較結果が正確かどうかを確かめます。

SELECT 
    MAX(total_sales) AS max_sales,
    MIN(total_sales) AS min_sales,
    AVG(total_sales) AS avg_sales
FROM (
    SELECT SUM(PRICEPAID) AS total_sales
    FROM tickit.sales
    GROUP BY sellerid
) AS user_sales;

LLMから出力された、全ユーザの売り上げに関する合計の最大、最小、平均が全て一致しております！

NL2SQLのまとめと課題

「まとめ」

この機能を利用する方は、SQLとデータの中身を全く分からない方が多いのではないかと考えられる
簡単な内容であれば、データの中身を考慮して正確に回答してくれることを確認できた
弊社では全国のネットワークデータ分析者から基本的なSQLの書き方に関する質問が相次いでおり自動化対応に応用したい

「課題」

簡単な内容であっても、正確な結果を返さない場合がある(システムの反映には精度が不十分)
プロンプトに与えるメッセージ内容への工夫が必要(検索対象テーブルのカラム名を直接指定する等)
カラム名の説明や入力文に対するクエリ指定等の細かな設定が可能であり、複雑な設定により精度を上げる必要があるかもしれない
生成されるSQLは不明で、生成される根拠も不明であることからシステムへ盛り込む際には評価が課題になるのではないかと考えられる

「既存機能との使い分け」
SQLやデータの中身が全く分からない人向けには、BedrockのNL2SQL機能が向いていると考えます。 データの中身が分からない、SQLを書けない場合には、複雑な質問をしないケースが多いと考えます。従って、BedrockのNL2SQL機能で十分な場合が多いのではないでしょうか？しかし、詳細な分析をしたい場合には不十分な機能であるかと考えます。業務で本質的な課題を発見するような分析をしたい場合に、SQLの知識0の状態では厳しいと感じます。

2023 AWS re:Inventでは以下の図に示すようにRedshiftにAmazon Qが内包されて、SQLの生成を助けてくれる機能が展開されました。こちらはある程度SQLがかける方向けの機能だと考えられます。対象のユーザをしっかり考えた上で、システムへ盛り込みたいところです。、昨年のアドベントカレンダーで、この機能の検証をしておりますので、興味のある方はご覧ください！

Amazon S3 Tables

Apache Iceberg形式に対して最適化されたストレージ
Redshift、Athena、EMR、Apache Sparkなどからクエリ可能 (Iceberg形式自体は、元々対応)
従来ストレージと比較して、最大3倍のクエリ性能と10倍のトランザクション処理が可能
- Glue, Athena等で通常S3にIcebergテーブルを作成しても上記の効果は得られない
ガベージコレクションをサポート
- 古いスナップショット、古いスナップショットで参照されていたデータファイル(ParquetやORC、Avroなどのファイル形式)、古いメタデータファイル等を自動で削除
- 結果的に、ディスクスペースの効率化やパフォーマンスの向上に繋がる模様

Apache Icebergとは？

Apache Icebergとは、大規模なデータの効率的な管理とクエリ性能を向上させる設計となっているOpen Table Format(OTF)です。ファイル形式のことを指している訳ではありません**データレイクやクラウドベースのデータストレージの世界で、標準として採用される可能性が非常に高いことから、概要を理解しておくことが必要と感じ、まとめました。**タイムトラベル機能、3層構造や高度なメタデータ管理によって効率的なクエリ実行が可能となっております。Icebergでは、効率的にデータを管理するために以下の図に示すように、カタログ層、メタデータ層、データ層の3層から成り立ちます。詳細は、ドコモ開発者ブログに投稿しておりますので、ご覧ください！

出典：Iceberg Table Spec

Amazon SageMaker Unified Studio

EMR、Glue、Athena、Redshift、Bedrock、MSK、Kinesis、QuickSight等の機能を統合
例えば、ストリーミングはKinesis、機械学習は、SageMakerで分析はRedshift, Athena, EMR等のサービスへ移動しなければならず、使用上の手間が存在
用途に応じた機能を1箇所で簡単に使えるようになった (統合のみ？)
将来的には、各種機能をマネージド化するプランがあると嬉しい(SnowflakeやDatabricks等の3rd partyツールと同等程度の柔軟な機能があると更に魅力的)

Get Started building ML models with natural language (workshop)

SageMaker Canvas(ノーコード、AutoML)でAmazonQを用いることで自然言語でモデルの構築ができるようになる
データセットの中身を読み取り、自然言語で指示を与えるとカラム名や各種統計値まで算出できていた(目的変数も当てていた)
レスポンス遅い、精度悪い、使い勝手が悪く、DataRobot等の3rd partyより利点があるのか
DataRobot(総当たりのようにモデル構築)、本機能(ML有識者に質問しながらモデル構築)の違いがあるという理解に至る

AWS Jam: DevOps and modernization with Jr.Champions (番外編)

同じJr.Championsで同期のNTT東日本の豊岡くんと、Jamにも参加してみました！

API GatewayとLambdaの組み合わせやECS、EKSを用いたアプリのバグを発見して解決していき、得点の高いチーム(4名で1チーム)が勝利
他の2名は初対面の方
Document読んだり、デバッグすればいけると思っていたが苦戦・・・
他のチームの方にも聞いたが、難易度は全体的に高かった様子
苦戦したからこそ、更に知識を習得するモチベーションが現地で向上
- Analytics以外のサービスに関するスキルが不足していることを強く実感

まとめ & 今後の意気込み

2024年のre:InventではJr.Championsに選出されて現地で多くの知り合いの方と交流でき、楽しみながら参加することができました！イベント自体は5日間、毎日楽しかったのですが、関連するイベント(Jr.ChampionsやNTTの集まり)にも参加し、現地で刺激を受ける機会もいただけました。現状に満足することなく、チームや自組織、ドコモに技術を還元できるように頑張っていきたいと思います！

昨年のアドベントカレンダーで掲げた目標は以下でした。

AWS資格を全冠すること (2024は達成)

AWSのコミュニティ活動に積極的に参加し、視野を広げた技術的知見や繋がりを持つこと (Jr.Champions選出やビッグデータJAWSの運営に参画)

英語を円滑に話せるようになること・・・(継続勉強中で2023 re:Inventよりは少し話せた程度)

上記の結果を踏まえて、2025年までには以下を目標に頑張っていきます！

2025年もAWS資格を全冠すること
Top Engineer等の次のステップの称号の獲得や準ずる行動
他組織に対して自身のAWSスキルを還元し、システムへの盛り込みや設計に貢献
継続的な英語の学習と英語での外部発表の機会を再び作る(2023 JAWS PANKRATIONでは英語発表)

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up