はてなブックマーク

Snowflakeパフォーマンス最適化機能クラスタリングキー & Search Optimization & Query Acceleration はじめに SnowVillageのUnConference第五回イベントで、けびんさんのSOS検証記事の解説LTを聞いた事が、この記事を書くきっかけとなりました。 その際に紹介いただいた以下の記事とその際の質疑応答を通じて自分の不勉強さを痛感し、自分でもちゃんと学ぼうと思い、改めて仕様の理解と実際の検証結果と共にこの記事にしました。 各機能の詳細な説明はけびんさんや諸先輩方の記事を参考にいただく事でより深く理解が出来ると考えています。この記事ではそれらの各機能を理解しつつ、その全体像を自分なりの考え方で体系化し、またそれらについてTPC-Hのデータを用いたハンズオン形式にすることでステップバイステップで、どのような効果があるかを比較した結果を加

はじめに：Copilot時代に必要なSQL基礎力 データ分析の民主化が進む現代、SQLはあらゆる職種で必須のスキルとなりました。 特にSnowflakeのようなクラウドデータプラットフォームでは、次の変化が起きています。 SQL利用の多様化：BIツールに依存しないdbtやRedashやStreamlitなどの直接分析の増加 AI連携の一般化：Copilotによる自然言語からのクエリ生成 またSnowflake Copilotなどの生成AIによるText2SQLにシフトしていく中で、AIが生成するSQLを正しく評価・修正するためには、以下の要素が不可欠です。 関数の挙動理解：例えばEXCLUDEやQUALIFYなど関数機能の特性やクエリ挙動の理解 結果の検証力：想定外の動作を発見するデータ感覚 Copilotは強力な支援ツールですが、生成クエリの妥当性を判断するには人間の知見が必要です。それ

はじめに こんにちは！シンプルフォームの山岸です。 弊社では社内向けのデータ分析基盤としてこれまで Amazon Redshift を利用してきましたが、昨年6月に Snowflake の導入を決定し、移行に向けた検証・構築を進めてきました。当時の技術選定については、以下の Findy Tools レビュー記事でもご紹介しています。 昨年末に Snowflake 基盤の提供を開始してからは、旧 Redshift 基盤の運用を停止すべく既存クエリ資産の移行に奔走していましたが、先日ようやくの終わりを迎えました。 上記のレビュー記事では技術選定をメインに扱いましたが、本記事では弊社データ基盤の歴史と、データ基盤移行のプロセスについて振り返ってみたいと思います。 SimpleForm データ分析基盤の歴史 ① データ分析基盤がなかった時期【- 2022.12】 弊社は主に金融機関のお客様を対象に

結論 データ部門は大福帳を中央集権的にユーザーに提供すべきでない。 なぜなら分析ユーザーの求めに応じて、大福帳を作って配布するということは、ビジネス上の本質的な課題を、テクノロジーの問題にすり替えるということであり、焼け石に水だからである。 データ分析者からの「購買と発送を横断して分析したいのですが、JOINキーは何ですか？」という質問は多い。これは、一つの購買に対してどのくらいの発送が紐づくかを理解していない、という分析者のビジネスプロセスの理解不足に由来する。 しかし、この問題を「一般ユーザーにはJOINなんてできないのだ」というテクノロジーの問題にすり替えてはならない。 JOINして渡したところで、結局は「JOINキーは何ですか？」という質問が「このカラムのNULLは何ですか？」に形を変えて繰り返されるだけである。 そしてデータ部門はこれはメタデータ整備の不足だと、またテクノロジーの

この記事は以下の2つのアドベントカレンダーの5日目のポストです。クロスコミュニティ！ Snowflake Advent Calendar 2024 HTAPデータベース Advent Calendar 2024 Snowflake Hybrid Tables 2024年10月についにGAされたSnowflake Hybrid Tablesは、主キーや行ロック、インデックス等を具備した行指向の実装によるOLTP（Online Transaction Processing）的なワークロードと従来のOLAP（Online Analytical Processing）ワークロード双方に同時に対応できるその名の通りハイブリッドなアーキテクチャとなっています。こうしたOLTPとOLAPのハイブリッドアーキテクチャやハイブリッドワークロードはHTAP（Hybrid Transactional/Analy

