売上データの集計から画面表示までをSnowflake内にまとめた、Pythonのダッシュボードです。
- 別途BIツールを導入せず、SQLとPythonで集計と表示を組み立てました。
- 売上記録と商品・顧客・地域のマスタを使います。
- 画面にはKPI表示・月別推移・カテゴリ別売上・地域別売上・商品ランキング・顧客セグメント別売上の6つを用意しました。
Snowflakeの構成
Snowflakeは、AWS、Microsoft Azure、Google Cloudに対応するデータ基盤です。今回使うのは、売上を保管するテーブル、SQLを実行するウェアハウス、Pythonで画面を作るStreamlitアプリです。
保管と計算を分けて運用する
Snowflakeでは、ストレージと計算資源を独立に管理します。データを保管したまま、処理量に応じてウェアハウスのサイズを変更できます。ウェアハウスを停止すると計算料金は止まり、保管料は日々の保存量を基に月額で算定されます。
Streamlit in Snowflakeとは
SnowflakeがStreamlitの開発元の買収合意を発表したのは2022年3月2日です。Streamlit in Snowflakeの一般提供は、AWSでは2023年12月、Azureでは2024年1月、Google Cloud(GCP)では2024年5月に始まりました。
今回のStreamlitアプリはウェアハウス上で動く構成です。
参考リンク
Snowflakeと他のデータ基盤の比較
表では、提供基盤や料金体系に加え、画面を作る方法と担当者が扱う技術を並べています。
| 観点 | Snowflake | Google BigQuery | Amazon Redshift | Databricks |
|---|---|---|---|---|
| 料金体系 | 従量制(計算+保管を別課金) | 計算は処理量課金または容量課金。保管などは別途課金 | プロビジョンド型とServerlessを選択。対応クラスターは一時停止可能。Serverlessの計算料金は使用資源に応じ、保管は別課金 | DBU単位の従量制。提供方式によってクラウド基盤の費用も加算 |
| サービスの提供基盤 | AWS・Azure・GCP | GCP。BigQuery OmniによるAWS・Azure上のデータ分析は別枠で、対応環境・機能に制限あり | AWSのみ | AWS・Azure・GCP |
| ダッシュボード機能 | Streamlit in Snowflake(組み込み) | Looker Studio連携(別サービス) | QuickSight連携(別サービス) | ノートブック・AI/BI dashboardsの組み込み機能。後者の旧名称はLakeview |
| データ共有 | Marketplace・Secure Data Sharing | BigQuery sharing。旧名称はAnalytics Hub | Redshift data sharing・AWS Data Exchange連携 | Delta Sharing(オープン規格) |
| 必要な知識・操作 | 分析利用者はSQL、アプリ開発者はPython・SQL、管理者は権限・計算資源・費用管理 | 分析利用者はSQL、アプリ開発者は接続API、管理者はGCPの権限・計算資源・費用管理 | 分析利用者はSQL、アプリ開発者は接続API、管理者はAWSの権限・計算資源・費用管理 | 分析利用者はSQL、アプリ開発者はPython・SQLなど、管理者は権限・計算資源・費用管理 |
| 向いている用途 | DWH・可視化・データ共有を一元化したい企業 | GCP中心で、その都度の疑問に応じて大規模データを分析したい企業 | AWS環境に既に集中投資している企業 | 機械学習・AIの処理とデータ分析を統合したい企業 |
Snowflakeを選ぶ利点
- 複数クラウドに対応し、AWS・Azure・GCPから選べます。
- ウェアハウスの自動停止を設定できます。夜間・休日に分析しない運用では、その時間帯の計算料金を抑えるために使えます。
- ダッシュボードまで完結する構成です。Streamlit in Snowflakeでは、Pythonで集計結果をグラフや表にできます。
- データ共有にはSecure Data Sharingがあります。同一リージョンのSnowflakeアカウント間では、共有先ごとにデータを複製せずに共有できます。別リージョンへの共有には複製などの設定が必要です。
- 管理画面への集約により、SnowsightからSQLの実行、テーブル操作、Streamlitアプリの管理を行えます。
運用と画面開発で考えること
- 計算料金を左右するのはウェアハウスのサイズと稼働時間です。Resource Monitorでは対象ウェアハウスの使用量に応じた通知や停止を設定できます。サーバーレス機能やAIサービスの使用量は別に扱います。
- データの取り込み方式には、ファイルを取り込むSnowpipeと、ストリーミングで取り込むSnowpipe Streamingがあります。月次集計の画面と低遅延の処理では、取り込みに求める間隔が異なります。
- Streamlit in Snowflakeの画面開発はPythonで行います。集計から明細へ進む操作は、入力・表示部品を組み合わせて実装する部分です。定期配信やアラート通知には別の仕組みを組み合わせます。
- 移行時に書き換える処理もあります。Cortex AI、Snowpark、Marketplaceなどを使う範囲が広がるほど、移行先に合わせる箇所が増えます。
選び方のポイント
固定集計で足りる用途では既存BIやSnowsightのダッシュボードも使えます。
想定する企業・チーム
導入先として考えているのは、売上の集約と月次集計を担うチームです。
Excelの月次集計に時間がかかる企業
拠点や取引先からExcelファイルを集め、整形・集計・配布している業務が対象です。Excel内の数式を画面に移す前に、商品・顧客コードと集計期間を揃えます。
BIツールのコスト・運用負荷がネックになっている企業
Streamlit用のBIライセンスは不要ですが、アプリとSQLの実行にはSnowflakeの計算料金がかかります。費用比較に含めるのは、既存BIの契約額、サーバーの保守、Snowflakeの利用料、SQLと画面コードの保守工数です。
ウェアハウス実行では、最後の操作から約15分間はWebSocket接続が残る場合があり、その間はコード実行用ウェアハウスが稼働します。費用を見積もる際は、利用時間の重なりと停止までの時間を含め、コード実行用とSQL用の稼働時間を分けて考えます。
データは溜まっているが活用できていない企業
基幹システム、kintone、SaaSに分散した売上を横断して見る用途です。システムごとに商品・顧客コードが異なるなら、集約時に対応付けます。
Python経験者がいるIT企業・DX推進チーム
導入先に求める条件
画面を作った後も、商品分類の変更や新しい集計の要望は発生します。運用には、SQLとPythonの両方を修正できる担当者が必要です。
デモの構成
今回のデモでは、商品10件、顧客10件と、2024年4月〜2025年3月の1年間にわたる売上5,000件を使っています。
| 構成要素 | 内容 |
|---|---|
| データベース | SALES_DEMO(Snowflake上に構築) |
| データモデル | 売上ファクト1テーブルとディメンション3テーブル |
| ダッシュボード | Streamlit in Snowflakeで可視化(KPI・月別推移・カテゴリ別・地域別・商品ランキング・顧客セグメント) |
売上明細とマスタの設計
売上と属性を分けるスタースキーマを基本に、地域を顧客マスタから参照する構造です。売上ファクトには商品・顧客ディメンションを直接接続し、地域マスタへは顧客マスタを経由し、REGION_ID同士を結びます。金額と数量はFACT_SALES、商品名や顧客区分は各マスタが持ちます。
DIM_PRODUCTS DIM_CUSTOMERS DIM_REGIONS
┌─────────────┐ ┌───────────────┐ ┌────────────┐
│ PRODUCT_ID │ │ CUSTOMER_ID │ │ REGION_ID │
│ PRODUCT_NAME│ │ CUSTOMER_NAME │ │ REGION_NAME│
│ CATEGORY │ │ REGION_ID ────┼────▶│ AREA │
│ UNIT_PRICE │ │ SEGMENT │ └────────────┘
└──────┬──────┘ └───────┬───────┘
│ │
▼ ▼
┌──────────────────────────────────────┐
│ FACT_SALES │
│ SALE_ID | SALE_DATE | CUSTOMER_ID │
│ PRODUCT_ID | QUANTITY | AMOUNT │
└──────────────────────────────────────┘ディメンションテーブル
| テーブル | 件数 | 内容 |
|---|---|---|
| DIM_PRODUCTS | 10件 | 商品マスタ。電子機器・周辺機器・消耗品の3カテゴリ |
| DIM_CUSTOMERS | 10件 | 顧客マスタ。大企業・中小企業・スタートアップの3セグメント |
| DIM_REGIONS | — | 地域マスタ。東京・大阪・名古屋・福岡・札幌など |
ファクトテーブル
| テーブル | 件数 | 期間 | 内容 |
|---|---|---|---|
| FACT_SALES | 5,000件 | 2024/4〜2025/3(1年間) | 売上取引の記録 |
デモデータの前提
日本の商品名・顧客名・地域名を使った、表示用の架空データです。
集計と画面表示
Pythonスクリプトはget_active_session()でSnowflakeのセッションを取得し、アプリ所有者に許可されたデータを参照します。接続用の認証情報をコードに持たせない構成です。SQL側で集計してからPythonへ結果を渡すのは、画面操作のたびに全明細を転送するのを避けるためです。
KPIカードと月別売上推移

