(3) DBに取り込んだデータをクレンジングしていく
前回は、COVID-19関連のデータセットとしてジョンズ・ホプキンス大学のデータをNoSQLデータベースに取り込みました。今回はそのデータの内容を確認して、クレンジングしていきます。
どんなカラムが存在するか、確認する
前回の連載でも言及しましたが、ジョンズ・ホプキンス大学のデータは途中でカラムが増えたり、カラム名が変わったりすることが分かっていました。それでは、全体として重複削除すると、どのようなカラムが存在するのでしょうか？ 私たちのDataDiscovery™というソリューションは、NoSQLデータベース中の実データを調査することでスキーマ情報をリバースする機能を有しています。
ジョンズ・ホプキンス大学のデータをロードした際に、同時にスキーマ解析を実施していますので、さっそく解析結果を確認しました。結果は以下の通りでした。カラム名が辞書順で並べられています。「9」とあるのは数値型、「A」というのは文字列型だということを示しています。
前回の連載で「1月22日のデータは6カラムでスタートしたが、2ヶ月後の3月22日には12カラムに増えている」という旨を記載しましたが、今回しっかりした調査するとデータ項目は12個ではなく15個存在することが分かります。
ジョンズ・ホプキンス大学のデータ項目がどのように追加・変更されたのか、その変遷は以下の通りです。
- 1月22日に6項目で開始しました
- 3月1日に
LatitudeとLongitudeの２項目が追加されました
- 3月22日に、
ActiveとFIPSとAdmin2とConbined_keyが追加され、またLast UpdateがLast_Updateに、LatitudeがLatに、LongitudeがLong_に、それぞれ変更されました。
つまり、初日と最新のデータだけを確認しても、すべてのカラムを把握することができるとは限らない、ということです（今回の例で言えば、LatitudeやLongitudeなどを見落とします）。面倒ですが全データを網羅的に確認する必要がありますし、そのために今回のようにツールの力を利用すると効率的です。
クレンジング１：カラム名を標準化する
それではクレンジングをしていきます。
まず、上述の「Last UpdateがLast_Updateに、LatitudeがLatに、LongitudeがLong_に、それぞれ変更されました」の部分について。DB上のデータも補正していきます。
例えば、3月1日のDBデータはこのようになっています。
これを、3月22日以降のデータに合わせて以下のようにJSONプロパティの値を変更しよう、というものです。Last UpdateがLast_Updateに、LatitudeがLatに、LongitudeがLong_に、それぞれ変更されていることをご確認ください。
我々の利用しているNoSQLデータベースのMarkLogicでは、DBMS上でJavaScriptを実行してデータを更新することができますので、以下の処理を実行してJSONプロパティ（＝カラム名）を標準化しました。
まとめ：スキーマレスDBは「格納してから加工」
伝統的なRDB開発の場合、今回と同じようなことをしたい場合には、おそらく以下のようなプロセスで実施していたでしょう。
- 1月22日から直近までのすべてのCSVファイルのヘッダからカラムを調査
- カラムの追加・変更を考慮してテーブル定義（CREATE TABLE）
- カラムの追加・変更を考慮したETL開発
- CSVファイルをデータベースに格納
それに対して、今回のNoSQLデータベースを使った開発では、プロセスがまったく異なり「いきなりデータ格納」「格納後にスキーマを調査し、データを加工」という順番を採用可能なことがお分かりいただけると思います。
- まず1月22日から直近までのすべてのCSVファイルをデータベースに格納
- データベース上のJSONプロパティからツールベースでカラムを調査
- 変更されたカラム名の部分だけデータ加工
- 追加されたカラムについては考慮不要
スキーマレスDBの柔軟性が発揮されています。
次回は、さらにデータのクレンジングを進めていきます。
