VOYAGE GROUP　エンジニアブログ

火曜日の12:30 GMT、それまで噂されていた iPhone5 ではなく iPhone4S の発売を Apple は発表しました。 数時間の内に、Apple ファンは #iphone5 が販売されなかった落胆をツイートし、ハッシュタグ #iphone4S のついたツイートが急増しました。 地図に表示されている円のひとつにマウスオーバーしてください。 そこでつぶやかれたツイートを見ることができます。 

男性女性のようにカテゴリ分けしていれば、その場で比較することも可能です。

ドライバーはこちら


Tableau使ってみると


■ お約束
VOYAGE GROUPでは、一緒に働いてくださる仲間を募集しております。
株式会社VOYAGE GROUP アドテクユニット キャリア採用サイト
株式会社VOYAGE GROUP - 採用
どんな会社か気になる方は、是非下記のサイトもご覧ください。
VOYAGE CULTURE

こんにちは。システム本部の@yuu_itoです。
主に弊社のメディアサービスのデータ分析の業務を行っています。

昨今、世間ではセキュリティに関する問題が増加しています！

情報セキュリティにおいて最小権限の原則という用語もあったりしますが、
システムの利用者に本当に必要な権限のみを付与することで
誤った操作を予防したり、外部からの侵入が起きてしまった場合にも
損害を最小限にできるように設計することが大事です。

前回の記事ではBigQueryについて書かれていましたが、
同様のDWH(データウェアハウス)機能を提供するサービスとしてAmazon Redshiftがあります。
今回はRedshiftのデータベースアクセスコントロールの設定方法について調べてみました。

■ データベース
データベースに対する権限設定コマンドは
PostgreSQLや、MySQL同様GRANT、REVOKEコマンドが使えます。 ALLは全権限、CREATEはスキーマ作成、TEMPORARYは一時表を作成する権限です。
テーブルへの SELECT や UPDATE の権限についてはスキーマ単位、テーブル単位で設定する必要があります。

■ スキーマ
MySQLではスキーマとデータベースは同義である(*1)と思いますが、Redshift、PostgreSQLではデータベースの中にスキーマがあり、スキーマの中にテーブルを配置するイメージです。 Redshiftのオブジェクト構成イメージ

スキーマの操作もGRANTコマンドを使います。 PUBLICスキーマについて
Redshiftは各データベースにデフォルトでPUBLICいう名のスキーマが存在し、全てのユーザ（全ユーザはPUBLICグループに所属している）にCREATE権限がついています。書込み権限が不要なユーザも存在すると思うので、REVOKEでCREATE権限を除いておくと良さそうです。
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_Schemas_and_tables.html

■ テーブル、カラム
テーブルについてもGRANTで個別に設定できます。しかしDBやスキーマのレベルでのみ管理するルールにしておけば、テーブル単位での管理をする必要はなくなるのでDB管理者としては気にすることが減って良さそうです。

カラム単位での操作制限はサポートされていなかったです。
一部のカラム隠蔽したいのであれば、ビュー(View)を作成したり、COPYコマンドでカラムを絞ってロードすることもできます。
また、CREATE TABLE AS(通称CTAS:しーたす)だったりINSERT INTO SELECTを使ってテーブルコピーを作る方法があります。

ビューの場合、テーブルコピーよりもコストが低い反面データベースをまたいだ作成ができないためテーブル、ビュー単位での管理が必要になります。 逆にCTASであればデータベースをまたいで作成することができるので、DBやスキーマのみの管理で済みます。

例えば、個人情報を除いたテーブルを権限を分けた別のデータベースやスキーマに作成すると良さそうです。 スキーマ、テーブルの構成例 CTASのコマンド例

■ ユーザの権限確認方法
データベース、スキーマ、テーブル単位で権限をチェックする関数がありました。
コマンド一発！一覧で確認するようなコマンドがあると期待していたのですが見つからず...
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_System_information_functions.html
HAS_XX_PRIVILEGEを使って確認できました。
試しに書いてみたクエリをgistに貼っておきます。
https://gist.github.com/yuu-ito/30733a9223e59e32bdb5#file-acl_check-md

