コンテンツデータ開発をリーンスタートアップする
本記事はストックマーク アドベントカレンダー 2022の4日目の記事です。
はじめに
こんにちは、ストックマークの谷本です。
今年10月に、弊社プロダクトであるAstrategyにおいて、ニュースに関連する特許を推薦する機能がリリースされました。
弊社ではこれまで自社開発したWebクローラーで収集したニュースデータをコンテンツとして提供してきましたが、上記の新機能をリリースするにあたり、夏頃から新たに特許データパイプラインの技術検証と価値検証が始まりました。完全に新しいデータソースと新機能になるため、社内の各部署のメンバー数名が集まり、素早く価値検証を行いMVPを決めて初版をリリースすることを目指しました。
そこで本記事では、エンジニアリング観点から、特許というコンテンツデータ開発[1]をリーンスタートアップするために行った取り組みをご紹介させていただきます。データ開発のご参考になれば幸いです。
本プロジェクトで重要視したこと
特許は会社としてこれまで提供したことのないコンテンツであったため、利用できるデータが無いとプロトタイピングも難しくなります。そこで初期のデータ検証ではとにかくプロトタイピングに使える完全なデータセットを少しずつでも増やしていくことを重要視し、プロジェクトの中~後期にかけて全データを扱えるパイプラインを構築していくことにしました。
上記を達成するために、以下に注力してデータ開発を行いました。
- 各データの処理完了/未完了の状態管理を行うことで、データセットの増築速度と完全性を両立させる
- パイプラインの再処理性能を上げることで、データの抽出精度を徐々に向上させる
- データ仕様をコード管理することで、MVPを作るための仕様変更の受容性を上げる
反対に、MVPが定まっていない状態で「作りすぎない」ことにも注意してプロジェクトを進めました。
以下では、これらの観点の経緯と実現方法を説明していきます。
初期リリース時の全体構成
先に全体構成をお見せします。
特許データは初めは外部から提供されたHDDに格納されており、それをクラウド化するところからスタートしました。左端のHDDから始まり右向きの黒矢印で進んでいく処理がバッチ処理で、左向きの橙矢印がユーザー操作によるオンラインのデータ読み取り処理です。
バッチ処理ではCloud ComposerとDataproc Serverless for Spark (以下Serverless Spark)を利用しました。オンライン処理では、FargateでホスティングしたgRPCサーバーを特許データのAPIとしてプロダクトチームに提供[2]しました。
それでは各注力点について見ていきます。
データセットの増築速度と完全性を両立させる
HDDには過去26年分の特許データが保存されていました。そして一つの特許につき、タイトル、出願人、要旨などが構造化されたXMLファイルと、特許原本であるPDFファイルが存在し、それらが数十ギガバイトごとにZIP形式で固められていました。
.
├── 1996_00001.ZIP
├── 1996_00002.ZIP
│ └── 1996_000000001.xml
│ └── 1996_000000001.pdf
│ └── 1996_000000002.xml
│ └── 1996_000000001.pdf
.
.
└── 2022_00100.ZIP
検証を始めてすぐに、特許データは、作成された時期(年)によってスキーマ(XMLの構造)や文字コードが異なるということがわかり、全てのデータパターンを網羅した処理を構築するにはかなり時間がかかることがわかりました。
そこで、AirflowのマネージドサービスであるCloud Composerを導入し、ZIPファイルごとに別々のジョブとして実行ステートを管理することにしました。これによって、処理が成功したデータセットを増やしていくと同時に、新しく出現したデータパターンによって途中で処理が失敗したり、後から上手くデータ化できていないことに気づいたZIPファイルに対して、抜け漏れなく処理を回すことができるようになりました。
データの抽出精度を徐々に向上させる
プロジェクトの中期ではMVPも定まり、初期に「とりあえずやっつけた」データを再処理して処理精度を上げ、UXを向上させる必要がありました。例えば、特許データにはその特許が解決しようとしている課題が記載されていますが、この情報は決まったスキーマで管理されておらず独自に抽出器を実装したため、うまく対象を抽出できていないパターンが発見されました。
そこで、既存のワークフローに対してライトに大量データを捌けるようにするために、GCPで提供されているServerless Sparkを利用しました。
Serverless Sparkは、コンピューティングリソース管理とコスト管理を極小化でき[3]、またAirflow向けの専用のOperatorも用意されているので、Cloud ComposerのDAGのなかで分散処理させたい箇所に手軽にスポット的に導入することができます。
こうして、データの抽出失敗箇所を発見→修正→Serverless Sparkで再処理→...のループを構築して改善させることができました。
MVPを作るための仕様変更の受容性を上げる
新機能の価値検証を進めていると、プロトタイピングやユーザーヒアリングの結果を踏まえてデータの仕様を変更した方が良い場合が多々あります。また、日々開発の方針も変わっていくため、定常的な開発業務との間でコンテキストスイッチの影響が大きくなりがちです。そうしたプロジェクトでは、データ(あるいはそのAPI)の仕様が明確に管理され、管理自体の工数を減らすことが重要です。
そこで、特許データAPIの仕様をProtocol Buffersで定義して単独の共有リポジトリに管理し、クライアント側(プロダクト開発側)もサーバー側(データ開発側)もそれを参照することで管理工数の削減と属人化の防止を行いました。
おわりに
ここまで、コンテンツデータ開発における取り組みをご紹介しました。
それではまた明日の記事をお楽しみに！
Discussion