後輩ができ、一応先輩ということになったunerryインターンのYukiです。

今回はタイトルにある通り、新たな試みに挑戦しました。その過程をレポートしていこうと思います！

気象データとの格闘

今回私は気象データ収集プログラムの修正タスクに取り組みました。因みにここで収集した気象データはunerryが提供している店舗の混雑予想を出す際に使用することになっています！

もともとこのプログラムは気象の実測値と予測値の２つを定期的に受け取り＋蓄積するはずでしたが、何らかの不具合によって正常に稼働していませんでした。その不具合を特定し、正しく動作するよう修正するというのが本タスクの目標です。

まずはプログラムの確認から。

仕組みとしては、契約している気象データ会社よりREST APIを用いて日本全国の気象データを読み込み、BigQuery に合うように整形し、Google Cloud Strage に一旦保存してから BigQuery テーブルを更新するという流れです。

ローカルでプログラムの実行。

まずは試しにローカル環境でプログラムを実行してみることに。すると驚いたことに、何の問題もなく処理が完了しました。一体プログラムのどこに不具合があるんだ？と不思議に思いつつ Google Cloud Strage を確認しに行くと、しっかりとファイルが保存されています。

しかし、BigQuery テーブルを覗いてみると、こちらは更新がされていませんでした。このプログラムは Google Cloud Strage から BigQuery テーブルを更新する部分に問題があることがわかりました。

問題の原因と対処を考える。

なぜ Google Cloud Strageには保存できるのに BigQuery テーブルは更新されないのか。

この謎を解明するのには少し時間がかかりましたが、気づいてみれば原因は意外と簡単なことでした。

当初は BigQuery テーブルを更新するため、プログラムに記述するスキーマ（データの型や並び方）や各種設定の記述が誤っているのではないかと考え、該当部分のコードを検索し、一行ずつ確認していきました。しかし、問題は見つからず、原因はここにはありませんでした。

その結果を踏まえて、テーブルデータを送り出すプログラム側に問題がないなら、データを受け取る BigQuery テーブル側に問題があるという仮説を立て、テーブル自体を調査しました。BigQuery にはパーティション分割という便利な機能があります。日付などの一定の基準でデータをグルーピングすることでデータの検索を素早く行えるようになる上、計算コストの削減も実現できます。

ただ、今回はこの便利な機能が悪さをしていました。パーティション分割数が上限の4,000を越えるとエラーが起きてテーブルの更新ができません。以下のリンクはその仕様の説明書になっています。
( Quotas and limits | BigQuery | Google Cloud )

修正前は分割基準が時間単位になっており、4,000÷24≒166.7(日分)だけしかデータを保存できないのです。そこで考えられる対処法として以下の二つを考えました。

今回は２つ目の案を採用することに。日単位でのパーティションにすれば4,000日分データを格納できることになります。年にすると約11年。それだけ保存できれば十分(11年後には代わりのより良いシステムが出来上がっているだろう)ということでこちらの案になりました。

既存のテーブルのパーティション分割基準を時間単位から日単位に変更し、それに合わせてプログラムの一部を修正しました。その後、プログラムの定期実行を行うVMインスタンス（仮想的なコンピュータ）に修正したプログラムを入れ、動作確認ができたところで本タスクは完了です。

これまでの経験から感じた外部からデータを持ってくること、BigQuery での効率的なデータ構造の作り方の難しさ。そして作り方のコツ

今回の気象データ収集では特に大きな問題はありませんでしたが、外部からデータを持ってくることは一筋縄ではいかないこともあります。

例えば前回のブログで触れた、緯度経度とその地点の高度（地面からの高さ）を整備するタスクでは、元となるデータの並び方が複雑だったり、想定と異なるものだと目的のデータを得る為にはかなりの時間と労力がかかってきます。

そのような場合、私は以下の4点を意識するようにしています。

1、2番は外部データソースを扱う際に最も重要で、そのデータの特徴を理解していなければ使いやすいテーブルデータを作ることはできません。

ここでいう「データの特徴」とは、そのデータがどのような土台（ファイル形式やスキーマ）の上に成立しているかを指します。その土台への理解が甘いと不安定な足場の上で作業を進めることになるので、当然成果物のクオリティも下がります。

逆にその特徴をしっかりと把握できれば、一見複雑に見える形式であっても使いやすいテーブルデータを作ることができます。

また、目標とするデータ構造を思い描けないままタスクを進めていると、後々多くの不都合が出てきてお手上げ状態になってしまいかねません。そのため構想をある程度持っておくことも非常に大切だと思います。

3番のツールの仕様確認も大切です。ツールの仕様がエラーの原因になっていることも少なくないのでこの点も忘れてはいけません。今回はまさにこのケースでした。

4番は特に定期的にプログラムを動かす際には大切です。例えばPythonだと、forループを一つ不必要に使っていた場合、数回プログラムを回すだけならそれほど大差はないですが、数十、数百回と実行すれば少しの無駄が大きなコストとなってしまいます。

そのためできるだけ効率的な書き方ができるようになると良いと思います。効率的な書き方の例としては、並列処理を行えるmultiprocessing関数などがあります。繰り返し処理を行う際にはfor文よりも圧倒的に処理効率が良くなります。

まとめ

前回のブログ更新時より出来ることの幅がさらに広がってきているのも感じますが、タスクをこなす際に的外れな修正を加えてしまったり、必要のない機能を加えたりといった無駄を少なく抑えられるようになっていると思います。これは嬉しい進歩と言えるのではないでしょうか！

今後は新しいスキルを増やすことも継続しつつ、既に扱ったことのあるスキルの腕前を上げて、素早く正確にタスクをこなせるようになることを目標にしたいです！

• #インターン
• #データサイエンティスト
• #データを楽しむ
• #仲間募集