はじめまして。デジタル庁ファクト&データユニット所属、データエンジニアの長谷川です。 本記事ではデジタル庁内でデータ活用を推進するための組織と分析基盤についてご紹介します。 これまでのデジタル庁noteと比べると、技術寄りの話題が多い記事となりますが、庁内のデータ活用に興味のある方はぜひご覧ください。 デジタル庁のデータ活用組織「ファクト&データユニット」ファクト&データユニットとはデジタル庁の特徴の一つに、デジタル分野において各種の専門性をもつ「民間専門人材」が多く所属していることが挙げられます。 民間の専門人材は、デザイン、プロダクトマネジメント、エンジニアリングなど、領域ごとに「ユニット」と呼ばれる組織を構成しており(参考:デジタル庁 - 組織情報)、必要に応じてさまざまなプロジェクトにアサインされて業務を遂行する、人材プールのような役割を果たしています。 ファクト&データユニットも
先人の知恵に学ぶ データエンジニア道で、本当に良かった!読み物を、不定期に追記していく。 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
ちょっと昔まではデータ基盤の管理人・アーキテクト, 現在は思いっきりクラウドアーキを扱うコンサルタントになったマンです. 私自身の経験・スキル・このブログに書いているコンテンツの関係で, 「データ基盤って何を使って作ればいいの?」的なHow(もしくはWhere)の相談. 「Googleのビッグクエリーってやつがいいと聞いたけど何ができるの?」的な個別のサービスに対するご相談. 「ぶっちゃけおいくらかかりますか💸」というHow much?な話. 有り難くもこのようなお話をよくお受けしています. が, (仕事以外の営みにおける)個人としては毎度同じ話をするのはまあまあ疲れるので, データ基盤にありがちな「何を使って作ればよいか?」という問いに対する処方箋 というテーマで, クラウド上でデータ基盤を構築する際のサービスの選び方 (データ基盤に限らず)クラウド料金の基本的な考え方 をGoogle
はじめに Modern Data Stack ? Modern Data Stack の特徴やメリット、関連するトレンド データインフラのクラウドサービス化 / Data infrastructure as a service データ連携サービスの発展 ELT! ELT! ELT! Reverse ETL テンプレート化された SQL and YAML などによるデータの管理 セマンティックレイヤーの凋落と Headless BI 計算フレームワーク (Computation Frameworks) 分析プロセスの民主化、データガバナンスとデータメッシュの試み プロダクト組み込み用データサービス リアルタイム Analytics Engineer の登場 各社ファウンダーが考える Modern Data Stack さいごに Further Readings はじめに Modern Dat
データ基盤グループの吉本です。 今回は先日開催されたdatatech-jp Casual Talksで登壇した内容について補足も含め紹介します。 datatech-jp.connpass.com 発表資料はこちらです。 データ基盤に関わる問い合わせ対応を仕組みで解決する from 株式会社MonotaRO Tech Team www.slideshare.net 発表内容の背景(問い合わせ対応における課題) 発表したこと 発表の反響 最後に datatech-jpは主にデータエンジニアリングやデータ活用に関わる方が参加するコミュニティで、DWHやデータマネジメント、データエンジニアリングに関わる技術、ツールなどについて知見を共有したり、輪読会やLT会のようなイベントを実施しています。 オーガナイザーとして同社同僚の吉田(id:syou6162)が参加しています。 その中でCasual
この記事は datatech-jp Advent Calendar 2023 3日目の記事です。 背景・趣旨 筆者(@yuzutas0)は風音屋(@Kazaneya_PR)という会社を経営しており、データ職種の採用・育成に関心を持っています。 複数企業で少ない専門家を奪い合って疲弊するような採用活動ではなく、マーケット全体がより豊かになるような動き方はできないだろうかと模索しています。 1つの実験として、MENTAで「第2新卒が3ヶ月でデータ職種への転職を目指す講座」というトレーニングを提供し、ありがたいことに30名以上の方々に受講いただきました。 ちなみにこの講座は今では風音屋の社内研修になっています。 MENTAの受講者が30名を突破しました🎉 卒業生が風音屋に入社したり、スキルアップして「社内で提案が通るようになった」「現職で活躍できるようになった」という感想もいただいています。
なぜいらないダッシュボードを作らないようにしなければならないのかいらないダッシュボードとは、作っても見返りがないか、見返りがあっても非常に少ないダッシュボードのことである。作っても最初から誰も見ていないのは論外であるが、そうでなくてもいらないダッシュボードがたくさんある。 作ったが最初だけで今は誰も見ていない 意思決定の役に立たない 作るのにとても手間がかかる 維持管理にコストがかかりすぎる いらないダッシュボードは作るのにリソースが必要になる。放っておけば邪魔になるので維持管理も必要だし、いらなくなったら後で削除すればいいと思ってもコミュニケーションの手間がかかる。 そしてこのいらないダッシュボードに費やした時間は何の価値も生まず、他にやるべきことに使えた時間を奪う。従って「いらないダッシュボードは作らない」に勝ることは無い。 ではどうしたらいらないダッシュボードを作らないようにできるの
さがらです。 11月8日20時~22時に、datatech-jp(データエンジニアリング関係のコミュニティ)主催でみんなの考えた最強のデータアーキテクチャというイベントが開催されました。 本記事はこのイベントのレポートブログとなります。 イベント概要 ※connpassより引用 datatech-jpで集ったデータエンジニアが、それぞれみんなの考えた最強のデータアーキテクチャを紹介し合うという夢のような企画が実現しました! たくさんの新しいプロダクトが群雄割拠する現在、モダンデータスタックなどという言葉も登場しています。 今こそ、どんなプロダクトを選び、どのようなデータ基盤を作れば、効率的にやりたいことが実現できるのか。 5人の猛者からおすすめの構成をご紹介いただきながら、参加者のみなさんとも一緒に考えていく時間としたいと思います。 おまけ:当イベントの応募者数 このイベントですが、なんと
こんにちは、データ基盤グループの吉田(id:syou6162)です。データ基盤やデータマネジメントに興味を持たれている方はDMBOKを持っている / 読んだことがあるという方も多いのではないでしょうか。このエントリではDMBOK中に紹介されているデータマネジメント成熟度アセスメント(以下、アセスメントと省略)をモノタロウでどう活用しているかについて紹介します。 背景 初手: 自社のデータ基盤の歴史を振り返る アセスメントの実施 データ活用者 / システム提供者 / 意思決定者へのヒアリングの実施 アセスメントを実施した結果 最後に 背景 まず、モノタロウでなぜアセスメントを行なったかについて説明します。モノタロウは20年以上歴史のある企業であり、データ基盤自体も10年以上の歴史があります。単一事業ではあるものの、受注 / 売上 / 商品 / 在庫 / 顧客 / 行動履歴など、対象となるドメ
# みんなの考えた最強のデータアーキテクチャ https://datatech-jp.connpass.com/event/258157/ ## イベント説明 datatech-jpで集ったデータエンジニアが、それぞれみんなの考えた最強のデータアーキテクチャを紹介し合うという夢のような企画が実現しました! たくさんの新しいプロダクトが群雄割拠する現在、モダンデータスタックなどという言葉も登場しています。 今こそ、どんなプロダクトを選び、どのようなデータ基盤を作れば、効率的にやりたいことが実現できるのか。 5人の猛者からおすすめの構成をご紹介いただきながら、参加者のみなさんとも一緒に考えていく時間としたいと思います。 ぜひ奮ってご参加ください! ## 発表概要 広告配信システムで発生する大量で多種多様のデータ。そして、人間の多種多様なデータへのニーズに耐えるために至ったデータアーキテクチャに
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。Yahoo!広告のデータマーケティングソリューション(以下、DMS)を開発しているデータアナリストの薄田です。 みなさんは、中間テーブル同士が複雑に絡み合い変更しようにも影響範囲を推定できず、手がつけられない分析パイプラインの保守で苦労された経験はないでしょうか? 私のチームでは数千行におよぶ分析用SQLをリファクタリングして、保守性と生産性を両立する分析パイプラインに生まれ変わらせることができました。 この記事ではリファクタリングを通して確立した、分析用SQLを構造化するための4原則を紹介します。4原則を意識しながらSQLを書くことで、高凝集・疎結合な分析パイプラインを作ることができます。 この記事では凝集度と結合度
こんにちは、佐々木です。年末に書こうと思って、すっかり忘れていた宿題です。 2022年末のre:InventのキーノートでAWSのCEOであるAdam Selipskyが、『A Zero ETL future』という概念が提唱しました。言わんとすることは解るのですが、これは一体どういう文脈で、なんのためなのだろうと疑問に思う方は多いと思います。そこで、自分なりにデータ分析を取り巻く現状と課題、ゼロETLの概念が出てきた理由をまとめてみます。これは私自身の思考なので、全然違う可能性が高いですので、悪しからず。 データ分析とETLの現状と課題 ゼロETLの話をする前に、データ分析とETLの現状の話をしましょう。データ分析をする際には、必ずデータが必要です。では、そのデータはどこからやってくるのか?単一のシステム内で分析する場合もありますが、多くの場合はいろいろなシステムから必要なデータを集めて
新年になったので今年のやりたいことをまとめようと思いたち筆をとっています。単にやりたいこと書いてもただのポエムになってしまうので、私が今時点で妄想している最強のデータ基盤を描いて、その中でまだ触ったことのない技術を今年触っていこうという意気込みを最後に書こうと思います(意気込みだけにならないように頑張りたいです!) まだ触ったことないものもあるので妄想しているレベルです。 アーキテクチャ図 まず最初に結論から書いていきます。 なぜこのアーキテクチャが最強と思うのか データ基盤として機能を分けると以下の6つの領域に分かれると思っています(もう少し細かく分けることもできたりします。例えばDMBOKとかではホイール図で11の領域に分けたりしています) データ基盤の領域 主に関連するDMBOKの知識領域 主担当
Analytics Engineerの吉田(id:syou6162)です。BigQueryを中心に10X社内のデータ関連の管理をしています。10Xに入社してそろそろ一年になろうかとしていますが、データ基盤を適切に管理 / 運用するためにSQLによる監視を少しずつ取り入れています。この記事では、具体的にどのようなSQLを書いて監視しているのか紹介したいと思います。 なお、SQLを使ったデータ基盤の監視自体については私の前職のTech Blogで詳細に書いていますので、そちらを参照してください。 SQLを使った監視でデータ基盤の品質を向上させる - MonotaRO Tech Blog データ管理に役立つメタデータに関する勉強会を社内外で開催しました - MonotaRO Tech Blog 本エントリはこれをベースに「dbtをフルに活用している10Xの環境向けに入れた監視」や「BigQuer
こんにちは。データエンジニアリングの支援を行っているstable株式会社の代表の宮﨑(@ikki_mz)です。弊社では、クライアント社内のデータウェアハウス(DWH)におけるデータモデリングをサポート...
For more than a decade now, the fact that people have a hard time gaining actionable insights from their data has been blamed on its size. “Your data is too big for your puny systems,” was the diagnosis, and the cure was to buy some new fancy technology that can handle massive scale. Of course, after the Big Data task force purchased all new tooling and migrated from Legacy systems, people found t
---------------------------------------------------------------------------------------- 【PR】一緒に働きましょう! https://kazaneya.com/kdec -------------------…
はじめに こんにちは。株式会社High Linkのデータユニットマネージャーの芦川 (@assy) です。 私たちのチームでは、データを強みとした事業価値創出を促進するために、データ基盤の整備やデータマネジメント、全社的なデータ利活用レベルの引き上げに取り組んでいます。 データマネジメントをしていると、「誰が作ったかわからない野良のテーブルが乱立している」ことや「BigQueryコンソール上でviewを定義してしまってコードレビューができない」さらには、「テーブル間の依存関係がわからず削除できない」といった課題にぶつかる方は多いんじゃないでしょうか。 私たちもまさにこのような問題に直面し、導入したのがdbtです。 今回は、dbtの導入に至る経緯や選定の理由、dbtをどう活用しているのかといった話を共有させて頂こうと思います。 私たちのようにデータマネジメントにがっつり人的リソースを割けない
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 本記事は、trocco® Advent Calendar 2023の9日目の記事になります。 trocco®だけを取り上げるわけではありませんが、この内容をおさえておくとその価値や使い方が理解しやすいと思いますし、もちろんユーザー以外でもデータエンジニアリング入門として読んでいただければと思います。 さて、私は今年の2月にtrocco®を提供する株式会社primeNumberに転職し、現在はtrocco®を利用したデータパイプライン/BIツールによるダッシュボード構築などを行っています。 前職は広告代理店でTableauを使っ
書き手:@takegue (分析チーム) Rettyのデータ活用の多くにはBigQueryが現在利用されており、その活用の方法についてこれまでこのブログでもいくつかとりあげさせていただきました。 engineer.retty.me そのほか分析チームの記事一覧 これらの記事はおかげさまで好評いただいております。いつもありがとうございます。 しかしながら、我々が初期からこのようにBigQueryを使い続けてきかというと、実はそうではありません。 事業の成長とともにデータ基盤を変化させてきた経緯があり、今の成果は過去のトライアンドエラーの賜物であり、数多くの苦労を背景にしてできあがっています。 ほんのつい最近まで、Rettyで構築されていたデータ基盤は表立って見える実態よりもかなり複雑なパイプラインで構成されていました(以降で触れますが、4種類のデータパイプラインが共存しているカオスな状態でし
最近読んだ、The Rise of Single-Node Processing: Challenging the Distributed-First Mindset という記事に最近考えていたことが書いてあったので便乗して自分の考えを書き留めておく。 元記事では、かつては大規模なデータの処理というと何はともあれ分散システムであり、Spark や BigQuery などを導入するのが当然であったが、近年は DuckDB や Polars など、シングルノードでも高速にテーブルデータを処理できる技術が登場してきたことで必ずしも分散システムは必要ではないよねという風潮に変わってきた、ということが述べられている。コスト面でもクラウドを使うのであれば、小さいインスタンスをいくつも立てて分散処理するのと、合計して同程度の vCPU や RAM を持つ一つの大きなインスタンスを立てて処理するのとで料金
データドリブンにプロダクトを改善していきたい、とはどんなプロダクトマネージャーでも志すことですが現実には上手く行かないこともあると思います。その時に、参考になる動画を見つけたので紹介します。 Product School のチャンネルで公開されている Webinar: Top 10 Digital Analytics Mistakes by Amplitude's Adam Greco and WillowTree's Jeremy Stern です。登壇者の Adam Greco さんは Amplitude という分析プラットフォームの Product Evangelist 、 Jeremy Stern さんは WillowTree というプロダクトでのデータ活用を支援するコンサルティングサービスの Director of Product Analysis を担当されています。動画の見ど
現在、IT系の仕事の中でデータアナリストは高い人気を博している。大手を含めて日本企業の大多数は情報活用が出来ていないので、データアナリストやその志望者にはブルーオーシャンが広がっているように見えるかもしれない。しかし、情報の分析・活用の現場で欠けているのはデータ分析のスキルではない。豊穣かつ正確なローデータ(分析用の生データ)の供給源となるべき「まともな基幹システム」である。 「いや、だからこそ分析基盤の整備から始める必要があるんです」とデータアナリストは語るかもしれない。そんな彼らにはあらためて"garbage in, garbage out"の格言を送りたい。garbage(ゴミ)を手間暇かけて整形しても、そこから得られる分析結果は「整形されたゴミ」でしかない。基幹システムがポンコツである限り、分析基盤をいかに充実させても効果は出ない。かつてビッグデータという言葉があったが、企業が抱え
SRE の鈴木 (id:eagletmt) です。先日、この開発者ブログで赤松から One Experience プロジェクトについての紹介がありました。 自分もこの One Experiene プロジェクトに携わっており、このプロジェクトが始まったちょうど1年くらい前にはイギリスにあるオフィスに行き、グローバル版のシステムを開発・運用しているメンバーと直接顔を合わせたりもしていました。自分は One Experience プロジェクトにおいて主にデータ移行について担当していました。データ移行に必要な作業はいくつかありますが、この記事ではその中から日本版のシステムのデータベースで発生したデータの変更をどのようにしてグローバル版のシステムのデータベースに継続的に反映したかの部分について紹介します。 One Experience でのデータ移行 赤松の記事にも書かれていたように、日本版とグロー
こんにちは。株式会社High Link で業務委託として働いている、データエンジニアのikki(@ikki_mz)です。 私たちデータチームでは、「データの民主化」を推進しており、全社員がデータ利活用を行えるように、dbtを用いた分析基盤の整備に取り組んでいます。 tech.high-link.co.jp データの民主化を推進していくにあたり、テーブル・カラムの説明文は非常に重要な役割を占めます。テーブルやカラムが何を意味しているかの説明は、分析をする上ではとても重要です。 しかし、このテーブルやカラムの説明はなかなか厄介で、データベースを開発した開発エンジニアとコミュニケーションをとらないと、説明文を正確に書くことができません。 そこで私たちは、dbt・スプレッドシートを使って、テーブルやカラムの説明文の入力をするという、組織横断的なプロジェクトを実施しました。 背景と課題 dbt de
整備したデータ基盤を、事業部や会社全体で活用に持っていく中で「データカタログ」の必要性が増々注目を集めています。 今回は、データカタログを導入し、データ利活用に挑んでいる6社に、アーキテクチャの工夫ポイントからデータカタログ導入によって得られた効果などを伺いました。 株式会社10X事業内容10Xでは「10xを創る」をミッションとし、小売向けECプラットフォーム「Stailer」の提供を通じて、スーパーやドラッグストア等のオンライン事業立ち上げ・運営支援を行っています。Stailerでは業務構築におけるコンサルティングから、必要な商品マスタやお客様アプリ・スタッフ向けのオペレーションシステム等の提供、配達システムの提供、販売促進の支援など、データを分析しながら一気通貫での支援を行っています。 データカタログ導入の背景以前はデータ分析にデータレイクのテーブルがよく利用されており、カラムのメタデ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く