SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Amazon Redshiftによるビッグデータ分析環境の構築

Amazon Redshiftの分析対象とするデータの設計/加工のポイント

Amazon Redshiftによるビッグデータ分析環境の構築(2)

  • X ポスト
  • このエントリーをはてなブックマークに追加

ファイル加工

 テーブル定義と並行して、取込対象となるファイルの精査・チェック作業を行います。構成されるデータがテーブル定義に正しく基づいたものであればこれらのチェックについてはあっという間に終わりますが、すべてのファイルが100%、きれいな状態であってくれているとは限りません(理想ではありますが……)。

 このチェック作業については、大きく以下2つのフェーズでその内容を弾き出すことができます。これら2段階のチェックを経て、不正な入力値が排除できるまでひたすら『トライアンドエラー』を繰り返す形になります。

  • ファイルベースでの事前チェック(当項で解説する部分)
  • Redshift上でCOPYコマンドを実行時に出るエラー内容

 当項ではまず、ファイルベースでチェックできる部分について洗い出そう、というところの説明をしていきたいと思います(いきなりS3にアップロードしてCOPYコマンドで試してみるのもアリですけども)。

 ファイルベースでチェックできるのは、主に以下のような部分です。

ファイルエンコードはutf-8に統一

 先述しましたが、Redshiftはシステム内のエンコーディングを「utf8」で統一しています。なので、もちろんマルチバイト文字が含まれるファイルエンコードが非utf8だった場合、正しく読み込んでくれません。既存出力ファイルがExcel由来のものである場合、得てしてShift_JISなど非utf8なエンコーディングのものであるというケースは多いです。なので、ファイル出力の時点で必ず『utf8』のエンコーディングとするようにしてください。エンコーディング変換については『nkf』というツールが便利です。

データの型にそぐわない入力値は排除する

 良くありそうな例で言うと、『日付項目に(未入力を示す)”0”(ゼロ)が含まれている』『数値項目にカンマが含まれている』などでしょうか。前者は出力元のシステム上では問題なく稼働していたかもしれませんが、Redshift上では日付型のフォーマットに数字は入らないのでエラーとなります。後者の場合ですと、Excelで見易さの観点からカンマが付与されていたりしますが取り込む際は不要な要素と成り得ます。このような値については、ファイル生成の時点で排除する必要があります。このように、定めたデータ項目に対して意図しないデータ内容、形式のものが混入されるケースは排除していかねばなりません。

区切り文字はデータ項目値の中に含めない

 この点は非常に重要です。なぜなら、Redshiftは所定の区切り文字で項目を分割し、テーブル定義と照らしあわせてデータを取り込んで行くため、データの中にその区切り文字が含まれてしまうとそこでデータ列の並びがズレてしまい、結果としてデータが正しく取り込まれなくなってしまうからです。『区切り文字がカンマ(『,』)のCSVなのに、データ列の中にカンマが含まれている、という状況は避けなければいけません。カンマ以外の場合であっても、この『区切り文字がデータ列の中に値として含まれている』という状況は避けなければなりません。

 データの中にカンマ(や他の区切り文字)を含まなければならない、というような場合は、その含みたい文字列以外の文字列を区切り文字とするなどして『取込の際に列がズレてしまうことを避ける』必要が出てくるでしょう。ファイル作成時に定めたその区切り文字でファイルを作成する、という処理も合わせて必要となってきます(項目内にカンマ区切りを含める替わりに、区切り文字をパイプ(|)とする、など)。

日付時刻フォーマットは統一する

 Redshiftでは後述するCOPYコマンドにおいて、取り込むべき項目の日付型(DATE)、およびタイムスタンプ型(TIMESTAMP)のフォーマットを指定することができますが、1テーブルの1つの型について1つしか指定ができません。ファイル(=取り込むテーブル)内で、例えば3つの日付型項目が存在した場合、

  • YYYY/MM/DD
  • DD/MM/YYYY
  • YY-MM-DD

というようにバラバラのフォーマットでは取り込むことができません。日付型、タイムスタンプ型については各々1つのフォーマットに統一し、ファイル出力の際もその統一したフォーマットで情報を出力する必要があります。

分析しやすいデータ構造にする

 データの中身に関する部分も大事ですが、データの構造そのものについても注意を払っておく必要があります。テーブル構造の正規化についても正規化し過ぎない(第2正規化程度に留めておく)ことなどは良く言及される点であるでしょう。行レベルの内容については以下ブログエントリでもまとめていますので宜しければ参考にしてみてください。

ファイル作成元に対するフィードバックを行う

 これらトライアンドエラーの過程で出てきたエラー内容については、出力元となるシステムや担当者にフィードバックを行い、以後同様のエラーや状況が発生しないように環境を整えて行きます。人力で作業を行っている場合、100%エラーを防ぐという状況は中々難しい部分がありますので、可能であればマクロやプログラムなどで半自動・自動化しておくことをお勧めします。

次のページ
テーブル定義 作成例

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Amazon Redshiftによるビッグデータ分析環境の構築連載記事一覧

もっと読む

この記事の著者

しんや(シンヤ)

2010年末~2013年前半位までの期間で興味のある勉強会に頻繁に参加。参加してきた勉強会のレポートブログとTogetterをひたすらまとめ続け、まとめ職人(自称/他称含む)として暫く過ごしておりました。色々な縁あってDevelopers Summit 2013では『公募レポーター』も務めました。2013年05月『出張ブロガー』を経て2013年08月にクラスメソッド株式会社へ転職。現在は業務(AWS及びその周辺技術を扱う)の...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/7866 2014/07/11 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング