サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
zenn.dev/tenajima
これは何? 私tenajimaがデータ基盤のパイプラインを作るとき、レビューするときに意識している点を言語化したものです データ基盤を作る上での考え方の一つに役立てていただければ幸いです この記事の前提 dbtを使ったデータ基盤構築を念頭に置いて書いています、dbtの記法が出てきます CTEsが使える環境を想定しています 記事内でデータエンジニアもアナリティクスエンジニアも総称してデータエンジニアと呼んでいます データ基盤を「使う側」のクエリと「作る側」のクエリの違い 最近ではファーストキャリアからデータエンジニアの方も出てきているかもしれませんが、データサイエンティスト、アナリスト、ソフトウェアエンジニアを経験してデータエンジニアを行っている人が一般的と考えています。 特にデータサイエンティスト、アナリストからデータエンジニアへの転向は私の周りでは多いように感じており、その方達は(過去の
これはdbt Advent Calendar 2023の16日目の記事です。 夏頃に「なぜデータモデリングに取り組むことが重要なのか」を文章化したものになります。 何を解決したいのかシリーズの第二弾です。 第一弾は「sqlfmtによって何を解決したいのか」になります’。 dbtとデータモデリングにどのような関係があるのか 私はdbtが提供する革新的な価値は次の4つに集約できると考えています 処理の依存関係を簡単に記述できる マテリアライズ(テーブルやview)を簡単に作成できる データ基盤の中でSCD type2を簡単に導入できる 自動テストを導入できる もちろんdocsを生み出せたり、それをホストできたり、いろんな機能がありますが、コアな価値は上記4つに集約されていると考えています。 3と4はぱっと見で価値が伝わりやすいと思いますが、1と2は単独では価値が伝わりにくいと感じます。 今回の
これは何 データ基盤の開発にsqlfmtを導入することについて考えてみたものです。 (チームにsqlfmtを導入するために書いてるものになります) sqlfmtによってどのような課題を解決したいのか 大きくはこれに集約されるかなと思います。 ではスタイル周りにある開発者生産性を阻害する要因とはどのようなものかというと: 読みづらいSQLによるバグの発見の遅れ ロジック周りには関係のない箇所のレビューをする必要性 SQLスタイルのスタンスの違いによる衝突 というものがあります。 これをsqlfmtならどう解決できるかを紹介します。 sqlfmtならどう解決できるか 読みづらいSQLによるバグの発見の遅れ これはそもそもformatterを導入していないことにより生じるものを想定しています。 やたらと長い一行、スペースの無い濃密な一行、揃わないインデント、無意味な改行...などにより、不用意に
この記事はdatatech-jp Advent Calendar 2022の12月11日の記事です! 概要 自チームでデータ基盤を作っていく際に使っているdesign docの紹介と、導入背景をここに記します 感じていた課題感 レビュアーにアサインされてプルリクを見るときに「このプルリクはどういう背景があって、どういうコードを書いたのか、どういうテストをしたから大丈夫なのか」を汲み取るのに時間がかかるなって思っていた 備忘録的にissueにたてる、とりかかるときにタイトルだけ埋めたissueを立てて走り出す、ということが多く感じて、事前に整理しておくともっと効率が上がるのではと思った データ基盤を作っていく際に、ログやテーブルの値の意味などをエンジニアにヒアリングすることがあるが、それをちゃんと蓄積したいと思った これに関しては、別途Notionで蓄積してるものがあるのですがGithubに
概要 dbt style guideを読んでいたら、このポストを参照していて、とても内容が濃かったので別でまとめました 同僚に読んでもらうために、僕なりに翻訳、噛み砕いたものなのとなっています 原文と若干ニュアンスが違うかもしれません、Single Source of Truthの精神でぜひ原文も読んでみてください tenajimaの感想 dbtのプロジェクトをどのように構築していくべきか学ぶ中で、データをどのように捉えるべきか(dimensionとfactなど)も同時に学べてすごく良かった 僕も型として「このパターンはこのようにプロジェクトを作っていく」というのを何個か持てるようになりたい How we structure our dbt projects 前提としてここで示す方法は、dbtとしてはベストだと思うが、自分自身のプロジェクトにとって最適かどうかは自分で判断してね(より深くデ
概要 dbtと仲良くなりたい私 dbtを社内でも広めたい私 ディレクトリ構成とかどうしていけばいいか分からない私 よし、まずはdocsのbest practiceを読んでみよう 後に同僚にも読んでもらいやすようにまとめておこう ということでこれを読んでいきます しっかり公式のdocs読むこと大切よね 余計なお世話かもしれませんが、途中私が気になったことに対しては以下のようにコメント残していきます Best practice workflows Version control your dbt project 全てのdbtプロジェクトはバージョン管理しようね 新しい機能やバグの修正のためにはブランチを生やして作業しようね 全てのコードの変更はプルリク出して、同僚に(もしくは自分で)レビューしてもらおうね Use separate development and production envi
概要 予定を見越したり、優先順位をちゃんと切ったりというのが苦手な僕が、今年取り組んでよかったタスク管理オブザイヤーを紹介します やってみてうまくいかなかった管理方法たち うまくいったものも紹介しますが、その前に「これは上手くいかなかったよー」(自分には合わなかった)というのも紹介します TODO形式のタスク管理 よくなかったこと 「何をいつまでに」が管理できていない タスクが何のプロジェクトに紐づいているのかが管理できない、見える化できていない この2点が致命的でした。そして上長に「TODOではなくガントで管理するといいよ」とアドバイスをもらい、チーム全体でガントで管理するようになりました ガント ver.1 なかなかいい感じに見える typeがプロジェクトのものにはそのプロジェクトの情報が一括して入れてあり、そのページを見ればプロジェクトを把握できるようにしてた よくなかったこと 数日
このページを最初にブックマークしてみませんか?
『tenajimaさんの記事一覧』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く