Mongo DBと相性が良いETL : Xplentyを利用するメリット

クラウドETL「[Xplenty](https://www.xplenty.com/jp)」では、データソースおよびDestination（送信先）の両方においてMongoDBのネイティブコネクタを提供しています。そして、MongoDBのテクノロジーパートナーでもあります。今回は、XplentyのMongoDBに関する機能と利用するメリットについて紹介したいと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65461/2bbabf01-6476-5b23-bb48-e310b0d5de98.png)
以下では、XplentyのMongoDB統合機能について紹介します。
#MongoDBからデータを取得する
##MongoDB接続の設定
XplentyパイプラインでMongoDBを使用するには、まずXplentyダッシュボードでMongoDB接続を追加します。XplentyのMongoDB接続は、SSLをサポートしていますので、MongoDBとのデータのやり取りは安全なプロトコルで行われます。

ほとんどのデータベースサービスと同様に、MongoDBをセットアップするには、マネージド型とセルフホスト型の2つの方法があります。

- **セルフホスト型**：MongoDBを自分でマシンにインストールする必要があります。
- **マネージド型（クラウド版）**：MongoDBチームが提供するマネージド版は[MongoDB Atlas](https://www.mongodb.com/ja-jp/cloud/atlas)と呼ばれています。オートスケーリング、モニタリング、アラート、バックアップ、データレイクなどの他のツールとの統合など、いくつかの優れた機能を備えています。

###MongoDBへの接続
Xplentyでは、MongoDBへの接続方法として「DNS Seed List（SRV）」もしくは「Replica Set Members」が指定可能です。「Replica Set Members」を指定する場合、レプリカセットのホスト名を１つもしくは複数していします。

また、**Read Priference**（読み取りの優先度）を指定し、レプリカセットのメンバーへ読み取り操作をルーティングするかを指定することが出来ます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65461/0fc13068-4ec1-bc04-bfae-8e08518886b6.png)


#MongoDBに対してデータを書き込む
Xplentyでは、AppendやUpsertといった更新時の更新方法を簡単に設定することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65461/612aaebf-e6fc-cc7d-9603-723369a20a22.png)
***Insert (Append:追加のみ)***
受信データを新規データとして処理し、ターゲット・コレクションに追加します。ソースから新しいデータだけが入ってくるとされる場合に便利です
***Merge（Upsert:差分更新）***
設定したマージKeyに基づき既存のドキュメントを更新し、存在しない新しいドキュメントを挿入することで、ターゲット コレクション内のデータをマージします。これにより、既存のドキュメントのみを更新することができ、ターゲットコレクションに重複したドキュメントが挿入されるのを防ぐことができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65461/5eadbaa3-8681-ea4c-3894-aa693a87895c.png)
#MongoDBでのETL処理における６つの課題
##1. 動的スキーマからリレーショナル形式への移行
MongoDB は、定義済みのリレーショナルスキーマではなく動的スキーマを使っています。このため、MongoDBからリレーショナル形式を必要とする一般的なデータウェアハウスにデータを移行する際には、問題が発生します。
**Xplentyのデータマッピングツールを使えば、移動先に読み込む前にMongoDBのデータを互換性のあるスキーマに変換することができます。**
##2. 矛盾するデータ型の変換
MongoDBコレクション内の異なるドキュメントで、異なるデータフィールドタイプ/値を使用していることは珍しくありません。たとえば、あるドキュメントでは電話番号を文字列 [(555) 555-5555] として記録し、別のドキュメントでは番号 [555555555555] として記録しているとします。
**Xplentyでは、リレーショナルデータウェアハウスにデータをロードする前に、単一のフォーマットを選択し、外れ値を変換することができます。 **
##3. 互換性のないデータ型の変換
MongoDBは、Javascript、正規表現、ObjectIdなど、データウェアハウスがサポートしていないであろう多種多様なデータ型をサポートしています。
**Xplenty はこれらのデータ型を、データウェアハウスがサポートしている形式に素早く変換することができます。**
##4. 深くネスト化されたオブジェクトや配列をフラットにする
MongoDBでは、深くネスト化されたオブジェクトや配列を作成することができるため、それらをDWHに投入する時にフラットにするのに苦労します。
**Xplentyのデータマッピングツールを使えば、ネスト化されたオブジェクトを素早く抽出してフラットにし、リレーショナルデータウェアハウスのレコードに収まるようにすることができます。**
##5. データウェアハウスのスキーマに新しいフィールドを追加する
MongoDBではUPDATEコマンドで新しいフィールドをドキュメントに追加できますが、リレーショナルデータウェアハウスではこのような変更を行うのはそう簡単ではありません。
**MongoDBで新しいフィールドが検出された場合、Xplentyは設定オプションを使って、それらの変更を追加先のスキーマに追加したり、事前にSQLでALTERしたりすることで行うことができます。**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65461/044459a8-0866-7aa5-dcee-e39dd42573b3.png)
#6. カラムのサイズ変更
MongoDBはドキュメント全体に16MBのしきい値を設定していますが、個々の文字列列の長さを制限するわけではありません。しかし、リレーショナルデータウェアハウスでは文字列カラムのサイズに制限があるかもしれません。
**Xplentyを使えば、MongoDBのカラムがデータウェアハウス側の制限を超えたときにはいつでもリサイズするようなワークフローを設定することができます。**
#最後に
もしMongoDBのデータをDWHに移動するのに苦労されている方は、ぜひXplentyをお試しください。
製品のデモに興味のある方は、[こちらのサイト](https://calendly.com/xplenty-etl-pipelines/trial-setup/?action=schedule&controller=help&month=2019-11&utm_source=xp&utm_medium=blog&utm_campaign=content)より申し込みください。（予約サイトは英語ですが、日本語でデモします）