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はその問題はクリアできそうです。ただ、規模が大きくなれば、それだけテーブルがどんどんできていくわけで、それはそれで面倒なことになる気もします。
この辺は実務を通して経験してみたいところだと思いました。
