はてなブックマーク

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

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

先人の知恵に学ぶ データエンジニア道で、本当に良かった！読み物を、不定期に追記していく。 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

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

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

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

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

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つはビジネスプロセスを分析支援する分析システム。それぞれ根本的に異なる目的があるため、異なる原則に基づき設計が進化してきた。 業務システムの目的は、ビジネスプロセスで発生した重要な事実や行動を記録する

本番環境でやらかしちゃった人 Advent Calendar 2020 14日目 の記事です。 稀によくあるアラートで始まる朝 ある日の朝、いくつかあるマイクロサービスの内の一つが稀によくある一部のメトリクスが取れてない趣旨のアラートが大量に飛んでいた形跡を発見した。 この稀によくあるアラートの原因として考えられるのは、一部のサーバーの調子悪いか、監視サービスが不調のどちらかだった。 ここで簡単にサービスの構成を説明しよう。 よくあるロードバランサーにいくつかのインスタンスがぶら下がってる系のもので、負荷が高まったらスケールアウトして、負荷が低くなればスケールインするいい感じのやつ。某AWSではオートスケーリンググループと呼ばれるもの。 インスタンスは使い捨て可能で、サーバーが不調になれば、自動でいい感じに殺すため、大体アラートが出ていても、朝起きた時には直ってることが多い。 加えて早朝に