大規模ならではの課題に挑戦できるのが大きな魅力　自前データプラットフォームの開発を担う、LINEのデータエンジニアの仕事の醍醐味

自己紹介とアジェンダ

内田早俊氏（以下、内田）：みなさんこんにちは。LINEのData Platform室の内田です。本日はお忙しいところ、ご参加いただきありがとうございます。私からは、Data Platform室のデータエンジニアのポジションの紹介をしたいと思います。

まず簡単に自己紹介をいたします。私は、2018年2月にデータパイプラインのSite ReliabilityエンジニアとしてLINEに中途入社しました。その後、Hadoopクラスタの統合プロジェクトに参加したり、最近では全社的なワークフローエンジンのプロジェクトをリードしたりしています。本日はどうぞよろしくお願いします。

こちらが本日のアジェンダです。データエンジニアのポジションについて紹介する前に、まずData Platform室の組織や開発・運用しているプロダクト、それからスケールなどを紹介したいと思います。

そのあとに、データエンジニアについて紹介します。このデータエンジニアというポジションは比較的新しい職種なので、あまり具体的なイメージが湧かない方が多いかと思います。データエンジニアがどんなミッションを持っていて、どんなチャレンジがあるのか。そしてそうしたチャレンジを通じて、どんな経験を積むことができるのかをお伝えしたいと思っています。

最後にData Platform室で行っている社外向けの発表や記事を簡単に紹介します。

「Always Data-driven」を実現するために独自のプラットフォームを開発

まずData Platform室のミッションと、組織構成についてご紹介します。先ほど戸塚さんからも紹介がありましたが、LINEは「CLOSING THE DISTANCE」というミッションと「Life on LINE」というビジョンを持っています。そしてそれらを実現するための価値基準として、11個の「LINE Style」というものを定義しています。

その中の1つがこのAlways Data-drivenです。「感覚ではなくデータ、事実を信じる」です。このAlways Data-drivenを実現するために、Data Platform室ではIUというSelf-service Data Platformをオンプレミスで開発・運用しています。

各組織が自分たちでデータプラットフォームを構築するのではなく、Data Platform室で提供しているプラットフォームを使うことで、各組織がデータの利活用に集中できるようになっています。

このIUでは、ストレージやコンピュテーションエンジンを土台として、さまざまなサービスからデータを集めるためのストリーミングパイプラインのサービスや、集めてきたデータを分析しやすいように加工するETLパイプラインのサービスや、クエリを書いてKPIなどをグラフィカルに表示するためのサービスなどを提供しています。

Data Platform室の中にある5つのポジション

LINE全体におけるData Platform室の位置づけはこのようになっています。全社組織としてData EngineeringセンターとData Scienceセンターがあり、それぞれの下にData Platform室、Data Management室、Machine Learning室、Data Science室があります。

先ほど紹介したとおり、Data Platform室はData Platformの開発・運用を行っていて、現在46人ほどのエンジニアが所属しています。Data Management室はデータの活用を促進するためのさまざまな取り組みや、データを利用するうえでのルール整備などを行っています。

それからMachine Learning室は、機械学習に関するさまざまな開発や運用を行っていて、ここでの機械学習は、例えば「あなたにおすすめのLINEスタンプはこちらです」というレコメンデーションのシステムがメインとなっています。

Data Science室はデータ分析による課題解決をミッションとした組織で、統計的なレポートの作成や、A/Bテストの設計、データのモデルの作成が主な業務になります。

Data Platform室の中には大きく分けて5つのポジションがあります。Data Platform EngineeringはData Platform室の各システムの開発・運用を担当しています。LINEはオンプレミスで自前のData Platformを構築しているため、その開発・運用をするメンバーです。

Data Engineeringは後ほど詳しくご紹介しますが、収集した生のデータを加工して、分析や機械学習にとって価値のあるかたちへの変換を行っています。

