BigQuery
https://gyazo.com/10190a90e4aefe1d0dee316ad754c7ef
サーバレスでビックデータ分析できて従量課金。ML、可視化などともシームレス 用語
データセット
テーブルの集合を所有するためのコンテナ。TDでのデータベースみたいな感じ
データセット単位でのアクセス制御
テーブル
スキーマがあるよ。jsonで指定できる
hiroki.iconネストされた列(Record)に列を追加することもできるらしい
ビュー
ジョブ
スロット
仮想CPU。処理の並列度をスロットで表す
グローバルリソースなので皆と共有するよ
同時実行最大スロットは2000まで
定額購入したリソースはリージョンリソースとなるので別のリージョンで使用・移行できない
割り当て
グローバルリソースなので個人のリソース利用に制限を設けている→従量課金だからとはいえ無限にリソース使い放題ではない。
バッチとかで意識する場面が出てくるかも？
料金体系
ストレージ料金（データ保管料)
列は圧縮されているが、課金は非圧縮状態のサイズに課金される
なんで？
クエリでのデータ読み込み量
クエリを実行したプロジェクトでの課金
あるプロジェクトに置いてあるデータを他部門や他社へ共有したりした場合は、その共有先のプロジェクトでクエリを実行するのでそちらでお金がかかる。
一般公開データセットにクエリ打ってもクエリ料金かかるのだから当然だね
ストリーミングインサート
アーキテクチャ
カラム指向データストア
ツリーアーキテクチャ
処理は全部インメモリ
Dremel→クエリエンジン
Colossus→ストレージ
Jupiter→ネットワーク
BigQueryへの接続
Rest API
Rest APIをラップしてくれているSDK
Pythonなどから気軽に使うなど
bq CLIコマンド
ODBC/JDBC
全機能ではなく一部のみ。普通にクエリする分には問題なし
注意点
ロケーションを跨いだデータの移動、SQLの発行はできない
→ロケーションを移動させたい場合はGCS経由するしかない
標準SQLとレガシーSQLがあるが標準を使いましょう
クエリの結果をエクスポートする際にはテーブルに保存してからGCSという順番出なくてはいけない
→小さいデータは一時テーブルに保存されるが、でかいデータは都度自分のdatasetの中のテーブルに入れてからエクスポートしないといけないのはめんどくさいと思った。
デカイ結果(1ファイル最大1GB)のエクスポートはファイルを分割してエクスポートされる。さらにエクスポート先には*を指定したファイル名であること
1 日あたりのテーブル オペレーション最大数 - 1,500 件
INSERT、UPDATE、DELETE、MERGEこれらオペレーションは一日にトータルで1500回までしかできない
テーブルのカラム名、データタイプ、必須などは変更不可能
→変更したい場合は新しいテーブルを作成してそこにインサートする
/icons/point.iconテーブルに新しいカラムを追加することはできる
ベストプラクティス
たとえば全レコードを1個のテーブルに収めるのではなく、分割して連番管理（日ごとにテーブルを分けるなど）したテーブルを扱うのがBigQueryの王道である。
ジョブはできるだけ直列実行
自分のプロジェクトのスロットは食いあう
ELT
読み込んでから加工する
クエリのwhere句で使うカラムをクラスターテーブルで最適化する
BigQuery DataTransfer ServiceかComposerとかのwfでデータを投入するのか？
テーブルに有効期間を設定することで自動でテーブルデータが削除されるようになる
→コスト最適化
datasetレベルでのアクセス管理がベストプラクティス
テーブルレベルでアクセス管理するべきじゃない
その他できること
GCSへ直接クエリを発行できる
GSSへクエリのデータへクエリを流せる
パーシスタントUDF
日付計算とかある場合ない場合がある時のjsonだったり
デメリットとしては標準SQLじゃなくなることかな
Information-Schemaから過去クエリがスキャンしたバイト数とかを調査できる
TableやDataset、Jobなどのメタデータにアクセスできる
使用量割り当て
https://gyazo.com/95d82695090441ffa4eb54872fee6acd
こちらの割り当てからBigQueryの一日の使用量に制限をかけられる
https://gyazo.com/2c8bf5721d4a8818eb2bde59e247d4ee