GitHub リポジトリに貯めていく分析 SQL 運用

Da Vinci Studio 分析チームの濱口です。
分析チームでは各々が書いた SQL をドキュメントにまとめて GitHub リポジトリに貯めて共有しています。この試みを始めてから1年ほどたったので、運用してみて感じたことや気づいたことについて紹介しようと思います。

背景

SQL を GitHub リポジトリに貯め始めたのは、以下のような問題意識からでした。

レビューの枠組みがなかった

ちゃんとした枠組みがなく、タスク管理ツール上で雑に行われていたり、そもそもレビューが行われていなかったりという状態でした。このような状態が続いてしまうと、SQL のミスやデータの誤りに繋がってしまい、データの信頼性が損なわれてしまいます。

書いた SQL が集約されていなかった

様々なところでレビューされていたりされていなかったりで、それぞれの書いた SQL がどこにあるのかがわかりづらい状態でした。他の人が書いた SQL を参考にしたり再利用したりするのにも一苦労で、とても非効率です。

GitHub リポジトリに貯めるまでの流れ

貯めるまでの流れですが、特に特別なことはなく

1. プルリクエストを作成する
2. レビューをもらう

という手順になります。

1. プルリクエストを作成する

マークダウン形式のファイルに作成した SQL の概要、実際に書いた SQL などを記載したプルリクエストを作成します。ディスクリプションには、データ抽出の目的と SQL を実行して抽出したデータを記載し、データの数値についても確認できるようにしています。

2. レビューをもらう

チームメンバーからレビューをもらい、SQL やデータに誤りがないかチェックします。
ディスクリプションにレビューのチェック項目を設けており、その項目に沿ってレビューを行うことで漏れが出ないように対策しています。最低でも1人から Approve もらって問題なさそうであればマージします。

運用してみて

• クエリのミスやデータのエラーに気づけるようになった
• 他の人が書いた SQL を再利用しやすくなった

といったように、当初抱えていた問題は解消できました。
しかし、運用する上でまたいくつか別の課題が出てきました。

参考にしたいファイルが見つからない

最初のうちは良かったのですが、ファイルがどんどん増えていくうちに参考にしたいファイルを見つけるのが困難になってきました。
解決策として、全てのファイルを同じ 1 つのフォルダに貯めていたのを、外部と内部の案件別で分割した上で、さらにデータマートごとにクエリを分けるようにしました。

レビューが滞る

データの抽出内容によってはかなり長い SQL になることもあり、とにかくレビューが大変でした。 レビューが大変だと後回しにされがちで、レビューが滞るという問題が出てきました。
この問題に関しては

• SQL のコーディングスタイルを定める
• 再利用できる箇所は切り出して共通化する

などを行っており、現在も改善を続けています。 上記２つの改善についてはいくつか別のブログにもまとめています。

blog.da-vinci-studio.com

blog.da-vinci-studio.com

まとめ

• プルリクエストによるレビューを実施することで、データの信頼性向上につながった
• GitHub のリポジトリに集約することで他の人が書いた SQL を再利用しやすくなった

運用していて出てきた新たな課題についても、さらに改善していきたいと思います。

We are hiring!!

Da Vinci Studio では一緒に働ける仲間を絶賛大大大募集中です！

データ分析に興味がある方、それ以外の開発に興味がある方、あるいは一緒に働いてみたいという方は recruit@da-vinci-studio.net までご連絡ください。

Core Web Vitals 数値の改善

Da Vinci Studio 第 2 サーバー部、社会人 2 年目の吉延です。 今回は最近開発してリリースしたばかりの 『ごっこランドTimes』で行った Core Web Vitals(CWV) 数値、その中でも First Contentful Paint(FCP) と Largest Contentful Paint(LCP) 数値の改善に焦点を当てた施策について紹介します。『ごっこランドTimes』は子どもの興味・関心を伸ばし、親子で一緒に楽しめる情報が満載のメディアです。Web フレームワークとして Ruby on Rails を用いて開発しています。

背景

SEO 対策はサイトへの集客アップのため重要なのは既知の事実かと思いますが、2021 年 6 月から CWV も Google の検索ランキングの要因となります。 ( 詳しくは Google 検索セントラルブログ を参照してください。) CWV はユーザー体験をより良いものにするために Google が提唱しているコンセプトで、表示速度、反応速度、表示の安定性の 3 つ要素に焦点が当てられています。そのため、表示ズレやサイトスピード改善はより重要となります。これらのスコアや細かな指標は PageSpeed Insights で測定することができます。

改善前の状態

