テーブルに対して設定する場合は、複数の日付列を指定するのが良いと記載があります。この場合は日付列はTIMESTAMP型の場合はTO_DATEでキャストすることを推奨されています。 例えば、ファクトテーブルに、多くの離散値（テーブル内のマイクロパーティションの数よりも多く）を含む TIMESTAMP 列 c_timestamp がある場合、タイムスタンプではなく日付に値をキャストすることで、列にクラスタリングキーを定義できます（例： to_date(c_timestamp)）。これにより、カーディナリティが合計日数に削減され、より優れたプルーニング結果が通常生成されます。 引用元：クラスタリングキーを選択するための戦略 費用 今回の例では、DATE列に指定した場合は約5クレジット、DATE列を含む4列に指定した場合は22クレジットの消費でした。 自動クラスタリング クラスタリングキーを設定し

イベントページ https://www.snowflake.com/events/data-cloud-world-tour-tokyo/ セッション説明 このセッションでは、Snowflakeがどのようにして、アドテクで発生する多種多様なビッグデータの一元管理を可能にし、データの真の価値を引き出す方法について詳しく説明します。データサイロの解消から多様なワークロードへの対応、Snowflakeがどのように運用上の課題を解決可能にし、ビジネス価値を引き立てるのかを、具体的な事例と共に解説します。 このセッションを通じて、Snowflakeの優れた特性を理解し、ビッグデータをより効果的に活用するための新たな視野を開くことを目指します。

はいさーい！ちゅらデータでPHP書いているaipaです。 みなさまEmbulkというOSSはご存知でしょうか。小さいデータから巨大なデータまでいろんなデータソースへバルク処理してくれるぱっとみシンプルだけど知れば知るほど多機能なすごいやつです。 今回はEmbulkを使って、AWS S3からSnowflakeへデータを保存するまでの手順を紹介します。Embulkはデータソースごとにpluginが用意されており、OSSで用意されたinとoutのpluginを組み合わせることでETLを簡単に実現することができます。 S3に対応したinput plugin「embulk-input-s3」はすでに知らていると思いますが、なんと！snowflakeに対応したplugin、「embulk-output-snowflake」があります！ これなら簡単に試すことが出来ますね！！ そんな風に考えてた時期が僕

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

