プログラマのはしくれダイアリー

2024/09/30

VLOOKUPをしたくない人生だった

VLOOKUPをしたくない人生だったのですが、色々ワケあってスプレッドシートを使うこともあるのでそんな時に覚えておくと便利な関数でも書いておきます。スプレッドシートは関数型言語です

QUERY

SQLのように色々かけます

=QUERY(
'Sheet1'!A:Z,
"SELECT A, B, C, D, E WHERE A = 'ドラえもん'"
)

WHERE とかGROUP BYとかORDER BYとかLIMIT 1とかできます
JOINをやろうとすると出来ないので爆発します

FILTER

FILTER関数を使うと特定の条件のものを除外した結果を返してくれます。スプレッドシートでフィルタ機能つかっても誰かが勝手にいじって絞り込みがいつの間にか変わってたやんウギャーとかならずに済みます

IMPORTRANGE

別のスプレッドシートからデータを引っ張ってくることができますとあるスプレッドシートと同じデータを使いまわしたい場合やとあるスプレッドシートの内容を確認したいけど直接いじりたくない時とかに便利です


=IMPORTRANGE("https://docs.google.com/spreadsheets/d/xxxxxxx", sheet1!A:Z)

UNIQUE

重複を排除します。これもデータクリーンアップで特定行で重複排除みたいなことをイチイチやらずに関数の組み合わせをしたいときなどに便利です

=UNIQUE(A:A)

ARRAYFORMULA

もう、関数を行数分コピペするなんて嫌なんやという時に便利です。

=ARRAYFORMULA(IF(A:A<>  "",  "空ではない","空"))

組み合わせると

組み合わせると、こんな感じになんやかんやできます。
A列がユニークなidだとして

Sheet1のA列の空文字でないところに絞り込み
重複を排除したデータをキーとしてVLOOKUP
対象のデータ範囲の1,2,3,4,5,6,7番目を列に展開

=ARRAYFORMULA(
  VLOOKUP(
    UNIQUE(FILTER('Sheet1'!A:A,  'Sheet1'!A:A  <>  ""))
    ,'Sheet1'!$A:$Z,  {1,2,3,4,5,6,7}
    ,FALSE
  )
)

まとめ

ということで関数型言語、スプレッドシートのお話でした！
でも、やりすぎると関数のネストが深くなって秘伝のタレ化しますなにごとも程々にするのがよいですね
そもそもの、元々のデータを綺麗にしてエクセルワーク的なのは減らしたいですね

2024/09/19

git diffを一番綺麗に出来た人選手権を開催します

カテゴリ: git

まぁ、僕あのSNSで謎に選手権開くスタイルあんまり好きではないんですけどね

git diffした時にいい感じに表示するようなライブラリを探しています (tigとかlazygitとかTUIも良いんだけど、単純にgit diffをいい感じにするやつを募集しています) 5つ、いいなぁと思うライブラリを紹介します。 ※ちなみに以下は、ChatGPTとかに紹介文章作ってもらいました

1. delta

https://github.com/dandavison/delta Gitの差分出力を美しく色分けして表示するツール。行の追加・削除を強調し、カスタマイズ性が高いのが特徴。CLIで簡単に設定可能で、直感的に使える。

2. diffstatic

https://github.com/Wilfred/difftastic 静的な差分表示を目的としたツールで、シンプルなインターフェースが特徴。シンタックスハイライトを提供し、変更点をわかりやすく強調。使いやすさが魅力で、視覚的な比較ができる。

3. bat

https://github.com/sharkdp/bat#git-diff ファイルビューアで、シンタックスハイライト機能を持っている。git diffの出力を視覚的に整形して表示でき、使いやすさが特徴です。強力なページング機能も搭載している。

4. diff-so-fancy

https://github.com/so-fancy/diff-so-fancy git diffの出力を整形し、変更点を視覚的にわかりやすくするツール。変更が一目でわかるように強調表示し、カスタマイズが可能。シンプルで直感的な使い勝手が魅力。

