Mongo DBからDatawarehouseへのリアルタイムストリーミングデータ

Question

アプリケーションから生成されたデータ（Eコマース注文の更新、配信、キャンセル、新規注文など）を保存するMongoDBコレクションがいくつかあります。現在、従来のETL （s3 /ステージング負荷のファイルに隠す）とDWへのロードを計画するアプローチ。データ量が増加しているので、リアルタイムストリーミング/類似と比較してレポートを生成するのに少なくとも1日遅れているため、効率が悪いように感じる一種の新しいETLアプローチです。ストリーミングオプションとして、まずApache Kafkaについてよく読んでいます。しかし、このMongo DBコレクションをKafkaのトピックに変換する方法が最大の課題です。 私はこれを読むMongoDb Streaming Out Inserted Data in Real-time (or near real-time)。キャップ付きコレクションを使用していないため、推奨されるソリューションはうまくいきません。

MongoDBコレクションはカフカのプロデューサーですか？ MongoDBリアルタイム/ニアリアルタイムからKafka以外のTarget DB/s3にデータを引き出す良い方法はありますか？ 注：Java/Scalaよりも現在のワークフローに簡単に統合できるPythonソリューションが好ましいです。

おかげ

Answer 1

あなたはETLへの代替を提供ELTアプローチを検討していますか？

ELTでは、データウェアハウスへの入力時にデータが処理されるため、ロード時間が短縮されます。ほとんどの場合、変換技術の設計は報告に使用されるプラットフォームに密接に結びついているため、ETLにはより良いハードウェアとソフトウェアの同期が得られるという利点があります。 ETL上ELTアプローチの

利点がある：

• 別個の変換エンジンの必要はありませんが、作業は、ターゲット・システム自体によって行われます。

• データの変換と読み込みが並行して行われるため、時間とリソースが少なくて済みます。速度はデータサイズに依存しません。

• データウェアハウスインフラストラクチャの処理能力により、データが転送に費やされる時間が短縮され、システムのコスト効率が向上します。

構造化、非構造化などの大きなデータソースをサポートするために、スケーラブルなクラウドインフラストラクチャで使用するに適した

しかし、いくつかの欠点がある：

• ELTの開発の詳細は、プラットフォームすなわちHadoopのに依存しますクラスタは、問題をより小さなチャンクに分割し、それらのチャンクを多数のマシンに分散して処理します。いくつかの問題は簡単に分割でき、他の問題はもっと難しくなります。
• 開発者は、変換を実行するために使用しているシステムの性質を認識する必要があります。システムによっては、ほぼすべての変換を処理できますが、十分なリソースがないものもあり、慎重な計画と設計が必要です。

ETLとELTの違いを説明しているPanoplyの記事を見てみましょう。