create pipe sample_table_pipe auto_ingest = true aws_sns_topic = 'arn:aws:sns:ap-northeast-1:xxx:hoge' as copy into sample_table from ( select $1::variant as raw_data , metadata$filename::varchar as _metadata_filename , metadata$file_row_number::bigint as _metadata_file_row_number , metadata$start_scan_time::timestamp_ntz as _load_at , to_timestamp(split_part(metadata$filename, '/', 2) || '/' || s

変更記録 2021/8/8/ 公開 2021/8/10 同じリージョンの Snowflake アカウントにデータ転送する場合はデータ転送料無料の旨を追記。 2021/8/11 別リージョンの Snowflake アカウントや別のクラウドプロバイダにデータ転送する場合は追加料金が発生する旨を追記。 本記事の背景 - 「AWS から Snowflake にデータを転送すると高額だと聞いたけど本当？」と言われた 著者の所属では、2020年末頃にデータウェアハウスとして Snowflake を導入しました。 Snowflake 導入にあたって、顧客データ管理に厳格な業種のため、自社の Snowflake アカウントを外部インターネットごしに利用せず、自社の AWS アカウントと AWS Private Link を使ってプライベートネットワーク越しに使うことを決断しました。 AWS Private

本書では、SaaS型のデータクラウド・データウェアハウスとして知られるSnowflakeの構成をInfrastructure as Code（IaC）のためのツールであるTerraformを使って簡単に管理する方法をご紹介します。 実サービスでも利用可能な実践的な構成を体系的に整理しながら、GitHub Actionsを使った安全なリソースの更新方法を取り扱います。 また、Golang-migrateを使ったテーブルの管理方法を紹介します。 【内容】 ・Terraform × Snowflake ・GitHub Actions ・Golang migrate ※執筆時点のバージョンでの紹介になるため、読者が記事の内容を再現する時にはソフトウェアが更新されている可能性がありますのでご注意ください⚠️

Snowflakeのアーキテクチャはどうなっているか　圧倒的なスケーラビリティを実現するクラウドネイティブ設計思想：Snowflakeで何ができる？　基礎情報解説（3） 過去2回の記事でSnowflakeとは何か、何ができるかを見てきました。今回はSnowflakeの特長を裏付ける実装とクラウドネイティブな設計思想を見ていきます。

前置き こんにちは。株式会社GENDAのこみぃです。 Snowflakeからちょっと前にUnistoreという機能が発表されました。 先日社内の勉強会的なアレでSnowflakeのお話をしたのですが、その時にUnistoreについては結構すごいねっていうお話になりました。 このお話は社外でも興味ある人がいそうだなということで、本日はその話をしましょう。 Unistoreとは 前述のリンクが英語なのでざっくりまとめますと、Unistoreとは 分析用途でのDBとサービス用途でのDBを合わせたようなDB サービスのようなトランザクション処理と、分析用途の重い集計クエリを両立してパフォーマンスを出せる MySQLで分析用途のSQLも受けたりするのとそんなに変わらないでしょ、と思う人が多いかと思うのですが、実はこれはすごくすごいことです。 何故すごくすごいのか？ 行指向と列指向 サービスに利用され

背景 筆者の所属チームは、自社で唯一のデータエンジニアリングチームであり、 Snowflake を使って自社のデータウェアハウスを構築・運営すると共に、データパイプラインの構築・運用、利用者への技術サポートを行なっています。 データウェアハウスは社内のデータ分析や機械学習など様々なプロジェクトで利用されますが、データウェアハウスの直接的な利用者の多くは、データ分析を行なっているチームです。利用者も構築側の我々もお互いにデータ分析のワークロードがどういうものか理解した状態でプロジェクトが運営されます。 しかし、利用範囲が広がっていくにつれ、段々、データ分析のワークロード、データウェアハウス（あるいは Snowflake ）の特性をよく知っているエキスパートではない人が利用し始め、利用者と運営者（データエンジニアリングチーム）の認識の食い違いにより、運営側が想定してない問題に発展することがあり

概要 TreasureDataにある大量データ(100GBレベルのtableデータを複数)をSnowflakeへ取り込む処理を実行しました。 しかし、一筋縄ではいかず、試行錯誤経て比較的シュッとできる方法に辿りつきました。役立ったのはSnowflakeの半構造化データ機能でした。 ここでは、同じような問題に直面された方のお役に立てればと結論と伴に試行錯誤の過程を記します ※1年近く運用してわかった改良版も投稿済みです、ご参照ください 結論 TDからSnowflakeへの大量データの移行は「TD→Snowflake」の直接移行は不可能でしたが、 **「TD→クラウドストレージ(s3)→Snowflake」**とクラウドストレージ経由にすることで、ほぼ手動調整無しに実現可能になりました。 手順は以下になります。 1. Snowflakeに適切なtable定義を作る。 TDのSnowflakeE

この記事はSnowflakeアドベントカレンダーの10日目の記事です。 今日は私が Snowflake を使いはじめて失敗したことを中心に、不幸な事故を繰り返さないために初心者の方に気をつけてほしいことを書こうと思います。 スピル見てない Snowflake ってとっても高速にクエリを実行してくれるので、ついついプロファイルを見るのをサボったりしてしまいますよね？ これは架空の話なんですが… あるとき、めっちゃクエリが遅かったんです。 あー、遅いねーって思ってた。 よーく、プロファイルを見ると、スピルの数字がめっちゃ増えていたわけですよ。 うーん？スピルってなんだっけ？ When Snowflake cannot fit an operation in memory, it starts spilling data first to disk, and then to remote sto