■ まとめ
簡単でしたが、Redshiftの操作権限の設定とその方法について調べてみました。今回はDBユーザのセキュリティのみに焦点をあてましたが、実際にはネットワーク構成やデータの元となる運用サービスのデータベースサーバなどの関連システムについても一緒に整理する必要があります。AWSサービスでのシステム構成設計についてはいろんな記事でまとめられているのでそちらを探してみてください。

■ 参考
データベースセキュリティの管理 - Amazon Redshift
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_Database_objects.html
*1:
http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_schema

■ お約束
VOYAGE GROUPでは、一緒に働いてくださる仲間を募集しております。
株式会社VOYAGE GROUP アドテクユニット キャリア採用サイト
株式会社VOYAGE GROUP - 採用
どんな会社か気になる方は、是非下記のサイトもご覧ください。
VOYAGE CULTURE

こんにちは。Zucks Ad Networkの開発に携わっている@smileeeenです。
最近では所謂ビッグデータを活用している事例も珍しくなくなってきました。
ビッグデータを用いて分析などを行う時に、便利なツールの1つとしてGoogleが提供しているBigQueryがあげられると思います。

弊社内でもBigQueryの活用例が増えてきているので、この機会にどのようなクエリが発行できるのか、お勉強を兼ねてまとめてみました。
ちなみに私は普段MySQLに慣れ親しんでいるので、MySQLではできないような事を中心にまとめてみたいと思います。

それでは、公式サイトのリファレンスに倣って確認していきたいと思います。
Query Reference - Google BigQuery — Google Cloud Platform

---

■SELECTクエリ概要

https://cloud.google.com/bigquery/query-reference#select-syntax

SELECTクエリのシンタックスは上記のようになっています。
パッと見、MySQLとほぼ同様のクエリを発行する事ができそうですね！
agg_function(expr3) WITHIN expr4 及び FLATTEN(table_name1|(subselect1)) が自分にとっては見慣れないキーワードです。

BigQueryはJSON形式でのデータ読み込みが可能なので、ネストされた構造や繰り返しの構造をサポートしています。
ネストされた構造に対してクエリを発行するために、WITHIN や FLATTEN が存在するようです。

細かく見ていきましょう。

---

■SELECT句

WITHIN句 - ネストされたフィールド内の集約

https://cloud.google.com/bigquery/docs/data#within

agg_function(field) WITHIN RECORD

agg_function(field) WITHIN node_name

ネストされたフィールドに対して集約関数を実行する場合に、WITHINを使用します。
深いネストの場合は、親となるノードの名前を指定してあげる必要があります。

最初すんなり理解ができませんでしたが、ネストされたフィールドに対して集約関数を実行する時にはWITHINを指定する、と覚えておけば良さそうです。

---

■FROM句

https://cloud.google.com/bigquery/query-reference#from

project_name は省略可能です。省略した場合、現在のプロジェクトを対象とします。
プロジェクト名にハイフンが含まれている場合は、テーブル名の指定全体を [] で囲む必要があります。

複数のテーブルを横断してクエリを発行する

BigQueryにはUNION句は存在しません。
その代わりスキーマが同一のテーブルは、FROM句内でカンマで区切って指定するだけで UNION ALL と同等の結果を取得する事ができます。
MySQLでは同じ表記だと INNER JOIN の省略形となり、動作が異なってくるので、注意が必要そうです。

Table wildcard functions - テーブルの指定にワイルドカードを利用

テーブル名にいくつかの種類のワイルドカードを利用する事ができます。
BigQueryでは探索したデータのサイズによって課金されるので、テーブルを日や月で区切って作成しているケースが多いと思います。
そのような場合にテーブルを横断してクエリを発行したい時に便利な機能です。

TABLE_DATE_RANGE - テーブル名の末尾に'YYYYMMDD'