対象のサイトは表示ズレに関わる Cumulative Layout Shift(CLS) のスコアは良かったので、表示速度に関連する FCP と LCP に焦点を当てて改善を行いました。 改善前のスコアを計測してみたところ、 FCP の良好とされるスコアは 1.8s 未満、 LCP は 2.5s 未満とされているのでかなり悪いことがわかります。現状は広告も入っていない状態にも関わらずこの状況なので、将来的に広告が入った場合さらにスコアが下がることが予想されます。

• TOP ページ
  FCP : 6.7s
  LCP : 9.2s
• 記事ページ
  FCP : 7.1s
  LCP : 9.5s

改善前のTOPページのスコア

改善前の記事ページのスコア

改善の方針

ではどんな施策をすればよいのだろう？となるのですが、それについては PageSpeed Insights の「改善できる項目」が参考になります。どの項目に対する施策を打つのかについては各サイトの性質によって異なると思うので、そちらを考慮した上で項目を選択してください。対象のサイトでは

• レンダリングを妨げるリソースの除外
• 使用していない JavaScript, CSS の削除

に対応した施策を打ちました。

施策一覧

検討した施策は以下となります。

• Web フォントを除外する
• 表示処理に関係のない JavaScript の読み込み順番の変更
• 使用していない JavaScript の削除
• 表示サイズが小さい画像の Retina 対応をやめる
• オフスクリーン画像の遅延読み込み
• ページごとに CSS を分割する

各施策の詳細

Web フォント ( Google フォント) の使用をやめる

こちらが一番効果があると思います。 Web フォントを使用しているのであれば一番に検討すべき施策です。 Web フォントを外すだけで対象サイトの記事ページでは以下のようにスコアが改善されます。

• FCP : 7.1s → 1.7s
• LCP : 9.5s → 2.7s

Web フォントありのスコア

Web フォントなしのスコア

しかし、 Web フォントを外すとサイトの印象がガラリと変わってしまうので、そのあたりを十分に考慮した上で Web フォントを使用するかどうか検討すべきです。一部の固定の文字のみに Web フォントを使用したい場合は URL に &text= を付けて当てたい文字を記入すればサブセット化されるので、少量のフォントの呼び込みで済みます。

<link rel="preconnect" href="https://fonts.gstatic.com">
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@500&display=swap&text=フォントをあてる文字" rel="stylesheet">

表示処理に関係のない JavaScript の読み込み順番の変更

JavaScript を外部ファイルとして HTML で読み込む場合、記述順に呼び込まれます。なので表示処理に関係のないファイルはなるべく最後に呼び出したほうが良いです。そうすることでファーストビューの描画が早くなり、 FCP や LCP のスコア改善につながります。対象のサイトで表示に関係ないものをなるべく body 要素に近い場所で呼び出すようにしました。

使用していない JavaScript の削除

余計な JavaScript を読み込むと表示に時間がかかる場合があります。なので使用していないものは気づいたら削除しておくのが良いと思います。不要なファイルの見つけ方として Google Chrome の検証モードを用いるのが良いと思います。 検証モード内の Network 項目を見ると、呼び出されいる js ファイルのサイズや処理時間の一覧を見ることができるので、不要な js ファイルや処理に時間がかかっているファイルを見つけることができます。また、ネットワークスピードを Fast 3G にしておくと、 PageSpeed Insights のネットワーク環境に近づけることができます。対象サイトでは active storage や action cable を使っていませんでしたが、 rails new 時に skip し忘れていたので残っていました。

表示サイズが小さい画像の Retina 対応をやめる

サイトで使用している画像は Retina ディスプレイ対応させるため、元の画像サイズを表示されるサイズの 2 倍の大きさにしていることが多いと思います。もちろんこの対応すると読み込むデータ量が増えるため、表示スピードが遅くなる可能性があります。なので比較的 Retina 対応の影響が少ない、表示サイズの小さい画像の元サイズを表示サイズと同じにすると速度改善する場合があります。

オフスクリーン画像の遅延読み込み

オフスクリーン画像を最初のロード時に読み込む必要がないので、それらの画像を遅延読み込みするのが良いです。 JavaScript で遅延読み込みを行う方法もありますが、 HTML5 の標準仕様の loading 属性を使って画像に loading=lazy を付与するだけで HTML だけで遅延読み込みを行うことができます。

<img width="116" height="116" alt="" loading="lazy" src="image.png">

ページごとに CSS を分割する

• app/javascript/packs/application.js

require("stylesheets/application")

• app/views/layouts/application.html.haml

= stylesheet_pack_tag "application"

上記のようにとすべての CSS ファイルと一度に読み込んでいませんか？このようにすると当然、無駄な CSS も多数読み込むようになります。そこで各ページごとで読み込む CSS を分割する方法があります。各ページに対応したエントリーポイントとなる js ファイルを用意してそのファイルの中で必要な CSS のみを呼び込むようにします。

