概要
この記事は、datatech-jpアドベントカレンダーの13日目です。
サーバやDBに詳しくなく、SQLを少し書いたことがあるだけレベルの未経験者が、この夏にHadoop関連のデータエンジニアリングを始めました。
その最初の1ヶ月間で学習した内容の話です。
間違ってるところなどあればコメントしてくださいませ。
対象
- 「HiveとかHadoopとか、意味がわからないです」
- 「そもそもデータエンジニアリングってなんだっけ、どんなテーマがあるんだっけ」
という人。
注意
データエンジニアリング ≠ データサイエンスなので、データサイエンスを学びたい人は東京大学などが公開しているコースで学習するのが最短だと思います。
今回はデータエンジニアリング、特にパイプラインマネジメントやHadoopエコシステム周辺のエンジニアリングに取り組む準備がテーマです。
勉強内容のステップ
- 0週間目 学習の前に
- 1週間目 データベースの初歩的な知識をもつ
- 2週間目 Hadoopエコシステムを最速で把握する
- 3週間目 トレンドをおさえる
- 4週間目 現場の問題を感じる
0週間目 学習の前に
コンサルタントは新しい分野の仕事をするとき、その分野の本を一気に10冊は読むそうです。
データエンジニアリングに限りませんが、知らない分野に飛び込むときは
- 専門用語
- 全体観
- 変化要因(アツイ部分)
の3点を最速で把握することを意識すると良いです。
この記事もこの流れを汲んでいます。
1週間目 データベースの初歩的な知識をもつ
データエンジニアリングを知る前に、データエンジニアの主戦場であるデータベースについて知る必要があります。
ネットや本で以下の用語がサッとイメージ湧くくらいまでになるまでデータベースやバックエンドについて調べます。
- RDB
- SQL
- 正規化
- カーディナリティ
- NoSQL DB
資料はなんでもいいですが、最近出たAI Shiftさんの資料は歯応えあって面白いと思います。
上のようなDB基礎用語のイメージが掴めたら、次はビッグデータ基盤特有の語彙についても調べます。
- データレイク
- データウェアハウス
- データマート
- 列指向データベース
- ETL, ELT処理
- OLAP, OLTP
上記の単語が何を指しているのか、どんな目的で使い分けられるのかが大体分かるレベルになればOKです。
ビッグデータ基盤も学習資料はなんでもいいですが、データ基盤全体の説明や[ETLとELTの違い] (https://it-trend.jp/etl/article/252-0002)あたりをざくっと読んで調べ始めると分かりやすいです。
2週間目 Hadoopエコシステムを最速で把握する
次に、Hadoopエコシステムの把握です。
正直コンポーネントが多く意味が掴みづらいため、全体感を把握しつつサクッと進めましょう。
※「うちはBigQuery使うからHadoopとかHiveとか一切触らないよ」って人は、このステップをスキップしてもよいと思います。
その代わり、GCPやAWSのデータ製品の関係性について調べると実務上有用かも。GCPの本など。
Hadoopエコシステムは以前主流だったもので、いま実際の現場の業務で触れないことも多いです。これらの技術は既にGCPやAWSに機能として組み込まれつつあります。
オンプレでHadoop、といった構成は今後も残るとは思いますが、用語や概念を頭にインストールしておくに留めるのもアリだと思います。
Hadoopまわりのデータエンジニアリングを学ぶために、『ビッグデータを支える技術』の前半を一気読みします。良書です。
- hadoop
- hdfs
- MapReduce
- hive
- Tez
- spark
- presto
- データの拡張子 (csv, parquet, など)
あたりの用語とそれぞれのツールの立ち位置を把握します。
書面は載せられないので別の記事を参照しますが、Apacheプロジェクト一覧が全体を把握するのに極めて有用です。
ここまで学習するとwebに落ちてるデータインフラの資料を読んでほぼわかるレベルまで来ます。
3週間目 オンメモリ、クラウドのトレンドを把握する
資料を調べていくと、データエンジニアリングにおけるここ数年のトレンドが見えてきます。大きく
- 処理がディスクからメモリへ
- サーバーがオンプレからクラウドへ
の大きく二つのトレンドがあります。
ディスク保存からオンメモリへ処理が移行
ここ数年のデータエンジニアリングにおいてはCPU、メモリ量の増大を背景としたストレージとコンピューティングの分離のトレンドがあります。
巨大なテーブルにクエリを投げる際も、ディスクに都度書き込みながらMap reduceで処理するより、**大きなメモリ上で全部処理した方が速いし拡張性もあるのでは？**といった発想があり、Prestoなどがその思想を引き継いで普及しています。
今後ディスク書き込みの必要なケース(巨大なテーブルを確実に処理したいときなど)よりも、オンメモリ処理が主流になっていくと考えられます。
オンプレからクラウドへ
これはソフトウェア業界の方ならご存知だと思うので割愛します。
※最近気づいたのですが、Dremel (BigQueryの前身) の振り返りペーパーにもトレンドが色々列挙されているので超オススメです。もっと早く読みたかった。
4週間目 現場の悩みを把握する
(会社にもよりますが) データエンジニアリングの現場の基本的な悩みは3つほどに集約されると思います。
- データがBigになったりユーザーが増えたりして、クエリが遅くなって困る
- パイプラインが入り組みすぎて混乱
- データ品質、データ仕様の管理が難しい
この基本的な問題に加え、機械学習のプロジェクトならモデルの管理やデプロイフロー、機密情報を扱うプロジェクトなら暗号化やパーミッションの問題、BIのプロジェクトならデータマートの設計や仕様決めの難しさ、などのフレーバーが足されていきます。
datatech.jpで輪講が行われていましたが『Self Service Data Roadmap』がこのあたりの問題を網羅的に整理しているので、気になる箇所があれば読んでみるのもアリです。
1ヶ月後
ここまで進めたあたりで、データエンジニアリングについて質問投げたり、技術論文を読んだりするときに困らなくなりました。
データサイエンスの資料は世の中に溢れていますが、データエンジニアリングについてまとまっている資料は少ないので記事にまとめました。
どなたかの参考になれば幸いです。