上段には「総注文数」「総売上」「平均注文額」「顧客数」というラベルの4指標を並べています。
折れ線は2024年4月〜2025年3月の月別売上です。期間全体の金額を上段で見てから、月ごとの増減をたどれる配置にしました。
カテゴリ別・地域別売上

- カテゴリ別では、DIM_PRODUCTSのCATEGORYを切り口に売上を集計します。商品単位の表示よりも、電子機器・周辺機器・消耗品というまとまりで金額を見られます。
- 地域別では、DIM_CUSTOMERSのREGION_IDを通じて地域名を参照します。顧客に紐づく地域ごとに、売上金額をまとめた表示です。
商品別売上ランキング

商品別売上はテーブルで表示しています。ノートPC、モニター、プリンター、HDMIケーブル、LANケーブルなどを商品単位で並べ、カテゴリ別の金額を個々の商品へ掘り下げて見るための表示です。
顧客セグメント別売上

顧客セグメント別は、DIM_CUSTOMERSのSEGMENTにある大企業・中小企業・スタートアップの3分類で集計します。
BI構成との運用比較
| 観点 | BIサーバーを自社運用する構成例 | Streamlit in Snowflake |
|---|---|---|
| 実行環境 | BIサーバーとDB接続設定 | Snowflake上でアプリを実行 |
| 閲覧権限 | BI製品のユーザー・権限設定で管理 | Snowflakeのロールでアプリの閲覧権限を管理 |
| 集計・画面開発 | 製品に応じた集計式・画面設定 | PythonとSQL |
| コスト | BIライセンス、サーバー、保守の費用 | アプリ・SQL実行の計算料金、保管料、コード保守の費用 |
| カスタマイズ | ツール依存 | 対応ライブラリ・機能の範囲で拡張 |
データの流れ
別のBIサーバーに分析データを複製する工程を挟まない構成です。
業務への適用例
経営会議用のKPIダッシュボード
経営会議に使うなら、KPIカードと月別推移にデータの最終更新日時を添えます。取り込みの完了と画面への反映には時間差があるためです。再取得の契機を画面の再読み込みに決め、取得に失敗したときはその旨を表示する設計にします。
営業チーム向けの地域別レポート
担当エリアだけを表示する用途では、ユーザーと許可地域の対応表を使う設計にします。ウェアハウス実行のアプリはオーナー権限で動くので、CURRENT_ROLE()は閲覧者の判別には使えません。CURRENT_USER()を使う行アクセスポリシーとし、オーナーロールにREAD SESSIONを付与する設計にします。
アプリと親DB・スキーマのUSAGE権限は、画面を開くための設定として別に扱います。
この構成で重視したこと
私は売上金額に取引時点のAMOUNTを使います。商品マスタのUNIT_PRICEと数量から計算し直すと、単価の変更が過去の売上にも影響するためです。集計の切り口は現在のマスタから取り、金額は売上記録から取る、という分担にしています。
自社データへ適用する際の進め方
試用アカウントを作成する
Snowflakeの無料トライアルは400ドル分の利用枠付きで、最長30日間利用できます。登録時のクレジットカードは不要です。利用枠を使い切ると30日未満でも試用が終了します。
売上データとマスタを整理する
Excelの売上一覧をCSVに変換し、Snowsightから取り込みます。商品・顧客の属性を複数の分析で共用するならマスタを分ける構成です。
Streamlitアプリを作成する
SnowsightでStreamlitアプリを新規作成するときは、ウェアハウス実行を選びます。最初に月別売上をSQLで集計し、その結果をPythonで折れ線にします。その後に商品・顧客マスタを使う切り口を加えます。
はてなベースの支援メニュー
「自社データの整理が難しい」「スタースキーマへの変換がわからない」という場合は、データモデル設計からダッシュボード構築までを一括でご支援しています。既存のExcel・kintone・基幹システムのデータをSnowflakeに集約するETLパイプラインの設計も支援しています。