omuronの備忘録

個人的な備忘録

「BigData-JAWS 勉強会#27」 #bdjaws 受講メモ

AWS 勉強会

BigData-JAWS 勉強会 #27 #bdjaws

jawsug-bigdata.connpass.com

セッション

LT① 【【Bedrock×Athena】生成系AIを活用したSlackデータの分析に挑戦

荒牧 慧さん

  • Slack AI が GA
    • 休み明けSlack貯まる問題のサマリーだしてくれるのでは？
    • 1,200円と高い...
    • 使わずに Bedrock x Athena で実装
  • AWSアーキテクチャ
    • 収集用 Lambda で Slack からデータ取得して S3 へ
    • 推論用 Lambda で Bedrock

LLMの使い方でサマリーや要約は比較的ハルシネーション起きなくいい感じの答えくれるので、ユースケースとしては実現しやすい内容ですね。

LT②　IoT Core と Data Firehose によるデータ連携で直面した課題

井川 朋樹さん

Firehose作成時に設定できる「動的パーティショニング」で処理する必要があったが「S3プレフィックスタイムゾーン」設定が増えたと。
UTCだけだったがバケットプレフィックスのタイムゾーンも指定できるようになったよと。

LT③ Athena Partiton Projectionを調べてみた！

水村 健太さん

speakerdeck.com

  • Athena のよくあるパーティション管理
    • Glue Crawler で定期的にバケット全体をスキャンして更新
      • 時間かかる、実行時間に対してお金がかかる
    • ALTER TABLE ADD PARTITION 文を定期実行
  • Athena Partition Projection
    • パーティション管理を自動化してくれるAthenaの機能
      • CRATE EXTERNAL TABLE 文の TBLPROPERTIES で設定
      • Glue コンソールからテーブル編集ページで Table properties でキーバリュー設定
    • 予測可能なパーティションパターンの場合
      • integer, date, enum
    • 予測不可能なパーティションパターンの場合
      • 挿入型(injected型)で設定
        • クエリ時には WHERE でパーティション指定が必須になる
        • 値はデータを読み取らなくても評価できるリテラルまたは式である必要がある
    • インメモリ処理で高速化される

Glue Crawler 便利だけど定期実行させないとだめで、だんだん辛くなるので Partition Projection に寄せれるときは寄せるほうがいいかと。

LT④ データ初心者がAWS GlueでPII対策やってみた

佐藤 亨さん

  • PII≒個人情報
  • Glue DataBrew で個人情報保護できるのでは？
    • DataBrew の PII マスキング機能
      • 日本語はマスクされない
        • メールはマスキングされるのに氏名はされない

Glue DataBrew の PII マスキング機能は英語(US)用のなので日本語では使えないと。
列を指定するなら使えそうと。

LT⑤ AWS Glue for Ray の普及にささやかで微力な貢献を

坂口 拓生（株式会社エーピーコミュニケーションズ）

  • Glue の ETL
    • Glue for Apache Spark：マルチノード分散処理、Spark学習コスト高め
    • Glue for Python Shell：シングルノード処理
    • Glue for Ray：シングルノード処理、学習コスト低め
  • Ray：PythonアプリをスケーリングするためのOSS統合フレームワーク
    • Ray Core：Pure Python コードを分散アプリとしてビルド、スケーリングする機能の提供
    • Ray Data：Ray アプリにおける分散処理のためのAPI
  • pip で ray をインストールしても使える
    • Cloud9は Glue の Ray とバージョン違うので注意

Glue Jobs は Spark と Python Shell は触った事あるけど、Ray は知りませんでした。
ただ、日本語も含めてドキュメントが少ないのがネックと。

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

小澤 遼さん

  • 500万レコード vs 8,500万レコードの LEFT OUTER JOIN 比較
    • S3 Standard 利用であれば 10-128MBでの分割ファイルが早い
    • S3 Express One Zone 利用であれば 1-128MBでの分割ファイルが早い
      • 小さいファイルの処理向け
    • 公式サイトでは128MBで分割が推奨されているので小さければ良いというものではない
    • 128MB以下ならファイル差(csv, csv.gz, parquet(snappy), parquet(gz))はあまりない

ログとかは細かく分割されるケースもあるのでそういうときに前処理したくない場合は S3 Express One Zone 使えば良さそう。