• app/javascript/packs/article.js

import "../stylesheets/article.css"

そして各ページに対応する view ファイルから対象の js ファイルを呼び出します。

• app/views/articles/show.html.haml

= stylesheet_pack_tag 'article', media: 'all'
= javascript_pack_tag 'article'

このようにすることで無駄な CSS 読み込みを避けることができます。規模が大きなサイトほど効果がある施策だと思いますが、大きくなってからだと対応が大変になるので、規模が小さいうちから対策しておくことをオススメします。

結果

対象のサイトでは開発環境でスコア改善が見られた以下の施策を実施しました。

• 表示処理に関係のない JavaScript の読み込み順番の変更
• 使用していない JavaScript の削除
• オフスクリーン画像の遅延読み込み
• ページごとに CSS を分割する

対象のサイトでは Web フォントを除外してしまうとサイトの印象が大きく変わってしまうため、 Web フォントは除外しませんでした。以下が対策後の数値です。良好なスコアにすることはできませんでしたが、 LCP は対策前と比べると TOP ページでは約 13% 、記事ページでは約 22% ほどスコア改善することができました。

TOP ページ

• FCP : 6.7s → 6.5s
• LCP : 9.2s → 8.0s

改善前のTOPページのスコア

改善前のTOPページのスコア

記事ページ

• FCP : 7.1s → 7.1s
• LCP : 9.5s → 7.4s

改善前の記事ページのスコア

改善前の記事ページのスコア

まとめ

『ごっこランドTimes』 で行った CWV 数値、中でも FCP と LCP 数値の改善に焦点を当てた施策について紹介しました。サイトによって効果がある施策、ない施策は異なると思うので、まずは試してみると良いと思います。

コーディング規約を定めて SQL の可読性を上げる

Da Vinci Studio データ分析チームの濱口です。
現在データ分析チームで運用されている SQL のコーディング規約について紹介します。

なぜコーディング規約を定めるのか

SQL のコーディング規約を定める主な理由として、 可読性を上げるというのがあると思います。 スタイルを統一せず、書き手によって異なるスタイルで書いていると以下のような弊害が発生します。

レビューしづらい

他の人が書いた別の作業の SQL というだけでも読みづらいですが、コーディングスタイルが揃っていないとさらに読みづらくなってしまいます。 そうするとレビューにも時間がかかってしまい、他の作業に割ける時間が短くなってしまいます。

再利用しづらい

Da Vinci Studio の分析チームでは、過去に書いたクエリを GitHub のリポジトリに貯めており、他の人も再利用できるようにしています。 しかし SQL が読みづらいとバグも発生しやすくなり、かえって作業効率を悪くしてしまいます。

どんな SQL に適用すべきか

他の人が読む可能性がある SQL は全て、定めたコーディング規約に則って書くことにしました。具体的には

• 他チームからの依頼の SQL
• アプリケーション内で利用される SQL

などを指します。個々人のアドホックな分析に関しては、必ずしもスタイルガイドに沿わなくてもいいというルールにしました。

コーディング規約

以下で定めているコーディング規約をいくつか紹介します。
なお、今回は分析チームで主に利用されている BigQuery の利用を前提としたコーディング規約になっています。

予約語は小文字で書く

# NG
SELECT
  name,
  comment,
FROM SAMPLE.table
WHERE
  name = 'name1'

# OK
select
  name,
  comment,
from SAMPLE.table
where
  name = 'name1'

SQL の予約語は大文字で書く文化が広く浸透しており、大文字で書く人はかなり多いかと思います。 しかし上記を踏まえた上でも、小文字で書く方が良いと思った理由として

• 予約語だけ大文字で書くのめんどくさい
• 予約語だけ大文字で書いても可読性は変わらない

の2点でした。可読性が変わらないのであれば、予約語だけ大文字で書くメリットはないという結論に至りました。

select 句のカンマの位置は行末

# NG
select
  name
  , comment
  , date
from SAMPLE.table

# OK
select
  name,
  comment,
  date,
from SAMPLE.table

このルールは可読性というよりは、試行錯誤の効率の観点で決められました。

• 行頭にカンマを書くと、一番上のカラムをコメントアウトの際にエラーになってしまう
• BigQuery は select 句の最後の行にカンマがついていてもエラーにならないので、一番最後の行をコメントする際もカンマの削除が不要

の2点が主な理由です。より少ない労力で各行をコメントできる書き方を採用しました。

where 句の and と or は先頭に置く

# NG
select
  name,
  comment,
from SAMPLE.table
where
  date between date('2021-04-27') and date('2021-05-05') and
  name = 'name1' or
  comment = 'comment1'