Web API Developmentは、Data Platformをよりユーザーに使ってもらいやすくするための仕組み作りを担当しています。データのカタログ化や権限管理を行うためのWeb画面、それからサービスとのシステム連携に必要なAPIの開発などはこちらが担当しています。

Product Managementはこのようなプラットフォームを開発するうえで、どのような仕組みがどれくらいのインパクトを持つのかについて調査や整備、優先順位付けをしています。プロダクトのロードマップの整備もこちらで行っています。

Technical Consultationは、ユーザーからの技術的な要望について深掘りして、どのように解決するのが正しいのかを調査したり、コンサルテーションをしたりしています。

本日ご紹介するのはデータエンジニアのポジションですが、Data Platformエンジニアのポジションも募集しているので、データそのものよりはData Platformの開発や運用に興味があるという方は、ぜひサーバーサイドの枠に応募してもらいたいと思います。

それから新しいサービスを開発する場合には、自分たちの強みを最大限発揮できるように、ポジションをまたがったプロジェクトが作られます。このプロジェクトではメンバーの役割は比較的柔軟で、ふだんはTechnical Consultationを行っているメンバーがData Platform Engineeringを行うということもあります。現在もData Platform室では複数のプロジェクトが進行中で、中には室やセンターをまたぐ大きなプロジェクトも存在しています。

Data Platform室で開発・運用しているコンポーネントとプロダクト

それでは次に、Data Platform室で開発・運用しているコンポーネントとプロダクトの紹介に移りたいと思います。これが私たちのData Platformで使用しているソフトウェアの例になります。黒いものがOSSや商用プロダクト、緑色のものがLINE独自で開発しているものです。ご覧のとおりData Platform室ではOSSを積極的に活用しています。

ただ既存のものは、なかなかそれだけだと要件を満たさないことも多いので、自社独自のツールやAPIの開発も積極的に行っています。簡単にいくつかの例を紹介したいと思います。

この「Yanagishima」は、TrinoやHiveと呼ばれるクエリエンジンのためのクエリツールで、OSSとしてGitHubにも公開されています。個人的には結果をWebLinkで簡単に共有できる点が気に入っています。

それから、この「OASIS」は、JupiterのようなノートブックツールでSparkやTrinoに対応しています。ノートブックやそれらを格納するスペース単位の細かな権限管理や、ファイルマージのOASIS独自のSpark APIを実装しているのが特徴です。

「Frey」は、サービスのデータベースのデータをIUに収集するためのサービスです。現在はMySQLやMongoDBをサポートしています。

こちらが現在のData Platform室のスケールです。ご覧のとおり、非常に大規模なプラットフォームを開発・運用をしていて、大規模ならではの課題や、やりがいがたくさんあります。

データエンジニアの主なミッションであるReliability・Performance・Security

それではデータエンジニアのポジションの紹介に移りたいと思います。LINEには本当にさまざまなデータがありますが、中には組織やサービスを横断して広く使われるコアなデータが存在します。そうしたデータを、データサイエンティストやマシンラーニングエンジニアなどのデータの利用者のためにETLで生成するのがデータエンジニアの主なミッションです。

こちらの図のReliably、Quickly、Securelyが具体的に何を示すのかを詳しく見ていきたいと思います。

まずリライアビリティから見ていきましょう。データを生成するETLパイプラインがReliableであるためには、ユーザーにそのデータが生成される時間や質を保証する必要があります。時間に関しては遅延が発生しないように、ETLパイプラインを安定的に運用する仕組みが必要ですし、万が一、遅延が発生した場合でもユーザーに通知が行く仕組みを開発する必要があります。

質に関しては、重複したデータがないかどうかや、あるカラムにふだんとは違う値が入っていないかなど、さまざまなメトリクスをデータの生成後に確認する仕組みが必要になります。

