問題タブ [lambda-architecture]

予知保全用のリアルタイム アプリケーションを構築したいと考えています。Phoenix で Hbase を使用することを考えました。Phoenix は HBase 上に SQL レイヤーを提供します。

Hbase は 1 億行 plus++ のようなビッグ データに適していると読みました。しかし、私のアプリケーションデータには現時点ではデータがありません。最初に少量のデータしかない場合、Hbase データベースはどのように反応しますか? また、HBase はリアルタイム Web アプリケーションに適したソリューションですか?

システムのようなラムダ アーキテクチャが必要です。バッチおよびストリーム処理用。HDFS の上にある HBase は、OLTP と OLAP システムを組み合わせたものになりますか?

ラムダアーキテクチャにはバッチとスピードレイヤーがあるため。HDFS の HBase データを Batch にも使用して、結果を Hbase に保存できますか?

一般的に、HBase がリアルタイムの Web アプリケーションを構築して分析を行う可能性を持たせるための優れたソリューションであるかどうかを知りたいです。

私はラムダ アーキテクチャを構築しています。ストリーミング レイヤーをコーディングし、現在はバッチ レイヤーを実行しています。そのために、Spark 2 をバッチ プロセッサとして使用し、HDFS をマスター データとして使用しています。

HDFS からデータを読み取るために、次のコードを書きました。

ただし、このコードでは、Spark を実行した後に HDFS に挿入された新しいデータは読み取られません。どうすればそれができるのだろうか？

構造化ストリーミング ( http://spark.apache.org/docs/latest/structured-streaming-programming-guide.html )を使用したソリューションしかありませんか、それとも別のソリューションがありますか?

私は、spark によって実装されたラムダ アーキテクチャについていくつかの調査を行いました。以下の記事から、バッチ ビューとリアルタイム ビューをマージする方法が "realTimeView.unionAll(batchView).groupBy......" を使用していることがわかります。 batchView の背後にあるデータは非常に大きいため、そのような方法を使用するとパフォーマンスの問題が発生しませんか???

たとえば、batchView の背後にある行数が 100,000,000 の場合、クライアントがマージ ビューを要求するたびに Spark は 100,000,000 行をグループ化する必要がありますが、これは明らかに非常に低速です。

https://dzone.com/articles/lambda-architecture-with-apache-spark

AWS スタック上に Lambda アーキテクチャを構築しています。DevOps の知識が不足しているため、カスタム デプロイよりも AWS マネージド ソリューションを優先せざるを得なくなりました。

私たちのワークフロー:

ElasticCache、DynamoDB、S3 (Athena でクエリ) の 3 つのデータストアを既に使用しています。毎時 500,000 列から 6,000,000 列までのバッチ層を生成します。低レイテンシーのランダム読み取りでレイヤーを提供することで、過去 1 時間の結果のみをクエリする必要があります。

どちらのデータベースも、バッチ挿入とランダム読み取りの要件に適合しません。DynamoDB はバッチ挿入に適合しません。バッチ挿入に必要なスループットのためにコストがかかりすぎます。Athena は MPP であり、さらに 20 の同時クエリの制限があります。ElasticCache はストリーミング レイヤーで使用されますが、そこでバッチ挿入を実行することをお勧めします。

4 番目のストレージ ソリューションを導入するか、既存のソリューションを維持する必要がありますか?

考慮されるオプション:

1. バッチ出力を DynamoDB および ElasticCache に永続化します (ほとんど更新されず、圧縮/集約できるデータの一部は DynamoDB に移動します。頻繁に更新されるデータ ~8GB/日は ElasticCache に移動します)。
2. 別のデータベース (HBase on EMR over S3/ Amazon redshift?) をソリューションとして導入する
3. S3 Select を parquetで使用して、Athena の同時クエリ制限を克服します。これにより、クエリのレイテンシも短縮されます。しかし、S3 Select には同時クエリ制限がありますか? 関連情報が見つかりません。

最初のオプションは、ストリーミングで使用される ElasticCache への一括挿入のために不適切です。また、Lambda アーキテクチャに従っていますか? バッチとスピード レイヤー ビューを同じデータ ストアに保持しますか?

4 番目のデータベース ストレージがあるため、2 番目のソリューションは良くありませんね。