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
550
アプリケーションエンジニアから強いデータエンジニアへの歩き方 / 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
110
PHPでアクターモデルを理解・体験しよう / Understand and experience the actor model in PHP
ytake
2
250
再考 アクターモデル/ reconsider actor model
ytake
0
1k
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
410
Phluxorでアクターモデルを 理解・体験しよう / toolkit-for-flexible-actor-models-in-php-phluxor
ytake
1
250
オブジェクトのおしゃべり大失敗 メッセージングアンチパターン集 / messaging anti-pattern collection
ytake
2
1.1k
DRE/SREのプラクティス融合によるクラウドネイティブなデータ基盤作り / dre_sre
ytake
0
770
技術的負債と向き合う取り組みでよかったもの / positive_efforts_to_tackle_technical_debt
ytake
10
3.8k
入門 境界づけられたコンテキスト
ytake
6
4.2k
Other Decks in Programming
See All in Programming
Rubyで始める関数型ドメインモデリング
shogo_tksk
0
120
pylint custom ruleで始めるレビュー自動化
shogoujiie
0
130
DROBEの生成AI活用事例 with AWS
ippey
0
140
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
280
Pulsar2 を雰囲気で使ってみよう
anoken
0
240
楽しく向き合う例外対応
okutsu
0
500
Ruby on cygwin 2025-02
fd0
0
150
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
180
コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」 / community-cdk-library
gotok365
2
180
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
210
Formの複雑さに立ち向かう
bmthd
1
890
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
130
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Speed Design
sergeychernyshev
27
800
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Optimizing for Happiness
mojombo
376
70k
Building Adaptive Systems
keathley
40
2.4k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
Practical Orchestrator
shlominoach
186
10k
RailsConf 2023
tenderlove
29
1k
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ツールは可視化に - レコメンデーションや自然言語処理の結果など データを利用できる様に 全文検索エンジンやワイドカラム対応の設計など
データを軸にしたプロダクトがあるのならば・・
連携システム グランドデザイン
連携システム グランドデザイン
まとめ - アプリケーションエンジニアと知識と技術 - データ分析のための思考 - パイプラインを作るためのインフラ知識 - データそのものをプロダクトとして考える
総合格闘技として様々な領域を鍛えていきましょう