はじめに こんにちは！ナウキャストのデータエンジニアのけびんです。 今年の6月に Iceberg Table が Snowflake の機能として GA したのは記憶に新しいかと思います。 自分もこの時から Iceberg に興味を持ちブログを書いたりしました。 そんな中、ちょうど良いタイミングで Apache Iceberg: The Definitive Guide が2024年5月に出版されており、 SnowVillage の有志の方たちと輪読会という形で読み進めておりました。11月末に無事に全体を読み終えましたので、今回は各章について簡単に紹介していきたいと思います。 Part1: Fundamentals of Apache Iceberg Part1 は Apache Iceberg の基礎、ということで、 Iceberg が生まれてきた歴史や、そのアーキテクチャや仕組み、カタ

こんにちは！シンプルフォームの山岸です。 皆さん、データ基盤のメタデータ管理には何を利用されているでしょうか。 当社では現在、Snowflake × dbt を軸としたデータ基盤への移行に向けて検証・構築を進めており、併せて dbt Docs の機能を用いたメタデータ管理・提供方法についても検討しています。 今回、dbt Docs を AWS 上で CI/CD、およびホスティングするための AWS インフラ構成について検討してみたので、本記事ではその内容についてご紹介できればと思います。（アーキテクチャの話がメインであり、細かい実装についてはあまり言及しない点について、予めご了承ください） メタデータ管理について メタデータとは データ基盤の文脈における「メタデータ」とは、一言で言えば「データに関するデータ」のことを指します。これには例えば、DB 内の各テーブル・カラムのビジネス的意味や、

こんにちは、CCCMKホールディングスのタロウです。 先日のSnowflake World Tour Tokyoでは弊社取締役の撫養がSMCCの白石執行役員と基調講演で企業間データシェアの事例を発表させていただきました。 さて、データシェアについては皆様も既にご利用進めているかと思いますが、 よりセキュアに、さらにプライバシーに配慮し、さらにビジネスに活用出来るために 事業に先駆けて準備をしておこうと個人的にクリーンルームを色々試しておりました。 そんな中、今年の5月にこのニュースが出たので、これは試さねばとSnowflakeの菅野さんに色々教わりながら実施したハンズオンを元に色々試しているとさらにアップデートのニュースが！ Samoohaの買収とネイティブ機能としての提供 9月26日の大型アップデート ・Branded clean room tiles（ロゴと企業名など設定できる！） ・

こんにちは！シンプルフォームの山岸です。 皆さん、ETL / ELT のワークフローエンジンには何を利用されているでしょうか？ Apache Airflow や、その AWS マネージドサービスである Amazon MWAA を利用されている方も多いかと思います。もしくは TROCCO や Fivetran のようなマネージドなワークフローツールを利用されているかもしれません。 当社では多くのワークフローで AWS Step Functions (SFN) を利用しています。今回、Snowflake への ELT ワークフローを SFN で実装してみたので、本記事ではその内容についてご紹介できればと思います。 背景・課題感 背景 少し前に、「Snowflake × dbt で構築する ELT アーキテクチャ」というタイトルの記事を投稿しました。詳細な説明はそちらに譲りますが、AWS 環境か

結論 以下の条件に当てはまれば、Icebergの採用を検討すべきです。 データ量がペタバイトを超える 社内でSnowflake以外のデータ活用製品（Databricks、Redshiftなど）も多く利用している 同一のデータを使う関連グループ・企業が多く存在する Icebergの採用は、特に巨大企業においてメリットが大きいです。 逆に上記の条件に1つも当てはまらない場合は、採用を見送るのがよいでしょう。 Icebergとは何に代わるものなのか？ Icebergは、Snowflakeのテーブルを置き換えることができます。 Icebergは完全にSnowflakeから独立した技術であり、Snowflakeの機能ではないことに注意が必要です。 最近Snowflakeが別のツールで作成したIcebergテーブルを、読めるようになっただけと捉えるのが1番実態に近いと思います。（※特定の条件下では書き

Snowflakeのマイクロパーティション Snowflakeのデータウェアハウスとしてのスケーラビリティ、パフォーマンス、多くの有用な機能の根源の一つに、マイクロパーティションというアーキテクチャの良さがあります。 Snowflakeはオブジェクトストレージ上に構成されたマイクロパーティションと、そのメタデータを徹底的に最適化することで、ACID制御からタイムトラベルまで、多くの機能をとてもうまく実装しています。（でもこのアーキって最近よく聞くIcebergや他のオープンテーブルフォーマットとちょっと似てない？というのは今回とは別のお話） マイクロパーティションを超わかりやすく解説されているほーりーさんの素晴らしい記事はこちら。 このマイクロパーティションはプルーニングという仕組みにより、Snowflakeのパフォーマンス向上に絶大な影響を与えています。解説記事はこちら。 最近、マイクロ