5. pretty-diff

https://github.com/prettydiff/prettydiff コードやテキストの差分を視覚的に表示するためのツールで、シンタックスハイライトもサポート。ブラウザベースのインターフェースが特徴で、柔軟にカスタマイズ可能。多様なフォーマットに対応しており、使い勝手が良い。

まとめ

いい感じだなーってやつを並べて紹介してみました。これら以外に「これはいいぞ！」というのを募集中

2024/08/19

Snowflakeで実現できるTransformとは何か？調べてみた

カテゴリ: Snowflake

SnowflakeのTransform機能はどの程度か調査したい

ETL、ELTなどといったときの文脈のTransformだが一体Snowflake側でどれほどの機能を提供しているのだろうか。

「データウェアハウスだけどTransformもちょこっと出来るよ」なのか「データウェアハウスだけじゃない。ETLすべてお任せあれ」なのか。

前提

Transformの定義はwikipediaのTransformの項に委ねる
https://ja.m.wikipedia.org/wiki/Extract/Transform/Load

Snowflakeで使える手札

Transform関数 https://docs.snowflake.com/en/sql-reference/functions/transform
MERGE https://docs.snowflake.com/en/sql-reference/sql/merge
UDF（ユーザー定義関数） https://docs.snowflake.com/ja/developer-guide/udf/udf-overview
Snowpark https://www.snowflake.com/en/data-cloud/snowpark/
Snowflake Script https://docs.snowflake.com/en/developer-guide/snowflake-scripting/use-cases

TaskとStreamを組み合わせ、変更差分をUDFでTransform

Snowflakeでよく見る、Streamで差分を確認し、Taskで定期実行し差分をTransformするやり方。この記事を書いた人が特徴的なのはUDF（ユーザー定義関数）をゴリゴリ使ってるところ https://dev.to/rnubel/transform-data-in-snowflake-with-streams-tasks-and-python-l71

Transformはdbtにすべて託すパターン

ExtractやLoadの部分はSnowflakeに任せTransformはdbtだ！という記事も見るそういう選択肢を取る人も居るらしい https://zenn.dev/dataheroes/articles/bcced35e8156ba

この記事内にも書いてあったが、Snowflakeで完結するメリットもあるといえばありそう

コストやテーブルの変更容易性
dbtの学習コスト、導入コストとのトレードオフ

Snowflakeをデータウェアハウスとして扱いTransformは各プロダクトでdbtで賄うパターン

Snowflakeのテーブルは使うのだが、Transformはdbtでやっているぽい。各プロダクトのチームがそれぞれ要件に合わせてdbtモデルを作ることでTransformする。プロダクト横断でdbtを使うぞ！となってる場合これで良さそう

https://techblog.cartaholdings.co.jp/entry/snowflake-data-platform-vision

その他参考

https://www.snowflake.com/guides/modern-etl-process/?amp https://www.snowflake.com/ja/guides/etl-vs-elt/?amp https://zenn.dev/circle_yukiyama/books/snowflake-zero2prod

まとめ

