データ収集の基本と「JapanTaxi」アプリにおける実践例
データ収集の基本として、データソース毎に典型的なデータ収集方法を整理して説明しています。またJapanTaxiアプリにおいてどのように実践しているかを説明しています。Read less
データ収集の基本として、データソース毎に典型的なデータ収集方法を整理して説明しています。またJapanTaxiアプリにおいてどのように実践しているかを説明しています。Read less
新しいデータ基盤アーキテクチャである「データレイクハウス」について調べてみた - Taste of Tech Topics
最近ソーダストリームを買い、炭酸水を飲むのにはまってます。機械学習エンジニアの@yktm31です。 以前に「AWS Lake Formationでデータレイク体験！」という記事を書いてみて、データ基盤アーキテクチャに興味が湧いてきました。 データレイクハウスは、「データウェアハウス」と「データレイク」を統合したようなアーキテクチャで、 2020年にDatabricks社により提唱され、新しいデータ基盤アーキテクチャとして注目されているようです。 www.databricks.com そこで今回、「データレイクハウス」について調べてみたことをまとめてみたいと思います。 なぜデータレイクハウスが注目されているのか？ データウェアハウスの特徴・課題 データレイクの特徴・課題 データレイクハウスの特徴 データレイクハウスのアーキテクチャ Azure Azure Synapse Analyticsを
リーガルテック領域のリーディングカンパニーである株式会社LegalForceが、「検索インフラTechTalk!」を開催しました。インフラ領域の中でも「検索インフラ」にフォーカスした今回は、検索インフラに関する具体的な事例や取り組みについて各スピーカーから発表がありました。野口真吾氏は、AWSを用いたデータレイクの基礎について紹介しました。 企業規模に関係なく起こるデータのサイロ化 野口真吾氏（以下、野口）：みなさんこんばんは。本日は「検索インフラ Tech Talk!」ということで、検索インフラから少し広げた話題にはなるんですが、「AWSを用いたデータレイクの基礎」というお話をします。よろしくお願いします。 最初に簡単に自己紹介します。アマゾンウェブサービスジャパンでスタートアップ担当のソリューションアーキテクトをしている野口真吾と申します。Twitterでは＠nogというIDを使って活
Data Platform Guide - 事業を成長させるデータ基盤を作るには #DataEngineeringStudy / 20200715
Data Engineering Study #1 の発表資料です。 https://forkwell.connpass.com/event/179786/ 当日の動画はYoutubeで閲覧可能です。 https://www.youtube.com/watch?v=hFYNuuAaiTg 参考文献 『Software Design (ソフトウェアデザイン) 2020年7月号』 https://amzn.to/30YueL7 『データマネジメントが30分でわかる本』 https://amzn.to/3fmz8Gw
「AWSではじめるデータレイク」出版記念データレイク解説セミナーの資料公開 | Amazon Web Services
Amazon Web Services ブログ 「AWSではじめるデータレイク」出版記念データレイク解説セミナーの資料公開 去年よりAWSのメンバー４名（志村、上原、関山、下佐粉）でデータレイクの基礎からアーキテクチャ、構築、運用管理までをカバーした書籍「AWSではじめるデータレイク」を執筆してきたのですが、7月出版の目処がたったことを記念して、5月末から毎週木曜にデータレイクに関するWebセミナーを開催してきました。 幸いにも大変多くの方にご参加いただくことができました。ご参加いただいた方にはあらためてお礼申し上げます。 一方で、以前の回に出られなかったので資料だけでも公開して欲しい、というご要望をたくさん頂いていました。そこで今回第1回から第3回の資料を公開させていただく事になりました。 ※ 2020/06/25更新：第4回の資料を追加公開しました 以下よりご覧いただけます。(PDFフ
Data Engineering Study #2「データ収集基盤とデータ整備のこれまでとこれから」https://forkwell.connpass.com/event/182769/ 作成者 ：しんゆう＠データ分析とインテリジェンス Twitter：https://twitter.com/data_analyst_
はじめに 環境情報 Delta Lake (デルタレイク) とは Delta Lake の実体 Delta Lake の構造 Parquet と Delta の相違点 Parquetとは何か Parquetの構造 Parquet と Delta の違い Delta Lake が生まれた経緯: データレイクと Delta Lake の違い データレイクのメリット データレイクの課題 *Parquetで構築した場合 Delta Lake の特徴 ACIDトランザクションの担保 スケーラブルなメタデータ管理 バッチとストリーミングワークロードの統合 タイムトラベル (バージョン管理) CONSTRAINT句のサポート DML (データ操作言語) のフルサポート UPDATE DELETE MERGE 柔軟なスキーマ管理 1. スキーマ エンフォースメント 2. スキーマ エボリューション ストレ
こんにちは、今年の1月に会員事業部から技術部データ基盤グループへ異動した佐藤です。先日、京まふ2019前夜祭イベントに参加するために人生で初めてピカピカ光る棒を買いました。 新卒で入社してから2年ほど分析作業をしていた身から、データ活用基盤を作る側へ立場を変えました。今回は新たに身を移したデータ活用基盤の外観を説明したいと思います。 2017年にも同内容の記事が投稿されていますので、当時との違いを中心に説明していきます。 外観図 以下が2019年10月現在におけるクックパッドのデータ活用基盤の全体像です。 クックパッドのDWH外観図 masterデータのインポートがMySQL以外にも複数種対応し始めたことと、PrismとSpectrum（S3＋Glue）周りと、Tableau Serverが大きな変更点となっています。2017年の図にDmemoはありませんでしたが、記事本文にある通り当時か
こんにちは佐々木です。 誰に望まれた訳でもないですが、データ分析基盤の設計シリーズの第三弾です。今回のテーマは、データ分析基盤における個人情報＆パーソナルデータの扱いについてです。ここを最初に考えておかないと、データ分析基盤は毒入りとなって、扱いづらいものになります。 データ分析基盤構築の肝は、データレイクとDWHの分離 - NRIネットコムBlog データレイクはRAWデータレイク・中間データレイク・構造化データレイクの３層構造にすると良い - NRIネットコムBlog 個人情報＆パーソナルデータと匿名加工について まず最初に個人情報＆パーソナルデータの定義と匿名加工について、サラッと確認しておきましょう。 個人情報＆パーソナルデータ 個人情報とは、任意の一個人に関する情報であり、かつその情報をもとに個人を特定できるものを指します。代表的な個人情報としては、名前・住所・電話番号・E-ma
データ基盤のメタデータを継続的に管理できる仕組みを作る - Hatena Developer Blog
こんにちは。MackerelチームでCRE(Customer Reliability Engineer)をしているid:syou6162です。 CREチームではカスタマーサクセスを進めるため、最近データ分析により力を入れています(参考1, 参考2)。データ分析を正確に行なうためには、データに関する正確な知識が必要です。今回はより正確なデータ分析を支えるためのメタデータを継続的に管理する仕組みについて書いてみます。 データに対する知識: メタデータ データ分析を正確に行なうためには、データ自身に関する知識(=メタデータ)が必要です。例えば、Mackerelのデータ分析タスクでは以下のような知識が必要とされることが多いです。 このテーブル / カラムは何のためのテーブルなのか 似たようなカラムとの違い 集計条件の違い、など データがどのような値を取り得るか SELECT column, COU
2021年3月18日に実施したデータ活用ウェビナーの登壇資料 データ分析基盤を作る上での設計のポイントと、AWSのサービス選定について
こんにちは佐々木です。 いろいろなところで口を酸っぱくして言っているのは、データレイクとDWHを分離しろと。とりあえずDWHに放り込むという考えはあるけど、DWHに入れる時点でデータの整形が行われて、情報の欠損がでてくる。だから、その前にデータレイクに生のままに入れること— Takuro SASAKI (@dkfj) 2021年5月1日 データレイクとDWHの分離について呟いたら、それなりの反響を頂きました。せっかくの機会なので、もう少ししっかりと解説してみます。何故、データレイクとDWHを分離する必要があるのか、格納するデータの構造と、データレイク・DWHの役割の観点から考えてみましょう。まずは、データの種類として、構造化データや非構造化データの説明をします。その次に、データレイクとDWHなどの用語・役割の説明をし、最後にアーキテクチャを考えてみます。 構造化データと半構造化データ、非構
ぼくのかんがえる最高のレポーティング基盤 @AWSで実践！Analytics modernization
VOYAGE GROUP Zucks DSPレポーティング基盤をどのようにして作ったかの話。 https://pages.awscloud.com/JAPAN-event-OE-20210624-AnalyticsModernization-reg-event.html ディメンションモデリング https://zenn.dev/pei0804/articles/dimensional-modeling スタースキーマ（基礎） https://zenn.dev/pei0804/articles/star-schema-design 複数スタースキーマ https://zenn.dev/pei0804/articles/multiple-star-schema ファン・トラップ https://zenn.dev/pei0804/articles/datawarehouse-fan-trap
書き手：@takegue (分析チーム) Rettyのデータ活用の多くにはBigQueryが現在利用されており、その活用の方法についてこれまでこのブログでもいくつかとりあげさせていただきました。 engineer.retty.me そのほか分析チームの記事一覧 これらの記事はおかげさまで好評いただいております。いつもありがとうございます。 しかしながら、我々が初期からこのようにBigQueryを使い続けてきかというと、実はそうではありません。 事業の成長とともにデータ基盤を変化させてきた経緯があり、今の成果は過去のトライアンドエラーの賜物であり、数多くの苦労を背景にしてできあがっています。 ほんのつい最近まで、Rettyで構築されていたデータ基盤は表立って見える実態よりもかなり複雑なパイプラインで構成されていました（以降で触れますが、4種類のデータパイプラインが共存しているカオスな状態でし
こんにちは、データ基盤の開発、運用をしていた谷口（case-k）です。最近は配信基盤の開発と運用をしています。 ZOZOではオンプレやクラウドにあるデータをBigQueryへ連携し、分析やシステムで活用しています。BigQueryに連携されたテーブルは共通データ基盤として全社的に利用されています。 共通データ基盤は随分前に作られたこともあり、様々な負債を抱えていました。負債を解消しようにも利用者が約300人以上おり、影響範囲が大きく改善したくても改善できずにいました。 本記事では旧データ基盤の課題や新データ基盤の紹介に加え、どのようにリプレイスを進めたかご紹介します。同じような課題を抱えている方や新しくデータ基盤を作ろうとしている方の参考になると嬉しいです。 データ基盤の紹介 旧データ基盤の紹介 旧データ基盤の課題 変更があっても更新されないデータ 性質の異なるテーブルを同じ命名規則で管理
Data Platform Meetup の登壇資料です。 https://data-platform-meetup.connpass.com/event/142822/
はじめに この記事はklis Advent Calendar 2019の22日目の記事です。 この記事では「図書館情報学という学問が大学の外の世界でどのように活用できるか」というのをIT系の企業で働いている実体験込みでつらつら書いていこうかなと思います。 この記事の目的は図書館情報学を学んでいる学生の方や、図書館情報学にちょっと興味のある方に対して、ちょっとお先に社会に出ている立場から「（司書にならなくても!）図書館情報学は社会で役に立つので頑張って学んでください！」という応援をすることです。*1 この記事の最後に、学問一般を学ぶことの意義にもちょっと触れてます。 何者？ 簡単に自己紹介しておきたいと思います。 自分は2011年に入学したklis11の卒業生で、卒業後5年くらい立った社会人です。（大学院含めると社会人歴3年くらい） 大学院卒業後は新卒でデータ解析職として人材系の会社に入社し
はじめに 昨今Webに限らずあらゆる事業領域において、蓄積されたデータの活用は必要不可欠、やっていて当たり前なものになってきているかと思います。これまでこのブログではあまりそういう話題に触れてこなかったこともあり、本稿では改めてドワンゴ教育サービスにおけるデータの活用に関する取り組みについて、概要レベルにはなりますがご紹介したいと思います。 はじめに N予備校における従来のデータの取り扱い 現在の取り組み 本番環境のデータのBigQueryへの蓄積 データ活用のプロトタイピング そのほかのデータ活用に関連する取り組みや展望 N予備校のアーキテクチャ・パイプラインの検討 分析対象のデータ拡充 データの管理体制 機械学習技術等の活用 おわりに We are hiring! N予備校における従来のデータの取り扱い まず従来から行われているN予備校におけるデータ活用の取り組みについて紹介します。現
第16回日本統計学会春季集会での発表資料です。 https://confit.atlas.jp/guide/event/tjss2022spring/top https://ies.keio.ac.jp/events/17173/ 講義や共同研究のご相談はブログのお問い合わせ欄にご連絡ください。 https://yuzutas0.hatenablog.com/
こんにちは。業務委託として SRE チームのお手伝いをしている @syucream です。 本記事では Repro にて開発した、 Go 製のカラムナフォーマットへのデータ変換ツール columnify について、開発背景や技術的な取り組みを紹介します。 なぜカラムナフォーマットか？ ことのおこり 事業がスケールすると共に扱うログの量が増えることは、喜ばしい反面さまざまな悩みをもたらします。その中でも顕著なものの一つとしてコストの問題が挙げられます。 膨大なログデータはログに対するストレージ料金を増大させると共に、分析や可視化に際してクエリで求められるコンピュートのコストも無視できなくなっていきます。 近頃 Repro でもコンテナのログの管理においてこの問題が顕著になってきました。Repro のバックエンドシステムは ECS 上のコンテナで実現され、ログの閲覧・管理のため外部のログ収集サ
AWS データレイク事例祭り 登壇資料です。
というのをチームで議論する機会があったので、書いてみます。「うちではこうしている」とか「ここはこっちのほうがいいんじゃない?」とかあったらコメントで教えてください。 背景 / 前提 データウェアハウスのテーブルを社内に広く提供したい 初期の提供時期が過ぎてしばらくすると、要望を元にスキーマの変更や集計ロジックの変更が入る (事前にレビューはもちろんするが)SQLのミスなどで以前のバージョンに戻したいといったことがありえる 他の部門では新しいバージョンをすでに使っていて、気軽に戻せないこともある データウェアハウスのバージョンを場面に応じて複数提供できると都合がよい 一方で、大多数のデータウェアハウスのユーザーは最新バージョンの利用だけでよいはず SSOT(Single Source of Truth)になっていて欲しいわけなので... 複数バージョン見えていると「どのバージョンを使えばいい
S3データレイクをAWSの分析サービスを使って有効活用する #AWS-06 #AWSSummit | DevelopersIO
本記事は、AWS Summit Japan 2021のセッション動画、「AWS-06: 貯めるだけじゃもったいない！AWS 分析サービスを使ったデータレイクの有効活用」のレポート記事です。 「データはとりあえずS3に溜めておけ！」とデータレイクっぽいものは作れたけど上手く使いこなせていない方、それなりにいらっしゃるのではないでしょうか？本セッションでぜひAWSの分析サービスの活用術をおさらいしてみてください。 概要 データの持つ力を活かす方法としてデータレイクがありますが、データレイク上にデータは貯まってきたものの、どう有効活用すればいいか悩んだ経験はないでしょうか？データレイクに存在するデータと分析ツールと組合せ、活用する方法として、“レイクハウスアプローチ”があります。本セッションでは"レイクハウスアプローチ"の考え方を紹介すると共に、どのようなAWSサービスを用いて"レイクハウスアプ
2021/12/10に開催された TechMarketing Conference 2021 # データマネジメント #techmar での講演資料です。 https://techxmarketing.connpass.com/event/229173/ Read less
実装方法 冪等性を担保したGoogle Cloud Composerの設計と実装で紹介しているとおり、Luupのデータ基盤はGoogle Cloud Composerを軸に動いています。なので今回も、Google Cloud Composerの環境下に作りました。 アウトプットイメージは以下です。 以下のNotion APIのDocumentを参考に実装を進めていきます。 サンプルコードも豊富で、説明も丁寧なので簡単に実装できました。 以下、コード一例です。 # Notionのフォーマットに変換するメソッド def format_standard_property_value(self, property_name: str, value: str): if property_name == "title": return {"title": [{"text": {"content": v
GMOペパボ株式会社では主にGoogle Cloud Platformのサービスを利用してデータ分析基盤を構築し運用しています。その中心となるのがデータウェアハウスのBigQueryとワークフローエンジンのCloud Composerです。また、社内向けのデータ可視化(ダッシュボード)システムではCloud Runを利用しています。 データ分析基盤から得られる情報を重要な意思決定に用いるためには、ユーザーに提供しているインフラと同様に、可用性を明らかにし、継続的に可用性を高める Realiability エンジニアリングが必要となります。本講演ではGCPで構築されているデータ分析基盤を題材として、データ分析基盤に求められる可用性や、小規模なチームにおけるオブザーバビリティへの取り組みについてご紹介します。
はじめに Baikal について Baikal を支える技術と工夫 AWS アカウント Terraform ワークフロー基盤 Athena Lake Formation アーキテクチャ Extract & Load データ生成元 AWS アカウントにある RDS からデータ抽出 データ生成元 AWS アカウントにある DynamoDB からデータ抽出 社外の API からデータ抽出 Transform workspace に配置されたデータの変換 データ生成元 AWS アカウント内の生ログ変換 ウェアハウス内での加工 Share 今後の課題 開発の一部を他チームへの委譲 データ異常検知 BI ツールの導入 はじめに DRE チームの hyamamoto です。 新卒の方々が入社されて 4 ヶ月ということで、時の流れの速さを感じています*1。なお、現在、新卒の方々でリレー方式でブログを書いて
マーケター自身がデータを管理するために、広告運用にdbtを導入した経緯と効果 - MonotaRO Tech Blog
こんにちは、マーケティング部門広告グループの小林です。この記事ではオンライン広告運用に使っているデータ変換処理をdbtに移行した過程と得られた効果についてご紹介します。 モノタロウでは、全社的なデータ活用研修などにより、マーケティングのようなビジネス系の部署でも、SQLを自身で書いてデータ抽出を行い、数字に基づいた意思決定を行っています。その一方で、集計後の数値のズレやドメイン固有のデータの品質管理など、活用が進んだ企業ならではの課題というのも表面化してくるようになってきました。 オンライン広告運用においては、投下した費用など配信実績のレポーティング、広告媒体へのデータ送信などのいわゆるELTを安定的に回す仕組みが必要になりますが、処理の自動化やデータの品質まで求められるようになると、「データが抽出できる」だけでは限界が見えてきていました。そこで今回、マーケター自身がデータを管理する立場に
こんにちは佐藤です。 今回はサービスのデータ分析基盤を作成する際に使用したDataformについて紹介させていただきます。 背景 Dataformについて 導入して良かったこと 依存関係がわかりやすい クエリのテスト 工夫した点 フォルダの構成について データセット名、テーブル名について シャーディングテーブルの定義について 最後に 背景 現在、広告部署に所属する私たちのチームは自社のサービスデータと外部データを分析してユーザーの利用率向上につながる仮説検証をおこなうプロジェクトを進めています。 その中で様々なデータをTableauを用いて分析しており、データソースとして主にBigQueryを使用しているのですが、現状、分析データの加工、集計処理についてBigQueryのスケジュールされたクエリで作成したりtableau側のカスタムクエリで作成したりと対応方法がバラバラで管理自体ができてい
分析基盤へのデータ連携処理をEmbulkからAmazon Aurora S3 Export機能に切り替えた話 - BASEプロダクトチームブログ
はじめに こんにちは！Data Platformチームでデータエンジニアとして働いている @shota.imazeki です。 分析基盤の構築・運用などの側面から社内のデータ活用の促進を行っています。 BASEではAurora MySQLにあるデータをEmbulkを用いてBigQueryに連携しています。BigQueryへ連携されたデータは分析基盤としてLookerなどを通して社内利用されています。 このデータ連携処理にはいくつかの課題があり、それを解決するためにEmbulkからAurora S3 Export機能を用いた連携処理に切り替えることにしましたので、それについて紹介していきたいと思います。 ※この切り替えについては現状、試験的に一部のDBのみの切り替えとなっていますが、運用上の大きな課題が出てこなければ徐々に切り替えていく予定です。 切替前のデータ連携処理 先述した通り、BAS
こんにちは、データエンジニアの石井です。 先日公開した記事「社内向けのデータ基盤から集計結果をReverse ETLしてサービスに組み込んだ話」で、ダッシュボード機能のリリースにより、Classiのデータ基盤が「社内用データ基盤」から「ユーザー影響あるシステムの一部」へ進化した話をしました。「ユーザー影響あるシステムの一部」への進化に伴い、データ基盤の品質担保は必要不可欠です。今回は、データ基盤の品質向上に取り組んだKANTプロジェクトについてご紹介します。 KANTプロジェクト 背景・課題 Classiのデータ基盤がユーザー影響あるシステムの一部になる前、つまり社内用データ基盤だった頃には以下のような課題がありました。 データ基盤の状態把握 マルチクラウドにおけるデータ基盤全体の状態把握ができていなかった データ基盤の実行状態（SUCCESS, FAIL, RUNNINGなど）の把握が、
AWS Outpostsで実現するオンプレデータレイク - NTT Communications Engineers' Blog
はじめに こんにちは、イノベーションセンターの鈴ヶ嶺です。普段はクラウドサービスをオンプレ環境でも同様のUI/UXで使用を可能とするハイブリッドクラウド製品の技術検証をしています。 NTT Comでは以下の過去の記事のように、AWSのハイブリッドクラウドソリューションAWS Outposts ラックの導入や技術検証を進めています。 engineers.ntt.com engineers.ntt.com engineers.ntt.com 本記事では、AWS Outpostsで実現するオンプレ環境におけるデータレイクのユースケースについて紹介します。 データレイクとは構造化データ、非構造化データに関わらず全てのデータを一元的に保存可能なストレージを意味しています。 このユースケースにより、低遅延性が求められる、もしくは秘匿性の高い大規模なデータをオンプレ環境で一元的に取り扱うことが可能となり
[レポート] モダンデータウェアハウスにおける「キンボール」〜残す価値のあるもの、ないもの #dbtcoalesce | DevelopersIO
[レポート] モダンデータウェアハウスにおける「キンボール」〜残す価値のあるもの、ないもの #dbtcoalesce 大阪オフィスの玉井です。 2020年12月7日〜11日の間、Fishtown Analytics社がcoalesceというオンラインイベントを開催していました（SQLを触っている方はピンとくるイベント名ではないでしょうか）。 「Fishtown Analytics社って何やってる会社？」という感じですが、dbtというツールを開発しているベンダーです。dbtについては、下記をご覧ください。 今回は、その中からKimball in the context of the modern data warehouse: what's worth keeping, and what's notというセッションを受講したので、レポートを記します。 イベント概要 公式 Kimball in
![[レポート] モダンデータウェアハウスにおける「キンボール」〜残す価値のあるもの、ないもの #dbtcoalesce | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/85281d1589a19c5d28bff75bb55314b9cd7de5f4/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F12%2FCoalesce_2020_online_-_December_7-11__2020.png)
データアナリティクス事業本部の鈴木です。 自分がデータ分析基盤の技術調査をする際、こういうことに気をつけるとうまく行きやすいなというポイントがまとまってきたので、ブログにしてみました。 あくまで1例として参考になればと考えています。 課題意識 ほかのメンバーで、技術調査に慣れていない方に調査をお願いするとき、初めはある程度やり方を説明したり、レビューを手厚くしたりすると思います。私が初めて技術調査をしたときは、やり方が分からず、先輩にかなりお世話になったことを覚えています。 最近では、私からほかのメンバーに調査をお願いをする側になる場面が少しづつ出てきたので、「お願いしたいことはある程度ブログにしておいた方が、聞く方が言われたことを全部覚えてなくていいし、絶対ええやろな〜」と思い、記事にしてみました。 場面としてはデータ分析基盤を構築する上で必要になる技術調査を想定しています。 技術調査の
訳者まえがき 原著者の Chris Riccomini の許可を得て以下の記事を翻訳・公開しました。 riccomini.name 下記より記事翻訳本文です。 データエンジニアリングの未来 私は最近、近頃のデータエンジニアリングがこれまで来た道について、また、この分野の仕事の将来について考えてきました。考えのほとんどは、私たちのチームが WePay で実践していることを背景にしています。その一方、以下に述べる考えは普遍的で、共有する価値があるものと思っています。 データエンジニアリングの仕事は、組織におけるデータの移動と処理を支援することです。これには、一般的に、データパイプラインとデータウェアハウスという2つの異なるシステムが必要です。データパイプラインはデータの移動を担当し、データウェアハウスはデータの処理を担当します。これは、やや過度に単純化しています。バッチ処理とストリーム処理では
スタディサプリでのBigQuery移管と実践的活用術 / meetup_kittaka
2022/01/27_スタディサプリのデータ基盤を支える技術 2022 －RECRUIT TECH MEET UP #3－での、橘高の講演資料になります
この記事について最近発売された『チームトポロジー』（以後、本書）を読んだのですが、チーム体制やコミュニケーションの設計について汎用的にまとめられていてとても良い読書体験でした。私自身、データ組織をどのように設計していくか日頃考えており、本書を読み進めながら、考えが構造化され、課題の解像度が高まった気がします。 現在、私は株式会社エウレカで、BIチーム（分析チーム）、AIチーム、Data Managementチーム（データ基盤チーム）、の3チームのマネジメントをしています。日々生まれるデータを価値に転換し、同時にプライバシーやセキュリティなどのガバナンスを徹底するために、全社的なデータ戦略を推進していく立場です。大雑把に「データ活用」と括ってしまいましたが、意思決定をサポートするのための活動（BI）、ユーザー向けの機能開発を伴う活動（AI）、それらの活動を効率よく進めるための活動（Data
Apache ArrowのPMC（Project Management Commitee、プロジェクト管理チームみたいな感じ）のメンバーの須藤です。 みなさんはApache Arrowを知っていますか？最近、ついに1.0.0がリリースされたんですよ。私がApache Arrowの最新情報をまとめた2018年9月から毎年「今年中に1.0.0がでるぞ！」と言っていた1.0.0がついにリリースされたんです！ 1.0.0を機に安心して使えるようになります。（どう安心なのかは後で説明します。） Apache Arrowはすでにデータ処理界隈で重要なコンポーネントになりつつありますが、数年後にはもっと重要になっているだろうプロジェクトです。データ処理界隈に興味がある人は知っておくと役に立つはずなので毎年Apache Arrowの最新情報をまとめています。1.0.0がリリースされたので2020年7月現在
タクシーアプリ「GO」、法人向けサービス「GO BUSINESS」、タクシーデリバリーアプリ「GO Dine」の分析基盤を開発運用している伊田です。本番DBから分析基盤への連携処理を改善した事例を紹介します。※ 本記事の対象読者はETLツールを利用している方を対象にしています はじめに本記事では、タクシーアプリ「GO」の DB から分析基盤への同期処理を約7時間から約10分に改善した事例を紹介します。まず、既存の処理および改善前の状況を説明し、次に改善にあたり実施した分析、その分析をもとにチーム内で実施した議論を経て、最終的にどのような実装を行ったのか紹介させて頂きます。 同期処理についてGO の DB は Cloud SQL 上で構築されており、分析基盤への同期処理は GKE 上で Embulk を起動し、リードレプリカに対してクエリを投げて一度 GCS に結果を格納します。その後、GC
アクティブメタデータの所感｜Rytm / Quollio
冒頭2022年現在、データ界隈で良く聞く概念の一つに、Active Metadataがある。最も、日本では未だ広く浸透していない概念ではあるが、北米ではData MeshやData Fablic、Metrics Layer等のバズワード(?)と同じように界隈を賑わしているものであり、こと ”データが資源” である21世紀の企業経営においては（現時点で少なくとも北米においては）最重要トピックの一つであると言って過言でない。 本日は、データの最前線を賑わしているアクティブメタデータについて、まだ日本語での記事も多くないので、思うところを書いてみることにした。 背景ときっかけ既にご存知の方も多いと思うが；象徴となったのは、Gartner社が2021年8月にMagic Quadrant for Metadata Managementの廃止を宣言し、代わりに Market Guide for Act
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSで“データのサイロ化”を防げ すべてのデータを1ヶ所に集めるデータレイクの作り方
事業に貢献するデータ基盤を作ろう・考え方編 / data_engineering_study_2
Delta Lake とは何か - connecting the dots
データ活用基盤の今 〜DWH外観図〜 - クックパッド開発者ブログ
データ分析基盤における個人情報の扱いについて - NRIネットコムBlog
AWSで作るデータ分析基盤サービスの選定と設計のポイント
データ分析基盤構築の肝は、データレイクとDWHの分離 - NRIネットコムBlog
Rettyのデータ基盤の歴史と統合 - Retty Tech Blog
全社共通データ基盤を廃止して新しいデータ基盤に引越した話 - ZOZO TECH BLOG
データレイク構築後の四方山話 #DPM / 20190905
大学で学んだ図書館情報学で食いっぱぐれずに済んでいる話 - oscillographの日記
N予備校のデータ分析基盤構築に向けた取り組み - ドワンゴ教育サービス開発者ブログ
民間企業におけるデータ整備の課題と工夫 / 20220305
軽量な Go 製カラムナフォーマット変換ツール columnify を作った話 - Repro Tech Blog
AWS データレイク事例祭り 登壇資料
データウェアハウスのバージョン管理をどうやるか - yasuhisa's blog
事業の進展とデータマネジメント体制の進歩（＋プレトタイプの話）
データカタログにNotionを選択した理由
データ分析基盤におけるオブザーバビリティの取り組み
Gunosy のデータ活用を支える統合データ基盤 Baikal の話 - Gunosy Tech Blog
Dataformでデータ分析基盤を整備した話 - Adwaysエンジニアブログ
データ基盤の品質向上への取り組み - Classi開発者ブログ
私流・データ分析基盤の技術調査のコツを整理してみた | DevelopersIO
(翻訳) データエンジニアリングの未来 - satoshihirose.log
データ組織のトポロジー｜Jun Ernesto Okumura
Apache Arrowの最新情報（2020年7月版） - 2020-07-31 - ククログ
分析基盤へのデータ同期を約40倍早くしてみた | MoT Lab (GO Inc. Engineering Blog)
www.soundhouse.co.jp
www.sankei.com
forbesjapan.com
kazarihisa.wixsite.com
www.reuters.com
www.sankei.com