TABLE_DATE_RANGE(prefix, timestamp1, timestamp2)

テーブル名の末尾に YYYYMMDD 形式の年月日が付いている場合に使えるワイルドカード関数です。
prefix にテーブルの YYYYMMDD 前の部分を指定すると、timestampで指定した範囲のテーブルに対して、一括でクエリ実行する事ができます。

さらに TABLE_DATE_RANGE_STRICT を利用すると、指定した範囲にテーブルが存在しない年月日があるとエラーを返してくれます。
全てのテーブルが存在する事を前提に、クエリを発行したい場合に有用そうです。

TABLE_DATE_RANGE_STRICT(prefix, timestamp1, timestamp2)

TABLE_QUERY - 柔軟なテーブルワイルドカード関数

TABLE_QUERY(dataset, expr)

expr部に正規表現など文字列の評価式を入れる事で、任意の条件にマッチするテーブルをクエリ対象にする事ができます。

---

■FLATTEN句

https://cloud.google.com/bigquery/query-reference#flatten

ネストした構造のフラット化を行います。フラット化したいフィールドを flattenField の部分に指定します。
SELECT句やWHERE句内に複数のネストされたフィールドを指定するとエラーになる事があるので、その際にFLATTENを利用してフラット化してあげる必要があります。

少し試してみたのですが、具体的にどういうケースでエラーになってフラット化する必要があるのか、解説できるまでに至りませんでした…orz

---

■JOIN句

https://cloud.google.com/bigquery/query-reference#joins

JOIN句では INNER JOIN、LEFT OUTER JOIN、CROSS JOINがサポートされています。
デフォルトでは INNER JOIN となります。

EACH - 大きなサイズのテーブルのJOIN

JOINは通常右側のテーブルに、8MB未満のデータサイズのテーブルしか指定できません。
より大きなサイズのテーブルを指定したい場合には JOIN EACH を使う必要があります。
EACHはCROSS JOINには使用できず、使用する事によって通常のJOINよりもパフォーマンスも悪化するそうです。
8MBというのは割と小さいので、もし大きなデータ同士をJOINしたい場合には、BigQueryにデータを読み込ませる時点で1つのデータにマージする事を検討しても良さそうです。

---

■GROUP BY句

https://cloud.google.com/bigquery/query-reference#groupby

GROUP BYに指定するフィールドのユニーク数が多い場合、エラーになる事があります。
その場合 EACH を付ける必要があります。
また、float型やdouble型のフィールドは現状GROUP BYに指定する事はできないそうです。

---

■HAVING句

https://cloud.google.com/bigquery/query-reference#having

集約された値を元に絞り込む場合には、MySQL等と同様にHAVING句を利用できます。
HAVING句で使用するフィールドは、必ずSELECT句に記載されている必要があります。
また、SELECT句で集約されたフィールドのエイリアスは、HAVING句で直接参照が可能となっています。

---

■集約関数

https://cloud.google.com/bigquery/query-reference#aggfunctions

COUNT(DISTINCT field) - fieldのユニーク数を返す

COUNT(DISTINCT field[, n])

COUNT()内のフィールドに DISTICT を指定した場合、そのフィールドの値のユニーク数を返しますが、統計的近似値で正確ではない可能性があるので注意が必要です。
第二引数の正確な結果が保障される閾値に、大きな値を設定する事でより正確な数を知る事ができますが、クエリの実行時間に影響を及ぼすそうです。
デフォルトの閾値は「1000」になっています。

統計学系

MySQLにも一部実装されていますが、やはり分析が目的で利用されることが多いサービスなので、統計系の関数は充実している印象です。

標準偏差

STDDEV(numeric_expr)

STDDEV_SAMP(numeric_expr)

母標準偏差

STDDEV_POP(numeric_expr)

標準分散

VARIANCE(numeric_expr)

VAR_SAMP(numeric_expr)

母標準分散

VAR_POP(numeric_expr)

相関係数

CORR(numeric_expr, numeric_expr)

母共分散

COVAR_POP(numeric_expr1, numeric_expr2)

