がんばらないデータ基盤

データ基盤ひとりAdventCalendarの16日目の記事になります。

データ基盤に関連した内容について学んだことを@takegue がまとめていきます。

内容については随時加筆/修正等を行なっていく予定です。

修正等の指摘ありましたらご連絡いただけると幸いです。

—

データ基盤は、取り扱う対象が大規模かつ横断的かつ持続可能であることが求められるなかデータの発生源のアプリケーションなどの上流に対する影響を強く受けやすい代物です。

開発と運用の大きいコストの割りに、作ったからといって事業に直接コミットメントが

すぐに認められるわけではない点で日の目を浴びづらく下手するとコスパが悪い取り組みです。

損益分岐点が明確にわかるようであればその辛さも将来のための我慢できるのですが

そういった見通しの悪さも難点のひとつです。

そういった背景からかデータサイエンティストやアナリスト、機械学習エンジニアという職種は人気があってもデータエンジニアといった職種に人気が集まっているという話は聞いたことがないのが現状です。

とはいえ、データ活用という華やかな夢のためにはデータ基盤がなければ作るしかなく

そういった形ではじめられて様々な苦労を経験されている方は多いのではないかと思います。

データ基盤の立ち上げは、やりたいことに対してヒトもモノも時間も足りない状態から始まり

利活用までを広げるところまでをスコープに含めればさながら

社内プロダクトとしてスタートアップを足し上げるようなものであると考えています。

この記事は、データ基盤に数年携わり少人数ながらというかひとり開発運用した経験を持つもののひとりとして

思うところあり、後続の方々の支えになるノウハウみたいなものが何かかければいいかなと

思い書き起こすものです。

Less is more: つくらない

データ基盤上に構築されるETL処理は長いパイプラインを構築します。

巷では魅力的なOSSのミドルウェア、新しい技術やフレームワークが日々登場しています。

開発初期であればあるほど知的好奇心が刺激されて目移りしやすいですが、

最もものごとを早く進める方法は開発しないことです。好奇心は好奇心として消化し、システムとしてはデータ活用の効用が十分に発揮されないうちにいろいろ作りすぎないことを目指すと

良さそうです。

JVM系言語、PythonやRubyのLLのツール群やさらにETLジョブごとの言語が違ったりなど

意図せずともpolygotな構成になりやすいです。

ネットワークからストレージ、セキュリティなどなど広いレイヤでの知識が必要で

アプリケーション開発者 + SRE + DBA + アナリスト… の種々の役割を足して平均を取ったような

器用貧乏さが必要です。

いかに少ない構成要素で実現できるかを常に考えていきましょう。

「ちょっとものたりないけど大体困らない」ぐらいが目安です。

Case Study: ETL処理

データ基盤のためのパイプライン処理をExtract(抽出), Transoform(加工), Load(転送)の頭文字をとってETLと呼びます。

データ基盤を構築する上でまずはじめに着手するのはこのETLになるのですが

ETLのTであるTransoformを極限までサボりましょう。

「データをいかに加工すべきか」は「データをどのように活用するか」が元に決まります。

​​Less is more: つくらない