Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アプリケーションエンジニアから強いデータエンジニアへの歩き方 / How to transit...
Search
yuuki takezawa
October 03, 2023
Programming
1
560
アプリケーションエンジニアから強いデータエンジニアへの歩き方 / How to transition and become a Data Engineer from an Application Engineer
データエンジニアってどんなことをするの?
どうするとうまくできそうなの?の話
yuuki takezawa
October 03, 2023
Tweet
Share
More Decks by yuuki takezawa
See All by yuuki takezawa
PHP ステートレス VS ステートフル 状態管理と並行性 / php-stateless-stateful
ytake
0
120
PHPでアクターモデルを理解・体験しよう / Understand and experience the actor model in PHP
ytake
2
260
再考 アクターモデル/ reconsider actor model
ytake
0
1.1k
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
430
Phluxorでアクターモデルを 理解・体験しよう / toolkit-for-flexible-actor-models-in-php-phluxor
ytake
1
270
オブジェクトのおしゃべり大失敗 メッセージングアンチパターン集 / messaging anti-pattern collection
ytake
2
1.1k
DRE/SREのプラクティス融合によるクラウドネイティブなデータ基盤作り / dre_sre
ytake
0
790
技術的負債と向き合う取り組みでよかったもの / positive_efforts_to_tackle_technical_debt
ytake
10
3.8k
入門 境界づけられたコンテキスト
ytake
6
4.2k
Other Decks in Programming
See All in Programming
クックパッド検索システム統合/Cookpad Search System Consolidation
giga811
0
190
コードを読んで理解するko build
bells17
1
120
kintone開発を効率化するためにチームで試した施策とその結果を大放出!
oguemon
0
380
Lambdaの監視、できてますか?Datadogを用いてLambdaを見守ろう
nealle
2
830
dbt Pythonモデルで実現するSnowflake活用術
trsnium
0
280
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta27
0
330
はじめての Go * WASM * OCR
sgash708
1
120
LINE messaging APIを使ってGoogleカレンダーと連携した予約ツールを作ってみた
takumakoike
0
140
「個人開発マネタイズ大全」が教えてくれたこと
bani24884
1
310
若手バックエンドエンジニアが Elasticsearch を使ってみた話
hott0mott0
1
100
Modern Angular with Signals and Signal StoreNew Rules for Your Architecture @bastacon 2025 in Frankfurt
manfredsteyer
PRO
0
130
Generating OpenAPI schema from serializers throughout the Rails stack - Kyobashi.rb #5
envek
1
440
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1.1k
Into the Great Unknown - MozCon
thekraken
35
1.7k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
KATA
mclloyd
29
14k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Building Your Own Lightsaber
phodgson
104
6.3k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
For a Future-Friendly Web
brad_frost
176
9.6k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Transcript
アプリケーションエンジニアから 強いデータエンジニアへの歩き方 ytake
データへの関わりのきっかけ - Apache HadoopやHBaseを通じてデータ処理を学ぶ - 分散処理に強いクエリエンジンやストリーム処理などを手がけ る - データからどこに問題がありそうか 予測できるようになり
解決のために自分で行動することが多くなる
これからのキャリアを考えたい 行動範囲を広げていきたい そんな方に
Agenda - データエンジニアってなにするの? - データエンジニアとして活動するための思考 - データエンジニアリングのための技術
データ基盤が必要なんだ でもなにをするものなのかわからない
データエンジニアとは - データ活用を前提にデータ収集や、管理、作成など データに関する基盤を作るエンジニア - データを元にアプリケーションに フィードバックをするなどもあり、 機械学習や一般的なアプリケーション作りも含まれる
データエンジニアへ - データ設計が好きなアプリケーションエンジニア - 自分がやりたいタイミングでデータを用意して 整備も自分でやりたいデータサイエンティスト - DB管理してるのインフラでしょ、やってよ
データエンジニアとは - データが整備されていないとなにもできないところから 整えていく - データの性質によって転送方法、加工方法が無数にある - 簡単なものか高難易度まで - データクレンジング
データ活用とは - 会社活動などにおける「意思決定」や「業務効率化」、 「マーケティング」などの向上に役立てるもの - どういうデータをエビデンスにしていけば良いか、 などは会社によって全く違うため、 何かを参考にすると活用ができるわけではない
データエンジニアをやるには - 事業・会社の課題を知る - 実際にデータを自分で見る、業務を知る - 今あるデータすらも信用しない
データエンジニアをやるには - まずは自分のために仮説検証ができるように - どこからデータがきているのか、どこが起点なのか - 自分が欲しいデータを見つける・見る・集約する
- 実装以外のやることが多い(兼務はおすすめしないです
誰かが教えてくれるわけではない 教えてくれても その人の視点だけでしかない
ドメインを噛み砕く
見つけ方が難しい! - どこからデータがきているのか、どこが起点なのか
イベントストーミング - どういうところでどういう事象が発生するのか - サービスにおけるイベントを見つけ出す - なぜなら データは事象のスナップショット
思考を鍛える - 自分が欲しいデータを見つける・見る・集約する 参考: https://www.ibm.com/docs/ja/spss-modeler/saas?topic=dm-crisp-help-overview
CRISP-DM - ビジネス課題の理解 - データの理解 - データの準備 - モデル作成 -
評価 - 共有
モデル作成・評価・共有 - DWHやデータマートなど - アプリケーションへフィードバックする仕組み - 機械学習 - 効果検証
データエンジニアもマインド必要なの? - データが揃った・揃ったら何がどうなりそうか、 これを意識して基盤作りなどをする必要がある - ただ持ってきただけだと、何を解決するためにあるのか 誰もわからない・使われない基盤になります
品質をあげる
データの品質を上げていく - 仕組みを作るだけではどうにもならない - データに関するリテラシーを上げていく - SREと同じくデータを軸にした品質向上活動をしていく - 一般的なアプリケーション開発とちょっと違う
すこし強くなる - 当事者意識を強く持つ - 今ないデータに価値がありそうか - 見えない範囲やネガティブなデータに価値がある - コミュニティを頼る(大事
今ないデータとは
生存バイアス - 装甲を厚くして撃墜されにくくする - 帰ってきた爆撃機のデータしかない、 撃墜されたものに価値がある - あるものだけに偏ってしまう - ちなみにこの図も仮説なので嘘の図
注意すること - ただのデータ抽出チームにならないこと - チームはエンジニアだけで閉じないこと - なんとなくやらない、しっかりと思想をもつ - うまくできなさそうな時は諦めること
注意すること - 97%は燃え尽きる - アプリケーションや業務フローで簡単に壊れるデータ パイプライン維持でほとんど終わってしまう - なぜ必要なのか、実現するためには文化と意識作り - 参考:
https://datadeveloperplatform.org/why_ddp_for_data/
なぜデータ基盤が必要なのか WHYが明らかになってからが最初の一歩
サイクルを回すための 実現可能な手法を習得
データ基盤ができてきた - データの取り出し方、保管の仕方、モデリングなど ドメインに合わせて最適化する - 全てSQLだけで済む、ということはあまりない - 共有するにはある程度加工が必須
ELT/ETL / そんなにフレッシュじゃない - 小難しい転送がなければdbt、Embulk、Glueなど - 転送に関して データの鮮度・更新頻度が高くないものは非常に簡単 - 鮮度がよくなるほど難しくなる
ELT/ETL / フレッシュ - イベントストーミングのイベント発生時から 保管すべきもの - Apache Kafka、Kinesisなど -
CDC(Change Data Capture)、ストリーミング処理少々 - 転送効率から選ぶことも
ELT/ETL / フレッシュ同士の結合 - Spark Streaming、Storm、Flinkなど - アプリケーション層に近いところまで寄ると マイクロサービスアーキテクチャと変わらなくなる -
アクターモデル導入
データ集約・抽出 - 静的なデータを全てGoogleに預けていい場合は BigQuery を軸に - AWSの場合はS3+Athenaが低コストで鉄板 - それらを包括したSnowflakeなど
データ加工・抽出 - 事業の課題やフィードバックの仕方によって様々 - BIツールは可視化に - レコメンデーションや自然言語処理の結果など データを利用できる様に 全文検索エンジンやワイドカラム対応の設計など
データを軸にしたプロダクトがあるのならば・・
連携システム グランドデザイン
連携システム グランドデザイン
まとめ - アプリケーションエンジニアと知識と技術 - データ分析のための思考 - パイプラインを作るためのインフラ知識 - データそのものをプロダクトとして考える
総合格闘技として様々な領域を鍛えていきましょう