リアルタイム分析システムの構築

第5章. サービング・レイヤーアパッチ・ピノ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

AATDは、スケーラブルなリアルタイム・アナリティクスを実現するためには、新しいインフラを導入する必要があるという結論に達したが、本格的なOLAPデータベース が必要だとはまだ確信していない。

この章では、リアルタイム分析用に設計された新しいタイプのOLAPデータベースの1つであるApache Pinotを紹介する前に、ストリームプロセッサを使ってストリームにクエリを提供できない理由を説明することから始める。orders ストリームを取り込む前に、Pinotのアーキテクチャとデータモデルについて学ぶ。その後、タイムスタンプインデックスについて学び、SQLを使ってPinotに対してクエリを記述する方法を学ぶ。

図5-1は、この章でインフラをどのように進化させていくかを示している。

図5-1. 受注サービスの進化

なぜ他のストリームプロセッサーを使えないのか？

前章の最後で、Kafka Streamsを使ってストリーム上でクエリを提供することの限界について、、いくつか説明した（「Kafka Streamsの限界」参照）。(Kafka Streamsの限界」参照）これらは決してKafka Streamsを技術として批判しているわけではなく、Kafka Streamsが設計されたタイプの問題に実際に使っていなかったというだけのことだ。

なぜksqlDBやFlinkのような別のストリーム・プロセッサーを代わりに使えないのか？ これらのツールはどちらもSQLインタフェースを提供しており、ストリームをクエリするためにJavaコードを書かなければならないという問題を解決している。

残念ながら、それでも根本的な問題を克服することはできない。ストリーム処理ツールは、分析クエリを大規模に実行するために構築されていないのだ。 これらのツールは、ストリーム処理アプリケーションを構築する際に優れており、ストリームのフィルタリング、ストリームの結合、アラートの作成などに最適だ。

しかし、1秒間に何万、何千というリクエストを処理するようなアプリケーションを構築したいのであれば、このような状況用にカスタム構築されたOLAPデータベースを導入する必要がある。

なぜデータウェアハウスは使えないのか？

データウェアハウスはOLAPデータベースの一形態であるが、 、、第2章で明らかにした要件（取り込み遅延、クエリ遅延、同時実行性）を満たさないため、リアルタイム分析には適していない。

バッチETLパイプラインは、BigQueryやRedshiftのようなビッグデータウェアハウスに。 しかし、これは取り込み遅延を引き起こし、クエリ時にデータが古くなる。 さらに、これらのクエリエンジンはミリ秒単位の遅延のために最適化されているのではなく、数秒単位の遅延を許容するアドホックなクエリのために最適化されている。 最後に、我々のサービングレイヤーは、ユーザ向けのアプリケーションを構築する場合、毎秒数千のクエリに拡張する必要があり、これはデータウェアハウスのスイートスポットではない。

アパッチ・ピノとは何か？

その代わりに、リアルタイムOLAPデータベース、 ...