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

ディメショナルモデリングの学び方について、それなりの頻度で聞かれるので、これ読んどけば良さそうをまとめました。 ※私の記事ばかりです 入門 ディメショナルモデリングって何？レベルの人は、過去に作った資料が参考になると思いますので、そちらを参照すると良さそうです。 動画講座の方は、ビジネスユーザーでも理解できる抽象度で解説しているので、社内のデータ活用プロジェクト推進にも使えると思います。 実践 ディメショナルモデリングを、リレーショナルデータベースで、実際にどうやってモデリングするんだっけ？の触りの部分を解説しています。 dbtで実装するディメショナルモデリング。 がっつり学ぶ人向け Snowflakeを使ってモデリングを学べる書籍ですが、内容がモデリングということもあり、Snowflakeを使ってない人でも、モデリングの部分は誰でも学べる内容になっています。 スタースキーマについて、がっ

nullableはやめとけ？ nullをデータベースでどのように扱うかは、非常に難しい。そもそも、nullとは何なのか。これは、データが存在しない(null)こととゼロを区別する方法として追加されたものになる。 業務システムにおいては、nullは必要であると誰しもが答えると思う。一方で分析システムではどうだろうか？本当に必要だろうか？について考えをまとめてみた。 分析システムにおいてnullはデメリットの方が大きい 結論から書くと、分析システムにおいては、nullを使うとクエリをする度に、気をつける必要があり、もし間違いが発生していても気づきにくい。逆にnullがあって助かったという場面があまり思いつかないくらいにはnullが嬉しい場面が少ない。（分析システム、業務システムについては、こちらの記事を参照 ） では、nullの代わりに何を使うべきか？それは、intなら0、textなら空文字や

当記事は、スタースキーマ の基礎的な知識がある人向けとなっています。 スノーフレークスキーマ wikipedia Wikipediaの内容を要約すると、スノーフレークスキーマは、ディメンションが正規化されたスキーマ。これを適用すると、正規化することでストレージは節約できるが、クエリは複雑になる。 スノーフレークスキーマは、ディメンションを正規化しているため、ERモデリングに慣れている人は、この設計手法に違和感を覚えないと思うが、ERモデリングは業務システム用に考えられた設計であり、分析用の設計ではないことを忘れてはならない。 仮にスノーフレークを使ったとして、出来上がったスキーマを扱うアプリケーションがスノーフレークに最適化されていなければ、メリットを得るのは難しいだろう。一方で横に長くなりすぎるレコードや、冗長な繰り返しに有効なケースもある。しかし、基本的にスノーフレークは、クエリが複雑

図1のスタースキーマは、注文(fact_orders)と返品(fact_returns)の2つプロセスを表している。それぞれ注文スター、返品スターと呼ぶ。 それぞれ別々の部門で実装されたもので、物理的に独立したデータベースに存在している。両方のデータベースに、ディメンションテーブルの日(dimension_days)、顧客(dimension_customers)、製品(dimension_products)がある。これらのスタースキーマを比較したいケースはあるとする。例えば、特定期間の製品別の注文に対する返品率などである。これはドリルアクロスを使えば実現可能である。以下が手順である。 各ファクト・テーブルを製品ごとに集約する。 集約した結果をマージし、注文された数量と返却された数量の比率が計算する。 図1の製品ディメンションを使えば、同様の手順で他のディメンション属性で分析可能だが、残念

広告配信を生業にしているエンジニアが、なぜスタースキーマを採用したか。 広告配信ログをコントロールするのは修羅の道 広告配信のログと聞いたらどんなものを想像しますか？ハイトラフィックだから、すごい量のログがあるとか、そんなところでしょう。語弊を恐れずに言うと、もしAWSなどの便利なサービスに乗っかっているのなら、アドテク畑の人たちから言わせると、多いだけなら余裕で、それは本当にやればいいだけ。 では、何が我々を大変にさせるのか？それは、ライフサイクルが全く異なるログを一覧したいからである。 一覧したいとは、どういうことか？DSPには様々な指標がある。まずはそれを紹介する。 ※当記事では、一般的なものだけに絞る。 Bid Request、Bid Response DSP/RTBの基本的な仕組み | DSP/RTB入門書特別公開 #1 Impression 広告配信イベント Click 広告の

スタースキーマ(基礎) の記事の知識を前提としています。 ディメンションテーブルのソースとなるデータは、運用している業務システムのものである。これらのデータは、データウェアハウスに移され、それぞれのディメンションテーブルに格納される。 しかし、この情報は運用の過程で変更されることがある。例えば、会員の生年月日を直したり、住所変更などである。この時に運用システム側は、変更履歴を追うようにする。または素直に上書きしてもよい。いずれにしても、ディメンションテーブルは、どのように分析をしたいかによって、変更に対応することが必要になる。 ディメンションの設計において、ソースデータの変更をどのように表現するかを決めることは重要で、これらを「スロー・チェンジ・ディメンション」と呼ぶ。これはファクトに比べるとディメンションはゆっくりと変更されることから由来している。 データ変更がされた場合、様々な対応が考

