クラスターごとに特徴量を集計。

BigQuery MLと総合ECサイトの会員の購買履歴データを用いた会員のクラスタリングを試みていますが、前回「BigQuery ML 試し打ち #03」でモデルの作成まで完了したので、今回はモデルの可視化と予測結果の出力を行います。

可視化するには、クラスターと特徴量のクロス集計表にする必要があります。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。このクエリ結果をデータセット「DE」に「sum_clusters_bqml」という名前で保存します。

モデルを可視化する。

「sum_clusters_bqml」テーブルをTableauで可視化します。クラスターIDを［行］、各説明変数を［列］シェルフにそれぞれ設定すると、以下のようなビューが表示されます。

クラスターごとの特徴を見ると、クラスターID:6は女性のみ、平均年齢は30歳程度、主に「エレクトロニクス・コンピューター」を購入しているセグメント、クラスターID:9は男性80%、平均年齢は40歳程度、主に「本・聞く本」「映画・音楽・ゲーム」「エレクトロニクス・コンピューター」を購入しているセグメント、などがわかります。また、年齢についてもクラスターごとにばらつきがあり、クラスターID:2は年齢層がやや高め、クラスターID:10は年齢層がやや低めなどの特徴があります。これらは「クラスター分析入門」で見られた特徴とは異なることがわかります。

どのクラスターかを予測する。

続いて、作成したモデルを使って、特定の特徴をもつ会員がどのクラスターに分類されるかの予測を行い、結果を出力します。それにはBigQuery MLで用意されているML.PREDICTという関数を使用し、以下の構文で記述します。

SELECT 出力したい変数
FROM ML.PREDICT(
  MODEL モデル名
  , (
    SELECT *
    FROM 機械学習用データテーブル
    WHERE 予測対象の会員の条件
  )
)

ではまず、男性で「本・聞く本」「映画・音楽・ゲーム」「エレクトロニクス・コンピューター」の購買経験がある会員がどのクラスターに分類されるかを予測します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

この結果から、すべての会員がクラスターID:9として予測されることがわかります。これはさきほど可視化したモデルと完全に一致します。

続けて、女性で「エレクトロニクス・コンピューター」の購買経験がある会員がどのクラスターに分類されるかを予測します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

この結果から、約90%の会員がクラスターID:6として予測されることがわかります。これはさきほど可視化したモデルとほぼ一致しますが、残りの約10%の会員がクラスターID:2として予測されています。それらの会員の特徴を見ると、比較的年齢の高い会員が多いように見受けられます。これはモデルの可視化結果で見た、クラスターID:2の年齢層がやや高めという評価と一致します。

そこで、年齢を20代から40代に限定した場合に、会員がどのクラスターに分類されるかを予測します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

この結果から、すべての会員がクラスターID:6として予測されることがわかります。これはさきほど可視化したモデルと完全に一致します。

BigQuery MLと総合ECサイトの会員の購買履歴データを用いた会員のクラスタリングを試みをしましたが、BigQuery上で完結して簡単に実現できることがわかりました。現時点で扱えるモデルは線形回帰・ロジスティック回帰・k 平均法クラスタリングのみですが、今後は協調フィルタリングやTensorFlowを用いたディープニューラルネットワークなど扱えるモデルも増えていくことが予定されているので、期待して待ちたいと思います。

SQLによるクラスタリング。

BigQuery MLは、Googleが提供するデータウェアハウス（Data Warehouse：DWH）であるGoogle BigQuery上にて機械学習（Machine Learning：ML）を可能とするクラウドサービスです。最大の特徴は、モデルの作成から評価や予測までをBigQueryと同様の標準SQLによるクエリ形式で行う点です。これにより、データの準備を含めた機械学習のすべてのプロセスをBigQuery上でSQLのみで完結することが可能となり、作業効率やセキュリティの面で大きなメリットが得られます。

前回の「BigQuery ML 試し打ち」ではロジスティック回帰モデルを用いて、総合ECサイトの会員の継続予測を行いました。今回は先日ベータ版がリリースされたk平均法クラスタリングのモデルの試し打ちがてら、例によって「データエスノグラフィ入門」と連動し、総合ECサイトの会員のクラスタリングを行なってみようと思います。

なお、同じテーマを「クラスター分析入門」で扱っており、クラスター分析（Cluster Analysis）あるいはクラスタリング（Clustering）とは何か、階層型と非階層型の違いは何かなどの詳細はそちらに詳しいので、ここでは省略します。また分析ツールについては、そこではGoogle Cloud Datalabを用いましたが、ここではBigQuely MLを用いるため、どちらも試しながら両方の違いを検証するのもよいでしょう。

機械学習用のデータと環境を準備。

それではBigQuery MLを用いたクラスタリングを始めましょう。分析を進める前に、まずは分析の背景と目的を整理します。

あなたは、とある総合ECサイトの責任者です。ECサイトでは、F2転換率が重要であると言われています。この”F”は購買頻度（Frequency）のことで、F2転換率とは初回購買から二回目購買への転換率（Conversion Rate）を意味します。一般的に、新規会員の獲得よりも、既存会員のリピート購買促進のほうがコスト効率が高いため、F2転換率は重要な指標となります。とはいえF2転換した会員が、その後も継続的に購買してくれる、いわゆる優良会員になるとは限りません。

そこで今回の分析目的を「優良化する会員の行動特性を、購買履歴データから把握する」とします。なおそこには、まだ優良化していな会員を意図的に優良化するためのヒントがあることは言うまでもありません。

分析対象データは、とある総合ECサイトの会員の購買履歴データとし、概要は以下のとおりです。

• 種類：総合ECサイトの会員の購買履歴
• 期間：2005年1月〜2013年12月（9年間）
• 会員数：639,777人
• 購買数：7,599,650件（平均11.9件/人）

データソースは以下の３つを使用します。なお、こちらはすでにBigQueryに投入済みとします。

