サービスのデータ品質向上を目指し、BigQuery、Amazon Athena や Metabase を採用。ビジネス向けのシンプルで効果的なデータソース管理戦略へ
G社は、2年目の新しいスタートアップで先日新しいWebサービスをリリースしたばかりでした。新サービスのプロモーションや顧客獲得、機能の追加開発に忙しい日々ですが、それとは別にある重要な課題を抱えていました。
課題まず、整合性の問題のあるデータにどうやってアクセスするかについて話し合いました。
データソースについて利用者がサービスを利用するときのデータの整合性が重要なので、アプリ側で整合性チェックをしたほうが良いのですが、最初の要望にあったように顧客の状況として難しいということで、案3)のRAWデータをデータソースとして分析できるシステムを作ることになりました。
その他要件と方向性G社ではすでにAWSとGoogleCloudを利用していたので、その中の各種サービスやOSS、自前でのツール開発も視野に入れ、いろいろな選択肢を組み合わせて素早く形にすることを目指しました。対象データソースの仕様も曖昧だったので、無理に仕様決定を行うよりは、試して問題があれば過程の中で逐次対応するような柔軟な進め方を取っています。
最終的なアウトプットは、BIツールのダッシュボードを予定しています。まず、今回の目的にフィットするBIツールの選定を行いました。仮セットアップして実際にデータソースに繋げられるものは繋いでみます。システムの構築・運用、ツールの使い勝手（分析のしやすさ、ダッシュボードの見やすさ、表現力）など、各種視点から評価を行います。想定する利用者にも実際に触ってもらって感想をもらいました。
候補の選出のポイント：囲い込まれることなく無料もしくは低コストでクイックにはじめられること、ずっと使いたいと思えること
Google DataStudio短期間での構築&検証をしてみると、やはり便利で Metabase を採用することとしました。
AWS S3に集積されたJSON形式のファイル群に検索クエリをかけて情報を可視化するのが目的です。それにそのままフィットするサービスとして、まず、Amazon Athenaを試すことにしました。
Athenaの設定をはじめてまず分かったのは、JSON対応といっても、その対応しているJSONの仕様に沿う必要があるということでした。
Athenaに直接取り込むJSONの条件AthenaがサポートするJSON形式に変換するために、ETLツールであるAWS Glue(Apache Spark)を利用しました。AthenaとGlueはシームレスに連携できるようになっており。簡単にAthena用のデータを出力することができます。
データソースはフォーマットの仕様が不明なRAWデータであり、100件くらいデータを眺めて日付型や数値として扱えるかなと思っても、全体に対して処理を実行すると、空文字、NULL、特殊な予定外の文字列などが検出されエラーとなることがありました。無理に数値や日付のような型に置き換えることはせず、最も柔軟性がある文字列型として素直に取り込むようにして、データ取り込み時のフォーマットエラーを回避するようにしました。
JSONの可変型のフィールドも、文字列型にフラット化して取り込んだのですが、その結果カラムのバリエーションが6,000弱となり、RDBに関連する各種ツールの挙動がおかしくなってしまいました。
JSON型に格納しているデータは優先度が低いということで、Glueの処理で一旦削除して処理を進めることにしました。
Glueで変換Athenaの実行エラーを解決するために使い始めたGlueですが、使い勝手がよく今後のフィールドの変換や自動更新についてもここで目処がたちました。
Glueの便利機能変換したデータに対しAthenaを設定しデータを繋ぎます。さらにMetabaseからデータソースとしてAthenaに接続します。 Metabaseでダッシュボードを作成し、ダッシュボードにRAWデータの内容が表示されることを確認しました。
次に、データの取得状況が分かるように、日毎のレコード件数のグラフを作成します。すると、グラフの表示でタイムアウトが発生してしまいました。
性能はそこまで重要ではないと考えていましたが、簡単な日毎の集計でタイムアウトするレベルでは、想定した用途で使えません。性能改善に向けて検討を進めることとなりました。
Athenaは、S3に格納されている大量のJSON形式のRAWデータにSQLでクエリを実行できる、今回の要件にフィットした素晴らしいサービスでした。しかし、そのままでは処理性能がボトルネックとなり今回の要件では役に立ちません。
性能改善のやり方はいろいろ考えられるが、すぐに出来て効果がありそうな方法として"データの形式をParquet形式に変えてみる"ことを試すことにしました。
現状は、JSONからJSONLに変換したファイルをそのまま格納し、このJSONLファイルにクエリを実行しています。この保存フォーマットをParquet形式にすることで列志向の格納形式となり、GROUP BYのようなクエリに対する高速化が見込めます。何よりGlueがParquet形式の出力をサポートし、AthenaもParquet形式の読み込みをサポートしているのため、今の仕組みの中で簡単に試すことができます。
GlueでParquet形式にしてS3に格納します。格納したParquet形式のファイル群に対してAthenaを設定します。その新しいAthenaに対してMetabaseの日毎のレコード件数のグラフのためのクエリを実行してみました。タイムアウトしていたダッシュボードは、数百msから数sec程度で気持ちよくグラフを表示するようになりました。これで、今回のデータ整合性のチェックを行うにあたり、十分実用に耐えうる性能に改善されました。
その後、発生している整合性の問題の条件を聞き、その日毎の発生件数をグラフにプロットし、その詳細をテーブルで出力するダッシュボードを作成、運用チームに共有し完了としました。
ところで、気になるのは、RAWデータの分析基盤といいながら、フラット化したときにカラム数が増えすぎるため削除することにしたあのJSONフィールドです。このシステムの役割としては、あらゆるRAWデータの情報を全てインデックス化し検索できるようにしたいところです。
そこで気になったのが、"BigQueryがJSONカラムをサポート(2022年10月)" というニュースでした。
BigQueryは非常に強力でよく利用しているサービスですが、いくつかの別のプロジェクトではコスト増に悩んでいます。念のためWebで比較記事を探したら検索クエリではAthenaの6.4倍くらいかかるというのもあり、今回のファーストチョイスから除外していた。
しかし、今回のRAWデータ分析基盤の構築を進めるにつれ対象データのサイズの実体が見えてきました。ビッグデータというキーワードや性能問題の話しからイメージしていたサイズより実際はかなり小規模であることも分かってきました。いよいよ、BigQueryでいいのではないかという考えが浮かびだしました。
実際、BigQueryでArray型、JSON型などを定義してデータを読み込むと、あっけないくらい簡単にデータがインポートできました。 BigQueryへのデータのインポートは無料なので、ちょっと間違えたらやり直せばいいというのも気楽なとこです。
テーブルサイズについても見てみると、思った通りかなり小さいことが判明しました。BIツールから繋いで、ダッシュボードからクエリをごりごり叩いてみる。やはり、問題になるサイズではありませんでした。
Amazon S3バケットに格納され、日々追加されている11種類のRAWデータファイル群について、クエリを実行してデータ整合性をチェックできる"RAWデータ分析基盤"を構築した。このシステムは、BIツールMetabaseのダッシュボードで可視化され、日々のデータ作成状況、発生した整合性問題の状況把握などに利用されています。
最終的な構成このシステムのリリース直後、さっそくあるデータソースの一部のフィールドについてデータの誤りが見つかり活躍の場が出来ました。その誤りに特化したダッシュボードを１時間程度で作成し、エンジニア、運用チームに共有しました。そのダッシュボードで、現象の範囲や影響度、修正の状況を把握することができます。ダッシュボード作成と共有のスピード感が大きな武器になっていることを実感しました。