こんにちは！シンプルフォームの山岸です。 当社では現在、Snowflake をベースとするデータ基盤への移行に向けて、機能・非機能それぞれについて検証・構築を進めています。今回は、機能要件の中でも特に重要な要素である ELT アーキテクチャについて、具体的な実装とともにご紹介できればと思います。 アーキテクチャ 早速本題ですが、移行後のデータ基盤として以下のような ELT アーキテクチャを構築しました。 プロダクト環境として product1, product2 ... のような複数の AWS アカウントが存在しているようなケースを想定します。各環境のプロダクト用 Aurora データベースを、Snowflake 環境上のスキーマとして再現します。 Snowflake 環境にデータを取り込んだ後のモデリングは dbt で行います。Staging 層から実際に利用されるテーブルを再現する部分

Snowflake主催の最大のカンファレンスであるSUMMITに参加してきました。 今年はサンフランシスコで6月3日から6月6日にかけて開催されました。 去年の参加レポート: Snowflake SUMMIT 2023参加して、世界のスピードを感じてきた。 私は普段、株式会社CARTA MARKETING FIRM のデータエンジニアとして、Snowflakeを使ったデータ基盤構築・運用をしています。 どういう機能がリリースされたという話は、他の方が記事を書いてくれてそうなので、当記事ではデータエンジニアの立場から、SUMMITのメッセージをどう捉えたか、今後どのようにデータと付き合っていくと良いかを考察してみます。 当時の様子については、X でたくさんつぶやいてるので、そちらを見ていただくほうがわかりやすいです。 また、データエンジニア目線で、注目の機能に関しては、「Snowflake

結論 Snowflake上のデータ分析には、Snowflake Notebooksを使おう。 SnowflakeにNotebook機能が突然登場した 2024年5月25日、Snowflakeに突如Notebookという新機能が追加され、データエンジニアリング界隈で話題となりました。 本記事ではそもそもNotebookとはなにか？なぜ便利なのか？Snowflake Notebookの優位性はなにか？を解説します。 そもそもNotebookとは？ まず、NotebookはSnowflakeの特別な機能の名前ではありません。Jupyter NotebookやGoogle Colab、Hexなどを含む、インタラクティブなプログラミング環境の総称です。 Notebookに共通する特徴は以下の3点です。 多言語対応: Python、SQL、Rなど複数のプログラミング言語に対応しています。 部分実行:

結論 社内データを扱うアプリケーションを安全にデプロイするならCloudflare Tunnel,Cloudflare Accessを使う。要件次第ではStreamlit in Snowflakeも使える。 はじめに Streamlitはデータアプリケーションを短時間で作成できる便利なツールですが、社内データを扱うアプリケーションをデプロイする際は外部からの不正アクセスを防ぐように厳重な注意が必要です。 にもかかわらず、Streamlitを安全にデプロイする成熟した方法はまだありません。 本記事では、最も単純なStreamlitのデプロイ構成の例から問題点を再確認し、それらを解決する方法を順に説明します。ただし、本記事で紹介する構成を使うにはドメインのネームサーバーがCloudflareである必要があることに注意してください。 単純な構成はどう危険なのか？ まずは非常に単純なStreaml

結論 Taskを管理するならSnowflake Python APIを使おう Snowflake Python APIとは Snowflake公式のPythonのオブジェクト管理ライブラリ「snowflake.core」のことです(Public Beta)。Snowflake Python Connectorとは全く別物です。 Snowflake Python APIを使用すると、Pythonコードを使ってSnowflakeのリソース(Table、Warehouse、Task、Snowpark Container ServiceのCompute Poolなど)を管理することができます。 本記事では、Snowflake Python APIを使ってSnowflakeのタスクとDAG（Directed Acyclic Graph）を管理する方法を詳しく解説します。これにより、Streamlit

2024年5月現在、GA4とSnowflakeの公式コネクタは正式に一般公開されています 2024年1月29日、GA4とSnowflakeの公式コネクタがリリース(プレビュー)されました。 ついに、GA4もSnowflakeで分析する時代がやってきました。 GA4×Snowflakeの組み合わせがやっとプロダクション運用可能なレベルに到達したのです。 これは今回のコネクタリリースでGA4のプロパティ取り込みパイプラインの運用コストが圧倒的に下がったことに起因します。 公式コネクタのリリース以前からGA4をSnowflakeに取り込むことは可能でしたが、その運用を継続することは様々な観点から困難でした。 この記事では、従来の取り込みソリューションと、最新の公式コネクタを比較して4つの観点から素晴らしい部分を解説します。 GA4のデータの取り込みが容易になった 取り込み後のデータの冗長な変換が

