Cherry Peeked

Image by Jake Aldridge from Pixabay You know oftentimes, the cause of runtime or compile errors and hours of debugging agony is all due to simply a missing semicolon. Have you ever had such experience? If you had, you are not alone. There are two ways to avoid these unfortunate situations: either become a perfect developer who never makes mistakes, or use helpful tools such as linters that can catch these errors early on. I am nowhere near being a perfect developer who never makes a mistake. In fact, I'm probably the opposite of a perfect developer, so even if I wanted to, I wouldn’t be able to teach you how to become a perfect developer. But what I can teach you is using linters. A Wikipedia defines a linter as a "static code analysis tool used to flag programming errors, bugs, stylistic errors and suspicious constructs." If you're not convinced yet on using linters, consider this scenario: in a large project with multiple members, different people tend to ...

Image by Icons8_team from Pixabay Tracking data loads in Snowflake is crucial to maintaining data health and performance. Load History and Copy History are features that provide valuable information about past data loads. Understanding these features can help you efficiently troubleshoot, audit, and analyze performance. You might be wondering why two functions exist to achieve the same goal, what are the differences, which one I am supposed to use and when? In this article we will provide you with all the answers. So, let's learn what are the differences and when to use which! Load History vs Copy History: 7 differences Differences 1 and 2: views vs table function and Account Usage vs information Schema Here things get little confusing, bare with me, there are two Load History views, a view that belongs to Information Schema and a view that belongs to Account Usage schema . As for Copy History, there are Copy History table function of Information schema and a Copy H...

Image by Gerd Altmann from Pixabay データベースの操作において、反復的なタスクや複雑なロジックの実行は、時間と労力を要する作業になりがちです。Snowflakeストアドプロシージャは、こうした課題を解決するための強力な機能であり、SQLクエリを拡張して、より効率的かつ安全なデータ処理を実現します。 本稿では、Snowflakeストアドプロシージャの基本的な概念から、JavaScript、Python、そしてSnowflake Scripting (SQL)といった複数のプログラミング言語を使った作成方法、さらにはセキュリティ対策まで、実践的な知識を提供します。 小売業におけるキャンペーン管理を例に、県名に応じてキャンペーン情報と割引率を一括更新するストアドプロシージャを実装します。 ストアドプロシージャと言うのは ストアドプロシージャを関数の一つ種類と考えてもいいです。ストアドプロシージャを記述して、 SQL を実行する手続き型コードでシステムを拡張できます。ストアドプロシージャを作成すると、何度でも再利用できます。 値を明示的に返すことが許可されていますが、必須ではないです。ストアドプロシージャを実行するロールの権限だけではなく、プロシージャを所有するロールの権限でも実行出来ます。 サポートされている言語: Java JavaScript Python Scala Snowflake Scripting (SQL) ストアドプロシージャの形： CREATE OR REPLACE PROCEDURE プロシージャ名(arguments argumentsのタイプ) RETURNS レターんタイプ LANGUAGE 言語 -- (例:python, JavaScript等) -- RUNTIME_VERSION = '3.8' (言語がpython, java, scalaなら必要 ) -- PACKAGES = ('snowflake-snowpark-python') (言語がpython, java, scalaなら必要 ) -- HANDLER = 'run' (言語がpython, java, scalaなら必要 ) EXECUTE AS ...

Image by Jan from Pixabay データ分析において、結果を分かりやすく可視化し、共有することは非常に重要です。従来のBIツールに加えて、近年ではインタラクティブなデータアプリが注目されています。 Snowflake で Notebook と Streamlit を使えるのを知っていますか？ Notebook の中で Streamlit を使えるのも知っていますか？ SnowflakeノートブックとStreamlitを使えば、Pythonの知識だけで、簡単にインタラクティブなデータアプリを作成できます。Snowflakeノートブックは、コード、Markdownによる説明、そして可視化結果を1つのドキュメントにまとめることができるため、データ分析の作業効率を向上させます。 この記事では、Snowflakeノートブック上でStreamlitを使ってインタラクティブなデータアプリを作成する方法を紹介します。SQLクエリからデータを取得し、Streamlitのコンポーネントを使って動的なグラフや入力フォームを備えたアプリを構築する手順を、実際のコード例とともに解説します。 Notebook と Streamlit は何でしょう？ Notebook ノートブックは、コードとその出力を 1 つのドキュメントに統合し、コード、説明文、視覚化、その他のリッチ メディアを組み合わせることができます。つまり、1 つのドキュメントで、コードを実行し、説明を追加し、出力を表示し、作業をより透明化することができます。 人気なのノートブックは Jupyter Labs と Google Colab です。 Snowflake もノートブックをサポートしています n ので、Snowflake のノートブックでは Markdown , Python と SQL コードを書けます。 内部ノートブックは .ipynb . Interactive Python Notebook (インタラクティブ Python ノートブック) ファイル形式を使用します。 Notebook に加えて、Snowflake が Streamlit もサポートしています。 Streamlit Streamlit を利用したら、Python だけを使ってインタラ...

