■21/3/9 11:39PM
Treachery
[Click for image]
:||
2021/4/25に気づいた、ハニーちゃんおめでとうとありがとう、エピソードは今度どこかで
Comment (0)
■21/3/6 1:43PM
ZERO
[Click for image]
値段と糖質とプリン体と度数、モノによっては明らかに太る感じがしない、ゆって0じゃ無い安酒でも糖質15g位らしいので良いのがなければいつものでいいかも。それより現像ができない!!→LightRoom再インスコ→LRよりSony謹製の方が色が良かった→元画像が暗すぎが理由→LRでノイズを追加調整(元画像に注意、14mmf1.8の使い道がなく勿体ない、マクロとして物撮りしたい感じがあるがマクロは70-200の方がええし、14は人物用だな)
極ZERO: 138/0/0/5 ちょい高、不味い、5%で軽いが酔えなくはない、太る感じ×Asahi Off: 118/0/0/3-4 酔えない、ノンアルの亜種かフルーティで旨い〇のどごしZERO: 118/0/0/4 フルーティで旨い、軽いが酔えなくはない〇贅沢ZERO: 118/0/x/6 プリン有 6%で嬉しいが雑味がすごくある気が▲バーリアル糖質50%off緑: 85/5-10/?/4 かるくない、そもそもZEROでないが旨い◯+氷結ZEROレモン: 108/0/0/5 レモンが強く旨い、飲みやすい◎鏡月焼酎ハイ: 98/0/0/7 スッキリ高アルコール度で満足感、ドライが好きかも◯+いいちんこ下町のハイボール: 168/0/0/7 高ぇ、重い感じがする▲
パーフェクトサントリービール: 168/0/x/5.5 高ぇ、旨い〇 →氷結Zeroレモン＞鏡月ドライのコンボが強い
イオン麻婆豆腐辛口(肉付)vs丸美屋辛口(花椒なし)：丸は味穏やか、Aは塩と肉多い →Aeonのとろみ入れるの減らす、甘口は邪魔甘さで、中辛が一番いいイオン四川式(肉無)vs丸美屋大辛(花椒付)：Aは高いし辛い、お口は甘め好きda
冷食が新しくなった、Palmボックスは忘れて何度か買ったが小さい
バターよりマーガリンの方が健康的になったらしい
小岩井ヘルシー仕立てか、明治コーンソフトは近くで買えるが
[Click for image]
[Click for image]
ノンアルはどうなのか？飲み比べる、ジンジャエールよりいいか
キリンGreen's free 旨い、ノンアルならビールが良さそうで、ノンアルビールならこれでは？
Suntoryのんある酒場レモンサワー 酸っぱい、旨い（メシが進む感じはしない
Takara辛口ゼロボール スッキリしているが何か不味いので逆に酒感あり旨い
AsahiStyleBalanceハイボール まじウィスキー、旨い（メシが進む感じはしない
トップバリューホワイトサワー カルピスソーダでノンアルの意味なし
トップバリューBeerTaste スッキリ旨いが軽くハレ感が少ない
Suntoryノンアル気分カシスオレンジ 旨い、大人のジュース感
ワイン チェリオ
ジントニック ジントニック
檸檬堂
「カルト」はすぐ隣に: オウムに引き寄せられた若者たち (岩波ジュニア新書) | 紹子, 江川 |本 | 通販 | Amazon
霊的体験は飲み物にLSDを入れていたとなっている、まぁ殆どコレで教祖になれる
Comment (0)
■21/2/22 12:00AM
BigQuery part2
■BQタイムアウトは6時間
■BQ transfer(クエリが不要なBQ連携、3rd partyもあり)
サードパーティ転送を使用する | BigQuery | Google CloudCloud Storage の転送の概要 | BigQuery | Google CloudAmazon S3 転送の概要 | BigQuery | Google Cloudデータセットコピー、GCSファイルAma S3, Azure storage, Oracle, Salesforce, Ads系等々
■Cloud SQLにBQからクエリSELECT * FROM EXTERNAL_QUERY("connection_name", "SELECT * FROM db.tbl")https://zenn.dev/ykdev/articles/4a4d2fbc6b4fe1
■BQ DMLクォータ超過割とSQLだとすぐに壁にあたる
上限がテーブル単位のためテーブル名を分けると回避できるらしいGCP BigQuery 応用編 ~制限について~ - 自称フルスタックエンジニアのぶろぐ。 (hatenablog.com)BQ streaming insert->BQ storage read/write APIの上限はDMLと別で、閾値が大きいINFORMATION_SCHEMAを用いたBigQueryのストレージ無駄遣い調査 - ZOZO TECH BLOGBigQuery Storage Write API を使用してデータを一括読み込み、ストリーミングする | Google Cloud
APIだとProtocol buffersが必要で、Date/Timestampが対応しておらず
Unixエポックからの日数/秒数への変換が必要、、、
■マテリアライズドビュー実体データを保持しリフレッシュ更新で早いため集計等に向くベーステーブルは一つ、カウントができない、使用できない関数がある等の制約がある
またマテビューはビューを元に作成できずテーブルからである必要があるストレージコストは掛かるが、通常ビューで時間掛かる計算を頻繁にする場合は早く安くなる可能性があるBigQueryのMaterialized Viewを使う #データ分析 - Qiita
■BQ同時実行数オンデマンドでは使用可能なスロット数に基づき自動的に同時実行数が決定され超えるとスロットに 空きがでるまでキューに保管されるプロジェクトごとにクエリの最大同時実行数は動的に決まる同時実行数の最大値は指定できるが、大きくしても実行数が増えることはなく、あくまで自動決定 内の方が優先されるEditionsが割り当てられているプロジェクトでは最大同時実行数を明示的に設定できる他に、インタラクティブクエリ、バッチクエリ、クエリ順序や上限などBigQueryクエリキューの概要まとめ (zenn.dev)
■BigQueryの列レベル・行レベルのセキュリティBigQueryの列レベル・行レベルのセキュリティを解説 - G-gen Tech Blog個人情報や機微情報を隠す
BigQuery の行レベルのセキュリティの概要 | Google Cloud
行レベルなら同じテーブルを使うので同じダッシュボード/Appが使える（AuthorizedViewの方が柔軟だが）
データ マスキングの概要 | BigQuery | Google Cloud
列レベルアクセス権以外にもマスクの種類があり、ハッシュだったり先頭4文字や末尾４文字等で共通文字化としてマスク化できる列レベルのアクセス制御の概要 | BigQuery | Google Cloud列レベルのアクセス制御によるアクセス制限 | BigQuery | Google Cloud
BQ画面＞左ナビのポリシータグ ポリシータグを作成（組織単位で一括一覧表示） タグは階層化できるので、全ユーザタグ＞管理者タグ＞社長タグ スキーマ＞Addポリシータグ タグが付いていればプレビューで見れない select * except(tag_column)にする必要がある メタデータは見れる（カラム名、型 ポリシータグ画面＞対象ポリシー選択＞情報パネルで権限者一覧 fine-grained readerを付与するとselect *ができるようになる 社長タグに社長だけ権限付ける等※APIを有効にし、ポリシーを有効にする必要がある
■承認済みビュー authorized view
authorized viewを設定するとそのviewを対象とする権限だけ必要で権限をさかのぼり付与しなくていい（通常のviewは参照元の権限も必要） この権限移譲は閲覧権限のみで編集権限等は含まないBigQueryの承認済みビュー設定方法 - Qiita被参照の元テーブル側に許可するview名を設定する
参照権限は緩くなるが、編集権限は厳しくなる（設定するビューは変更しない前提で承認する形）
authorized viewを付与すると玄関となったビューはdataEditorではビュー更新ができなくなる
ソーステーブルにもdataOwnerが必要（通常のビュー作成にはdataViewerがソースに必要）
基本の安全策はauthorized view設定を外す＞ビュー変更＞AV再設定がいい 対象のAVは管理者を立て一元管理するのが良さそう
（テーブルやビューを作って権限付与してバッチだとdata ownerが必要なのは注意）
■Authorized系にはメリットとデメリット
１) Authorized viewを設定するメリット一度設定してしまえばソース側への権限付与依頼が不要となりビューの権限管理が省力化できるビューにて閲覧対象を絞ることができソース全体は閲覧させないことができる、絞れる
普通のビューは元データへの権限が必要で見せたくないデータへも権限が必要になる場合がある
２) Authorized viewを設定するデメリット一度設定してしまえばソース側での権限付与依頼が不要となり被参照側で許可不許可の判断ができなくなる、誰にデータ閲覧権限を付与しているか把握できず管理が機能しなくなる一面がある将来に置かれるソース側のデータの閲覧も許可することになり不用意に閲覧が可能となってしまうterraformでAuthorized view設定が剥がれてしまう危険性ビューを編集するにあたりAuthorized viewを外す必要がある、あるいはソースにもEditor権限
すぐにビューを変更することができなくなる（ビューを一旦削除することはできる）
Authorized viewはビューを削除して、再度作り直すと生きている場合がある、ダメな場合も多いが これで漏洩させたくない情報を一時含められる危険性がある３）authorized datasetを設定するデメリット
設定時は良いかもしれないが、将来的に意図しないデータがDS入った場合も閲覧を許してしまう
↓
データセットは細かく作成してアクセスレベル設定し普通のビューを使う
ソース全体を閲覧させられない場合(直接権限を付与できない場合)にAVを使うメリットがでる
情報漏洩リスクはどちらも多段ビューで同じ感じ、だがビュー作成でAV設定が生きているバグがデカい
■BQクリーンルームデータ準備側でパブリックし、使う側でサブスクする (BQ exploreでペインでAddする)スプシ保存できない、開覧数のレポートが見れる(使用者名は見えない) 実はパブ側でサブスクし公開すれば、閲覧とJobUserだけで使用できるようになるGAでなく、またオンデマンドしか無理、コピペやデータコネクタは可能で残念
■ロール割り当て者の出力
カスタムロールのProject_Admin、Project_Managerが誰に割り当てられているか
Asset inventoryをBQにダンプしたデータからクエリする
WITH projects AS ( SELECT resource.data AS rsc, ancestor_path FROM prj.cloud_asset_inventory.cloud_asset_inventory_org_resource_now WHERE asset_type = 'cloudresourcemanager.googleapis.com/Project' ), projects_info AS ( SELECT JSON_EXTRACT_SCALAR(rsc, '$.projectId') AS projectid, JSON_EXTRACT_SCALAR(rsc, '$.lifecycleState') AS lifecycleState, ancestor_path FROM projects ), projects_efficient AS ( SELECT * FROM projects_info WHERE NOT REGEXP_CONTAINS(ancestor_path, "folders/apps-script") ), projects_num_adm_mgr AS ( SELECT REPLACE(name, '//cloudresourcemanager.googleapis.com/projects/', '') AS project_num, REPLACE(b.role, 'organizations/1234567/roles/', '') AS role_value, STRING_AGG(REPLACE(m, 'user:', ''), ', ') AS member_value FROM prj.cloud_asset_inventory.cloud_asset_inventory_org_iam_policy_now, UNNEST(iam_policy.bindings) AS b, UNNEST(b.members) AS m WHERE asset_type = 'cloudresourcemanager.googleapis.com/Project' AND (role LIKE '%Project_Admin%' OR role LIKE '%Project_Manager%') GROUP BY project_num, role_value ), projects_adm_mgr AS ( SELECT JSON_EXTRACT_SCALAR(resource.data, '$.projectId') AS project, projects_num_adm_mgr.role_value, projects_num_adm_mgr.member_value FROM projects_num_adm_mgr LEFT JOIN prj.cloud_asset_inventory.cloud_asset_inventory_org_resource_now AS res ON projects_num_adm_mgr.project_num = REPLACE(res.name, '//cloudresourcemanager.googleapis.com/projects/', '') )SELECT projects_efficient.projectid, projects_efficient.lifecycleState, CONCAT(projects_efficient.projectid, ', ', projects_adm_mgr.role_value) AS role_value, projects_adm_mgr.member_valueFROM projects_efficientLEFT OUTER JOIN projects_adm_mgrON projects_efficient.projectid = projects_adm_mgr.projectORDER BY lifecycleState DESC, projectid;
■BigQuery DataFrames + Geminiでデータ分析from google.cloud import bigqueryfrom google.generativeai import GenerativeModel
bq_client = bigquery.Client()
# クエリ実行してDataFrame取得query = "SELECT customer_review FROM `my_project.my_dataset.reviews` LIMIT 10"df = bq_client.query(query).to_dataframe()
# Geminiモデルの準備model = GenerativeModel("gemini-pro")
summaries = []for review in df["customer_review"]: response = model.generate_content(f"次のレビューを要約してください: {review}") summaries.append(response.candidates[0].text) # 修正: 正しくレスポンスを取得
# DataFrameに要約を追加df["summary"] = summaries
table_id = "my_project.my_dataset.review_summaries"job = bq_client.load_table_from_dataframe(df, table_id)job.result()print("データをBigQueryに保存しました！")
■BigQuery ML (bqml_llm_infer) + Geminiで感情分析from google.cloud import bigquerybq_client = bigquery.Client()
# クエリ実行してDataFrame取得query = """SELECT bqml_llm_infer( model_name => 'my_project.my_dataset.gemini_model', prompt => CONCAT('このレビューの感情分析をしてください: ', customer_review) ) AS sentiment_analysisFROM `my_project.my_dataset.reviews`LIMIT 10"""df = bq_client.query(query).to_dataframe()print(df)
■IAM(Identity and Access Management)/// BANGBOO BLOG /// - GCP
前回
/// BANGBOO BLOG /// - BigQuery
Comment (0)
Navi: < 16 | 17 | 18 | 19 >
-Home
-Column [134]
-Europe [9]
-Gadget [78]
-Web [137]
-Bike [4]
@/// BANGBOO BLOG ///
