SageMaker Unified Studio で Titanic のデータを分析する

はじめに

この記事では、 SageMaker Unified Studio を用いて、Titanic のデータを分析する方法と、その後の ML モデルを作成する準備の解説をします。

SageMaker Unified Studio とは、組織内のすべてのデータを検索してアクセスし、あらゆるユースケースにおいて、極めて優れたツールを使用して、それらのデータに基づいて行動できる、単一のデータおよび AI 開発環境です。

これを使用して、機械学習の業界で有名な Titanic のデータを分析します。Titanic とは、20 世紀最大の海難事故を起こした船の名前です、乗客データから「どのような人が生き残る可能性が高いか」を予測するモデルを構築するタスクとして、機械学習の有名なタスクの一つとなっています。

ドメインの作成

新しい SageMaker Unified Studio を利用するためには、ドメインを作成する必要があります。

ドメイン単位でリソースが管理されており、ドメインには専用のポータル URL が割り当てられます。これによって権限やリソースの管理がわかりやすくなり、データ分析や機械学習の総合プラットフォームとして利用することができます。

今回は、クイックセットアップを使用します。このとき、 VPC を選択する必要があります。SageMaker Unified Studio で作成されるリソースで VPC の中に作る必要のあるものは、この VPC の中に作られます。
「VPC を作成」のボタンを押すことで、スタックのクイック作成をすることができます。このように AWS が CloudFormation テンプレートを用意してくれており、これを使用することで簡単に環境を用意することができます。中身を見たところ、VPC、subnet、S3 VPC Endpoint、NAT Gateway、EIP、RouteTable、Internet Gateway など基本的なリソースでした。

上記のようにVPC を用意した後に、その中のサブネットを Unified Studio のドメインに登録する必要があります。プライベートサブネットが推奨されていました。先ほどの CloudFormation で 3 つのプライベートサブネットが定義されていたので、それらを使用します。

これでドメインを作成します。

SageMaker Unified Studio 初期設定

ドメインを作成した後は、SSO または IAM で認証し、SageMaker Unified Studio にログインできます。

Select a project のタブの中から、 create project を選択して project を作成します。

次の画面で、 Redshift Serverless と Lakehouse Database の名前を設定します。これらは、Unified Studio で分析するデータを保存するために使用されます。必ず作成されるので、 Redshift Serverless のコストには注意が必要です。

Create project を押して、project を作成します。これには時間がかかります。

データの用意

Kaggle の Titanic - Machine Learning from Disaster からデータをダウンロードします。（https://www.kaggle.com/competitions/titanic/data）
Titanic のデータセットは、乗客データとその生存結果からなります。欠損値 (値が登録されていないマス)や、カテゴリ変数 (男性と女性など)が含まれており、機械学習全体のワークフローが試せる良いデータセットになっています。

先ほど作成した Projects の中から Data を選び、 Add を選択します。Create table を選択し、データを追加していきます。
データを追加する方法は 2 種類あります。

• S3/external table
  • オブジェクトは S3 にそのまま保存し、 Glue Data Catalog のテーブルでメタデータを管理します。巨大なデータを安価に保存できます。
• Redshift table
  • オブジェクトは Redshift クラスタに保存され、メタデータも自身のカタログで管理します。処理が早いです。

今回は、両方を試してみようと思います。

Redshift にデータを追加する

すると、次のように Schema を出してその Data type まで補完してくれます。 Age は 1 才以下の場合に小数点で表現されているので、 real 型として推定されています。

S3 にデータを追加する

すると、Schema の補完がミスされていました。本来 Age は数値トレイトになるはずですが、 string になっています。

実際にデータを確認すると (確認方法は次の章を参照してください)、

名前が first name と second name で分かれてしまっています。生データを確認してみると <first name>, <second name> の形式になっています。これによって、 Schema の推定が間違えてしまったのだと思います。文字列に , が含まれているようなデータを S3 に取り込みたい場合は注意が必要です。何らかの方法でデータの形を整形する必要があります。今回は、 Schema の name にある , を : に置き換えます。

import pandas as pd
df = pd.read_csv('train.csv')
df['Name'] = df['Name'].str.replace(',', ':')
df.to_csv('train2.csv', index=False)
print(df)

このコードを train.csv が保存されているフォルダと同じフォルダで実行します。そして、新しく作成された train2.csv を読み込みます。