行動特性の分析を進める中で、購買商品カテゴリ数と優良化との間に相関があることがわかりました。（※「データエスノグラフィ入門 #04」を参照）これは、新たな商品カテゴリを提案することが優良化につながる可能性を示唆しています。ただし、闇雲に提案するよりも、類似する会員セグメントの併売傾向と照らし合わせ、未購買商品カテゴリを提案するほうが効果が高いと考えられます。そこでクラスター分析によりそれを明らかにします。

まずはクラスタリングに用いる説明変数を定義します。説明変数を定義することを変数選択や特徴選択といいますが、非常に難しい問題なので、ここでは深く触れず、ひとまず「性別・年齢・購買商品カテゴリ」とします。

なお、クラスタリングにおいて強い相関をもつ変数の存在は冗長で無意味であり、予めどちらかを除外する必要がありますが、これらの各変数間に相関性が見られないことは確認済みとします。（※「クラスター分析入門 #02」を参照）

次にクラスタリング用のデータを用意するわけですが、ここでひとつ前処理が必要になります。クラスタリングでは要素間の距離を類似度とみなすことで類似性を分析するのですが、距離を測定するためには変数が数値化されている必要があります。しかしながら、性別や購買商品カテゴリは質的変数であるため、そのままでは数値として扱うことができません。そこでダミー変数（Dummy Variable）に置き換えます。また、年齢は量的変数であるため、説明変数として扱うことが可能ですが、クラスタリングに使うには他の説明変数と値の範囲を揃える必要があります。そこで正規化（Normalization）を行います。ダミー変数と正規化については「クラスター分析入門 #02」に詳しいので省略します。

以上を踏まえ、クラスタリング用のデータを以下のスキーマ定義で作成します。

この定義に従ってBigQueryで分析用のテーブルを作成します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。このクエリ結果をデータセット「DE」に「sum_members_cls_ non」という名前で保存します。これで分析用のデータと環境は整いました。

モデルを作成する。

データの準備が整ったので、クラスタリングを進めて行きます。まずはモデルの作成を行います。モデルの作成には、BigQuery MLで用意されているCREATE MODELという関数を使用し、以下の構文で記述します。なおクラスタリングは教師なし学習のため、正解を示す目的変数は存在せず、また訓練データと評価用データに分割する必要はありません。

CREATE OR REPLACE MODEL データセット名.モデル名 
OPTIONS( 
  model_type = 使用するモデリングタイプ
  ,num_clusters = クラスター数
  ,standardize_features = 真偽値
) AS (
  SELECT 説明変数, ...
  FROM 機械学習用データテーブル
)

［model_type］にはk平均法クラスタリングを示す［kmeans］を指定します。クラスター数を指定するオプションの［num_clusters］には妥当性が確認されているである10を指定します。（※「クラスター分析入門 #03」を参照）また、［standardize_features］は正規化を行うかどうかのオプションで、すでに処理済みですがTRUEを指定しておきます。なお、初期設定はTRUE であるため省略可能です。

BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。なおこのクエリ結果はデータセット「DE」に「mdl_members_cls」という名前で自動的に保存されます。

これでモデルの作成は完了です。次回は作成したモデルの可視化や予測結果の出力を行います。

モデルを評価する。

BigQuery MLと総合ECサイトの会員の購買履歴データを用いて、一年間の購買傾向から、翌年も継続して購買する会員を予測するという試みをしていますが、前回「BigQuery ML 試し打ち #01」で予測モデルの作成まで完了したので、今回はモデルの評価と予測結果の出力、さらに重みの分析を行います。

まずは予測モデルの評価を行いますが、それにはBigQuery MLで用意されているML.EVALUATEという関数を使用し、以下の構文で記述します。

SELECT * 
FROM ML.EVALUATE(
  MODEL モデル名
  , (
    SELECT 目的変数, 説明変数, ...   
    FROM 機械学習用データテーブル
    WHERE 評価データを指定
  )
)

モデル作成時と同様、目的変数は列名を「label」で指定するルールのため「retention」をそれに置き換えます。説明変数には「性別・年齢・購買商品カテゴリ・購買頻度・購買金額」を指定するため、それ以外は除外します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

すると、クエリ結果に以下のような表が出力されるかと思います。

これらの項目と値の意味を簡単に解説しますが、その前に二項分類の予測と結果のマトリクスについて理解をしておく必要があります。それは以下の表で整理できます。

• 真陽性：TRUEの結果を正しくTRUEと予測
• 真陰性：FALSEの結果を正しくFALSEと予測
• 偽陽性：FALSEの結果を誤ってTRUEと予測
• 偽陰性：TRUEの結果を誤ってFALSEと予測

このマトリクスを基に、評価結果の［precision］［recall］［accuracy］［f1_score］の各項目の意味を以下のように説明することができます。またそれぞれの値は0から1の実数となり、1に近くほど精度が高いことを意味します。

すなわち今回の予測モデルの評価結果としては、正解率は77%であり、TRUEと予測したものが結果としてTRUEであった確率を示す適合率は89%と非常に高いものの、結果が TRUEであるものを正しくTRUEと予測した確率を示す再現率は50%に止まった、ということになります。

継続か否かを予測する。

続いて、作成した予測モデルを使って、評価データに対する「継続か否か」の予測を行い、結果を出力します。それにはBigQuery MLで用意されているML.PREDICTという関数を使用し、以下の構文で記述します。

SELECT 出力したい変数
FROM ML.PREDICT(
  MODEL モデル名
  , (
    SELECT *
    FROM 機械学習用データテーブル
    WHERE 評価データを指定
  )
)

構文としては評価の場合とおおむね同じですが、機械学習用データテーブルから抽出する項目には、最終的に出力したい変数を含めておく必要があります。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

