MySQLからレッドシフトに近いほぼリアルタイムのETL

Question

私は、MySQLからデータを抽出し、変換し、ほぼリアルタイムでRedshiftにロードする最も効率的な方法を見つけようとしています。 現在、私たちは夜間ETLプロセス（Pentahoを使用しています）が〜40分であり、それをほぼリアルタイム（ミニバッチ1-5分）に置き換えたいと考えています。

それを書いて、私はAWS Kinesesにコネクタを持つMySQLのバイナリログ（すなわちhttp://maxwells-daemon.io）からのデータ抽出のためのツールのカップルを発見し、私は変換し、参加データをApacheのスパークやAWSラムダとし、S3にそれを書くために計画し、そこCOPYコマンドからレッドシフトに

誰もこの似たような解決策に関する提案や推奨はありますか？ ありがとうございます！

Answer 1

実際には、MySQLからのデータに対してどのような変換を行いたいのか、どのような言語とフレームワークがあなたの環境に最も適しているかによって異なります。

以下

が私の提案

1. は、MySQLと赤方偏移の間の仲介ストレージを追加している、例えばS3
2. は赤方偏移の場合のデータのロード中にデータの再ローディング機構が

を失敗した私は考えるだろう考えてみましょうAWS Data Pipelineはすぐに使用できるテンプレート、再試行メカニズム、組み込みのロギングとモニタリングを備えているためです。

それは次のようになります。

のMySQL - > S3 - >赤方偏移（ステージング） - > SQL - >赤方偏移（生産）

のMySQL - > S3

このデータパイプラインは "Incremental copy of RDS MySQL to S3"テンプレートで始まります。

MySQLのインクリメンタルデータを格納するS3パスをパラメタ化できるため、S3プレフィックスを使用してこれらのインクリメントを時間の経過とともに管理する方が簡単です。 S3上のデータを再度使用しない場合は、S3 Object Lifecycle Managementを使用してこれらのオブジェクトを定期的に削除することができます。

しかし、S3のデータを使用すると、AWS Athenaを使用してクエリを実行したり、QuickSightを使用して視覚化したり、まれにアクセスが少ない、または氷河のストレージクラスを使用してアーカイブするだけでストレージのコストを削減できます。

S3 - >赤方偏移（ステージング）もちろん

は、ご利用の場合のために、それは赤方偏移に行かなければならないので、私はAWS赤方偏移ローダーラムダをお勧めします。設定はやや複雑ですが、正常に完了すると、管理がゼロに近づきます。 this

AWS Redshift Loaderを使用すると、データが定義されたS3接頭辞に到着するたびにRedshiftクラスタにロードされます。もう1つはRedshiftクラスタにロードされます。ロード前にxファイルを待つか、y分ごとに読み込むなど、他のオプションもあります。

また、S3からRedshiftへのデータの一部のみをテスト環境または開発環境にロードする必要がある場合があります。 AWS Redshift Loaderを使用すると、特定のS3接頭辞のみを定義できます。/data/2017/11を押してRedshiftにロードします。

Redshift Loaderを使用すると、データが非同期に読み込まれるため、マイナーチェンジしてそのプロセスを制御するのが少し難しくなります。これは、あなたのケースで問題になるかもしれないし、そうでないかもしれません。

Redshiftへのデータロードが失敗した場合は、Redshfit Loaderコマンドラインツールを使用して特定のオブジェクトをRedshfitに再ロードします。

赤方偏移（ステージング） - >赤方偏移（生産）赤方偏移は、あなたが赤方偏移テーブルに重複行を挿入しないようにするメカニズムを持っていなければならないことを意味する、例えば、ユニーク・キーの、参照整合性を強制しないことを

注意。重複を心配しなければ、これは無関係です。データは既にRedshiftにあります。

なぜ重要ですか？ソース（つまりMySQL）から取得したデータが既にRedshiftにある場合は、実行するアクションを知っておく必要があります。あなたはそれを上書きするか、無視しますか？

Redshift自体でそれを行うことで、一意の列を使用して新しい行と既存の行を比較し、削除と挿入、あるいは更新することが容易になります。 Redshfitの外でそれを行うと、おそらくRedshiftの外部で利用可能な独自のキーを追跡して比較することになります。どこ？いつそれらを更新するのですか？どうやって？多分あなたはすでにそれのための解決策を持っています。

したがって、前の手順では、データをRedshift（ステージング）に挿入します。実稼動テーブルに移動するときにデータの整合性を保証するために、マージを行う必要があります。 AWSは、following技術をRedsiftのデータをマージすることを推奨しています。

これが当てはまる場合は、SQLを使用して変換を行って、管理するコンポーネントが少なくて済むようにしてください。

SQLを使用して変換ジョブを定義し、それらのSQLスクリプトをS3に保存し、SQLActivityで参照して、データマージスクリプトと一緒にRedsshiftクラスタで実行することができます。

AWS Kinesisは、S3機能への変換とストレージがあれば適切かもしれません。私が上に挙げたいくつかのポイントは、キネシスの使用にも適用されます。