このようになりました。正しく Schema が推定されています。実際にデータを確認してみても、正しくデータがインプットされていることがわかります。

Schema の推定という面で見ると、 S3 経由で csv ファイルを読み込むよりも、コストを度外視するのであれば Redshift で読み込んだ方が手間をかけずにできました。

データの中身を確認する

ここから、探索的データ分析に入ります。Build から Query Editor を開きます。ここでは、データベースにあるデータに対して SQL を用いてクエリすることができます。Select database から先ほどデータを登録したデータベースを使用します。Redshift と S3 を使用して比較しつつ、検証しています。

Amazon Q を使用しながら確認していきます。 SQL 文を自分で書くこともできますが、複雑なクエリを書く際は Amazon Q に書かせた方が楽です。日本語で Amazon Q に指示をすることもできますが、 UI が英語仕様なので英語で命令しました。

まずは、どのようなデータがあるかを見ていきます。

Show me 10 items in train table?

を Amazon Q に聞くと、SQL 文を出力してくれます。
これをRun all すると、結果が出力されます。S3 と Redshift で結果に違いはありませんでした。

ここまでで、SageMaker の機能と Amazon Q を併用することで、データに対して簡単にクエリを発行できることを確認しました。 Amazon Q が SageMaker と連携しているおかげで、テーブルやカラムを理解しており、有効なクエリを返してくれています。

欠損値の補完

まずは、欠損値を埋めることを考えます。欠損値がどこに有るかを確認します。

I want to search there is null value in the train2 table.

と Q にお願いをします。すると、

Redshift

SELECT
  *
FROM
  project.train
WHERE
  passengerid IS NULL
  OR survived IS NULL
  OR pclass IS NULL
  OR name IS NULL
  OR sex IS NULL
  OR age IS NULL
  OR sibsp IS NULL
  OR parch IS NULL
  OR ticket IS NULL
  OR fare IS NULL
  OR cabin IS NULL
  OR embarked IS NULL
LIMIT
  10;

S3

SELECT
  *
FROM
  poc_titanic_<データベース名>.train2
WHERE
  age IS NULL
  OR cabin IS NULL
  OR embarked IS NULL
LIMIT
  100;

と出てきます。S3 では、age, cabin, embarked 以外に NULL 値がないことが前提となったクエリになっています。明示的に全てのカラムと指定をすると、全てのカラムを探索するようなクエリになりました。今回はデータ数が少ないので可能ですが、データを全て走査するクエリになってしまうのでパフォーマンスを気にしているのかと感じました。
実行すると、欠損値のあった列が全て出力されます。出力される最大数の出力がありました。かなりの数の欠損値があることがわかりました。そこで数をカウントします。

I want to find out how many null values there are in each column.

このようにお願いすると、

出力された SQL

SELECT
  SUM(
    CASE
      WHEN passengerid IS NULL THEN 1
      ELSE 0
    END
  ) AS passengerid_null_count,
  SUM(
    CASE
      WHEN survived IS NULL THEN 1
      ELSE 0
    END
  ) AS survived_null_count,
  SUM(
    CASE
      WHEN pclass IS NULL THEN 1
      ELSE 0
    END
  ) AS pclass_null_count,
  SUM(
    CASE
      WHEN name IS NULL THEN 1
      ELSE 0
    END
  ) AS name_null_count,
  SUM(
    CASE
      WHEN sex IS NULL THEN 1
      ELSE 0
    END
  ) AS sex_null_count,
  SUM(
    CASE
      WHEN age IS NULL THEN 1
      ELSE 0
    END
  ) AS age_null_count,
  SUM(
    CASE
      WHEN sibsp IS NULL THEN 1
      ELSE 0
    END
  ) AS sibsp_null_count,
  SUM(
    CASE
      WHEN parch IS NULL THEN 1
      ELSE 0
    END
  ) AS parch_null_count,
  SUM(
    CASE
      WHEN ticket IS NULL THEN 1
      ELSE 0
    END
  ) AS ticket_null_count,
  SUM(
    CASE
      WHEN fare IS NULL THEN 1
      ELSE 0
    END
  ) AS fare_null_count,
  SUM(
    CASE
      WHEN cabin IS NULL THEN 1
      ELSE 0
    END
  ) AS cabin_null_count,
  SUM(
    CASE
      WHEN embarked IS NULL THEN 1
      ELSE 0
    END
  ) AS embarked_null_count
FROM
  project.train;