すると、以下のスキーマのテーブルが出力されます。レコードは会員ID単位で、predicted_labelが予測結果となります。predicted_label_probs.probは真偽それぞれの予測の確からしさの値であり、高いほうが予測結果として選択されます。

重みを分析する。

最後に重みの分析を行います。重み（Weight）とは結果の決定に対する影響力のことであり、それが大きい説明変数がわかれば、意図する結果を再現しやすくなります。機械学習の目的は、予測結果を導出することでもありますが、重みの大きい説明変数を発見することでもあります。それにはBigQuery MLで用意されているML.WEIGHTという関数を使用し、以下の構文で記述します。

SELECT * 
FROM ML.WEIGHT(
  MODEL モデル名
  ORDER BY ABS( weight ) DESC
)

BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

すると、クエリ結果に以下のような表が出力されるかと思います。

重みは、正の場合は値が大きいほど、その変数が目的変数の真値への影響力が強く、逆に負の場合は値が小さいほど、目的変数の偽値への影響力が強いことを意味します。この結果から、やはり購買金額（Monetary）と購買頻度（Frequency）が目的変数の真値への影響力が強い、すなわち購買金額や頻度が高い会員ほど継続する可能性が高いことがわかります。逆に年齢（Age）が目的変数の偽値への影響力が強い、すなわち年齢が高い会員ほど離反する可能性が高いことがわかります。

BigQuery MLと総合ECサイトの会員の購買履歴データを用いて、一年間の購買傾向から、翌年も継続して購買する会員を予測するという試みをしましたが、BigQuery上で完結して簡単に実現できることがわかりました。現時点で扱えるモデルは線形回帰・ロジスティック回帰・k 平均法クラスタリングのみですが、今後は協調フィルタリングやTensorFlowを用いたディープニューラルネットワークなど扱えるモデルも増えていくことが予定されているので、期待して待ちたいと思います。

SQLで機械学習。

BigQuery MLは、Googleが提供するデータウェアハウス（Data Warehouse：DWH）であるGoogle BigQuery上にて機械学習（Machine Learning：ML）を可能とするクラウドサービスです。最大の特徴は、モデルの作成から評価や予測までをBigQueryと同様の標準SQLによるクエリ形式で行う点です。これにより、データの準備を含めた機械学習のすべてのプロセスをBigQuery上でSQLのみで完結することが可能となり、作業効率やセキュリティの面で大きなメリットが得られます。

現時点で扱えるモデルは線形回帰・ロジスティック回帰・k 平均法クラスタリングのみですが、扱えるモデルは今後増えていくことが予定されています。

ベータ版リリースから一年近くが経過しており、いまさら試し打ちというのも変ですが、一般提供されたのを受けて、復習もかねてその触り心地をまとめておきます。それではBigQuery MLを用いた機械学習を始めましょう。

今回は「データエスノグラフィ入門」と連動し、総合ECサイトの会員の継続購買の予測を行うという設定で進めます。分析対象データは、とある総合ECサイトの会員の購買履歴データとし、概要は以下のとおりです。

• 種類：総合ECサイトの会員の購買履歴
• 期間：2005年1月〜2013年12月（9年間）
• 会員数：639,777人
• 購買数：7,599,650件（平均11.9件/人）

データソースは以下の３つを使用します。なお、こちらはすでにBigQueryに投入済みとします。

これらのデータを使用し、2012年の一年間の購買傾向から、2013年も継続して購買する会員を予測してみます。

機械学習用のデータと環境を準備。

分析を進める前に、まずは分析手法を決めます。売上や継続率などの数値予測の場合は線形回帰（Linear Regression）を用いますが、「継続か否か」のような二項分類の場合はロジスティック回帰（Logistic Regression）を用います。

また、予測対象の変数を目的変数（Objective Variable）といい、今回は「継続か否か」がそれになります。その結果を決定づける原因となる変数を説明変数（Explanatory Variable）といい、機械学習では特徴量（Feature Value）とも言います。説明変数は無数に存在しますが、結果の決定に対する影響力を重み（Weight）といい、重みの大きい説明変数がわかれば、意図する結果を再現しやすくなります。機械学習の目的は、予測結果を導出することでもありますが、重みの大きい説明変数を発見することでもあります。

説明変数を定義することを変数選択や特徴選択といいますが、非常に難しい問題なので、ここでは深く触れず、ひとまず「性別・年齢・購買商品カテゴリ・購買頻度・購買金額」とします。なお、集計期間は2012年の一年間とします。

次に、BigQueryで機械学習用のテーブルを用意します。必要なのは会員IDごとの集計データで、そこに目的変数と説明変数を含めます。さらに、訓練データ（Training Data）でモデルを作成し、評価データ（Evaluation Data）でモデルを評価するというプロセスを踏まえるため、データをその二つに分割します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。また、このクエリ結果をデータセット「DE」に「sum_members_ret」という名前で保存します。

なお、処理の効率化のために10%のサンプリングをしていますが［※1］、これは会員IDを10で割った剰余が0の場合に限定するという意味です。また、欠損を除外するために性別がNULLでない会員に限定し［※2］、年齢の異常値を除外するために10歳以上90歳未満の会員に限定しています［※3］。さらに、集計期間中の購買がない会員を除外しています［※4］。

SQL内の「retention」が、目的変数である「継続か否か」を指す変数で、最終購買日が2013年以降の会員の場合のみ継続を意味する「TRUE」を、それ以外は離反を意味する「FALSE」を設定します。また「evaluation」が、訓練データと評価データを切り分ける変数で、90%が訓練データ、10%が評価データになるようランダムに振り分けます。もともと10%のサンプリングを行なっているため、会員IDを100で割った剰余が0の場合を評価データとして「TRUE」を、それ以外は訓練データとして「FALSE」を設定します。

