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
530
アプリケーションエンジニアから強いデータエンジニアへの歩き方 / 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でアクターモデルを理解・体験しよう / Understand and experience the actor model in PHP
ytake
2
230
再考 アクターモデル/ reconsider actor model
ytake
0
900
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
370
Phluxorでアクターモデルを 理解・体験しよう / toolkit-for-flexible-actor-models-in-php-phluxor
ytake
1
240
オブジェクトのおしゃべり大失敗 メッセージングアンチパターン集 / messaging anti-pattern collection
ytake
2
1k
DRE/SREのプラクティス融合によるクラウドネイティブなデータ基盤作り / dre_sre
ytake
0
740
技術的負債と向き合う取り組みでよかったもの / positive_efforts_to_tackle_technical_debt
ytake
10
3.8k
入門 境界づけられたコンテキスト
ytake
6
4.1k
時間軸とドメインイベントとデータ処理
ytake
1
2.1k
Other Decks in Programming
See All in Programming
AWSのLambdaで PHPを動かす選択肢
rinchoku
2
360
PSR-15 はあなたのための ものではない? - phpcon2024
myamagishi
0
350
Compose UIテストを使った統合テスト
hiroaki404
0
120
テストコード書いてみませんか?
onopon
2
280
ATDDで素早く安定した デリバリを実現しよう!
tonnsama
1
730
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
6
1.3k
Внедряем бюджетирование, или Как сделать хорошо?
lamodatech
0
860
どうして手を動かすよりもチーム内のコードレビューを優先するべきなのか
okashoi
3
800
Оптимизируем производительность блока Казначейство
lamodatech
0
870
Fibonacci Function Gallery - Part 2
philipschwarz
PRO
0
200
見えないメモリを観測する: PHP 8.4 `pg_result_memory_size()` とSQL結果のメモリ管理
kentaroutakeda
0
880
iOS開発におけるCopilot For XcodeとCode Completion / copilot for xcode
fuyan777
1
1.1k
Featured
See All Featured
Bash Introduction
62gerente
609
210k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Rails Girls Zürich Keynote
gr2m
94
13k
Docker and Python
trallard
43
3.2k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
The Cult of Friendly URLs
andyhume
78
6.1k
Faster Mobile Websites
deanohume
305
30k
How STYLIGHT went responsive
nonsquared
96
5.3k
The Pragmatic Product Professional
lauravandoore
32
6.3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
850
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ツールは可視化に - レコメンデーションや自然言語処理の結果など データを利用できる様に 全文検索エンジンやワイドカラム対応の設計など
データを軸にしたプロダクトがあるのならば・・
連携システム グランドデザイン
連携システム グランドデザイン
まとめ - アプリケーションエンジニアと知識と技術 - データ分析のための思考 - パイプラインを作るためのインフラ知識 - データそのものをプロダクトとして考える
総合格闘技として様々な領域を鍛えていきましょう