次にパフォーマンスについては、データをできるだけ速く生成したり、ユーザーのクエリを高速にしたりするためのデータモデリングやクエリチューニングを行う必要があります。その際に、ストレージやコンピュテーションのリソースを効率的に使う工夫も重要になってきます。

最後にセキュリティですが、生成されたデータは適切に権限管理される必要があって、データによってはマスキングや暗号化を行う必要があります。こういった仕組みを適切に実装するためには、データエンジニアリングに関する専門性が必要になってきます。

データの種類やデータの利用者が少ない場合にはそこまで問題にならないかもしれませんが、LINEのような規模になってくると実際のETLの開発よりも、それを支えるリライアビリティ、パフォーマンス、それからセキュリティの開発のほうがより重要になります。

データエンジニアのスキルセットと技術スタック

データサイエンティストやMLエンジニアのような、本来データを利用する側がこうした周辺機能の開発に時間を取られてしまって、本来の仕事に集中できないという問題を防ぐために、このデータエンジニアというポジションの需要が世界的にも高まっています。

こちらがデータエンジニアとデータサイエンティストのスキルセットを比較した図です。データサイエンティストは統計やマシンラーニングに対して高度な専門性を持っています。

データエンジニアはデータ分析がまったくできないかというと、そういうわけではありません。例えばData Platform全体のキャパシティプランニングや、ストレージやコンピュテーションリソースの最適化。それからデータの統計情報を元にしたデータクエリの最適化などで、データ分析の知識や経験を活用できます。2つのポジションで迷われている方の参考になれば幸いです。

こちらはGoogle Trendsを使って、データエンジニアの過去5年間の人気度を調べた結果です。ご覧のとおり過去5年間で、人気度が3倍から4倍ぐらいになっていることがわかります。

これがData Engineeringで使われているTech Stackの例です。Hadoopのような分散型ストレージのコンピュテーションエンジンや、SparkやHiveのような分散型のクエリエンジンはもちろん、Kubernetes上でさまざまなアプリケーションを走らせることもあります。

特に最近は、このICEBERGという新しい技術に注目していて、現在Data Platform室で導入のための検証を進めています。言語についてはHadoopがJavaで書かれていたり、会社の歴史的な理由でJavaが使われることが多いですが、Pythonや、プロジェクトによってはGoやRustを使っても問題ないです。

LINEのデータエンジニアは大規模ならではの課題に挑戦できる

データエンジニアの具体的な仕事を紹介したいと思います。まず分析型のクエリエンジンや、スケジューラなどのさまざまな技術を使って、LINEのコアなデータセットを生成するETLパイプラインの開発・運用を行ってもらいます。特にリライアビリティやセキュリティの機能を実装する際には、Data Platform室の他のエンジニアが開発・運用しているツールやAPIを使うことも多いため、Data Platform室内での協業は活発に行う必要があります。

また、データの利用者側から新しいETLパイプラインの開発の依頼がある時は、コミュニケーションを取りながら進めることになります。ほかにも、Data Engineeringの領域は技術の流れが速く、新しい技術が次々に出てくるので、そうした新しい技術を使って、既存のパイプラインを継続的に改善していくことも重要な仕事の1つです。

次にLINEでData Engineeringを行う魅力を紹介します。まずはなんと言っても、データやそれを扱うプラットフォームのスケールの大きさです。大規模ならではの課題に挑戦することで、高い問題解決能力を身に付けることができます。また、LINEがビジネスのためにどのようにしてデータを活用しているのかも、ETLパイプラインの開発・運用や、データ利用者とのコミュニケーションを通じて知ることができます。

また、LINEはオンプレミス環境で自前のData Platformを構築しているので、Self-service Data Platformのいわば舞台裏の経験を積めるのも大きな魅力だと思います。LINEで出会う問題の中には、まだOSSのコミュニティに知られていない問題もたくさんあります。そうした問題の解決を通じて、HadoopやSparkなどのトップレベルのOSSプロジェクトに貢献できます。