ちなみに、説明変数に購買頻度（Frequency）や購買金額（Monetary）は含めますが、最終購買日（Recency）は含めません。これは、目的変数である「継続か否か」自体が最終購買日を基準に定義されるためです。これを含めてしまうと、当然ながら予測精度は自動的に100%になります。

モデルを作成する。

データの準備が整ったので、機械学習を進めて行きます。まずは「継続か否か」の予測モデルの作成を行います。モデルの作成には、BigQuery MLで用意されているCREATE MODELという関数を使用し、以下の構文で記述します。

CREATE OR REPLACE MODEL データセット名.モデル名 
OPTIONS( 
  model_type = 使用するモデリングタイプ
) AS (
  SELECT 目的変数, 説明変数, ...
  FROM 機械学習用データテーブル
  WHERE 訓練データを指定
)

［model_type］にはロジスティック回帰を示す［logistic_reg］を指定します。目的変数は列名を「label」で指定するルールのため「retention」をそれに置き換えます。説明変数には「性別・年齢・購買商品カテゴリ・購買頻度・購買金額」を指定するため、それ以外は除外します。

BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。なおこのクエリ結果はデータセット「DE」に「mdl_members_ret」という名前で自動的に保存されます。

これでモデルの作成は完了です。次回は作成したモデルの評価や予測結果の出力、さらに重みの分析を行います。

サブクエリはWITH句。

前回は検索の基本構文であるSELECT文と、集計と正規化の基本構文であるGROUP BY句について説明しましたが、今回は非正規化の基本構文であるJOIN句を中心に見ていきましょう。

練習用データ「E-Commerce Data」をBigQueryで操作します。なお、BigQueryと練習用データの準備は「BigQueryではじめるSQL #01」を参照してください。

非正規化（Denormalization）とはデータの重複を許容することです。データが重複すると、データの追加・更新・削除における処理が冗長化するため、メンテナンス効率を重視する場合はなるべく排除しますが、処理速度を重視する場合はそれを犠牲にして、あえて非正規化を行います。

練習用データ「E-Commerce Data」は、とあるECサイトの購買履歴データで、各レコードには「CustomerID」（顧客ID）が紐づいているため、各顧客IDをグループとみなし、それぞれの購買回数に基づいた顧客ランクの集計が可能です。

その顧客IDごとの顧客ランクを、購買履歴と合わせて参照したい場合は、購買履歴の各レコードに、該当する顧客IDの顧客ランクを保持しておくと便利です。すなわち非正規化を行うということです。この非正規化を以下の手順で進めます。

1. 購買履歴データから、顧客IDごとの顧客ランクを集計する。
2. 購買履歴データの各レコードに、上記1で集計した顧客IDごとの顧客ランクの列を結合する。

このように、前のクエリの出力をもとに後のクエリを行うこと、あるいはその「前のクエリ」のことをサブクエリ（Subquery）といいます。サブクエリの記述方法には、後のクエリのFROM句に前のクエリを記述する方法もありますが、構文が視覚的に煩雑になるため、それを回避したい場合にWITH句を用います。WITH句を用いたサブクエリの構文は以下のようになります。

WITH ビュー名 AS ( サブクエリ ) クエリ

ちなみに、サブクエリの出力は実体を持たない仮想的なテーブルですが、それをビュー（View）といいます。また、構文中のASはAS句といい、ここではサブクエリが出力したビューに名前をつける役割を担います。

前回の「BigQueryではじめるSQL #03」で行った顧客IDごとの顧客ランクの集計をサブクエリとして、後のクエリに利用できるようWITH句を用いて以下の例文のように記述します。

列結合による非正規化はJOIN句。

それでは、購買履歴データの各レコードに、上記で集計した顧客IDごとの顧客ランクの列を結合して、非正規化を行います。このように列方向に結合することを列結合といい、列結合による非正規化にはJOIN句を用います。構文は以下のとおりです。

SELECT 列名, 列名, … FROM テーブル名（ビュー名） AS 略称 JOIN テーブル名（ビュー名） AS 略称 ON 結合条件式

さきほどのサブクエリと組み合わせると、例文は以下のようになります。

上記の例文全体の意味は、テーブル「ECData」（略称「ED」）と顧客ランクの集計結果であるビュー「CRank」（略称「CR」）を、列「CustomerID」が一致する場合に列結合し、列「InvoiceNo」「StockCode」「UnitPrice」「CustomerID」「CustomerRank」を出力する、となります。青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

なお、例文中のASはAS句といい、ここではテーブルやビューに略称をつける役割を担います。略称は必須ではありませんが、つけておくと便利です。というのも、列結合ではテーブル間で列名が重複することが多く、その場合はどのテーブルの列かを「テーブル名.列名」の形で明記する必要があるのですが、テーブル名が長いとSQL文が冗長となり、可読性が損なわれるからです。この例文では「ED.CustomerID」がそれにあたります。

また、列結合には内部結合と外部結合があります。内部結合は結合条件に合致するレコードが双方にあるものだけを残す結合方式で、INNER JOINを用います。ちなみに、単にJOINと記述するとINNER JOINと同じ意味になります。つまり上記例文のJOINは内部結合となります。

一方で、外部結合は結合条件に合致するものが双方になくても残す結合方式で、OUTER JOINを用いますが、左右どちらも残す場合はFULL OUTER JOIN、左のみ残す場合はLEFT OUTER JOIN、右のみ残す場合はRIGHT OUTER JOINと、区別して指定する必要があります。

ビッグデータ分析に便利な構文。

複数のテーブルを列方向に結合することを列結合というのに対し、行方向に結合することを行結合といい、UNION句を用います。なお行結合では、結合するテーブルの列の構成が一致していることが前提となります。構文は以下のとおりです。

SELECT 列名, 列名, … FROM テーブル名（ビュー名） UNION SELECT 列名, 列名, … FROM テーブル名（ビュー名） 

ちなみに、上記のように単にUNIONと記述すると、結合するテーブル間で重複するレコードは削除され、ユニークなものだけが残ります。重複を許容したい場合はUNION ALLと記述します。