# OK
select
  name,
  comment,
from SAMPLE.table
where
  date between date('2021-04-27') and date('2021-05-05')
  and name = 'name1'
  and comment = 'comment1'

条件が複雑で長くなっている際に and や or が行末についていると見づらいというのがありました。 先頭に書いておけば、条件のかたまりの切れ目が分かりやすく良いのではという議論がありました。

サブクエリではなく、 with 句を使う

# NG
select
  name,
  sum_price
from (
  select
    name,
    sum(price) sum_price,
  from SAMPLE.table
  where
    date between date('2021-04-27') and date('2021-05-05')
  group by name
)
where
  sum_price >= 10000

# OK
with
  t_base as (
    select
      name,
      sum(price) sum_price,
    from SAMPLE.table
    where
      date between date('2021-04-27') and date('2021-05-05')
    group by name
  )
select
  name,
  sum_price
from t_base
where sum_price >= 10000

主な理由としては

• 一つのクエリが大きくなりすぎない
• ネストが深くなりすぎない
• 同じクエリを何度も再利用できる

の3点が挙がりました。可読性だけでなく、再利用性の観点からも with 句を使うようにしています。

ビフォーアフター

以下、全ての規約を適用したときのビフォーアフターの一例です。

# 適用前
SELECT
  date,
  target_name,
  SUM(price) sum_price,
  AVG(price) avg_price,
FROM (
  SELECT
    date,
    CASE
      WHEN regecp_contains(name, r'regexp1') THEN 'name1'
      WHEN regecp_contains(name, r'regexp2') THEN 'name1'
    ELSE null
  END target_name,
    price,
  FROM DataBase.table1
  WHERE date BETWEEN DATE('2021-01-01') AND DATE('2021-01-31'))
WHERE target_name IS NOT NULL
GROUP BY date, target_name
GROUP BY date, target_name

# 適用後
with
  t_base as (
    select
      date,
      case
        when regecp_contains(name, r'regexp1') then 'name1'
        when regecp_contains(name, r'regexp2') then 'name1'
        else null
      end target_name,
      price,
    from DataBase.table1
    where date between date('2021-01-01') and date('2021-01-31')
  )
select
  date,
  target_name,
  sum(price) sum_price,
  avg(price) avg_price,
from t_base
where target_name is not null
group by date, target_name
order by date, target_name

紹介した規約以外にも、インデントに関する規約などが適用されており、読みやすくなりました。 規約通りにかけているかのチェックは、現状は目視で確認しています。最低限レビューや後で読み返すときに困らない程度の可読性を保てたら良いので、そこまで厳密にはチェックしていません。

まとめ

分析チームで運用している SQL のコーディング規約についてまとめました。カラム名や with 句における命名規約なども定めていますが、それはまた別の記事で紹介しようと思います。
このコーディング規約はあくまでも一例で、状況によって規約の内容や運用方法は変わると思います。その時のチームの課題や状況に応じてアップデートしていきたいと思います。

We are hiring!!

Da Vinci Studio では一緒に働ける仲間を絶賛大大大募集中です！

データ分析に興味がある方、それ以外の開発に興味がある方、あるいは一緒に働いてみたいという方は recruit@da-vinci-studio.net までご連絡ください。

BigQuery で定数を使う方法

Da Vinci Studio 分析チームの末安です。
今回は BigQuery で定数を使う方法をいくつか紹介します。

日付だけ変えて同じクエリを実行したいケースなどよくあると思いますが、変更箇所が漏れていたりして無駄に時間を消費してしまったりします。 こういう場合、定数にしておくと便利です。

まず前提として BigQuery では、定数を定義する機能はありません。( 2021年05月時点 )
ここで紹介する方法は、定数っぽくつかえる BigQuery の機能になります。

今回紹介する方法は以下の 3 つです。

• with 句を利用する
• UDF を利用する
• BigQuery Scripting を利用する

ではひとつずつ説明していきます。

with 句を利用する

with 句で固定値をサブクエリとして定義することで定数っぽくする方法です。

with
  const as (
    select date('2021-04-01') st, date('2021-04-30') en
  ),

  date_array as (
      select 
        date(sequence) item,
      from unnest(generate_date_array('2021-01-01', '2021-05-01')) sequence
  )

select
  date_array.*
from date_array, const
where
  item between const.st and const.en

このように定義した const というサブクエリを CROSS JOIN することで利用します。
都度 from に書く必要があって少し面倒です。

UDF を利用する

UDF とは、ユーザー定義関数のことです。固定値を返す関数を定義することで、定数のように扱うことができます。

cloud.google.com

