こんにちは。品質管理部エンジニアリングチームの遠藤です。 私の所属している品質管理部では、業務の一環として、ZOZOSUIT計測精度の向上のために新しいアプリがリリースされる度に精度のチェックを行っております。
常に計測、比較、検証などを行っており、特に計測は実際にZOZOSUITを着用し、計測、結果の記録を行っているのでとても時間がかかる作業です。 計測プロセス自体は毎回（大体）同じなので、その点をエンジニアリング的に解決できないか試してみました。だってエンジニアリングチームなんですもの！
続きを読む
こんにちは、最近気になっている哺乳類はオリンギートな、開発部の塩崎です。
私の所属しているMarketingAutomationチームではRealtimeMarketingシステムの開発運用を行っております。 このシステムはZOZOTOWNのユーザーに対してメールやLINEなどのコミュニケーションチャンネルを使い情報の配信を行うものです。 メルマガの配信数や開封数などの数値は自動的に集計され、BIツールであるRedashによってモニタリングされています。 このRedashは社内PCによってホスティングされていましたが、運用面で辛い部分が多々あったためパブリッククラウドに移行しました。 移行先のクラウドはawsを選択し、RedashをホスティングするためのサービスはECS/Fargateを選択しました。 この記事ではawsに構築した環境や、移行作業などを紹介します。
続きを読む
こんにちは。バックエンドエンジニアの田島(@katsuyan121)です。
弊社ではデータマートをBigQuery上に構築しています。データマートはデータベース全体のデータのうち、必要なデータだけを使いやすい形にしたデータベースです。データマート作成のためのSQLクエリは日々更新や追加があり、BigQueryのコンソールから自由にデータマートを作ってしまうと管理が大変になってしまいます。
そこで、データマートをすべてGitHub上でバージョン管理し、運用の効率化をしました。また、差分更新の導入や依存関係のあるデータマートへの対応などのデータマート構築に必要な機能を作成しました。
弊社のデータ基盤をざっくり紹介します。まずデータはBigQueryへ集約し、Digdagを用いてデータ基盤を構築しています。以下がその概要図です。S3などの分散ストレージや各種DBからデータをBigQueryへ同期し、BigQuery内部でデータマートを構築します。本ブログではこのうちのデータマート構築について紹介します。
データマートをBigQuery上に構築していると紹介しましたがその実態は以下の2つです。
計算コストが小さいマートに関しては View を用いることでデータの鮮度を保つようにします。逆に計算コストの高いマートは事前に集計などの計算をし Table として保持することで、参照時にコストの高い計算しなくて済むようにしています。
冒頭でもいくつか紹介しましたがデータマートの構築には以下のような問題が存在します。
Table View の数は100を超えており、今でも日々追加されているまたテーブルを用いてデータマートを構築する場合以下のことが問題となります。
Table View が他のTable View を参照している場合、更新する順番を間違えるとデータに不整合が生じるそこで、これらの問題を解決するためのシステムを作成しました。
BigQueryのViewやTableはBigQueryのWebコンソール画面から簡単に作ることができます。しかしそれでは誰が作ったマートなのかなのかが簡単には分からないなどの運用の問題が生じてしまうと紹介しました。そこでSQLファイルを作成し、それらをAPIからBigQueryに反映をします。実際にはRubyの Google Cloud SDK を利用して反映を行っています。
また、SQLファイルのファイル名を View または Table の名前にすることで、実際のマートとSQLファイルとの対応関係が簡単にわかります。以下がその概要です。
| Before | After | |
|---|---|---|
| マート作成方法 | BigQueryのコンソールから手動で作成 | SQLファイルをGit管理しAPI経由で作成 |
以下に View Table をデータマートへ反映する方法を示しますが、全てのマートをSELECT文のSQLファイルとして表現できます。
BigQueryにSQLを反映する仕組みを作ったことで、すべてのマートをSQLファイルとしてGit管理できるようになりました。
View のマートに関しては作成したSQLをそのままBigQueryに反映します。
require 'google/cloud/bigquery' sql = File.read('テーブル名.sql') bq_client = Google::Cloud::Bigquery.new(project: 'project', credentials: 'path') dataset = bq_clent.dataset('データセット名') dataset.create_view('ビューの名前', sql, standard_sql: true)
require 'google/cloud/bigquery' bq_client = Google::Cloud::Bigquery.new(project: 'project', credentials: 'path') sql = File.read('テーブル名.sql') dataset = bq_clent.dataset('データセット名') view = dataset.table('テーブル名) view.set_query(sql, standard_sql: true)
テーブルのマートについてはBigQueryの Destination Table という機能を使うことで、SELECT文の結果をそのままテーブルに反映できます。
以下のようなコードを実行することでBigQueryにSELECT文の結果がテーブルとして作成されます。この処理は、BigQueryによってアトミックにテーブルが作成されます。
require 'google/cloud/bigquery' bq_client = Google::Cloud::Bigquery.new(project: 'project', credentials: 'path') sql = File.read('テーブル名.sql') job = bq_client.query_job(sql, standart_sql: true, table: 'テーブル名', write: 'truncate', create: 'needed') job.wait_until_done!
計算コストの高いマートは事前に集計などの計算をし Table として保持すると紹介しました。しかし集計するデータが大きすぎる場合、毎回全量のデータを集計・更新すると時間がかかりすぎてしまいます。
例えば日付ごとに集計するテーブルの場合、毎日全量のデータを集計し直していると最新の日付以外の集計処理は前日と同じ計算をしてしまうことになり集計処理が増えて行きます。そこで差分更新をすることでこの問題を解決します。
本システムでは差分更新にappendとoverwriteの2種類を行っています。
appendは集計した結果を既存のテーブルに対してinsertします。
以下のようなテンプレートに対しSQLファイルの中身をそのまま埋め込むことで、「テーブルのマート反映までの流れ」で紹介した処理と同じようにBigQueryに反映できます。
SELECT * FROM `既存のテーブル` union all ( <%= sql %> )
一部集計した結果を既存のマートに上書きしなければならない場合appendだけでは対応できません。overwriteの処理ではそのようなケースに対応するため pk などのユニークキーを利用して集計結果をマージします。
こちらもappendのときと同じように以下のようなテンプレートに対してSQLを埋め込みBigQueryに反映します。
SELECT * except(priority, row_number) FROM ( SELECT *, row_number() over (partition by <%= pk %> order by priority) as row_number FROM ( SELECT *, 1 AS priority FROM ( <%= sql %> ) union all SELECT *, 2 FROM `既存のテーブル` ) ) WHERE row_number = 1
以上のように差分更新する対象のテーブルは統一した方法で差分更新が行われるようになりました。
最初は以上のようにappendとoverwriteの処理を通常の更新処理と同じように行っていました。しかし運用しているうちに SELECT * FROM により全件のデータを毎回取得していることが以下の2点で問題になりました。
そこでBigQueryのappendの機能を利用するように変更しました。この、 append によるデータの追記もBigQueryによりアトミックに行われることが保証されています。以下のコードで、それを実現しています。
require 'google/cloud/bigquery' bq_client = Google::Cloud::Bigquery.new(project: 'project', credentials: 'path') sql = File.read('テーブル名.sql') job = bq_client.query_job(sql, standard_sql: true, table: 'テーブル名', write: 'append', create: 'needed') job.wait_until_done!
これにより、SELECT * FROM の処理をなくすことに成功しました。ただし、overwriteは以上の解決策は適用できないため上で紹介した通りに今も更新を行っており、課題となっています。
差分更新の仕組みを紹介しましたが、差分更新の処理があると何かの問題で処理を再実行した場合データが重複するといったデータの整合性に対する問題が生じてしまいます。
例えば、既存のテーブルに対して append の処理をします。その後再実行したい場合、もう一度 append の処理を行うと append により追加されたデータが重複してしまいます。
そこで、以下のようにすることで冪等性を担保し、何回同じ処理をしても同じ結果になるよう工夫しました。 また、 overwrite でも同じように処理を行います。
マート更新時に、マートと同じデータを保持したバックアップを作成します。そして、差分更新を行う場合はバックアップに対して差分更新を行い、その結果を実際のマートに反映します。
2018-01-06 にマートを更新すると以下のような処理になります。
これをコードにしたものが以下になります。
require 'google/cloud/bigquery' bq_client = Google::Cloud::Bigquery.new(project: 'project', credentials: 'path') dataset = bq_clent.dataset('データセット名') table = dataset.table('mart_table', skip_lookup: true) backup_table_yesterday = dataset.table('mart_table_20180105', skip_lookup: true) backup_table_today = dataset.table('mart_table_20180106', skip_lookup: true) backup_table.copy_job(destination_table, create: 'needed', write: 'truncate') # バックアップテーブルを実際のテーブルにコピー job = bq_client.query_job(sql, standard_sql: true, table: table, write: 'append', create: 'needed', &job_configuration) job.wait_until_done! raise "Fail BigQuery job: #{job.error}" if job.failed? table.copy_job('バックアップテーブル.sql', create: 'needed', write: 'truncate') # 更新されたテーブルをバックアップ
以上のように差分更新をすることで、何回リトライしてもデータの整合性が保たれるうようになりました。
マートが他のマートを参照している場合、更新する順番を間違えるとデータに不整合が生じると紹介しました。例えば existing_table1 existing_table2 のテーブルが存在するとし、以下のような4つのマート構築を考えます。その場合、「table3の前にtable1」「table4の前にtable1とtable3」が更新されている必要があります。
table1.sql
SELECT * FROM `project.dataset.existing_table1`;
table2.sql
SELECT * FROM `project.dataset.xisting_table2`;
table3.sql
SELECT * FROM `project.dataset.table2`;
table4.sql
SELECT * FROM `project.dataset.table1` UNION ALL SELECT * FROM `project.dataset.table4`;
そこで以下のようなグラフを作成し、実行順を確認します。このグラフは、SQLの FROM または JOIN の後ろのテーブル名とSQLファイル名を利用します。FROMの後ろに書かれているテーブルはSQLファイル名のマートよりも前に実行しなければなりません。そのため「FROMの後ろのテーブル名」->「SQLファイルのファイル名」というグラフを作成します。
例えば上の4つのSQLからマートのグラフを作成すると以下のようになります。
以下のようなコードでグラフを生成します。
graph = {}
sql_files = [table1.sql, table2.sql, table3.sql, table4.sql]
sql_files.each do |sql_file|
sql_file_table_name = sql_file.split('.').first
sql = File.open(sql_file, 'rt:UTF-8') { |file| file.read.chomp }
related_tables = sql.scan(/(?:FROM|JOIN)[\s \n]+`(.+?)`/i)
graph[sql_file_table_name] = related_tables.map do |str|
_, table = str.first.split('.')
next if table == sql_file_table_name # 自己参照は除外
table
end.compact
end
この結果に対してマート以外のテーブルを削除すると、以下のような結果になります。
[
{'table3' => ['table2']},
{'table4' => ['table1', 'table3']}
]
以上のグラフを利用することで、マート作成のクエリの実行の順番を担保したまま並列化できます。並列実行を簡易化するために以上のようなグラフを、以下のようなテーブルのリストのリストに変換します。各テーブルのリストは先頭から順番に実行でき、テーブルのリストの中身はそれぞれ並列実行することが可能になります。
[[table1, table2], [table3], [table4]]
この変換は、まず親ノードがないテーブル一覧をリストに追加します。そして追加したテーブルをグラフから削除し、もう一度親ノードがないテーブル一覧をリストに追加します。これを繰り返すことで、以上のようなリストが生成されます。
以下のようなコードでグラフからリストを生成します。
def sort_tables(graph) graph = graph.dup result = [] until graph.empty? nodes = graph.keys.select { |node| graph[node].empty? } result << nodes raise 'cyclic path detected!' if nodes.empty? nodes.each { |node| graph.delete(node) } graph.transform_values! { |v| v - nodes } end return result end
このリストを利用し、最初に「table1, table2」続いて「table3」最後に「table4」を実行します。 並列実行はDigdagで実現しており、以下のようなconfigファイルになっています。
+set_refresh_views:
call> set_refresh_views # REFRESH_TABLESESにテーブルのリストのリストを格納
+update_views:
for_each>:
REFRESH_TABLES: ${REFRESH_TABLESES}
_parallel: false
_do:
for_each>:
REFRESH_TABLE: ${REFRESH_TABLES}
_parallel: true # ここをtrueにすることで並列実行を実現
_do:
_retry: 3
call> refresh # 実際にマートを更新する処理
以上のように実行する順番を考える必要があった所を、システムにより自動解決することに成功しました。さらに、並列実行をすることで更新スピードの短縮にも成功しました。
最後に本システムによりデータマートの運用に関してどのようになったか紹介します。
以上のように冒頭に挙げた問題を解決することに成功しました。またその他に以下のようなメリットが見られました。
以上のようにデータ基盤のコード管理とマート管理をGIthubに統一、システム化することで様々なメリットが得られました。
本文でも紹介しましたが、本システムにはまだまだ問題が残されています。弊社では一緒にデータ基盤を作ってくれる方を大募集しています。 ご興味がある方は以下のリンクから是非ご応募ください！
こんにちは！
好きなスシローは五反田店なバックエンドエンジニアのりほやん( @rllllho) です。
9/6,7,8に開催されたbuilderscon tokyo 2018へ参加しました。
カンファレンスで印象に残ったセッションをいくつかご紹介します。
こんにちは。品質管理部エンジニアリングチームの高橋です。
今回は品質管理部として初のTECH BLOG投稿ということもあり、
「品質 / Quality」について掘り下げてみたいと思います。
「品質」という言葉の語源は古代ギリシャにまで遡ります。
「万学の祖」と称されるアリストテレスは、物質（Substance）を「量的側面」と「質的側面」に分けて定義しました。
その際に量的な側面を表現する言葉として英語の質量（Quantitiy）に相当するギリシャ語を用いました。
そして対立概念である質的な側面を表現する言葉として、英語のQualityの語源となったラテン語のQualitasを用いたと言われています。
月日は流れ現在、ISO 9000シリーズにて「品質」は「本来備わっている特性の集まりが、要求事項を満たす程度」と述べられています。※ISO 9000シリーズとは、国際標準化機構が定めた品質マネジメントシステムに関する規格の総称です。
『プログラミングの心理学』や『一般システム思考入門』を著した、ソフトウェア開発の人類学者であるジェラルド・ワインバーグは、「品質は誰かにとっての価値である」と自著内で述べています。
続きを読む
福岡研究所の渡辺（しかじろう @shikajiro）です。Kotlinのおっきなイベントが東京で開催されるということで福岡から飛んで✈いきました。
福岡でもFukuoka.ktという名前で過去に2回ほどイベントを主催しており、KotlinFest主催の太郎さんに登壇していただいたこともありました。僕自身3か月ほどKotlinから離れてましたが、直近の技術情報などをフォローできたらいいなと思い参加しました。
続きを読む
こんにちは、新事業創造部の遠藤です。現在WEARの開発を行っています。
最近はWEARのコーディネート一覧やユーザー一覧など、リスト画面にバナー型の広告を実装をしました。
リストにデータを挿入する実装は簡単なように思えますが、種類の違うデータを扱う場合には、考慮するべきポイントがいくつかあります。
本記事ではリストに広告を表示することを例に、種類の違うデータをリストに挿入する際のデータの持ち方・実装ついて紹介したいと思います。
こんにちは。スタートトゥデイ研究所の真木です。 8月5日から8月8日にかけて開催されたMIRU 2018という学会に行ってきました。また、5月下旬から約2か月間にわたって実施されてきた「MIRU若手プログラム」という 若手研究者同士 の交流プログラムにも参加してきたので、今回はその報告をします。
続きを読む
こんにちは。新事業創造部インフラチームの内山（@k4ri474）です。
弊社が運営するIQONというサービスでは、長らくMySQLのバージョン5.6.27を利用していました。これは2018年9月にEOLを迎えるため、RDSの方針として強制アップグレードがアナウンスされています。
MySQLを継続する選択肢もありましたが、Auroraの運用知見が溜まっていたということもあり、これをキッカケにMySQLからのAurora移行を実施しました。
新事業創造部ではほぼ全てのAWSリソースをCloudFormationを使って宣言しているため、例に漏れずAuroraもテンプレートへ落とし込むことにしました。
ただ、CloudFormationだけで完結しない作業があったので、今回はCloudFormationでの宣言とコンソールからの手作業を織り交ぜるという対応を取っています。
執筆時点の公式ドキュメントではカバーできていない需要を満たすべく、CloudFormationを使ったAmazon Auroraへの移行の手順を皆さんに共有したいと思います。
続きを読む
こんにちは！ スタートトゥデイテクノロジーズ新事業創造部の塩崎です。 2018年7月24日〜26日にかけてサンフランシスコでGoogle Cloud Next '18が開催されました。 このイベントに新事業創造部の塩崎、今村、そして代表取締役CIOの金山の3名で参加してきました。
この記事では多数あった講演の中で特に印象に残ったものをいくつか紹介いたします。
続きを読む