行結合は、日時で分割して蓄積や集計したレコードを統合する場合などで利用されます。すなわち、ビッグデータ分析には便利な機能です。なお、大量のレコードを日時などで分割して管理することをパーティショニングといいます。

この他にも、ビッグデータ分析では集計関数＋OVER句をよく用います。これは、通常の集計処理をGROUP BY句を使った正規化状態で行うのに対し、非正規化状態のまま、特定のグループごとに集計処理を行う方法です。そのグループをウィンドウ（Window）といい、PARTITION BY句で指定します。なお、この場合の集計関数は、分析関数やウィンドウ関数とも呼ばれます。構文は以下のとおりです。

SELECT 集計関数 OVER( PARTITION BY 列名 ) FROM テーブル名（ビュー名）

これを利用すれば、購買履歴などの時系列データの集計処理を行う場合に、サブクエリでGROUP BY句を使って集計し、その結果をJOIN句を使って時系列データに列結合する、という煩雑な処理をする必要がなくなり、とても便利です。

なお、時系列データの分析については、別の記事にて詳しく説明する予定なので、UNION句やOVER句の具体的な使い方や例文の紹介はその機会に譲りたいと思います。

また、この「BigQueryではじめるSQL」で触れたもの以外にも、SQLには多くの便利な構文・関数・演算子があります。とりわけBigQueryで利用可能なものについては、GCPのBigQuery公式リファレンスサイトに詳しいため、こちらをご参照されることをお勧めします。

検索はSELECT文。

SQLによる検索の基本構文はSELECT文、集計と正規化の基本構文はGROUP BY句になりますので、こちらを中心に見ていきましょう。

練習用データ「E-Commerce Data」をBigQueryで操作します。なお、BigQueryと練習用データの準備は「BigQueryではじめるSQL #01」を参照してください。

SELECT文は検索対象のテーブル（Table）と列（Column）の名前を指定する形で記述します。BigQueryの場合、テーブル名はデータセット名と合わせて記述し、その間をドット「.」で結びます。また、列名は複数の指定が可能で、その間をカンマ「,」で区切ります。構文と例文は以下のようになります。

SELECT 列名, 列名, ... FROM テーブル名（ビュー名）

ちなみにビュー（View）とは、テーブルの一部を抽出あるいは複数のテーブルを結合するなどして作成した実体をもたない仮想的なテーブルのことで、SQL文中のサブクエリ（Subquery）の出力がそれにあたります。サブクエリについては次回説明します。

また、検索対象となる行（Record）の条件や数を指定する場合は、それぞれWHERE句とLIMIT句を用います。構文と例文は以下のとおりです。

SELECT 列名, 列名, ... FROM テーブル名（ビュー名） WHERE 条件式 LIMIT 行数

なお、WHERE句には条件式を指定しますが、検索対象となる列名と、演算子や定数などを組み合わせて表現します。この例文でいうと「UnitPrice >= 10」がそれにあたります。そして、この例文全体の意味は、テーブル「ECData」で、列「UnitPrice」が10以上の行を100行だけ抽出し、列「InvoiceNo」「StockCode」「UnitPrice」を出力する、となります。青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

集計はGROUP BY句。

集計と正規化の基本構文であるGROUP BY句は、SELECT文と組み合わせて使います。内容の説明は後述するとして、構文と例文はこのようになります。

SELECT 列名, 集計関数 AS 列名, ... FROM テーブル名（ビュー名） GROUP BY 列名

集計（Aggregation）とは、データ内のあるグループ（Group）について、頻度・合計値・平均値などを計算することをいいます。グループの軸には性別や年代などさまざまあり、この軸のことをディメンション（Dimension）ともいいます。

練習用データ「E-Commerce Data」は、とあるECサイトの購買履歴データで、各レコードには「CustomerID」（顧客ID）が紐づいているため、各顧客IDをグループとみなし、それぞれの購買回数を集計することができます。

上記の例文全体の意味は、テーブル「ECData」で、グループの軸「CustomerID」ごとに、列「CustomerID」と、行数の集計結果である「InvoiceCount」を出力する、となります。こちらも、青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

なお、例文中のCOUNTは集計関数（Aggregate Function）と呼ばれ、行数を集計するものになります。集計関数は他に、合計値を集計するSUMや、平均値を集計するAVGなどがあります。

また、例文中のASはAS句といい、ここでは集計関数の出力列に名前をつける役割を担います。つまり「COUNT(*)」の出力列に「InvoiceCount」という名前をつけることを意味します。AS句はこの他にも、SELECT文で出力されたテーブルに名前をつける機能もあります。こちらは次回のWITH句やJOIN句のところで説明します。

ちなみに、ここでもう少し踏み込んで、各顧客IDごとの顧客ランクを集計する方法を見てみます。顧客ランクの集計条件を、購買回数が300回以上を「A」、100回以上を「B」、それ未満を「C」と定義すると、例文は以下のようになります。なお、例文中のCASEはCASE句という条件分岐の基本構文のひとつで、分岐が多い場合に使います。条件分岐には他にIF句があり、こちらは分岐がひとつの場合に使います。

上記の例文全体の意味は、テーブル「ECData」で、グループの軸「CustomerID」ごとに、列「CustomerID」と、顧客ランクの集計結果（集計条件は、購買回数が300回以上を「A」、100回以上を「B」、それ未満を「C」とする）である「CustomerRank」を出力する、となります。こちらも、青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

正規化もGROUP BY句。

GROUP BY句は、集計の他に正規化の役割を持ちます。正規化（Normalization）とはデータの重複を排除することです。

練習用データ「E-Commerce Data」においては、StockCode（商品コード）とUnitPrice（商品単価）が重複しているはずです。なぜなら商品コードとは商品管理の最小単位であるため、商品単価が一意に定義されているはずだからです。すなわち、商品コードと商品単価の1対1の対応表を別テーブルで保持しておけば、購買履歴のテーブルとして保持する必要があるのは商品コードだけでよいことになります。