create temp function const()
as (
  struct(date('2021-04-01') as st, date('2021-04-30') as en)
);

with 
  date_array as (
      select 
        date(sequence) item,
      from unnest(generate_date_array('2021-01-01', '2021-05-01')) sequence
  )

select
  date_array.*
from date_array
where
  item between const().st and const().en

上記の場合では、構造体を返すようにすることで複数の定数を一つの関数で定義できるようにしています。
with 句を利用する方法と違って CROSS JOIN する必要がありません。

デメリットとしては、 JOIN する際の条件のなかで利用できないという点があります。
例えば以下のようなケースでは Subquery in join predicate should depend on one of join sides. のようなエラーがでます。

create temp function const()
as (
  struct(date('2021-04-01') as st, date('2021-04-30') as en)
);

with 
  date_array as (
      select 
        date(sequence) item,
      from unnest(['2021-01-01', '2021-02-01', '2021-04-01','2021-05-01']) sequence
  ),
  date_array2 as (
      select 
        date(sequence) item,
      from unnest(['2021-01-01', '2021-02-01', '2021-04-01','2021-05-01']) sequence
  )

select
  date_array.*
from date_array
  join date_array2 on date_array.item = date_array2.item and date_array2.item = const().st
where date_array.item between const().st and const().en

BigQuery Scripting を利用する

BigQuery Scripting では、変数やif 文やループ処理などのステートメントを特に何の設定もすることなく利用できます。この変数の宣言と代入を利用することで定数のように扱います。

cloud.google.com

declare st, en date;
set st = date('2021-04-01');
set en = date('2021-04-30');

with 
  date_array as (
      select 
        date(sequence) item,
      from unnest(generate_date_array('2021-01-01', '2021-05-01')) sequence
  )

select
  date_array.*
from date_array
where item between st and en

with 句や UDF を利用する方法と違い CROSS JOIN する必要もなく、JOIN の条件の中でも利用できます。 また他の方法よりも可読性も良く、現時点では一番良い方法だと思います。

ただし、BigQuery Scripting を使うと事前にスキャン量を計算できないので注意が必要です。

まとめ

今回は BigQuery で定数を使う方法を紹介しました。 クエリを再利用する際に有用なので、ぜひ試してみてください。

BigQuery Scripting はこれ以外でも工夫次第で色々応用できそうなので活用していきたいと思います。

We are hiring!!

Da Vinci Studio では一緒に働ける仲間を絶賛大大大募集中です！ データ分析に興味がある方、それ以外の開発に興味がある方、あるいは一緒に働いてみたいという方は recruit@da-vinci-studio.net までご連絡ください。

BigQuery 用 ETL ライブラリ inbulk を公開したので紹介する

Da Vinci Studio 分析チームの末安です。
今回は 2021 年 1 月に公開した ETL ライブラリ inbulk について紹介します。

github.com

inbulk でできること

• ジョブを簡潔に定義できる
• 差分実行できる
• それらの処理を BigQuery 内で完結できる

ざっくり言うと、ほとんど yaml で定義できる BigQuery の API の wrapper のようなものになっています。

背景

分析チームでは BigQuery を利用することが多く、BigQuery 内のテーブルを加工して別のテーブルを作るといった作業がよく発生します。

以前まで、こういった処理は BigQuery の機能である Scheduled Query を利用して行っていましたが、利用していて幾つかの問題が見えてきました。

1. 依存関係を定義できない

一つの処理が終わった後に別のテーブルを作りたいということはよくあると思います。

Scheduled Query ではそういった依存関係は定義できないため、実行時間をずらすことでどうにか実現していましたが、最初の処理が失敗しても次の処理が実行されてしまうという問題がありました。

2. 差分実行のコストが大きい

バッチ処理においても冪等性を考慮することは重要だと思います。

これも BigQuery 上のみで実現できなくはないですが、宛先テーブルを全スキャンして新規追加分マージしてからそのテーブルを置換する必要がありました。

この方法の場合、宛先テーブルのデータ量が多いとかなりのコストがかかってしまうという問題がありました。

3. レビューしづらい

当時は BigQuery の UI 上で Scheduled Query を設定していたため、レビューがうまくできない状態でした。

この問題に関しては Terraform などで管理すれば解決できそうではありますが、こういった管理方法の場合、GitHub 上の定義と実態に差異が発生してしまうことが多いことと、他にも解決できない課題があったため別の手段を探すことにしました。

調査

1 の依存関係を定義できない問題は、ワークフローエンジンを利用することで解決できるのでそちらに移行することにしました。

差分実行とジョブ定義の実現方法についても調査しましたが、それらしきものは見つかりませんでした。