データ最適化のテクニック

このData Engineeringの仕事をよりよく理解してもらうために、データを効率的に保存するテクニックを簡単に紹介したいと思います。（スライドを示して）左側があるテーブルの論理的な図で、右側がParqetやORCと呼ばれる、Columnarストレージフォーマットを使って左のテーブルを保存した場合の物理的な図です。

もちろん左の図をそのまま保存することもできるのですが、Columnarストレージフォーマットを使って保存をすることで、データサイズを削減し、クエリを高速化することができます。右の図でRowはグループに分割されていて、A0、A1、A2、B0、B1、B2のようにカラムごとに連続して保存されていることに注目してください。

このように同じ種類のデータが物理的に連続していると、Dictionary EncodingやRun Length Encodingのような、さまざまなエンコーディングを使ってデータを圧縮できる可能性が高まります。また、分析で使われるクエリは特定のカラムをスキャンしてアグリゲーションすることが多いのですが、同じカラムが連続して保存されているためクエリも高速になります。

ここまでは、ParqetやORCのようなColumnarフォーマットを使うだけで得られるメリットで、データエンジニアとしてはさらにもう一歩踏み込んだ最適化を行うことが求められます。例えばカラムAのカーディナリティが非常に高い場合には、SQLクエリにCLUSTER BY Aというクローズを指定することで、さらなる最適化が期待できます。

このCLUSTER BY Aを行うと、カラムAの各値に対してハッシュ関数を適用して、そのハッシュ値が同じものを同じファイルに集めて、さらにソートできます。そうすると、各ファイルのカラムAのカーディナリティが下がって、しかもソートがされているので、先ほど言及したエンコーディングを活用できる可能性がさらに高まります。

実際にある1つのデータセットに対してこのCLUSTER BYを適用したところ、CLUSTER BYがない場合に比べてデータのサイズが3分の1になりました。単純にデータの価値を、このデータが生んだ利益÷データサイズで考えると、このデータの価値は3倍になったと言うことができそうです。

このデータセットは冗長化のためのレプリケーションも含めると、1時間分で1TB以上あります。1年分を保存すると8PBぐらいになるため、この最適化によって5.5PBのデータサイズの節約ができます。

さて、このCLUSTER BYによる最適化は、ある特定のテーブルの特定のカラムに対してうまくいきましたが、どのようにして一般化できるでしょうか。LINEのData Platformには、4万を超えるテーブルがあるので、それら一つひとつに対して、どのカラムにCLUSTER BYを適用するのがよいのかと考えるのはあまり現実的ではありません。

そもそもこのCLUSTER BYをそのまま適用するのが難しいカラムも存在します。これはカラムの値の偏りが大きい場合に、その偏っている値を集めて1つのファイルに書き込むという処理に非常に時間がかかってしまうためです。この問題はごく一例に過ぎませんが、LINEのデータエンジニアのポジションではこうした問題に取り組みます。

ほかにも、さまざまなオプティマイゼーションのテクニックがあるので、気になる方はぜひGoogleで調べてみてください。

データエンジニアに求めるスキルと人物像

私たちがデータエンジニアに求めるスキルや人物像はこちらです。特に目新しい項目はないかと思いますが、スキルは基本的なアルゴリズムとデータ構造の理解や、JavaやPythonのようなオブジェクト指向をサポートしているプログラミング言語。それからSQLに関する基本的な理解は必要になると思います。分散システムに関する知識や経験は、あるとプラスになるかもしれませんが、必須ではありません。興味があったほうがよいと思います。

人物像ですが、Data Engineeringは技術の流れが非常に速いので、新しい技術を貪欲に学ぶ意欲のある方、それから会社にとって非常に重要なデータを扱うことになるので、強い責任感のある方を募集しています。

言語ですが、口頭での会話は日本語がメインで、文字でのやり取りは基本的に英語を使っています。