会社の人に紹介されてイベントの存在を知りました。
普段は自社サービス（一種の分析ツール）のデータ処理・加工部分の機能開発を担当しており、大量のデータをアプリケーションから分析・表示できるようにすることがミッションです。最近では大規模データ処理のつらみが身にしみることも増えてきたため、他社ではデータ処理としてどんなことをしているのか、そもそも「データエンジニア」（データサイエンティストではない）とはどんな立ち位置の人なのかに興味があり参加しました。

データエンジニアとは？

このイベントにおける「データエンジニア」の定義は明確に定められているわけではありませんが、今回のトークは自分たちの事業が以下のような状況であることを前提とするものが多かったです。

日々大量のデータを扱っており、DWHには様々な形式の生データが雑多に蓄積されている
機械学習・ビッグデータ解析など、大量のデータに対して多様で複雑な分析をする必要のある業務が社内で行われている
上記のデータ分析を精度高く行い、その結果をもとにすばやく事業をカイゼンしていくことが重要視されている
そのため、大量のデータを自由度高く活用できるように、データを自動で集計・指標化するワークフローを構築する必要がある

どう考えてもつらみが溜まりそうですね...うちの会社はここまでの状況ではないのですが、データを扱う仕事をしている以上、共感できるところが大きかったです。
この前提をふまえて、それぞれのトークを振り返ってみます。

Cloud Composerを半年運用してみて困ったこと

EurekaではCloud Composerを使って、Data WareHouseにあるデータを用途に応じて集計・指標化するワークフローを管理しています。
最初は個々の分析の処理内容ごとにDAGタスクをまとめた(例えば「つぶやきの分析」)のですが、各グループ内に複数の処理が含まれるため、 - 既存のグループを組み合わせて新しいワークフローを作るのがとても難しい - 順番によってはデータに破壊的な影響を及ぼしてしまいうる - DAGタスクの内容が理解しづらくなり、みんなコピペするようにといったことが起こったそうです。Cloud Composerは使ったことないけどこのつらみはわかる...

そのため、処理内容ではなく各タスクの関心事ごとにDAGを分離させる(例えばつぶやき分析なら、「既存テーブルを消す」「新しいテーブルを作る」「ツイートをロードする」など)ことで、それぞれのDAGを組み合わせやすくなりました。また、個々のファイルの内容は完全に使い回せるので、レビュー対象がワークフロー自体のみになりコードを見る必要がなくなったそうです。以前Javaのバッチ処理で関数型インターフェースを扱ったことがあるのですが、正しく責務の分離が行われていれば個々のファイルのテストだけで全体が担保できるので理想的ですね。

Argo Workflowによる機械学習ワークフロー管理

リブセンスではMLシステムの中で、因子計算などのデータ解析にバッチ処理を使っています。さらにそのバッチ処理の中でも複数のアルゴリズムが組み合わされており、同じアルゴリズムを複数のバッチ処理で再利用していることも多いそうです。
しかし、構成が複雑化していったことで開発・運用に限界が生じ、単機能コンポーネントに分割することにしました。各コンポーネントはdocker run やkuberctl run だけで実行でき、各バッチ処理ごとの差分は設定ファイルで吸収するという形を取ったそうです。
そして並列化やリトライなどがある高度なワークフローの場合、Argo Workflowを利用しています。ワークフローはk8sから起動でき、またトリガーなどはなく実行に専念するシンプルな構成です。ドキュメントが少ないようですが、パラメータを渡せたり、ワークフローを分岐させられたりなどなかなか高機能そうでした。

自由と統制のバランス共通分析基盤のアプローチ

自由と統制のバランス_分析基盤のアプローチ from Ryoji Hasegawa

今回最も面白かった発表です。「ユーザにとっての自由度という観点で、データ分析基盤をどう設計するか？」という観点が新鮮でした。
DeNAにはデータで意思決定をするという文化があるため、ユーザが分析システムにbashでログインしてスクリプトを書くことすら許容してきたのですが、会社の規模が大きくなるにつれ、文脈・用途不明の野良スクリプトや書きかけで放置された野良ファイルなどが溢れて混乱が生じてきたそうです。その一方で、AIやMLに取り組む事業の場合、専用環境を組むコストが高いため共通分析基盤をもっと自由に使いたいという声もありました。
そこで、自由と統制を両立するようなデータ分析基盤に作り直す大型プロジェクトが進行しています。まず統制としては、自分でバッチジョブやスクリプトを作りたい場合、社内GitHubと連携させてそこからDigdagタスクとして登録しない限り実行できない構成に変更。そしてスマートなのが自由を与える方法。digdagのタスクとしてk8s apiを叩いて別のコンテナを起動し、そのコンテナを開発環境にするというものでした。これは想像していなかったです。さらにGKEを使うことでリソースの要求に応じてnodeを増減させてくれるため、重い処理を回しても適切なリソース管理がなされて安心です。
コンテナがヘヴィユーザと分析基盤運用者の責任分界点になる という言葉がとても刺激的でした。

感想

データエンジニアの仕事の重要性がよくわかりました(語彙力)。皆さん「IT土方」という自虐的な言葉を使われていましたが、 いやこれは普通に経営課題レベルじゃないか...？ と思うような規模の大きい取り組みの話が多く、とても興味が湧きました。
データ活用を推進する企業が増えるに従ってデータエンジニアの重要性は高まるので、この分野のコミュニティや情報発信がもっと盛り上がってほしいですね。