Study

【Udacity】データエンジニア勉強中 -データモデリング-【3】

UdacityのData Engineering Nanodegree Programの経過報告になります。

前回はこちら

Udacity Data Engineering 進捗状況

全行程 2/6が終わり、今は「3. Cloud Data Warehouses」をやっています。

前回からやったことは、

  • RDBのプロジェクト
  • NoSQLの座学
  • NoSQLのプロジェクト

になります。

学習内容まとめ

RDBのプロジェクト

RDBのプロジェクトはPostgresにDB、テーブルを作成して、サンプルデータを突っ込んで、ETLを作成するというものでした。

テーブルは5、6個ぐらいで規模は大きくないのですが、ETLの実装のところでPandasを使っています。このPandasのところが少しわかりづらかったです。

というのもUdacityが意図しているデータセットを作成しないといけないのですが、それは書きかけのコードから読み解かないといけませんでした。何か、本題とは少しずれたところで時間をかけた感じがします。

まだPandasのデータセットを単純にforループでデータを取り出しているのですが、それパフォーマンス的にどうなの?と思いました。まあ、この辺は実務で問題がでたら対策することなのかもしれませんが。

環境はUdactiyが用意したJupyterのワークスペースがあるのですが、そこでコーディングするのは大変なので、ローカルに環境を構築してやりました。

NoSQLの座学

RDBのプロジェクトの後は、NoSQLのモデリングの座学がありました。

NoSQLといってもいろいろありますが、UdacityではCassandraをメインに使っていくようです。内容はCassandraの基本って感じでした。とはいえ、私はCassandraをほとんど使ったことがなかったので、良い勉強になりました。

以下、まとめノートです。

Udacity-DataEngineering2-2-lesson4

NoSQLのプロジェクト

NoSQLのプロジェクトは、Cassandraでキースペース、テーブルを作成して、サンプルデータを突っ込んでETLを作成するというものでした。扱うサンプルデータは違いますが、RDBのプロジェクトでやったことの、Cassandra版って感じです。

こちらは環境は、Jupyaterのワークスペースでなくノートブックでした。ローカルにCassandraを用意するのは大変そうなので、そのままUdacityの環境でやりました。RDBと違って、Pandasも出てこなくごちゃごちゃしたコーディングもなかったので、こちらはたいして時間がかからず終わりました。

座学の時、Cassandraって、DynamoDBと似ているなと思ったのですが、実際にプロジェクトで手を動かしてみて、全然違うなと思いました。

キーや分散の考え方はにていますが、テーブルの設計思想が全然違います。DynamoDBはユニット数をむやみやたら増やさないためにテーブル数は極力少なくなるように設計しますが、Cassandraは、Selectクエリごとにテーブルを用意します。

このクエリごとにテーブルを用意する考えは面白いなと思いました。DynamoDBは1テーブルにいろいろ突っ込むので、DB構築者しか知らないデータ構造になりがちですが、Cassandraはその問題はクリアできそうです。ただ、規模が大きくなれば、それだけテーブルがどんどんできていくわけで、それはそれで面倒なことになる気もします。

この辺は実務を通して経験してみたいところだと思いました。