Embulk を利用すれば実現はできそうでしたが、Embulk 自体はデータ転送ツールであり、今回のケースでは BigQuery 内で完結できる処理のため、一度 BigQuery からデータをダウンロードして再び BigQuery に入れるという内部の流れが個人的に許せませんでした。

inbulk

そんなわけで、ETL ライブラリ inbulk を OSS として開発しました。

特徴

定義

このように Embulk っぽい記述でジョブを定義できます。

Embulk と違うのは、データを実行環境に一切ダウンロードしない点です。そのためジョブ実行するマシンのメモリ消費を抑えることができます。

init:
  credential-file: /.gcp/credential.json
  service: bigquery
in:
  query: |
    select
      id
    from Dataset.users
out:
  project: project
  database: Destination
  table: users
  mode: append

変数

inbulk では、事前に別のクエリを実行してその結果をクエリに組み込むことができます。 具体的には、下記のように in のセクションの vars で組み込みたいデータを指定して query のなかで ${変数名} とすることでクエリに組み込みます。

init:
  credential-file: /.gcp/credential.json
  service: bigquery
in:
  query: |
    select
      id
    from Dataset.users
    where created > '${last_modified}'
  vars:
    - name: last_modified
      database: Destination
      table: users
      mode: meta
      field: last_modified_time
out:
  project: project
  database: Destination
  table: users
  mode: append

上記の例では、last_modified という名前で宛先テーブルの最終更新日を BigQuery のメタデータテーブルから取得して利用しています。これにより差分実行が低コストで実現できます。

また、他のテーブルを参照することも可能で、vars に下記のように指定すると、宛先テーブルの最後の id を取得するようなこともできます。

  vars:
    - name: last_id
      database: Destination
      table: users
      mode: max
      field: id

マージ

マージ機能も用意しています。マージモードでは、指定したフィールドが重複する場合は、指定したオーダーで最初に来るもので置き換えます。 下記の例では、id が重複した場合、最終更新日が新しいレコードで置き換えるような設定になっています。

ただし、マージモードでは内部的には宛先テーブルを全スキャンしてリプレイスしており、宛先テーブルのデータ量が多い場合はスキャン量が多くなってしまうので注意が必要です。

init:
  credential-file: /.gcp/credential.json
  service: bigquery
in:
  query: |
    select
      id
    from Dataset.users
out:
  project: project
  database: Destination
  table: users
  mode: merge
  merge:
    order:
      - column: modified
        desc: True
    keys:
      - id

パーティション

下記の例のように、宛先テーブルのパーティションも定義することができます。

init:
  credential-file: /.gcp/credential.json
  service: bigquery
in:
  query: |
    select
      id
    from Dataset.users
out:
  project: project
  database: Destination
  table: users
  mode: append
  partition:
    mode: time
    field: created
    type: DAY

利用例

日毎に新規ユーザー数を集計して保存しておきたい

宛先テーブルの最新の created 以降に作成された未集計の users を集計する

init:
  credential-file: /.gcp/credential.json
  service: bigquery
in:
  query: |
    select
      date(created) created,
      count(distinct id) user_count,
    from Sample.users
    where
      date(created) > date('${last_created}')
      and date(created) <= date_sub(current_date, interval 1 day)
  vars:
    - name: last_created
      database: Destination
      table: new_users
      mode: max
      field: created
out:
  project: project
  database: Destination
  table: new_users
  mode: append
  partition:
    mode: time
    field: created
    type: MONTH

特定のイベントのみ整形して保存しておきたい

宛先テーブルの最終更新日から昨日までのデータを append するように定義する

init:
  credential-file: /.gcp/credential.json
  service: bigquery
in:
  query: |
    select
      timestamp_micros(event_timestamp) event_time,
      user_id,
      user_pseudo_id,
      (select value.string_value from unnest(event_params) event_param where key = 'screen_class') screen_class,
      device.category device_category,
      device.operating_system os,
      device.operating_system_version os_version,
    from Sample.events
    where
      event_name = 'screen_view'
      and date(timestamp_micros(event_timestamp)) between date('${last_modified}') and date_sub(current_date, interval 1 day)
  vars:
    - name: last_modified
      database: Destination
      table: screen_views
      mode: meta
      field: last_modified_time
out:
  project: project
  database: Destination
  table: screen_views
  mode: append
  partition:
    mode: time
    field: event_time
    type: DAY

まとめ

今回は、ETL ライブラリの inbulk について紹介しました。 inbulk を導入したことによって、課題であった差分実行とレビューのしづらさを解消することができました。

今は BigQuery 専用となっていますが、追々 Redshift などにも対応していきたいと考えています。

なにか要望などあれば気軽に Issue をあげてもらえると嬉しいです。

We are hiring!!