Snowflake と Slack の連携でデータエンジニアの仕事がはかどる！ Snowflake と Slack を連携させると、データエンジニアの業務効率が大幅に向上します。 その理由を見ていきましょう。 リアルタイムなエラー検知とデバッグ : これまでのようにログを常に監視しなくても、Snowflake でエラーが発生した場合に Slack チャンネルに自動通知を送信するように設定できます。これは、コードのエラーを監視し、すぐに知らせてくれる専任のアシスタントがいるようなものです。迅速な問題解決が可能になります。これは、Webhook を使用することで実現します。Webhook とは、イベントをトリガーとして Snowflake から Slack に送信される自動 HTTP リクエストです。 チーム全体の情報共有 : Slack 連携により、データパイプラインなどの処理状況をチーム全体に共有することもできます。パイプラインが完了、失敗、または問題が発生した場合に、共有チャンネルに通知を送信するように Snowflake を設定できます。これにより、全員が状況を把握できるようになり、不要な進捗確認会議を減らすことができます。 この連携により、Slack がデータワークフロー管理の強力なハブとなり、データエンジニアの業務をよりシンプルかつ生産的にします。 SnowflakeとSlackを統合する方法 Snowflake の NOTIFICATION INTEGRATION と言う機能と Slack の Webhook を利用し Snowflake から Slack にメッセージを送る事が出来ます。 同じ方法を使って、Snowflake から Microsoft Teams と PagerDuty にもメッセージを送るのは可能です。 Slack の使う方の概要が必要なら、この 動画 を見てください。 Webhook は http リクエストです。これは API 呼び出しで、リバース API または Push API と呼ばれることもあります。Webhook の特徴は、何らかのイベントが発生したときにクライアントがサーバーにコールバック (http リクエストを送信) するように指示することです。...

TL;DR: Cortex Fine-tuning is a fully managed service that lets you fine-tune popular LLMs using your data, all within Snowflake. While large language models (LLMs) are revolutionizing various fields, their "out-of-the-box" capabilities might not always align perfectly with your specific needs. This is where the power of fine-tuning comes into play. As it will be explained in this article, this feature empowers you to take a base LLM and customize it to excel in your particular domain. Here's the brief summary of why you might want to leverage Snowflake's fine-tuning capabilities: Unlocking Domain Expertise : Pre-trained LLMs are trained on massive, general datasets. Fine-tuning allows you to build upon this foundation and train the LLM further using data specific to your field, such as legal documents, medical records, or financial data. This empowers the LLM to understand complex terminology and patterns unique to your domain, leading to more accurate a...

Snowflake におけるデータロードの追跡は、データの健全性とパフォーマンスを維持するために非常に重要です。Load History と Copy History は、過去のデータロードに関する貴重な情報を提供してくれる機能です。これらの機能を理解することで、トラブルシューティング、監査、パフォーマンス分析などを効率的に行うことができます。 Snowflake で Load History を使っても Copy History を使ってもテーブルにロードされた過去のデータの履歴を取得できますが。 何が違うでしょうか。いつどっちを使った方が良いでしょうか。 Load History と Copy History の７違いさ 違いさ１: ビュー vs テーブル関数 Load History は ビュー です。 Copy History と言う テーブル関数 も ビュー もあります。 Load History の使う方の例： USE DATABASE db_1 ; SELECT table_name , last_load_time FROM information_schema . load_history WHERE schema_name = current_schema ( ) AND table_name = 'TABLE_1' ; Copy History ビュー: select file_name , table_name , last_load_time from snowflake . account_usage . copy_history order by last_load_time desc limit 10 ; Copy History テーブル関数: select * from table ( information_schema . copy_history ( TABLE_NAME = > 'TABLE_1' , START_TIME = > DATEADD ( hours , - 1 , CURRENT_TIMESTAMP ( ) ) ...

TL;DR:  Dynamic Tablesは、同期機能が組み込まれたテーブルです。Dynamic Tableの定義では、同期元テーブル、同期するデータ、同期頻度を定義します。その後、Snowflakeがデータ同期プロセスを自動的に処理します。 Dynamic Tableは、信頼性が高く自動化された方法でデータを変換するために使用されます。 ソース テーブルを定義し、同期するデータを選択するための SQL クエリを記述し、同期の頻度を設定します。残りの作業は Snowflake が行います。Dynamic Tableの基になる基礎データが変更されると、テーブルが更新されてその変更が反映されます。これらの更新は自動化されており、「更新」と呼ばれます。 Dynamic Tableのソースは複数のテーブル、さらには別のDynamic Tableにすることもできます。 Dynamic Tableの主な利点: 宣言型プログラミング (Declarative programming): 宣言型 SQL を使用して終了状態を定義し、Snowflake にパイプライン管理を処理させることができます。 簡単に切り替え可能: ALTER DYNAMIC TABLE コマンドで、バッチからストリーミングにシームレスに移行できます。パイプラインでデータを更新する頻度を制御できるため、コストとデータの鮮度のバランスをとることができます。 注記: Dynamic Tableの内容はクエリに基づいており、DML 操作を使用して変更することはできません。 Dynamic Table の仕組みを解き明かす Dynamic Tableは、変更を検知するためにベース テーブルの変更追跡に依存します。ベース テーブルで変更追跡がまだ有効になっていない場合、Snowflake は自動的に変更追跡を有効にしようとします。Dynamic Tableを作成するユーザーは、すべての基礎となるオブジェクト/テーブルで変更追跡を有効にするために、 OWNERSHIP 権限を持っている必要があります。 変更の追跡 (Change tracking) テーブルで変更の追跡を有効にするかどうかを指定します。テーブルで変更の追跡が有効になります。この設...

TL;DR: Dynamic tables are tables with in-built syncing capability. On the dynamic table definition you define the source tables, what data to sync and how often to sync, after that Snowflake takes care of data syncing process automatically. Dynamic tables are used to transform data in a reliable, and automated way. You define the source table, write SQL query to select what data to sync,and set frequency to sync. Snowflake takes care of the rest. When the underlying data on which the dynamic table is based on changes, the table is updated to reflect those changes. These updates are automated and referred to as a “refresh”. Source of the dynamic table can be multiple tables and even another dynamic table. Main benefits of dynamic tables: Declarative programming: You can define define the end state using declarative SQL and let Snowflake handle the pipeline management. Easy switching: Transition seamlessly from batch to streaming with a single ALTER DYNAMIC TABL...