bigquery の int64 への cast は切り捨てではない
すなわち、
select cast(1/2 as int64)
は切り捨てではなく、丸められ
1
となる。
(今更ながら知る。。。)
切り捨ては、floor を使おう。
参考
bigquery で日本語の曜日のJOIN用テーブルを作成する
背景
毎度日本語で曜日を表示するためのJOIN用テーブルを作成に時間がかかるので、 コピペ用のコードが欲しい。 (JOIN用テーブルでなくifで作ったほうががテンプレートしては使いやすいかも。)
そのクエリ
#standardSQL WITH _weekday_list AS ( SELECT SPLIT('日,月,火,水,木,金,土', ',') AS a), weekday_list AS ( SELECT w, ja FROM _weekday_list, UNNEST(a) AS ja WITH OFFSET AS w )
例
'2019-01-01' は何曜日か?
#standardSQL WITH _weekday_list AS ( SELECT SPLIT('日,月,火,水,木,金,土', ',') AS a), weekday_list AS ( SELECT w, ja FROM _weekday_list, UNNEST(a) AS ja WITH OFFSET AS w ) SELECT ja FROM (SELECT cast(format_date('%w', '2019-01-01') as int64) w ) data JOIN weekday_list using(w)
参考
colaboratory で、pycodestyle を使う
次のように、colaboratory 上に書いて実行(python3.6で確認)
!pip install flake8 pycodestyle pycodestyle_magic %load_ext pycodestyle_magic
あとは、
%%pycodestyle
# ... ここにコード
と書いて実行。チェックの必要がなくなれば、コメントにしてしまう。
#%%pycodestyle # ... ここにコード
PACモデルで十分な事例数とその使い方
PACモデルで十分な事例数
ここで、は学習事例数、 は仮説空間、エラー率以内の概念モデルを の確率で学習すること(Tom Mitchell 著 Machine Learning 7章より)。
使い方
次の様な質問に即答できる。
- データが倍になったら何がうれしいか?
- エラー率が半分になる
- あるいはエラー率が目標に未達の場合、その目標の達成確率がかなり上がる。
参考
BigQuery で、ある特定の期間の日を全て列挙する
背景
BigQuery で、ある特定の期間の日を全て列挙したくなった。
方法
generate_date_array を使う。
例:'2018-01-01' から '2018-12-31' までの期間を array に。
SELECT GENERATE_DATE_ARRAY('2018-01-01', '2018-12-31') dt_list
例:'2018-01-01' から '2018-01-31' と '2018-06-01'から'2018-06-30' までの期間を array に。
WITH date_range AS ( SELECT DATE '2018-01-01' AS start_date, DATE '2018-01-31' AS end_date UNION ALL SELECT DATE '2018-06-01' AS start_date, DATE '2018-06-30' AS end_date ) SELECT ARRAY_CONCAT_AGG(GENERATE_DATE_ARRAY(start_date, end_date)) dt_list FROM date_range
例:'2018-01-01' から '2018-01-31' と '2018-01-15'から'2018-02-15' までの期間をかぶりを考慮しつつ 展開
WITH date_range AS ( SELECT DATE '2018-01-01' AS start_date, DATE '2018-01-31' AS end_date UNION ALL SELECT DATE '2018-01-15' AS start_date, DATE '2018-02-15' AS end_date ), date_list AS ( SELECT ARRAY_CONCAT_AGG(GENERATE_DATE_ARRAY(start_date, end_date)) dt_list FROM date_range ) SELECT DISTINCT dt FROM date_list JOIN UNNEST(dt_list) AS dt
例:'2018-01-01' から '2018-01-31' と '2018-01-15'から'2018-02-15' までの期間をかぶりを考慮しつつ またarrayに
WITH date_range AS ( SELECT DATE '2018-01-01' AS start_date, DATE '2018-01-31' AS end_date UNION ALL SELECT DATE '2018-01-15' AS start_date, DATE '2018-02-15' AS end_date ), date_list AS ( SELECT ARRAY_CONCAT_AGG(GENERATE_DATE_ARRAY(start_date, end_date)) dt_list FROM date_range ) SELECT ARRAY( SELECT DISTINCT dt FROM UNNEST(dt_list) dt) AS dt_list FROM date_list
FirebaseのRTDBからFireStoreに乗り換えるためにGCPのプロジェクトを作成したときのメモ
背景
GCPのプロジェクトの中では、Firebaseのストレージは、排他的で、RTBDかFirestoreのどちらしか選べないらしい。 強制的にFirestore にする手もあるが、戻れなくなるのも嫌なので、新しくGCPのプロジェクトを作ることにした。 なお、Firebaseのプロジェクトという言葉と、GCPのプロジェクトいう言葉があって紛らわしい。
対応
普通に作った。ただ、ユーザの設定を元のGCPのプロジェクトから引き継ぎたい。継承という文字列が見えるが別のプロジェクトから継承するものではないらしい。
またrole(役割)のコピーというコマンドも見つかったりするかもしれないが、割り当てられた状態をコピーするのではなく、role(役割)そのものをコピーするものなので関係がない。
答えは、 iam-policy を入手すること。 次のコマンドで得られる。
gcloud projects get-iam-policy OLD_PROJECT_ID > iam-policy.yaml
サービスアカウントも含まれているので、editor などで、不必要な項目は消す。 etag や version も消さないと、
ERROR: (gcloud.projects.set-iam-policy) Resource in project [xxx-xxx-xxx:setIamPolicy] is the subject of a conflict: There were concurrent policy changes. Please retry the whole read-modify-write wit h exponential backoff.
みたなエラーが出る。
次に新しいGCPプロジェクトを作成し、そのプロジェクトに読み込ませる。
gcloud projects set-iam-policy NEW_PROJECT_ID iam-policy.yaml
etagやバージョンが消されていれば(バージョンは新しい番号をふってもいいかも)
The specified policy does not contain an "etag" field identifying a specific version to replace. Changing a policy without an "etag" can overwrite concurrent policy changes. Replace existing policy (Y/n)?
みたいなメッセージが出るので、エンターを押して実行する。
以上で別プロジェクトのユーザの設定が引き継がれているはずだ。
- https://cloud.google.com/sdk/gcloud/reference/projects/get-iam-policy
- https://cloud.google.com/sdk/gcloud/reference/projects/set-iam-policy
まとめ
別のGCPプロジェクトからユーザをコピーするときは
gcloud projects get-iam-policy
と
gcloud projects set-iam-policy
を使う。