SnowflakeでAWS S3 Express One Zoneを組み合わせて、パフォーマンスと互換性を検証したので結果を共有する。 互換性テストが通らなくても、一部の機能は使用できるようだ。 結論 読み取り系のワークロードでは、最大16%ほどのクエリパフォーマンスの改善が見られた。 ただし、現時点では、スタンダードなS3バケットからExpress One Zoneへ移行する必要はない。 現時点では移行するメリットをデメリットが上回る。 まず、書き込み系の操作はエラーで実行できない。 また、LISTなどバケット全体のスキャンを行うクエリでは、最大20倍も遅くなった。 全体的にSnowflakeの内部のコードがExpress One Zoneを想定していないようでエラーが頻発した。　未サポートなので当然だが日常的な使用は厳しい。 SnowflakeでExpress One Zoneを活用し

この記事はSnowflakeアドベントカレンダー2023の19日目です。 はじめに 昨年、Snowflakeのパフォーマンスにおいて非常に重要な概念であるクラスタリングとプルーニングに関して、以下の記事を書きました。 なぜクラスタリングやプルーニングが大事なのかを説明させてもらったのですが……理屈はわかった！ではどうすれば？という、具体的なユースケースについて全く書けておらず、また別のブログにします、と宣言しておいて、1年間完全に放置してしまっていました。すみません。。 この記事では、上記の記事の続きとして、クラスタリング・プルーニングの概念を知ったうえで、具体的にパフォーマンスを向上させるにはどうすれば良いかのヒントとなるようなものを書きたいと思います。 具体的には、そうデータモデリングです！ データモデリング万能説 データモデリングがめちゃくちゃ大事だよ！ってことは、SnowVilla

本記事の背景 本記事は、某所で密かに行われていた Snowflake DevOps 情報交換会 Season 1 最終回の議論用に共有した内容です。 本会は、 DevOps を中心に、また DevOps とは直接は関係ないテーマも含め、その時々において関心のあるテーマを取り扱っていましたが、今回は最終会ということで、本来のテーマである DevOps において、私個人が中心的テーマであると考える構成管理やデプロイの自動化について議論したいと思い、整理しました。 中心的テーマを再び取り上げようと考えたきっかけの 1 つが Snowflake Data Superhero の Tomas が LinkedIn で EXECUTE IMMEDIATE FROM という新しい構文について紹介しているのを発見したことです。これはステージ上の SQL ファイルを直接実行できるという機能です。 Tomas

これは何？ こんにちは。 dely株式会社でデータエンジニアをしておりますharry(@gappy50)です。 この記事は、昨年書いた以下の記事の続きの記事になります。 SnowflakeではDynamic TablesのPuPrが開始されており、宣言的なデータパイプラインの全貌徐々に見え隠れしております。 また、これに追従する形でdbt1.6でもMaterialized View（SnowflakeではDynamic Table）をサポートしはじめました。 このDynamic Tablesのメリットとして一番わかりやすいのは、ニアリアルタイムなストリーミングパイプラインをクエリを書くだけで実現が可能になる面だと思います。 これまではモデルを作成したあとのワークロードの実行は dbt build を実行するタイミングとなってしまうため、リアルタイムなデータパイプラインの構築が難しい側面があ

本記事の背景 先日、自社のデータアナリストやデータサイエンティストに Snowflake の概要を紹介した際に、データリネージをどう実現するのか聞かれる機会がありました。本記事では、比較的簡易的に実現する方法として、Python モジュールの sqllineage を紹介します。 データリネージとは Data lineage includes the data origin, what happens to it and where it moves over time.[1] Data lineage gives visibility while greatly simplifying the ability to trace errors back to the root cause in a data analytics process.[2] リネージ (lineage) は日本語

(画像は Snowflake 公式 Web サイトのものを流用) 概要 データエンジニアとして働いていると RDB 上での変更をリアルタイムで近い形でデータウェアハウスに転送し、即座にデータ分析に利用できるようにしたいというニーズについて相談を受ける機会があります。 筆者は、RDB からデータウェアハウスの間のリアルタイムデータパイプライン部分を OSS 中心とクラウドサービス中心の 2 つの構成で構築した経験があります。その際の経験を踏まえて、両者の簡単な比較について紹介します。 （前職）OSS 中心のデータパイプライン RDB・・・AWS RDS Aurora (PostgreSQL) BigQuery データパイプライン・・・Kafka、Debezium コンテナオーケストレーション・・・データパイプラインを AWS EKS 上 k8s クラスタにデプロイ （現職）クラウドサービス中