とクエリが出てきます。 S3 と Redshift で同様のクエリが出てきました。結果としては以下のようになり、年齢に NULL があることがわかります。正しく検出されています。

Age の分布を見てみます。

I want to see the age distribution.

これで返ってくるクエリがこちらでした。

Redshift

SELECT
  ROUND(AVG(age), 2) AS avg_age,
  ROUND(MIN(age), 2) AS min_age,
  ROUND(MAX(age), 2) AS max_age,
  ROUND(STDDEV (age), 2) AS std_dev_age
FROM
  project.train;

S3

SELECT
  CAST(age AS DOUBLE) AS age,
  COUNT(*) AS count
FROM
  poc_titanic_<データベース名>.train2
WHERE
  age IS NOT NULL
GROUP BY
  CAST(age AS DOUBLE)
ORDER BY
  age;

出てくるクエリが異なっています。Redshift は分布の統計値を出しているのに対し、 S3 は年齢別の階級表を出すクエリとなっています。プロンプト内での「distribution」という単語の解釈に揺らぎがありそうです。このような分布を調べる際は、のちに出てくる JupyterLab の可視化の機能を用いた方が調べやすいと感じました。

カラム間での相関関係の確認

さて、次は相関関係についてみていきます。性別と生存率に比例関係でもあれば、予測に効果的なカラムだとわかります。一方で、生存率と全く無関係の値であればそれを学習データに加えてしまうと精度が落ちる原因になり得ます。

ここでは例として、性別と生存率の間に相関関係があるかどうかをみていきます。

What is the degree of correlation between sex and survived?

Redshift

SELECT
  ROUND(
    CORR (
      CASE
        WHEN sex = 'male' THEN 1
        ELSE 0
      END,
      survived
    ),
    2
  ) AS sex_survived_correlation
FROM
  project.train;

# 実行結果
ERROR: function corr(integer, integer) does not exist Hint: 
  No function matches the given name and argument types. 
  You may need to add explicit type casts.

Redshift のクエリはエラーになりました。クエリ中で使用されている CORR という関数は数値型の 2 値を引数にとります。しかし、今回 sex の列は “male"/"female" の VARCHAR 型となっています。 残念ながら、Unified Studio が型を事前に判定していても、関数が実際に適用できるかどうかはあまり気にしてくれないようです。
そこで型を意識して欲しいとお願いをして、同じクエリを生成するように伝えました。

What is the degree of correlation between age and survival? Please consider this carefully, paying attention to the type.

このようにお願いをしても、先ほどのエラーが改善されることはありませんでした。自動的にスキーマをつけてくれはしますが、操作がしやすいようにencodeするなどはクエリを実行する前にした方が良いかもしれません。

S3

SELECT
  sex,
  AVG(CAST(survived AS DOUBLE)) AS avg_survived
FROM
  poc_titanic_<データベース名>.train2
GROUP BY
  sex
ORDER BY
  avg_survived DESC;

一方で、 S3 の方は

のように思った通りの結果が出ました。

Q に分析するデータも判断してもらう

少し挑戦的なことをしてみます。Titanic の目的を Amazon Q に入力してみます。これまでの探索的データ分析では、どのようなデータを分析するかはこちらが指示していました。ここでは目的だけを入力し、 Amazon Q にどのようなデータを分析するべきかを判断してもらいます。
まずは、Titanic コンペのページから、このコンペの目的をコピペします。

The sinking of the Titanic is one of the most infamous shipwrecks in history.
On April 15, 1912, during her maiden voyage, the widely considered “unsinkable” RMS Titanic sank after colliding with an iceberg. Unfortunately, there weren’t enough lifeboats for everyone onboard, resulting in the death of 1502 out of 2224 passengers and crew.
While there was some element of luck involved in surviving, it seems some groups of people were more likely to survive than others.
In this challenge, we ask you to build a predictive model that answers the question: “what sorts of people were more likely to survive?” using passenger data (ie name, age, gender, socio-economic class, etc).

Amazon Q にそのまま入れてみます。すると、 SQL 文が出てきます。

Redshift

SELECT
  "passengerid",
  "survived",
  "pclass",
  "name",
  "sex",
  "age",
  "sibsp",
  "parch",
  "ticket",
  "fare",
  "cabin",
  "embarked"
FROM
  "project"."train"
WHERE
  "survived" = 1
ORDER BY
  "passengerid";

S3

SELECT
  "survived",
  COUNT(*) AS "total_passengers"