Da Vinci Studio では一緒に働ける仲間を絶賛大大大募集中です！ データ分析に興味がある方、それ以外の開発に興味がある方、あるいは一緒に働いてみたいという方は recruit@da-vinci-studio.net までご連絡ください。

Redash の metadata だけでできるダッシュボードのアクセス解析

Da Vinci Studio インフラ基盤部データ分析チームの濱口です。
Da Vinci Studio のデータ分析チームでは、グループ内に溜まっている膨大なデータを日々分析・集計しています。そうして得られた学びについては、公開可能なものに限り Redash のダッシュボードとしてグループ内で確認できるようにしています。 ただ公開して終わりではなく、ダッシュボードがどれくらい見られているのかも計測して、グループ内のデータへの関心の把握やダッシュボードの改善などに繋げたいですよね。
というわけで今回は Redash 内のクエリやダッシュボードの閲覧状況を可視化した話についてまとめておこうと思います。

Redash の metadata

閲覧状況を可視化するにあたって Redash の内部データベースに貯まっている metadata を利用しました。 Redash の metadata には、登録ユーザーやユーザー権限、追加されたクエリやダッシュボードなど色々なデータが貯まっています。

Redash の metadata のテーブル一覧

events というテーブルがあり、その中にユーザーの閲覧履歴や操作履歴が記録されるようになっています。

events テーブルの詳細

これを利用して閲覧状況を可視化してみましょう。

Redash で Redash の metadata にクエリを投げられるようにする

metadata に今回必要そうなデータが入っていることが確認できたので、次に Redash の metadata をデータソースに接続します。 今回は docker のコンテナに立てているので、それぞれ設定した値から host, port, user, password などを入力していきます。

Redash のデータソース接続画面

設定を完了して、以下のようにテーブル一覧が確認できたら接続完了です。

Redash のデータソース接続確認

events テーブル

ここまできたらあとはいつものごとくクエリを書いて events テーブルのデータを集計します。

events テーブルのデータ例

先ほどテーブル内容を紹介しましたが、その中の action に何の操作が行われたか、object_type に action の対象物が記録されています。ダッシュボードの閲覧であれば action = 'view' and object_type = 'dashboard' の条件で絞り込むことでデータを確認できます。ここに users テーブルや dashboards テーブルを join すれば、誰が何のダッシュボード見ているのかを集計できます。

with
    t_base_events as (
        select
            u.name user_name,
            e.action,
            d.name dashboard_name,
            e.created_at
        from events e
            join users u on e.user_id = u.id 
            join dashboards d on cast(e.object_id as integer) = d.id
        where
            action = 'view'
            and object_type = 'dashboard'
    )

select
    dashboard_name,
    count(*) view_dashboard_count
from t_base_events
group by dashboard_name
order by view_dashboard_count desc

action には他にも create, update, load_favorites, execute_query など、object_type は dashboard, query, page などが入っていて、色々な対象物の様々な操作履歴を把握できます。閲覧状況以外にも、誰がどれくらいクエリを書いているかやどれくらいダッシュボードを作成しているかもモニタリングできそうです。

ダッシュボード完成

ダッシュボードとクエリの日別閲覧状況

大きく伸びている日は、新しくダッシュボードを追加して周知した日です。それ以外の期間では、あまり継続して見られていないことが分かります。何の情報をどういう見せ方にすれば興味を持って継続的に見てもらえるのか、まだまだ改善の余地があります。

人物、会社別の閲覧状況

また会社別に見てみると、直近でダッシュボードを見ている会社と見ていない会社で大きく差があることが分かりました。追加したダッシュボードに対して強く興味を示している会社は良いですが、あまり興味を示していない会社に対してはどういった情報だとより興味が惹かれるのかをもう少し深ぼりして考える必要があります。

まとめ

• Redash の metadata には様々な使えるデータが入っている
• events テーブルにありとあらゆるものの操作履歴が入っている
• Redash に接続して集計して可視化すると、閲覧状況や利用状況などをモニタリングできる

分析結果を Redash のダッシュボードで公開するのはもちろんですが、公開内容が見られているかどうか、しっかり計測までできるようになりました。今後のダッシュボードの公開内容やまとめ方の改善に繋げていきたいと思います。
最後までご覧いただきありがとうございました。

We are hiring!!

Da Vinci Studio では一緒に働ける仲間を絶賛大大大募集中です！ データ分析に興味がある方、それ以外の開発に興味がある方、あるいは一緒に働いてみたいという方は recruit@da-vinci-studio.net までご連絡ください。もしくは 濱口 までご連絡いただいても大丈夫です。

データ分析チームの紹介

