Uberのビッグデータプラットフォームが100ペタバイト超の規模に至るまで

Uberのエンジニアリングチームは、同社のビッグデータプラットフォームが、リレーショナルデータベースを使用した旧来のETLジョブから、HadoopとSparkをベースとするものへと発展した状況に関する記事を書いた。スケーラブルな取り込みモデル、標準転送フォーマット、インクリメンタルアップデートのためのカスタムライブラリが、同社プラットフォームの主要なコンポーネントである。

Uberでは、ライダーの需要予測や不正の検出、地理空間計算、さらにはライダーパートナー登録プロセスのボトルネック解消に至るまで、さまざまなチームがビッグデータを使用している。2014年に開発された最初のソリューションは、MySQLとPostSQLをベースとしていた。当時はデータ量が比較的少なかった — 数TB — ため、これらのRDBMSに格納するのに適しており、ユーザ自身がデータベースに問い合わせる方法を理解する必要があった。データの利用者は、都市部の運用チーム、データサイエンティストとアナリスト、エンジニアチームだった。

標準化作業の結果、列指向の分析プラットフォームであるVerticaが採用され、アドホックなETL(Extract-Transform-Load)ジョブでサポートされた。また、カスタムクエリサービスにより、SQLを使ったデータアクセス機能が提供された。データを使用するチームやサービスの数の増加に伴い、データ総量は数十TBに達した。この時点でUberが直面していた問題は、水平スケーラビリティの不足、費用の増大、データのプロデューサとコンシューマ間の正式なスキーマが存在しないことによるデータ損失だった。

次のフェーズでは、複数のストアのデータを変換せずに取り込むためにHadoopが採用され、Apache Spark、Apache Hive、クエリエンジンのPrestoがスタックに組み込まれた。Verticaは高速な反面、スケーラビリティに乏しかったが、Hiveには逆の問題があった)(PDF)。前フェーズでの問題は、独自のスキーマサービスを使ってスキーマとデータを合わせて格納することで解決した。データ総量は数十PBとなり、データインフラストラクチャは10,000仮想CPUコアを使用して1日に10万ジョブを実行するまでになった。

水平スケーラビリティは実現したが、HDFSのボトルネックが発生していた。HDFSクラスタでは、NameNodeがクラスタ内でファイルの保存されている場所を記録し、ディレクトリツリーをメンテナンスする。HDFSは大規模ファイルのストリーミングアクセスに最適化されており、多数の小さなファイルのアクセスでは効率が低下するのだ。データが10PBを越えた頃、Uberはこの問題に直面した。そこで、NameNodeのガベージコレクションを調整することでHDFSボトルネックを回避するとともに、サイズの小さなファイルの数とHDFSロード監視サービスを制限した。加えて、エンドユーザが十分な速度でデータを利用できないという問題もあった。エンジニアリングマネージャのReza Shiftehfar氏は、次のように記している。

Uberのビジネスはリアルタイムで運用されているため、当社のサービスは可能な限り新しいデータにアクセスする必要があります。データの提供速度を向上するため、パイプラインを再構築して、更新データと新しいデータのみをインクリメンタルに取り込めるようにする必要がありました。

画像提供 — https://eng.uber.com/uber-big-data-platform/

その結果として、Hudi(Hadoop Upserts anD Incrementals)という独自のSparkライブラリが開発された。HudiはHDFSとParquetに上にレイヤを形成し、更新と削除を可能にすることで、増大するETLジョブの目的に対応する。Hudiは、最後のチェックポイントタイムスタンプによってチェックポイント以降に更新された全データをフェッチすることで、テーブルの全検索を実行する必要なく、ユーザクエリを実行可能にする。これにより、それまで24時間であったレイテンシが、モデル化データの場合で1時間以内、未処理データならば30分になった。

Hudiの他にも、同社ビッグデータプラットフォームの最新フェーズでは、Apache Kafkaを通じて、メタデータを付加したデータの取り込みが追加されている。MarmarayというコンポーネントがKafkaから変更をピックアップし、Hudiライブラリを使用してHadoopにプッシュする。これがすべて、Apache MesosとYARNを使ってオーケストレーションされている。Mesosが長時間実行に適するのに対して、YARNはバッチ/Hadoopジョブに適している。Uberでは、Mesos上に開発した独自のスケジュールフレームワークであるPelotonを使用して、コンピューティングロードワークを管理している。