では、商品コードと商品単価の1対1の対応表を取り出して正規化してみましょう。例文はこのようになります。

上記の例文全体の意味は、テーブル「ECData」で、グループの軸「StockCode」ごとに、列「StockCode」と、列「UnitPrice」の任意の値を列名「UnitPrice」として出力する、となります。こちらも、青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

なお、例文中のANY_VALUEも集計関数のひとつで、グループ内の指定した列の任意の値を取り出すものであり、データの重複を正規化する場合によく用います。

また、このように正規化された対応表データをマスタデータ（Master Data）といい、商品コードをキーとしたものを商品マスタ、顧客IDをキーとしたものを顧客マスタといいます。逆に、購買履歴などの発生事象の時系列データをトランザクションデータ（Transaction Data）といいます。

次回は「BigQueryではじめるSQL」最終回、非正規化の基本構文であるJOIN句を中心に見ていきます。

RDBとNoSQL。

BigQueryの準備が整ったところで、ビッグデータ分析のためのSQLの実践を進めていきましょう。なお、BigQueryの準備は「BigQueryではじめるSQL #01」を参照してください。

とはいえ、データベース（Database：DB）やクエリ（Query）の基本概念を理解していないと、ただサンプルどおりにSQLを実行するだけになってしまうので、簡単におさらいしておきます。

蓄積や検索をしやすいように整理されたデータの集まりのことDBといい、蓄積や検索の指示を行うことをクエリといいます。また、単にDBというと関係データベース（Relational Database：RDB）のことをさします。RDBは、データを複数のテーブル（Table）として管理し、テーブル間の関係を定義することで、複雑なデータの関連性を扱えるようにしたもので、企業の基幹システムのような大規模なものから、個人のブログのような小規模なものまで、データ管理の領域で幅広く利用されています。

DBを管理するシステムのことをデータベース管理システム（Database Management System：DBMS）といいますが、とりわけRDBによるものをRDBMS（Relational Database Management System）といい、代表的なものにPostgreSQLなどがあります。GCP（Google Cloud Platform）ではCloud SQL、AWS（Amazon Web Services）ではAmazon RDSがそれにあたります。

一方でRDBは、データ構造が複雑化したり、データ量が膨大化すると、整合性の確保のために処理速度が遅くなるという問題を抱えています。そこでNoSQLという概念が登場しました。NoSQLは「Not only SQL」の略とされる、RDB以外のDBを示す大まかな分類であり、特定のデータ管理方式を示すものではありません。代表的な方式としてキーバリュー型があり、GCPではCloud Bigtable、AWSではAmazon DynamoDBがそれにあたります。

RDBとNoSQLは、どちらが優れているかということではなく、用途により使い分けることが重要です。NoSQLの登場前は、これらを考慮することなく無条件にRDBを採択していたことが問題であったわけで、RDBが劣るということではありません。RDBとNoSQLの比較表は以下のとおりで、ざっくり言うと、顧客ランクのような日々更新されるマスタデータの管理はRDB、購買履歴のような日々追加されるトランザクションデータの管理はNoSQLが、それぞれ得意領域としています。

なお、Google BigQueryやAmazon Redshiftはカラムストア型と呼ばれ、RDBではないためにNoSQLに区分されますが、RDBと同じテーブルの概念を持ち、SQLによるデータ操作を可能としつつも、列指向にデータを蓄積することで処理速度を高速化させる方式となります。この列指向について詳しく見ていきます。

行指向と列指向。

テーブル型のDBには大きく、行指向DBと列指向DBの二つの方式があります。もともと行指向という概念や言葉は存在しませんでしたが、列指向の登場後、従来のRDBはそれと区別するために行指向と呼ばれるようになりました。

データの蓄積と検索を、行指向DBでは行単位、列指向DBでは列単位で行います。この方式の違いが、以下のような特徴の違いを生みます。

つまり列指向DBは、大量データの特定の列に対する集計処理が得意であり、ビッグデータ分析に向いているといえます。一方で、1行に対する計算処理が苦手なため、1行をまるごと更新する処理（SQLでいうとUPDATE）は推奨されません。またデータの抽出を行う際も、すべての列を指定するような処理（SQLでいうとSELECT *）も非効率であるため避けるべきです。なお、BigQueryはクエリ課金（クエリ時のデータスキャン量による従量課金）であるため、コスト面においても指定する列を必要最小限に抑えることは重要です。

正規化と非正規化。

DBの基本概念でもうひとつ重要なのが、正規化と非正規化です。これをきちんと理解することで、用途に対して効率的なDBを設計することが可能となります。

正規化（Normalization）とはデータの重複を排除することであり、これによりデータの追加・更新・削除における処理の冗長化が抑制され、メンテナンスが効率化されます。この正規化を簡単に実現できるように考えられたのがRDBです。

正規化をするほど冗長化が抑制され、メンテナンス効率が上がる一方で、テーブルの分割によりデータ構造が複雑化し、処理速度が遅くなるという欠点があります。そこで、処理速度を重視する場合には、あえて非正規化（Denormalization）を行います。非正規化を前提として処理速度の高速化を追求したのがNoSQLであるともいえます。

正規化と非正規化の特徴を整理すると、このようになります。

この正規化と非正規化も、どちらが優れているかということではなく、用途に合わせて選択する、あるいは併用することが重要です。典型的な併用方法として、マスターとなるDBを正規化して管理し、メンテナンスを効率化させつつ、個別の分析用途に合わせて非正規化かつ高速化したDBを出力するという構造化手法がよく用いられます。その出力されたDBをデータマート（Data Mart）といいます。また、正規化と非正規化に用いられるSQLの構文がGROUP BY句とJOINk句で、SQLを利用したデータ分析の主役となります。