dbt Advent Calendar 2022 の20日目の記事です。 背景 筆者は、dbtを使った広告プラットフォームのデータ基盤の構築・運用をしています。 この基盤は、最初からdbtを使っていたわけではなく、過去にフルスクラッチから、dbtへのリプレイスをしました。 広告レポーティング基盤に、dbtを導入したら別物になった話 そのdbtへのリプレイスで、当初困ったことがありました。世の中で紹介されているdbtのサンプルコードは、データ量が少ないもの（広告に比べると）を前提にしているので、大量データを扱っている筆者にとっては参考に出来るものがありませんでした。 けれども、元々フルスクラッチで実装していた時に、採用していたパーティショニングを使ったデータ処理のパターンが、dbtでの実装においても、非常に有効だったので、今回はそれについてシェアします。 今回、紹介する設計は、データウェアハ

複数スタースキーマ(Multiple star schema) 1つのファクトで、全ての分析対象がカバー出来ることは稀である。ほとんどのケースで複数のファクトテーブルが必要になるだろう。本当に価値ある分析は複数のプロセスを横断した分析である。これを誤った方法で実現するとどうなるか？どうすれば良いのかを見ていく。 スタースキーマの作り方に関しては、別の記事にまとめている 。 発生タイミングが異なるファクト 2つ以上のファクトがあったとする。それらは同時に発生しないファクトである場合、異なるファクトテーブルに配置するべきである。誤って単一ファクトテーブルにまとめられると、個々の分析が困難になる。もし分けていれば個々に分析が可能になる。 ある営業部門で以下のような分析要件があったとする。 日付、顧客、製品別注文数量の分析 日付、顧客、製品別出荷量の分析 ディメンションは日付と顧客。ファクトは製品

アドテクエンジニアを生業にしてます。AWSとかアプリケーション、設計全般好きです。

まず、dbtの前提は「ELT」です。ETLなデータ前処理には対応していません。今日のDWHはパワーがありますので、先にDWHにロードを済ませてしまい、変換処理はDWH上で実施するという考え方です。 ですので、dbtの出番としては、「分析対象となるデータの抽出」「抽出したデータをDWHにロード」の2つが終わった後となります。要するに「DWHまでデータが持ってこれている状態」が前提ということですね。 dbt（データビルドツール）は、データアナリストやエンジニアがウェアハウス内のデータを変換することを可能にします。 エレベーターピッチより深く知りたいなら、かなり深く入る必要があります。dbtとは何か、エコシステムの中でどのような位置づけにあるのか、そしてどのように利用を考えるべきなのかを理解したいのであれば、この投稿がそれにあたります。 dbt and the modern BI stack d

スタースキーマ wikipedia スタースキーマ または 星型スキーマ はデータウェアハウスに利用される最も単純なスキーマである。スタースキーマには唯1つもしくは少数のファクト表と複数のディメンション表が含まれる。スタースキーマはスノーフレークスキーマの一種であるが、多くの用途で利用されている。 スタースキーマは、ディメショナル・モデリングをリレーショナル・データベースで実装したものになる。 詳しくは、ディメンショナル・モデリング にまとめている。 この記事は、あなたが「様々な指標を様々な軸で、レポートを見たい」類の要望に応えるためのスキーマ設計に困っている場合に役立つだろう。 ディメンションテーブル設計 サロゲートキー スタースキーマでは、各ディメンションテーブルに、サロゲートキーを割り当てる。このキーは、業務システムで使われているキー（ナチュラルキー）とは別のものを使用し、データウェ

先人の知恵に学ぶ データエンジニア道で、本当に良かった！読み物を、不定期に追記していく。 A Beginner’s Guide to Data Engineering — Part I データエンジニアをこれから始める人に、必ず薦める記事。データエンジニアの基本を学べるかつ、どういう世界に広がっていくのかまで、一気に学べるのでとても良い。 Functional Data Engineering — a modern paradigm for batch data processing 関数型パラダイムを使ったデータパイプラインの構築方法。これを初めて読んだ時の衝撃は今でも忘れないし、フルスクラッチからdbtを使ったデータパイプラインになっても健在な設計手法。 Engineers Shouldn’t Write ETL: A Guide to Building a High Function

VOYAGE GROUP Techlog Advent Calendar 2020 13日目 ディメンショナル・モデリングとは ディメンショナル・モデリング Wikipediaには以下のような説明がある。 Dimensional Modeling (DM) is a data structure technique optimized for data storage in a Data warehouse. データウェアハウスにデータを格納するために、最適化されたデータ構造の手法。 背景 情報システムは2つの大きなカテゴリに分類される。1つはビジネスプロセスの実行支援する業務システム、もう1つはビジネスプロセスを分析支援する分析システム。それぞれ根本的に異なる目的があるため、異なる原則に基づき設計が進化してきた。 業務システムの目的は、ビジネスプロセスで発生した重要な事実や行動を記録する