こんにちは。
ストリーム・パイプラインエンジニアの辻です。
早速ですが、ストリーム・パイプラインってご存知でしょうか？
社内でもよく「ストリーム・パイプライン」って何だ？「ストリーム・パイプラインエンジニア」ってどんなことをするポジション？というふうに聞かれる機会が多いです。同じエンジニアでさえその実態を正確には把握できないという事もあり、改めてその仕事の内容について少しご紹介したいと思っています。
実は知られていないというのもそのはずでして、日本にはまだこのポジションを明確に示す名前がありません。（ですので、dely内ではこのように呼んでいます。）しかしながら、海外のデータを重要視している会社などでは、状況によってデータサイエンティストよりも重要なポジションと考えられることもあるほど、とても有益でやりがいのあるとてもエキサイティングなポジションだと思っています。
ストリーム・パイプラインとは
まずはストリーム・パイプラインについて少しご説明したいと思います。
よく、データの流れは水の流れに例えて説明されることが多いかと思います。
たとえば、
データの流れのことを『データストリーム』と呼んだり、
データを貯めるストレージを『データレイク』と呼んだりします。
これはなぜでしょうか？
この水という存在は、私たちの生活の中において全く欠かせないものです。飲料用、食事用、食器を洗う、手を洗うなどなど、蛇口をひねればいつもそこに水が出るという状態というのは、日本に住んでいるとなんだか当たり前のように感じますが実は当たり前ではないんです。
これを実現している仕組み、それこそがパイプラインです。それでは水のストリーム・パイプラインをもう少し詳しく見ていきましょう。
水のストリーム・パイプライン
横浜市水道局の図をお借りしてご説明させていただきたいと思います。
山に降り注いだ雨水は地中を通りやがて川となり低地へと流れて来ます。その川の水が各家庭の蛇口へと供給されるわけですが、多くの家庭に供給すべく供給量を一定に保持するために川の水をせき止めてダムを作ります。ダムから一定的に放出される水は、導水施設を通って浄水場で浄化され、生活用水としての基準を満たしたのち配水管・給水管（時には増圧ポンプなどを利用）を通して各家庭へと供給されます。
データのストリーム・パイプラインも実はこれと同じなのです。つまり、蛇口をひねると水ではなくデータが供給されるのがデータのストリーム・パイプラインというわけです。もし、日常的に供給されるべきタスクを、データレイクに対して毎回SQLを発行しているとしたら、例になぞらえて、あなたは水を飲むためにわざわざダムへと赴き、コップをダムへと延々垂らして汲み上げ、持参したろ過装置でろ過して飲んでいるようなものと言えると思います。（しかし、アドホック分析は定常的なタスクには該当しないので、さしずめ水質検査のようなものと考えられます。）
（厳木ダムのイメージをお借りました） （ろ過装置の例）
つまり、水とデータのパイプラインにはこのような対応関係にあると言えます。
水 ⇆ データ
ダム ⇆ データレイク
導水施設 ⇆ メッセージキューサービス
浄化 ⇆ ETL処理
配水池 ⇆ データストア
配水管・給水管 ⇆ ジョブフロー
蛇口 ⇆ API、Batch、分析ツール
ストリームパイプラインの具体的なデータの流れはこのようになります。
データはまずデータレイクに保存されて、メッセージキューサービス(MQS)を通して、データの流れ（つまりストリーム）が制御されます。MQSにエンキューされたデータは、サブスクライバやトピックによってデキューされその後ETL処理に譲渡されます。ETL処理済み(つまり浄化された)データはジョブフローに乗り、それぞれが必要なデータストアへと運ばれていきます。データストアに保存されたデータは随時、最新状態に更新され、APIやBatchのインプットとなったり、あるいは機械学習の学習時のデータセットに用いられたり、分析ツールのコンソールなどから直接SQLで参照されたりして日常的に活用できる状態を維持することが可能となるのです。
しかし、一方でこのような疑問があると思います。
「データレイクに直接SQLを投げても実現できるのでは？」
はい、もちろん実現はできます。しかし、現実に目を向けてみるとどうでしょうか？使い捨てのアドホック分析であれば可読性の低いSQLであってもさほど支障はないでしょう。しかし、定点観測していきたい指標の集計処理や、機械学習に用いるデータを毎回複雑なSQLで取得するとしたら、データレイクにストアされているデータ量に比例して処理コストも高くなりパフォーマンスも落ちてしまいます。（何10ペタバイトのデータレイクは今ではそれほど珍しい話ではないですよね。）また、SQLは運用が長くなるとうなぎのタレ的に複雑な構成が追加されていくものなので、改修にかかるコストは高くなり、いずれバグの温床になりかねません。そうならないためにも、健全で安定的に必要なデータをデータストアに供給する仕組みというのは非常に重要な責務を担っていると考えられます。
「データレイクに直接SQLを発行した方が加工処理を加えるよりデータの信頼性が高いのでは？」
これも確かに一理ありますが、時間的コストと精度とのトレードオフになると思います。ペタバイト、エクサバイト級のスキャンを何度も実行すると料金コストが大変なことになりますし、レスポンス時間が処理時間全体のボトルネックになります。この課題において一番重要なことは、加工時の冪等性を保証するということになると思います。そのためには、アウトプットの項目数の一致やデータ量の変化に対するバリデーターをETL処理終了後に実行し結果をSlackで通知したり、あるいは場合によって後続処理を停止するなどの配慮が必要になります。いやいや、そんなことをするくらいならSQLを発行した方がやっぱりいいのでは？と思うかもしれませんが、昨今では特にこれらのETL処理に加え、機械学習の文脈においてデータ量が決定的に扱えない課題もありますので、トレーニング処理や前処理を行うインスタンスサイズを可変にして、コストを抑えたいという思いもあり、このこともより柔軟なパイプライン設計が求められる背景となっていると考えます。
ストリーム・パイプラインを構築する
例としてストリーム・パイプラインをAWSで構築した場合をご紹介したいと思います。
AWSでの構築例
AWSでの構築例です。
ユーザのイベントデータは、Kinesis Firehoseを通してS3に定期的に保存されます。このデータは、AWS Glueがクローリングしてカタログ化しETL処理を行ったのち、再びS3にparquetフォーマット等で保存します。また、それと同時にlambda経由でAmazonMQへとパブリッシュされます。AmazonMQにはTopicとQueueがETL単位でサブスクライブされていますので、エンキューしたイベントログに対してデキューを行いStepFunctionsやAWS Batchのジョブフローを通し所定のデータストアに保存されます。データストアはAthenaでアドホック分析を行ったり、lambdaからの利用やアプリでの利用の結果として、再びイベントデータとしてデータレイクへと保存されていきます。
また、管理画面などからRDSに登録したデータについてもAWS Glueがクローリングしてカタログ化しETL処理でユーザのイベントデータと統合されて、所定のデータストアに保存されます。
AmazonMQはデッドレターキュー配信アラームを設定したり、上流プロセスの失敗を受けて下流のサブスクライバのデキューを止めたり、逆に下流の処理が追いつかない場合にバックプレッシャーをかけるなど、まさにダムやパイプラインのバルブのような役割を担っています。
GCPでの構築例
こちらはGCPでの構築例です。
ユーザイベントはFirebaseを通じてBigQueryに保存されます。BigQueryのデータはpub/subを経由してdataflowにてETL処理を行います。処理済みの（浄化された）データは所定のデータストアに保存されます。BigQueryでアドホック分析した結果やCloud Functionsやアプリの利用結果はやはり再びデータレイクへと循環していきます。
このように、データストリームは常々循環し必要なデータストアを満たし様々な用途として利用されていきます。利用するAPIや機械学習のBatch処理などにとってそれは、あたかも蛇口をひねってデータが供給されるように、常時最新のデータを利用することが可能となります。ダッシュボードなどでKPIを見る際、安心して利用できる、または、APIやBatchのインプットが常に最新状態を維持されていることは、サービス全体の品質を上げ、現時点よりグロースするための基礎として必要不可欠だと考えています。また、機械学習では循環したデータのフィードバックを再びインプットデータとすることにより、推論精度の定常的向上が期待できます。
まとめ
今回は、ストリーム・パイプラインエンジニアについてご紹介しました。
ストリーム・パイプラインが何か？、あるいは、ストリーム・パイプラインエンジニアの仕事についてなんとなくご理解いただければ大変嬉しいです。
水が人にとってライフラインであるように、データ活用は会社が運営するサービスにおけるライフラインだと思っています。そのために、常に新鮮で浄化されたデータを供給することは安定的にサービスを運営する上での根幹となります。そして、このペタバイト級のデータの流れを円滑に管理し、運用コストを抑え、サービス向上に貢献することはとても難しく高い技術力を要しますが、その分とてもやりがいのあるポジションであると思っています。
最後に
今delyでは、このとてもエキサイティングなポジション「ストリーム・パイプラインエンジニア」を募集しております。しかし弊社においてもストリーム・パイプラインの取り組みはまだまだ始めたばかりで、まったく手付かずな点も数多くあります。この取り組みに興味をお持ち頂けた方、あるいは機械学習も併せて今後ご活躍したいと検討されている方にはうってつけのポジションだと思っておりますので、少しでもご興味を持って頂けた方はぜひご連絡お待ちしております！