標本共分散

COVAR_SAMP(numeric_expr1, numeric_expr2)

文位数

QUANTILES(expr[, buckets])

TOP - 便利なエイリアス

TOP(field|alias[, max_values][,multiplier]) ... COUNT(*)

GROUP BY ... ORDER BY ... LIMIT ...　のエイリアスになります。
またGROUP BY 形式よりも実行時間も速いそうです。
例えば下記の2つのクエリは同じ事をしています。

---

■IPアドレス用関数

https://cloud.google.com/bigquery/query-reference#ipfunctions

アクセスログの分析など活用できるIPアドレスを人間の読みやすい形式に整形したり、パースしたりすることができます。

人の読みやすい形式のIPv4→in_addr 形式 IPv4

PARSE_IP(readable_ip)

in_addr 形式 IPv4→人の読みやすい形式のIPv4

FORMAT_IP(integer_value)

人の読みやすい形式のIPv4, IPv6→パックされたin_addr 形式 IPv4, IPv6

PARSE_PACKED_IP(packed_ip)

パックされたin_addr 形式 IPv4, IPv6→人の読みやすい形式のIPv4, IPv6

FORMAT_PACKED_IP(packed_ip)

使用例

---

■JSON用関数

https://cloud.google.com/bigquery/query-reference#jsonfunctions

通常はJSONの構造をスキーマとして反映させますが、JSON文字列を操作する関数も用意されています。

文字列で表現されたJSONから指定したパス部分を抜き出す

JSON_EXTRACT(json, json_path)

使用例

---

■正規表現

https://cloud.google.com/bigquery/query-reference#regularexpressionfunctions

正規表現にマッチするか判定

REGEXP_MATCH('str','reg_exp')

正規表現にマッチする部分を抜き出す

REGEXP_EXTRACT('str', 'reg_exp')

正規表現でマッチする部分を文字列置換

REGEXP_REPLACE('orig_str', 'reg_exp', 'replace_str')

使用例

---

■文字列操作関数

https://cloud.google.com/bigquery/query-reference#stringfunctions

文字列が含まれるかどうかの判定
単純な文字列を含むかの検索であれば、正規表現の REGEXP_MATCH ではなく、こちらの使用が推奨されています。

expr CONTAINS 'str'

使用例

---

■URL用関数

https://cloud.google.com/bigquery/query-reference#urlfunctions

ネットサービスには欠かせないURLを操作する関数も用意されています。

URLのホスト部分を取得

HOST('url_str')

URLのドメイン部分を取得

DOMAIN('url_str')

URLのトップレベルドメインを取得

TLD('url_str')

使用例

---

■Window(分析)関数

https://cloud.google.com/bigquery/query-reference#windowfunctions

OracleやPostgreSQLなどでも利用できるWindow関数が利用できます。 1ブログ記事には収まらないボリュームなので、詳細は公式サイトを参照してくださいm(_ _)m

---

■感想

SQLの書き方はMySQLなどと大きくは変わらないので、手を付けやすいですね。
ネストされた構造などは今までになかったので、少し慣れが必要そうです。
これから沢山触ってビッグデータと戯れたいと思います！

---

[PR]

VOYAGE GROUPではビッグデータと戯れたいエンジニアも大募集中です！

• 株式会社VOYAGE GROUP アドテクユニット キャリア採用サイト
• 株式会社VOYAGE GROUP - 採用

どんな会社か気になる方は、是非下記のサイトもご覧ください。

• VOYAGE CULTURE

皆さんこんにちは。adingoにてFluctという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。

今回は、先日、社内のエンジニア向けに開催した「2014年のJavaScriptのトレンド総まとめ」というコンセプトの勉強会の内容について紹介します。

それでは、スライドに書ききれなかった前提事項について、何点か補足と解説をします。

補足と解説

前提: なぜ「2014年」なのか