FROM
  poc_titanic_<データベース名>.train2
GROUP BY
  "survived"
ORDER BY
  "survived" ASC;

ともにデータの表示しかされませんでした。目的を理解して、それにあったような統計的特徴を表示するといったタスクはできないようです。コンペの問題文だったので、どちらかというと作って欲しいモデルの作成を依頼した形になったのかもしれません。

ML モデルを作成する

ここまで Redshift での検証も並行して進めましたが、訓練データは S3 にあった方が扱いやすいです（この時点まで到達して気づきました）。理由としては、以下のとおりです。

• データのサイズが小さいのでコストを考えると S3 で十分。
• 運用が簡単。 Python からの呼び出しもやりやすい。
• SageMaker build-in アルゴリズムにそのまま使うことができる。

データの読み込み

from sagemaker_studio import Project
project = Project()
databases = project.connection().catalog().databases
project_db = next(db.name for db in databases if db.name.startswith('poc_titanic_'))

とします。これによって、先ほど作成した DataCatalog のデータベース名を得ることができました。

print(project_db)

と出力し、この値をメモしておきます。

select * from "awsdatacatalog"."<データベース名>"."train2"

とすることで、訓練データを出力できます。先ほどは、 QueryEditor で操作しましたが、ここでもデータの可視化が可能です。

データの可視化

先ほどの SQL 文を実行すると以下のような表が表示されます。

ここでもデータの確認ができます。デフォルトで表示されているのはテーブルデータですが、 Summary の部分を開くと以下のようになります。

データの分布がどのようになっているかが図として表示されておりとてもみやすいです。欠損値の数なども表示されており、モデルを構築する際のことが意識されているように思います。

その下の Column で特定のカラムについてさらに詳しくデータを見ることができます。

箱ひげ図なども表示されており、データの分布や傾向を掴むことができます。

さらに Plotting ではカラムごとの相関関係を確認できます。

年齢に対して生存率はある程度傾向がありますが、全体としては相関はそこまで強くないことがわかります。

一方で、社会階級は生存率に対してかなり相関が強いことがわかります。

この部分の可視化機能が、同じ Notebook でモデル開発を進めていく中でかなりの強みになりそうです。これまで、 matplotlib を用いて可視化していた部分の大半の作業をこの機能が肩代わりしてくれそうです。

モデル開発の準備

data = _.to_pandas()

として、データを今後扱いやすいように pandas の dataframe にしておきます。
このあとは、Scikit-learnやLightGBMなどを使って、実際のモデル開発と同じ流れで開発していくことができます。さまざまな書籍やブログに書いてあると思うので、省略します。

まとめ

新しい SageMaker を使用して、探索的データ分析をするというテーマでした。Amazon Q がクエリを生成してくれる点が魅力的でした。簡単なクエリだったり、欠損値の確認は Amazon Q が生成してくれます。カラムを1 つ指定して、そのカラムのどのような特徴がみたいかを指示することで適切なクエリが生成されます。

Redshift と S3 の比較に関しては以下の表のようになっています。SageMaker Unified Studio にデータを保存する際は、従来の価格などの比較などに加えて以下のような観点も取り入れることができそうです。

観点	Redshift	S3
Amazon Q が生成する SQL の精度	異なる型のカラム同士の関係を求めるクエリなどで実行できないものが出力されることがあった	異なる型のカラム同士の関係を求めるクエリで適切な型変換を自動で挟むことができた
スキーマの自動読み取り	適切な型を自動で推定してくれた	文字列内にある , を separator として誤認識するケースがあった
機械学習という観点で見たときのデータ扱いやすさ	Jupyter Lab で扱いにくい	Jupyter Lab で扱いやすい

また、Jupyter Notebook の機能も良かったです。プロジェクト内で JupyterLab を起動できるので、簡単にモデル開発の準備ができます。途中の可視化の機能も、これまでのように matplotlib などでわざわざコードを書かなくて良くなる点で良いと感じました。

おまけ

CloudFormation で大量のリソースが作成され、 SageMaker でもおそらくさまざまなリソースが作成されました。Redshift serverless と S3 は覚えていますが、それ以外のリソースで高額なものが使用されていないか心配です。途中で使った Notebook 用のインスタンスとかどこに行ったんでしょうか？ EC2 の部分にも SageMaker AI の Notebook にもありませんでした。 SageMaker のドメインを削除したときに消えていると信じています。