次回は検索の基本構文であるSELECT文と、集計と正規化の基本構文であるGROUP BY句を中心に見ていきましょう。

ビッグデータ分析のためのSQL。

Google BigQuery¹⁾BigQuery vs. Redshift どっち？は、Googleが提供するクラウドサービスで、フルマネージドなデータウェアハウス（Data Warehouse：DWH）であり、総合的なクラウドコンピューティングサービスであるGCP（Google Cloud Platform）の一部です。

BigQueryは、PostgreSQLなどの一般的なRDBでも使われている標準SQL（Standard SQL）で、大量データの処理に優れた列指向DB（Columner Database）でデータを自在に操作することが可能です。また、AWS（Amazon Web Services）のAmazon Redshiftとよく比較されますが、SQLの実行にブラウザUIを利用でき、さらに時間課金ではなくクエリ課金（クエリ時のデータスキャン量による従量課金）であるため、より手軽かつ安価にビッグデータのアドホック分析ができるという特徴を備えています。

そしてこのことは、これからビッグデータ分析のためのSQLを学びたい人のトレーニング用としても相性がよく、Googleのアカウントがあれば、いますぐSQLの練習を開始できます。

ではさっそく、BigQueryによるビッグデータ分析のためのSQLをはじめてみましょう。GCPコンソールにアクセスしてみてください。検索エンジンで「Google Cloud」と検索してもらっても結構です。すると、初めてアクセスする方にはチュートリアルが、ログイン経験がある方にはデフォルトプロジェクトのダッシュボードが表示されるかと思います。

なお、GCPには12ヶ月間300ドル分の無料トライアルがあります。（2019年2月現在）画面上部［無料トライアルを試してみませんか…］の右横の［有効化］をクリックして、クレジットカードを登録すれば、無料トライアルを開始できます。また、無料トライアル終了後に自動的にクレジットカード課金されることはないので安心して利用できます。

ところで、GCPにはプロジェクト（Project）という特徴的な概念があります。BigQueryはもちろん、Cloud StorageやCompute EngineなどのGCPのすべてのサービスインスタンスがこれにひもづき、またプロジェクトごとに参加するアカウントを設定することができます。まさに、現実世界のプロジェクトの概念に近いものと言えるでしょう。仕事で使うには、まずはプロジェクトを作成するところからスタートしますが、練習用にはデフォルト設定されている「My First Project」で問題ありません。

Kaggleで練習用データを準備。

さて、GCPの準備が整ったところで、BigQueryによるビッグデータ分析のためのSQLに挑戦するわけですが、それには分析用データが必要です。手元にあるデータでもよいのですが、せっかくなのでビッグデータ分析に向いたデータで進めてみましょう。こんなときはKaggle（カグル）がおすすめです。

Kaggleは世界中のデータサイエンティストが集まるコミュニティーサイトで、最大の特徴はコンペの開催です。企業や政府がデータ分析や機械学習の課題を提示し、もっとも優れた分析や予測のモデルを賞金と引き換えに買い取る仕組みになっています。Kaggleに登録しているデータサイエンティストは、コンペへの参加や練習用データセットのダウンロードを無料で行えます。

ではKaggleに登録して、練習用データをダウンロードしてみましょう。Kaggleの登録はFacebookなどのSNSアカウントで簡単に行えます。登録が完了したら、ログインして「E-Commerce Data」というデータセットのページにアクセスしてみてください。こちらは、とあるECサイトの購買履歴データで、内容・サイズともにビッグデータ分析の練習用にはちょうどよいものとなっています。このページの右上部の「Download」というリンクをクリックすれば、練習用データの準備は完了です。

簡単なクエリにトライ。

練習用データをさっそくBigQueryで操作してみましょう、と行きたいところですが、もう少し準備が必要です。BigQueryでデータを操作するには、テーブル（Table）を作成する必要があります。テーブルの作成には、データファイルをそのままBigQueryにアップロードする方法もありますが、ファイルサイズに10MBの上限がかかるため、今回の練習用データ（45.6MB）では使えません。別の方法として、Googleドライブを経由する方法とGCPのGoogle Cloud Storage（GCS）を経由する方法がありますが、ここではGCSを経由する方法を選択します。

GCPコンソールの左上のハンバーガーメニューをクリックすると、GCPで利用できるサービスメニューが開くので［Storage］をクリックをしましょう。ここに練習用データをアップロードするわけですが、そのためにはバケット（Bucket）の作成が必要になります。バケットはフォルダのようなものと考えてください。画面上部の［バケットを作成］をクリックし、任意の名前をつけて作成します。あとはそのバケット内に入り、練習用データファイル「data.csv」を画面内にドラック＆ドロップするか、［ファイルをアップロード］ボタンをクリックすることで、練習用データをアップロードできます。

GCSへのアップロードが完了したら、BigQueryのテーブルへの取り込みを行います。サービスメニューの［BigQuery］をクリックしましょう。ここでも、テーブルを作成する前にデータセット（Dataset）を作成する必要がありますが、こちらもフォルダのようなものになります。右下ペインにある［データセットを作成］をクリックし、任意の名前をつけてデータセットを作成します。ここでは「Training」と命名します。すると左ペインに作成したデータセット「Training」がツリー状で表示されるので、それを選択し、右下ペインにある［テーブルを作成］をクリックします。

そこで表示される［テーブルの作成］画面で、GCSにアップしたデータを取り込んでテーブルを作成します。手順は以下のとおり。

1. ［テーブルの作成元］で［Google Cloud Storage］を選択
2. ［GCS バケットからファイルを選択］で「data.csv」を選択
3. ［ファイル形式］で［CSV］を選択
4. ［テーブル名］に任意のテーブル名を入力（ここでは「ECData」と命名）
5. ［スキーマと入力パラメータ］にチェック
6. ［詳細オプション］のアコーディオンを開く
7. ［スキップするヘッダー行］に「1」を入力
8. ［テーブルを作成］ボタンをクリック