JavaScriptを用いた開発、特にWebフロントエンドとも呼称されるクライアントサイドJSのトレンドは、非常に速いサイクルでの進化を見せています。その一方、Webサービスを提供するに際して、我々は好む好まないに関わらず、デファクトスタンダードであるJavaScriptに触れる必要が存在しています。そうしたことから、JS以外の言語を専門とする（同僚の）エンジニアから、「三ヶ月も経つと新しいライブラリの話がされているので、今現在のベストプラクティスないしは全体的なトレンドを追うのが非常に難しい」という話を耳にします。

本スライド（を用いた勉強会）では、「全体的な潮流、および2014年末日現在であれば、このような方法を用いるのが十分に実用的な水準に達しているものを振り返り、トレンドを理解する」というコンセプトで、現時点でのJavaScriptのトレンドを押さえるのに必要な単語と流れを紹介する事にしました

タイトルに「2015年」と冠していないのは、年が明けて一ヶ月しか経っておらず、2015年のベストプラクティスとも呼べる物は未だに登場していないと判断した為です。

内容選定の基準に付いては以下の通りです:

• 最先端ではなく「トレンドの少し後ろ」を主軸にする
  • 少なくともアーリーアダプターの間では一定の評価を得ていると判断できる物を中心に選択しています
• 過去にJSに触った事のある（JS以外がメインの）エンジニア向きの内容
  • 特に、Webアプリケーションエンジニアが主な聴衆となる前提での話が多いです
• 2013年までに出てきたものを踏まえて、14年に出てきたものを拾う
  • 過去の経緯（コンテクスト）を理解しなければ、全体の流れの理解にはつながらないからです

• クライアントサイドの話を中心にする

  • Node.js（io.js）では既に解決されている問題が多いため
  • 変化が極端に激しいのはクライアントサイドのため
  • 現時点において、サーバーサイドに関しては必ずしもJavaScriptを採用する必要性が無いため
    • Isomorphicなどの文脈はありますが、業界における決定的潮流には至って居ないため、このような判断をしています
• パフォーマンスについては、以下の理由から言及していません
  • 話し始めるとキリが無い
  • 万能の解決策は無い

「現代のJavaScriptはビルドする物である」

CSSにおいて、Sass/LESS, Autoprefixerのようなプリプロセッサが普及しているのと同様に、JavaScriptも、Lintやminifyに限らない、デプロイ前にビルド工程を挟む前提でのツールが一般化しつつあります。CoffeeScriptを始めとした「任意の構文で記述したソースコードから、JavaScriptを最終的に生成する」AltJSの大量発生が典型的な事例ではありますが、他にもソースコードをパースし、抽象構文木（AST）を生成する事で、より複雑な変換・解析をカジュアルに行うためのツール群（esprimaが有名）も広く利用されています。

開発環境や目的によっては、これらのビルド工程を挟むツールの利用が困難なケースもありますが、制約の中でもこうしたツール群の恩恵をいかに受けていくかが鍵になるのは間違いありません。

終わりに

上記のスライドで挙げた内容について、本格的に普及が始まるのは今年以降であると予測していますが、情勢を知った上で選択するのと、知らないで選択するのとでは雲泥の差が存在します。上記のスライドおよび本記事が、まさに今、次のアプローチを検討している皆様の一助となれば幸いです。

会社のブログですので

お約束となりますが、弊社には AJITO という社内バーがあり、毎夜のようにエンジニアが現れ、酒を嗜み、軽食をつまみつつ、エンジニアリング談義を行っています（ #ajitingで既にご存知の方も多いと思います）。「私も一緒にエンジニアリング談義をしたい！」という方がいらっしゃいましたら、是非とも弊社エンジニア or @tech_voyageに、お声掛けいただければと思います。

また、adingoを含むVOYAGE GROUPアドテクユニットでは、一緒に働いてくださる仲間を募集しております。VOYAGE GROUPや広告配信に興味を持たれましたら、お気軽にご連絡ください。

• 株式会社VOYAGE GROUP アドテクユニット キャリア採用サイト
• 株式会社VOYAGE GROUP - 採用