2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

AzureFunctions + AzureStorage + AzureDocumentDBでデータImport1

Posted at

GYAOのtsです。
我々のチームは、オールパブリッククラウドで、Microservice Architectureを採用した次期バックエンドを設計中です。

経緯

突然なんですが、PJ内で色々ありまして、急遽設計を大幅に変更することになった。
我々のチームではよくあることだが、チーム全員がいい意味でまとまっているので今回もなんとかなりそうかなと思っています。その変更は以下のような感じ。
※なぜこうなったかは今回はなしで。

export.png

要は

  • Meta data
  1. jsonファイルを1行ずつ分割
  2. AzureFunctionでServicebusにtopicとしてpublish
  3. AzureFunctionがsubscribeしてDocumentDBに保存。
  4. DocumentDBに対してはrestで検索させる
  • Log data
  1. Sevicebusへtopicとしてデータをpublish。
  2. AzureFunctionがsubscribeしてDocumentDBに保存。
  3. MachineLearningのinput data resourceはDocumentDBを指定。定期的に取り込む。
  4. 学習結果はrestで提供。

のような流れだ。

こちらで書いた設計とはだいぶ変わった。。。

だいぶAzure一色になってきた。Apigeeだけ浮いているのでおそらくAzureAPIManagementとかになるかな。そのままApigeeでも面白いと思うが。

Blobコンテナ

Blobのコンテナにデータが作成されたらそれを1行ずつ読んで、servicebusにpublishする。
スクリーンショット 2016-11-24 16.44.44.png

json:testLines.json
{ "original_id" : "1", "b":false , "c":0 , "d":1 , "e":2 , "f":0.345 , "g":"あ" , "h":"い" }
{ "original_id" : "2", "b":false , "c":0 , "d":1 , "e":2 , "f":0.345 , "g":"あ" , "h":"い" }
{ "original_id" : "3", "b":false , "c":0 , "d":1 , "e":2 , "f":0.345 , "g":"あ" , "h":"い" }

ここで、original_idがドキュメントの識別子になるのだが、DocumentDBに保存する際、idという名前があるとDocumentDBのkeyとして登録されてしまうので、それは避けたい(こちら側でkeyは発行したい)。なので、idというエレメントがないかどうかFunctionsでチェックする必要がある。

次回

AzureFunctionsを使用して上記のjsonを読んでServicebusにpublishする

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?