Transformationに絡みそうなSnowflakeの手札を調べ、世の中でどんなふうに使われているか色々ネット記事を漁ってみた。できることにはある程度限りはあるものの、 SnowpipeとTaskを組み合わせて流れを組めばできることは色々ありそう。あと、TransformなのかLoadなのか微妙な位置な気がするけど Dynamic Table (https://docs.snowflake.com/en/user-guide/dynamic-tables-about)も良さそう。結論、このSnowflakeで組めるジョブフローや機能の範囲であればSnowflakeを使う。そうすると、Snowflakeの特徴である計算リソースがうまく並列で使えることやRole定義などの恩恵が受けれそう。 Snowflakeの提供する機能でユースケースが満たせなさそうであれば、DigdagやAirflowなどのワークフローエンジンやdbtとかでゴニョゴニョする感じだろうか

2024/08/16

Snowpipeについて調べる。自動ロードや差分ロードが良い感じに出来るのか

カテゴリ: Snowflake

Snowpipeとは

https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-intro

COPYコマンドとかとは異なり、ファイル単位で小さい粒度のロードが出来るということらしい。

用語の整理

Snowpipe→機能名
パイプ→名前付きファーストクラスSnowflakeオブジェクト
Snowflakeテーブル→Snowflakeの世界のテーブル
内部ステージ→Snowflakeのテーブルとか、名前付きステージ
外部ステージ→S3とかのファイルの置き場所のこととか
半構造化データ→JSONとかAVROとか

使い方

パイプを作ることでなんやかんやするらしい

CREATE PIPE ALTER PIPE DROP PIPE DESCRIBE PIPE SHOW PIPES

一旦CREATE PIPEさえ理解すれば、使い始められそうではある。

基本、RDBでいうところのTABLEがPIPEに置き換わった構文のようだ。

CREATE PIPE

https://docs.snowflake.com/ja/sql-reference/sql/create-pipe

こう書くらしい。

create pipe mypipe_s3
  auto_ingest = true
  aws_sns_topic = 'arn:aws:sns:us-west-2:001234567890:s3_mybucket'
  as
  copy into snowpipe_db.public.mytable
  from @snowpipe_db.public.mystage
  file_format = (type = 'JSON');

このように、ステージからsnowflakeテーブルへと、データを流し込むことになる。
データがS3にputされる→SNS経由でSQSにキュー送信→Snowflake側でサブスクライブ→PIPEの定義通り、ステージからテーブルにCOPYという流れが組まれるということらしい。

ややこしいのは、Snoflake側がSQSを作成、管理しており、S3側がその送信先を知っていないといけないこと。

このあたり、日本語ドキュメントがよく分からなかったので結局英語の公式ドキュメントを読むことになった

英語版 https://docs.snowflake.com/en/user-guide/data-load-snowpipe-auto-s3

日本語版 https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-auto-s3

差分ロードなどの仕組み

上記のようなイベント通知を使った自動ロードを使えば、差分を日時で取り込むワークフローなども作りやすそうである。
S3以外にもCloud StorageやAzure Blobなどメインどころのクラウドのストレージサービスに対応してる。

全量をドカンとロードしたあと、日時データをS3にアップロードし、毎日S3に1日分をputしてサブスクライブ→PIPEで差分をロードとか出来そう。

あとは、REST APIも用意されてるらしいので
それでよしなに自分でロードするためのバッチでも作るのも出来そう。

取り込む内容についてはfile formatが対応していればゴニョゴニョ出来そう。
例えば「csvファイルの特定ファイルだけSELECTしてCOPYする」など

https://docs.snowflake.com/en/user-guide/querying-stage

まとめ

SnowpipeでS3からSnowflakeへのファイル単位のロードが出来る
PIPEのDDLでSnowpipeを構築できる（CREATE PIPEなど）
SQSのサブスクライブかRESTのAPIコールによってPIPEを動かすことが出来る
ロードの単位はファイルっぽい。ファイルある程度SELECT文で条件つけて取り込むことも出来るが、あまり難しいことは出来ない（COPY構文の範囲内のことしか出来ない）

2024/07/04

Kotlin Fest 2024、とある運営スタッフのふりかえり（個人の感想です）

カテゴリ: Kotlin

なかなかあっという間の数ヶ月だった。

本格的に始動したのは2月か3月ぐらいだったか。
2022年を思い出しながら、運営スタッフが再び集まり Kotlin Fest 2024に向けた動きが始まった。

とにかく、みんなありがとうございました

まず、はじめに書いておきたいのですが、とにかく感謝です。

参加者、スピーカーの方、スポンサーの方、運営スタッフ、デザイナーさん、当日手伝ってくれたスタッフ、会場 etc... それら全てがあったからこそ、良いKotlin Festになったのではないかなと思います👏👏👏 ありがとうございました！！！

登録: 投稿 (Atom)

cssmenu