Da Vinci Studio インフラ基盤部データ分析チームの濱口です。 今回は Da Vinci Studio のデータ分析チームについて紹介したいと思います。

Da Vinci Studio の「データ分析チーム」

Da Vinci Studio のデータ分析チームは現在は 3 名体制で、くふうグループ横断のデータ分析を担当しています。 まだ最近できたばかりの比較的新しいチームで、データ分析を通してユーザーや社会により良い価値を届けるために日々活動しています。 まずはそんなデータ分析チームのミッション・ビジョン・バリュー(MVV)について紹介したいと思います。

データ分析チームにおけるMVV

紹介の前に、チームなのにMVV？と思われた方もいらっしゃるかもしれません。その疑問の通りで Da Vinci Studio 全体としてミッション・ビジョンは掲げられているので、全てのチームがミッションを定めているわけではありません。
しかしデータ分析チームは新しくできたばかりで、実績を積み重ねるために日々多くの業務をこなしながら、手探りで進んでいる状態でした。メンバーそれぞれのやっていることがチームの目指したい理想像や目的から逸れていないかを振り返ることができるようにMVVを決めるに至りました。

ミッション

まずはミッションですが、Da Vinci Studio ではテクノロジー(エンジニアリング/デザイン)の力を引き出すというミッションを掲げています。それを踏まえた上でデータ分析チームでは

最強の玩具箱をつくる

というミッションを設定しました。
玩具箱というのは、面白い知見やアイデア、技術が溜まる場所という意味で名付けています。新しくて唯一無二、変幻自在で独創的な玩具箱を作りたいという話になり、まとめて「最強の」「玩具箱」を作ろうとなりました。

ビジョン

つづいて Da Vinci Studio では新しいスタンダードを作り出すというビジョンを掲げています。それを踏まえた上でデータ分析チームでは

最強のアトリエになる

というビジョンを設定しました。
アトリエとは、画家・美術家・工芸家・建築家などの芸術家が仕事を行うための専用の作業場、もしくはその作業場を拠点とする芸術家集団のことを言います。ここでは後者の芸術家集団のことを指しています。
新しい技術を試して積極的に取り入れながらも、しっかり作って価値を届ける最強の「アトリエ」になろうという思いが込められています。

バリュー

ここまで紹介してきたミッション、ビジョンを達成するために

• 面白いことをやろう
• 好奇心旺盛であろう
• 価値を届けよう
• 開かれたチームであろう

の 4 つのバリューを設定しました。
面白いことをやろう、好奇心旺盛であろう、価値を届けようの 3 つに関しては、他のチームでも重視されている価値観とほとんど同じです。データ分析チームとしても重要な価値観となるので明示的に掲げています。
開かれたチームであろうは、分析に興味がある人は誰でも歓迎という意図で掲げられています。色々な人の力を借りて、色々なことに挑戦して、新しくて唯一無二の玩具箱を作っていこうということですね。

今やっていること

サービス改善のための分析

くふうグループでは結婚や不動産、金融など様々なサービスが運営されており、より良い価値をユーザーに届けるためのくふうや改善が日々行われています。
データ分析チームでも、サービス改善や新たな施策の閃きなどの助けとなるように、グループに溜まっているデータや一般公開されているデータを集計・分析して、ダッシュボードにまとめて公開しています。

公開しているダッシュボードの一例

自社プロダクトの開発

自社プロダクトにおけるデータの活用や分析活動も行っています。データ構造の設計からデータフローの構築・運用、機械学習部分の実装まで幅広くやっています。
ゆくゆくは機械学習などを軸にしたデータ分析主導のプロダクトも出していきたいと思っています。

社会貢献のためのデータ提供や研究

データの分析結果を外部に提供したり、公的機関との共同研究を行ったりしています。直近ではグループ会社サービス「Zaim」のデータ分析チームの一員として「コロナ禍のお財布の変化」について分析し、メディアへの情報提供協力を行い、テレビ番組で取り上げられました。

www.nhk.jp

www3.nhk.or.jp

社会的変化の把握に寄与する活動などを行うことで、ユーザーはもちろん社会全体にも価値を届けていきたいと思っています。

最後に

ざっくりとですが Da Vinci Studio のデータ分析チームの紹介でした。
これからも面白くてワクワクすることをやっていきながら、ユーザーや社会にしっかりと価値を届けていきたいと思います。最後までご覧いただきありがとうございました。

We are hiring!!

Da Vinci Studio では一緒に働ける仲間を絶賛大大大募集中です！
データ分析に興味がある方、それ以外の開発に興味がある方、あるいは一緒に働いてみたいという方は recruit@da-vinci-studio.net までご連絡ください。もしくは 濱口 までご連絡いただいても大丈夫です。