アプリケーションエンジニアから強いデータエンジニアへの歩き方 / How to transition and become a Data Engineer from an Application Engineer

データエンジニアってどんなことをするの？
どうするとうまくできそうなの？の話

Transcript

1. アプリケーションエンジニアから 強いデータエンジニアへの歩き方 ytake
2. データへの関わりのきっかけ - Apache HadoopやHBaseを通じてデータ処理を学ぶ - 分散処理に強いクエリエンジンやストリーム処理などを手がけ る - データからどこに問題がありそうか 予測できるようになり 解決のために自分で行動することが多くなる
3. これからのキャリアを考えたい 行動範囲を広げていきたい そんな方に
4. Agenda - データエンジニアってなにするの？ - データエンジニアとして活動するための思考 - データエンジニアリングのための技術
5. データ基盤が必要なんだ でもなにをするものなのかわからない
6. データエンジニアとは - データ活用を前提にデータ収集や、管理、作成など データに関する基盤を作るエンジニア - データを元にアプリケーションに フィードバックをするなどもあり、 機械学習や一般的なアプリケーション作りも含まれる
7. データエンジニアへ - データ設計が好きなアプリケーションエンジニア - 自分がやりたいタイミングでデータを用意して 整備も自分でやりたいデータサイエンティスト - DB管理してるのインフラでしょ、やってよ
8. データエンジニアとは - データが整備されていないとなにもできないところから 整えていく - データの性質によって転送方法、加工方法が無数にある - 簡単なものか高難易度まで - データクレンジング
9. データ活用とは - 会社活動などにおける「意思決定」や「業務効率化」、 「マーケティング」などの向上に役立てるもの - どういうデータをエビデンスにしていけば良いか、 などは会社によって全く違うため、 何かを参考にすると活用ができるわけではない
10. データエンジニアをやるには - 事業・会社の課題を知る - 実際にデータを自分で見る、業務を知る - 今あるデータすらも信用しない
11. データエンジニアをやるには - まずは自分のために仮説検証ができるように - どこからデータがきているのか、どこが起点なのか - 自分が欲しいデータを見つける・見る・集約する
12. - 実装以外のやることが多い(兼務はおすすめしないです
13. 誰かが教えてくれるわけではない 教えてくれても その人の視点だけでしかない
14. ドメインを噛み砕く
15. 見つけ方が難しい！ - どこからデータがきているのか、どこが起点なのか
16. イベントストーミング - どういうところでどういう事象が発生するのか - サービスにおけるイベントを見つけ出す - なぜなら データは事象のスナップショット
17. 思考を鍛える - 自分が欲しいデータを見つける・見る・集約する 参考: https://www.ibm.com/docs/ja/spss-modeler/saas?topic=dm-crisp-help-overview
18. CRISP-DM - ビジネス課題の理解 - データの理解 - データの準備 - モデル作成 - 評価 - 共有
19. モデル作成・評価・共有 - DWHやデータマートなど - アプリケーションへフィードバックする仕組み - 機械学習 - 効果検証
20. データエンジニアもマインド必要なの？ - データが揃った・揃ったら何がどうなりそうか、 これを意識して基盤作りなどをする必要がある - ただ持ってきただけだと、何を解決するためにあるのか 誰もわからない・使われない基盤になります
21. 品質をあげる
22. データの品質を上げていく - 仕組みを作るだけではどうにもならない - データに関するリテラシーを上げていく - SREと同じくデータを軸にした品質向上活動をしていく - 一般的なアプリケーション開発とちょっと違う
23. すこし強くなる - 当事者意識を強く持つ - 今ないデータに価値がありそうか - 見えない範囲やネガティブなデータに価値がある - コミュニティを頼る（大事
24. 今ないデータとは
25. 生存バイアス - 装甲を厚くして撃墜されにくくする - 帰ってきた爆撃機のデータしかない、 撃墜されたものに価値がある - あるものだけに偏ってしまう - ちなみにこの図も仮説なので嘘の図
26. 注意すること - ただのデータ抽出チームにならないこと - チームはエンジニアだけで閉じないこと - なんとなくやらない、しっかりと思想をもつ - うまくできなさそうな時は諦めること
27. 注意すること - 97%は燃え尽きる - アプリケーションや業務フローで簡単に壊れるデータ パイプライン維持でほとんど終わってしまう - なぜ必要なのか、実現するためには文化と意識作り - 参考: https://datadeveloperplatform.org/why_ddp_for_data/
28. なぜデータ基盤が必要なのか WHYが明らかになってからが最初の一歩
29. サイクルを回すための 実現可能な手法を習得
30. データ基盤ができてきた - データの取り出し方、保管の仕方、モデリングなど ドメインに合わせて最適化する - 全てSQLだけで済む、ということはあまりない - 共有するにはある程度加工が必須
31. ELT/ETL / そんなにフレッシュじゃない - 小難しい転送がなければdbt、Embulk、Glueなど - 転送に関して データの鮮度・更新頻度が高くないものは非常に簡単 - 鮮度がよくなるほど難しくなる
32. ELT/ETL / フレッシュ - イベントストーミングのイベント発生時から 保管すべきもの - Apache Kafka、Kinesisなど - CDC(Change Data Capture)、ストリーミング処理少々 - 転送効率から選ぶことも
33. ELT/ETL / フレッシュ同士の結合 - Spark Streaming、Storm、Flinkなど - アプリケーション層に近いところまで寄ると マイクロサービスアーキテクチャと変わらなくなる - アクターモデル導入
34. データ集約・抽出 - 静的なデータを全てGoogleに預けていい場合は BigQuery を軸に - AWSの場合はS3+Athenaが低コストで鉄板 - それらを包括したSnowflakeなど
35. データ加工・抽出 - 事業の課題やフィードバックの仕方によって様々 - BIツールは可視化に - レコメンデーションや自然言語処理の結果など データを利用できる様に 全文検索エンジンやワイドカラム対応の設計など
36. データを軸にしたプロダクトがあるのならば・・
37. 連携システム グランドデザイン
38. 連携システム グランドデザイン
39. まとめ - アプリケーションエンジニアと知識と技術 - データ分析のための思考 - パイプラインを作るためのインフラ知識 - データそのものをプロダクトとして考える
40. 総合格闘技として様々な領域を鍛えていきましょう