💭 データ活用、こんな課題ありませんか？

事業の立ち上げ当初は要求もシンプルなので、あまり気にならないんですが、事業・組織の拡大とともに複雑性を増して起こる課題ですね。

ボディブローみたいにジワ...ジワ…と判断のスピードと質が落ちていくんですね

背景と課題：成長とともにデータへの障壁が顕在化する

スマートバンクも例外ではなく、事業・組織が大きくなっていくにつれ、データに纏わる課題を目にする場面が増えてきました。

データ量の増加に伴うパフォーマンス劣化
データのサイロ化。それによって引き起こる人力データ集計
付け焼き刃に拡張され乱立する集計ロジック
似たようなクエリの大量生産
担当者の退職や異動によって失われる知識。主を失ったクエリ
それでも、データは参照され続ける。

三種の神器（あまりありがたくない）

🧙 秘伝のクエリ・スプシ：継ぎ足しを重ねた深みのあるデータ群
🧟 ゾンビクエリ：Redashに潜む「生存不明だけど怖くて消せないやつ」
🦍 ゴリラワーク：人力パワープレイによるデータ加工・集計

上記以外にも、ワンバンクは1つのプロダクト内に多種多様なユーザー属性（家計管理・あとばらい）やニーズ・機能群（決済、課金 etc...）があり複雑です。

これらは、エンジニアであっても網羅してデータを集計するには、日に日に敷居が高くなっていました。

こうした状況の先に、何が待っているかというと…複雑に絡み合った 「データの宇宙」 の誕生ですね。

組織体制的にも事業側の開発で手一杯であったり、課題は認知しているんだけど、対処に明るいメンバーも少なかったり。サービスが止まるわけではないので、蓋をして耐え凌ぐみたいな状態だったんですね。

技術面での対処

まず、技術面でどのように課題と向き合っているかに触れたいと思います。

データ基盤の全体像

Snowflake × dbt でデータ基盤を構成しています。

ワンバンクは Amazon Web Services（AWS）のインフラに構築しています。そのため分析で扱いたい主軸となるデータは AWSのデータベースにあります。

データ基盤

データ基盤として Snowflake を採用しています。インフラは terraform-provider-snowflake で構成管理をしています。

Snowflakeを採用した理由はいくつかあるのですが、その中でも意思決定を後押したポイントは2つです。

1つ目は、プロダクトと同じクラウドサービス上で運用ができることです。

Snowflakeは構築するクラウド環境をユーザーが選択できる柔軟性があります。

それにより、データ転送のコストや煩わしさ、社内のエコシステムの恩恵やチームメンバーからの支援の受けやすさなどがありました。

2つ目は、コストコントロールの観点です。

Snowflakeはクエリの実行単位課金ではなくインスタンスの起動時間によって請求されます。そのため、比較的コストの予測がシンプルになります。

管理者観点、利用者目線でも不慮のクエリ事故で課金爆発…（怖い!）といった不安を抱えないで良いといった、心理的な面での後押しもありました。

これら意思決定のログをスマートバンクでは、 Architectural Decision Record（ADR）としてNotionへ残す文化があります。

データに纏わる意思決定は属人化しやすいため、可能な限りADRを残すようにしてしています。

ADRについての説明はノバセルさんの記事が分かりやかったのでご参照ください。 techblog.raksul.com

データ収集

Aurora S3 Export でデータをS3にエクスポートしています。

それらを dbt-external-tables というパッケージを利用し dbt でSnowflakeの外部テーブルとして定義しています。

外部テーブルで必要となる YAML の定義は dbt macro を組み合わせたスクリプトを用意してYAML生成のコストを省エネ化するように工夫しています。

#!/bin/bash

# ユーザーからの入力を受け取る
read -p "Table name: " table_name
read -p "Output file name (default: models/source/$table_name.yaml): " output_file
output_file=${output_file:-models/source/$table_name.yaml}

# JSONオブジェクトを構築
json_args=$(cat <<EOF
{
  "source_name": "db_name",
  "schema_name": "dbt_staging",
  "table_name": "$table_name",
  "table_description": "$table_name",
  "stage_location": "@dbt_staging.d43_core/db_name.$table_name",
  "file_format": "dbt_staging.parquet",
}
EOF
)

# dbt run-operationコマンドを構築
dbt_command="dbt run-operation generate_external_source_yaml --args '$json_args' --quiet"

# 出力ファイルが指定されている場合、リダイレクトを追加
if [ -n "$output_file" ]; then
    dbt_command="$dbt_command > $output_file"
    echo "Executing: $dbt_command"
    eval "$dbt_command"
    echo "Output saved to $output_file"
else
    echo "Executing: $dbt_command"
    eval "$dbt_command"
fi

# 対応するstagingテーブルの生成

{% macro generate_external_source_yaml(
    source_name,
    schema_name,
    table_name,
    table_description,
    stage_location,
    file_format,
    loader="S3",
    infer_schema=false,
    auto_refresh=false
) %}
    {%- set yaml_output %}
version: 2

sources:
  - name: {{ source_name }}
    schema: {{ schema_name }} 
    loader: {{ loader }}

    {%- endset -%}

    {{ print(yaml_output) }}

    {% set result = generate_external_table_yaml(
        table_name,
        table_description,
        stage_location,
        file_format,
        infer_schema,
        auto_refresh,
    ) %}

    {{ return(yaml_output) }}
{% endmacro %}