すると左ペインに作成したテーブル「ECData」がツリー状で表示されているかと思います。これでテーブルの作成は完了です。

試しに、簡単なSQL文を実行してみましょう。左ペインで作成したテーブルをクリックすると、右下ペインにテーブルのデータが表示されます。その状態で、同じく右下ペインの［テーブルをクエリ］をクリックしてみてください。すると右上ペインに「SELECT FROM ‘Training.ECData’ LIMIT 1000」というSQL文が表示されるかと思います。そのSQL文の「SELECT」と「FROM」の間に「InvoiceNo, StockCode」というテキストを挿入して、青い［実行］ボタンをクリックしてみましょう。「InvoiceNo」と「StockCode」の二つの列と1,000行に絞られたデータが右下ペインに表示されるかと思います。このように非常に手軽にSQLを実行することができるわけです。

SELECT
  InvoiceNo
 ,StockCode
FROM 'Training.ECData'
LIMIT 1000

では次回以降で、ビッグデータ分析のためのSQLの実践に踏み込んで行きたいと思います。

セルフサービスなDWH。

データウェアハウス（Data Warehouse：DWH）は、直訳すれば「データの倉庫」で、データベース（Database：DB）の一種ですが、過去すべての時系列データを要約せずにそのまま保持し続ける、文字通り倉庫のような役割から、区別してそう呼ばれています。

また、DWHはデータを活用した意思決定に利用されることから、ビジネスインテリジェンス（Business Intelligence：BI）のひとつに位置付けられます。BIは経営・会計・情報処理などの用語で、企業などの組織のデータを収集・分析・可視化することで、ビジネスの意思決定に役立てる手法や技術のことを言います。

DWHを利用するのは商品開発やマーケティングなどの部門ですが、基幹データを扱うことから、管理するのは情報システム部門であることがほとんどです。管理部門がDWHのデータ設計と実装を行い、分析可能な状態にして利用部門に提供するのが一般的な役割分担です。一方で、利用部門が分析を進める中で、データ構造を変更したいという要求がうまれるものの、自分たちでそれを実施できないため、分析や意思決定のスピードが上がらないこともよくあります。

そこで、利用部門が管理部門に頼ることなく、自分たちでデータの分析・可視化に必要な環境を構築するセルフサービスBIという考え方が生まれました。その中でも、とりわけDWHに特化したクラウドサービスとして、いま人気を二分しているのが、Google BigQuery（以下、BigQuery）とAmazon Redshift（以下、Redshift）です。

ツールのBigQuery、基盤のRedshift。

BigQueryとRedshiftはそれぞれクラウドコンピューティングサービスであるGCP（Google Cloud Platform）とAWS（Amazon Web Services）の一部であり、フルマネージドなDWHです。GCPとAWSはよく比較されますが、サービスラインナップ¹⁾GCP・AWSサービス比較表としては同質化が進んでおり、いま現在はほぼ横並びといえます。

ただ、AWSがECサイトのAmazon.comのインフラのシェアリングを、GCPがGoogleの各種アプリケーションのエンジンのシェアリングをそれぞれルーツとしているため、それが特徴の違いを生んでいます。

サービス拡張の経緯にもそれは現れていて、IaaSについてはAWSは当初からAmazon EC2（Elastic Compute Cloud）として提供していましたが、GCPのGCE（Google Compute Engine）はかなり後発です。一方で、PaaSについてはGCPのGAE（Google App Engine）が先行しています。

また、導入されるケースの違いにも特徴があり、レガシーなインフラの置き換えには、インフラの導入実績が豊富なAWSが、ビッグデータ基盤の構築には、深層学習（Deep Learning）などの先進的なアプリケーションが充実したGCPが、それぞれ選ばれる傾向にあるように思います。

この特徴の違いがBigQueryとRedshiftにも引き継がれていて、GCPの一部であるBigQueryはアドホック分析のための分析ツール、AWSの一部であるRedshiftは既存のDWHを置き換えてセルフサービス化する分析基盤の性格が強いといえます。

用途に合わせた選択を。

BigQueryとRedshiftを、諸元レベルで比較してみます。

BigQueryの特徴をRedshiftとの比較で整理してみます。

• Redshiftと同じく、標準SQLに対応。
• Redshiftと同じく、大量データの集計に優れた列指向の格納方式を採用。
• テーブル名・カラム名のマルチバイト文字は非対応。
• ブラウザUIのクエリ実行環境を装備。
• 課金体系は、時間課金ではなくクエリ課金。（データスキャン量による従量課金）

BigQueryとRedshiftの共通点としては、標準SQLに対応した列指向DBであるということ。これにより、一般的なRDBと同様のSQLで、大量データの集計に優れた列指向DBとしてデータの操作が可能です。

BigQueryの特長は、ブラウザUIでクエリ実行が可能なのと、時間課金ではなくクエリ課金（クエリ時のデータスキャン量による従量課金）であるため、手軽にアドホック分析を行う分析ツールとして採用しやすいという点です。

一方で、時間課金ではないためにコストを見積もりづらいのと、テーブル名・カラム名のマルチバイト文字は非対応という欠点があるため、既存のDWHの置き換えには不向きであり、その場合はRedshiftのほうが採用しやすいでしょう。

ちなみにAWSには、ブラウザGUIのクエリ実行環境を備え、クエリ課金であるAmazon Athenaという、BigQueryと似たサービスもあるので、AWSユーザーは用途に合わせて選択することが可能です。ただしSQL互換エンジンのPrestoを採用しており、関数の体系が異なるため注意が必要です。

このようにBigQueryとRedshiftは、同じセルフサービスDWHでも特徴がかなり異なるので、用途に合わせて選んでもらえればよいと思います。