データ分析はじめまして。Japanなど各社に提供していました。内容に関する簡単な分析についてはプレスリリースでお伝えしているので、そちらもあわせてご覧ください。prtimes.jp実はこのツイート収集システムは、2週間ほどでほぼゼロから立ち上げたものでした。今回は五輪関連のツイート収集を支えた技術について紹介します。五輪に関するツイートを、NTTデータの提供するAPIからストリームで受け取り続けるツイート量などの統計情報やRTが多いツイート情報をダッシュボードの形で見ることができる上記を(ほぼ)リアルタイムで実現できる実はこの取り組みにあたり、システム全体を一から構築する必要がありました。提供が決まったとき、データ提供までのタイムリミットは約2週間。開催までは否定的な意見が目立っていたとはいえ、オリンピックが実際に始まると盛り上がることは容易に想像できました。フルスクラッチで全部を作ることは早々に諦め、GCPのマネージドサービスをできるだけ活用する方向に切り替えました。Engineツイートを収集し続ける役割。弊社で提供しているプロダクトFASTALERT(ファストアラート)で同じような収集システムが存在していたので、そのコードを再利用しています。いっても、コード自体は大したものではなく、全部で100〜200行程度。コンテナを立ち上げています。コンテナをデプロイできる機能があるので、これを活用しました。Dataflowに一つずつ流してあげる役割。ツイートを収集し続けられているか、死活監視していました。さまざまなテンプレートが用意されています。吐き出すテンプレートを使用しました。吐き出す選択肢もありましたが、データのスキーマ設定で沼ったので諦めました。ロードする構成を取っており、同様の構成としました。動かすDAGの定義のために50行くらいコードを書きましたが、これも社内のコードを再利用する形。社内のデータ基盤についてはこちらも見てみてください!tech.jxpress.net5分おきにロードされるよう設定しましたが、重複排除の仕組みを作るのが少し面倒でした。クラスタを立てると維持費が高くなってしまうため、先述したデータ基盤のクラスターに相乗りすることで維持費を節約しました。データポータル簡単な可視化であれば、これで十分です。使っていたため、重宝しました。フロントの開発が必要なかったのが非常によい。平均すると1秒あたり40ツイート程度を処理し続けました。することができました。死活監視も仕込んでましたがアラートが来ることもなく、安定性もバッチリでした。実際に動かす前は結構気にしていた点で、動かし始めた当初は費用がかさんでいたのですが、いろんな工夫をした結果、1日あたりの費用は数十ドル程度までおさえることができました。既存プロジェクトのものを使うといった工夫をしています。後者の工夫がなければ、費用は跳ね上がっていたと思います。Dataflowの2つです。ツイートごとにログを吐き出す形にしていたため、前者は流量に比例するものですが、後者はCPUやストレージが常に必要になる以上、その動作時間に対して常に費用がかかり続けます。共有コアを使う(安価な)インスタンスタイプを割り当てられないことも費用がかさむ要因です。立ち上げてみて2週間という短い期間にもかかわらず、社内のリソースとGCPのマネージドサービスを使うことで、大量のデータを処理できるシステムを作ることができました。16:57Tweet関連記事2022-08-18AI開発時に、あるClassのデータを集中的に追加する時のTipsと注意点こんにちは!JX通信社シニアMLエンジニアのファンヨンテです。Corp.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。