これは何? 私tenajimaがデータ基盤のパイプラインを作るとき、レビューするときに意識している点を言語化したものです データ基盤を作る上での考え方の一つに役立てていただければ幸いです この記事の前提 dbtを使ったデータ基盤構築を念頭に置いて書いています、dbtの記法が出てきます CTEsが使える環境を想定しています 記事内でデータエンジニアもアナリティクスエンジニアも総称してデータエンジニアと呼んでいます データ基盤を「使う側」のクエリと「作る側」のクエリの違い 最近ではファーストキャリアからデータエンジニアの方も出てきているかもしれませんが、データサイエンティスト、アナリスト、ソフトウェアエンジニアを経験してデータエンジニアを行っている人が一般的と考えています。 特にデータサイエンティスト、アナリストからデータエンジニアへの転向は私の周りでは多いように感じており、その方達は(過去の
現代のビジネス環境では、大量のデータが毎日生成されており、これらのデータを効果的に管理し活用することが企業の成功に不可欠です。しかしながら、データはしばしば複数の形式やソースから来るため、整理し、分析に適した形に変換する作業は複雑です。この複雑な課題を解決するために、dbt(Data Build Tool)のようなツールが注目されています。 dbtはSQLベースのデータモデリングツールであり、データをステージング、ベース、インターメディエイト層においてクレンジング(洗浄)やSSOT(Single Source of Truth:単一情報源)処理を容易にし、最終的にマート(利活用)を目的としたビジネスエンティティのデータの生成を開発・管理します。これにより、異なるデータソースを一元化し、整合性を保ちながら分析可能な形式に変換することが可能になります。 dbtの導入はビジネスにおけるデータ処理
分析チームの井下田(@hiroki_igeta)です。 Tokyo dbt Meetup #5で登壇機会をいただき、「Lookerから、dbtと相性のよいLightdashに移行してみた話」というタイトルで発表させていただきました。 speakerdeck.com ちなみに今回のMeetupは、オフラインとオンラインのハイブリッド開催でした。 会場および配信環境の提供をいただいたCARTA HOLDINGS様ありがとうございました!! また、Meetupの企画をいただいた瀧本さま、発表をお聞きいただいた皆様にもこの場を借りてお礼申し上げます。 ↓こちらでイベントの録画をご覧いただけます! www.youtube.com 登壇の概要 登壇では「なぜLightdashに乗り換えたのか」「LookerとLightdashの違い」「今後の展望」について話させていただきました。*1 まだまだLigh
テストの完了をゴールにしない! ~仮説検証を繰り返し、開発・QA・ユーザーが交流しながら開発することで見えてくる理想の姿~ - #RSGT2024 #DevSumi / Shift left and Shift right
先日、dbtの公式から以下のような記事が投稿されました。 非常に興味深い内容だったので、多くの人にみてもらいたくひとまず翻訳記事をぱっと書いてみます。 サマリ ビジネスメトリクスの管理を特定のプロダクトから開放し、バージョン管理下に置きながら様々なBIから利用できるようにしようとしている取り組み(ヘッドレスBI) BI
DataEngineeringStudy #13に10Xの瀧本が登壇した際の資料です。
事業会社においてBIやレポート用の分析を担当しているが以下のような状況に該当する人に向けたデータパイプライン構築の入門のための資料です 🧑🏻🦱「BigQuery等のView機能を活用しているが、データの流れを追うのが困難な状態になってしまっている、クエリの実行に時間がかかりBIツールが使いづらい」 👩🏻「専任のデータエンジニアがおらず、前処理をpython等で処理したりするのがリソース調整的に大変」 👱🏻♂️「ロードされたデータに重複があったり、過不足があったりしてデータの品質が担保できていない」 🧑🏻🦰「Digdagやluigiといったデータ変換ツールの独自の仕様を理解しきれておらず使いこなせていない」 ※現時点ではBigQueryを中心に記事を構成してあります、SnowflakeやAmazon Redshift等の様々な分析基盤でもdbtは対応可能です
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く