カテゴリー: Google Cloud Platform

　今日も見に来てくださって、ありがとうございます。石川さんです。今夜は中秋の名月です。と言っても書き始めたのが遅いし、記事も長くなりそうなので、書き終わって公開するときには、中秋の名月は終わっているでしょうね。

　さて、今回は、ちょっと要望がありまして、GCPのCloud SQLを使ってみることにしました。ぼくはOracleマスターということもあり、普段データベースを使うと言えば、Oracleを使っています。そう、RDBMSシェアNo1のオラクルさまです。ただ、GCPではOracleのインスタンスが作れるようになっていないのですよね。Oracleもクラウドサービスを展開していますから、ライバル関係ということになるのかなぁ。そんなこともあり、GCPのCloud SQLのラインナップには登場しそうにありませんよね。

　所有している書籍やWeb上のGCPのドキュメントを色々と読んで、バッチリ理解してから始めようと思っていたのですが、いつまでたっても一向に始められません。こういう時は、まずやってみる、ということが大切ですよね。ということで、スクリーンショットを取りながら進めてみたいと思います。

新規プロジェクトの作成

　では、まずはGCPコンソールへ行って、プロジェクトを作成しましょう。三角形をクリックします。

　今回は、プロジェクト名を「Sample-DB」にしてみます。上記の三角形をクリックすると以下のようなウィンドウが表示されなりますので、「新しいプロジェクト」をクリックします。

　プロジェクト名は、「Sample-DB」に入力しなおして、あとはデフォルトのまま「作成」ボタンをクリックします。

　すると、アイコンが表示されたり、なにやら作成中の雰囲気を出したあと、プロジェクトのダッシュボードが表示されました。が、、、これは今作ったプロジェクトではありませんね。そこで下向きの三角形をクリックしてプロジェクト一覧を表示します。

　すると、以下のような一覧が見えますが、先ほど作ったプロジェクトが見当たりませんね。以下の「すべて」のところをクリックするか、虫眼鏡アイコンの隣の「プロジェクトとフォルダを検索」へ「Sample」と入力すれば、先ほど作成したプロジェクトが現れます。

　では、「すべて」をクリックしてみましょう。

　見つかりましたので、「Sample-DB」を選択して「開く」をクリックしてみましょう。以下の通り、プロジェクトの作成に成功しました。プロジェクトを作っておくと請求情報をプロジェクト単位でみられる等、管理しやすくなると思います。

Cloud SQLのMySQLインスタンスを作成してみる

　では、次にCloude SQLのMySQLを作成してみます。ナビゲーションメニューの「データベース」カテゴリから「SQL」を選択します。左上の横線三本のハンバーガーマークをクリックするとナビゲーションメニューが表示されますので、メニューを下の方へ下げて行って、「SQL」を探してください。

　「SQL」をクリックするとCloude SQL インスタンスを作成するためのウィザードが始まりました。次は、当然「インスタンスを作成」ですね。既存システムのデータを持っていれば、データの移行もできるようですね。企業システムでのリプレース案件だと結構利用するタイミングがありそうなので、気になりますね。いやいや、今回はまずインスタンスを作成しますよー。（ちょっと調べてみたら、今のところ、MySQLとPostgreSQLで利用可能で、SQL Serverは、まもなく利用可能ということです。2021年9月23日現在）

　よく読んでみると、「MySQL」「PostgreSQL」「SQL Server」のインスタンスが作成できるようですね。では、「インスタンスを作成」ボタンをクリックします。以下のような表示になりました。今回は「MySQL」を選択します。

　「MySQL を選択」をクリックすると以下のような画面になりました。

　ふーむ、何々、「インスタンスを作成するには、まずCompute Engine APIを有効にする必要があります。」ですか。なるほど。と、いうことはMySQLインスタンスはCompute Engineを利用して実現しているのですね。いきなりMy SQLインスタンスって、どうやって起動するんだろうか、と、思っていましたが、仮想マシンを実行して、その上で動かす、ということなのでしょうね。ま、完全な想像ですけど。そして、このホームページはCompute Engineを利用しているので、この設定は不要なのでは、と、思いましたが、プロジェクトごとに設定が必要なのか、APIとは別の設定なのかのどちらかでしょうね。いずれにせよ、APIを有効にしないとどうにもならないので、「APIを有効にする」をクリックします。

　しばらく上記のようにくるくるしてから、以下のようになりました。

　必須入力は、「インスタンスID」と「パスワード」のみですね。今回はお試しで作ってみるだけなので、最小構成にしたいですね。データベースのバージョンは、8.0、5.7、5.6から選べました。おそらく初期値の「5.7」は安定したバージョンなのでしょうね。今回はお試しなので、8.0を選択しておくことにします。インスタンスが作成され、常時存在することになるので、インスタンスを起動している間は使用料がかかります。金額については、概算ですが、Cloud SQL for MySQL の料金で、計算できるようです。リージョンの選択によって若干金額が変わってきます。現時点のアイオワでは、1仮想CPUあたり、1か月で$30.15、1GBあたり、1ヶ月で$5.11です。東京は$39.19、$6.64なので、やはり若干高くなっていますね。業務で利用する場合は、ネットワークの距離の影響もあるので、慎重に選ぶ必要があるかと思いますが、今回は安い方のアイオワで問題ありませんね。そして「ゾーンの可用性」ですがこちらは「シングルゾーン」に変更しましょう。複数のゾーン（高可用性）を選択すると、およそ料金が二倍になります。ま、二台用意しておいて、一台がダメになったとき切り替えてダウンタイムを極小にしよう、という取り組みですから、ま、そうなりますよね。そして、vCPU数が4に、メモリ、26GBもいらないでしょう。こちらは、「構成オプションを表示」を選択することで設定できるようになっていました。

　へえ、インスタンス構成は、あとから更新することもできるのですね。ま、ちゃっちゃと最小構成を目指して片づけてしまいましょう。まずは、マシンタイプですね。

　おや、4 vCPU、26GBが最小構成なのでしょうか、、、あ、違いました。「ハイメモリ」が選択されている状態でしたね。ちょっとクリックして中身を覗いてみましょう。

　なるほどねぇ、順番的には「共有コア」が一番軽量なのでしょうか。以下に、一覧にしてみました。

• 共有コア
  • 1vCPU、0.614GB
  • 1vCPU、1.7GB
• 軽量
  • 1vCPU、3.75GB
  • 2vCPU、3.75GB
  • 4vCPU、3.75GB
  • カスタム※
• 標準
  • 1vCPU、3.75GB
  • 2vCPU、7.5GB
  • 4vCPU、15GB
  • カスタム※
• ハイメモリ
  • 4vCPU、26GB
  • 8vCPU、52GB
  • 16vCPU、104GB
  • カスタム※

※カスタムは、vCPUが1～96まで入力可能（1より大きい場合は偶数）で、メモリがvCPU数(N)に応じておよそ、3.75+1.75×(N-4)/2+0.25×INT((N-2)/10)[N<6は3.75]～6.5×N GBの範囲で変更されました。

　と、いうことで、今回は「共有コア」の1vCPU、0.614GBを選択します。

　次は、ストレージですね。

　SSDとHDDですね。やはりHDDの方が安価ですね。どれくらい違うのかというと、1GBあたり、アイオワリージョンでは、SSDが$0.170/月、HDDが$0.090/月、東京リージョンでは、SSDが$0.221/月、HDDが$0.117/月ということのようです。パフォーマンス要件はありませんので、ま、ここはHDDを選択しておきましょう。

　ストレージ容量は、10GB、20GB、100GB、200GB、カスタムですが、こちらも最小要件の10GBを選択します。容量を増やすほどパフォーマンスが向上する、ということが書いてありますが、どうしてでしょうね。もしかしたら、ディスクへのアクセスをうまく分散できるのかも知れませんね。ストレージの自動増量を有効にする必要は、まったくありませんが、ま、利用しなければ影響ありませんので、そのままにしておきましょう。

　次は、「接続」ですね。

　おすすめは、Cloud SQL Ploxyを使って接続してください、ということのようです。プライベートIPはVPCのみの内部（プライベート）IPアドレスで、インターネットにアクセスできるのが外部（パブリック）IPアドレスになります。Webアプリケーションの一部としてのデータベースなら、プライベートIPアドレスのみ有効にすればよいでしょうか、これは構成によりますね。今回はお試しなので、このままの設定でよいでしょう。

　次に、バックアップの設定ですね。今回のお試しではバックアップなしでよいのですが、ちょっと内容は確認しておきましょう。

「バックアップを自動化する」はデフォルトでチェックが入っていますが、時間枠で選択するようですね。マルチリージョンを選択しておけば複数のリージョンにバックアップされるのでとりあえず安心ですね。リージョンを選択すると、特定のロケーションをセットする必要があります。バックアップの数が7にセットされていますが、1週間であれば、特定のタイミングまで戻せますよ、という感じでしょうか。ポイントタイムリカバリを有効にすると、詳細オプションにログを保持する日数を設定できるようになりました。デフォルトは7日でした。
　ま、ここは、「バックアップを自動化する」はチェックを外しておきます。サンプルですから、バックアップ必要ありません。実際に稼働するシステムならもっとまじめに考えないといけませんけどね。あ、このチェック外すと「ポイントインタイムリカバリを有効にする」は触れなくなりました。普通のバックアップも取得していないのに、復元はムリですよ、ということですね。

　次は、メンテナンス項目ですね。ちょっと見てみましょう。なるほどねぇ、デフォルトだと、短期間だけど中断してしまうのですね。

　メンテナンスの時間枠は、「おまかせ」以外は「土曜日」～「金曜日」でした。曜日単位で指定するのですね。一般的な企業なら、土日が選ばれるのでしょうね。更新の順序は「任意」「後で」「早め」の三択でした。これは面白いですねぇ。バージョンアップを適用する時期を早めにするのか後でやるのか、それともお任せなのか、設定するのですね。あと、メンテナンス不要期間も設定できるのですね。今回はお試しで、すぐ削除してしまおうと思っているので、設定はこのままにしておきます。

　「フラグ」では、MySQLのパラメータやオプション、インスタンス構成や調整など、様々な設定ができるようです。これはMySQLに精通しないとなかなか設定は難しそうですね。今回は不要ですが、チューニングや調査が必要な局面があるときにはここで設定可能ですね。いざというときのために覚えておきましょう。

　やっと、最後の項目、「ラベル」です。

　「ラベル」を追加すると、インスタンスを区別したり、請求料金を分析したりすることができるようです。今回は放置しておきます。

やっとひととおりの設定を眺め終わりました。

インスタンスの作成

　やっと、「インスタンスを作成」をクリックしました！ここまで読んでくれたひと、いますかねぇ。。。

　あら、インスタンスIDと、パスワードがない、と、叱られました。もうすっかり失念しておりました。

　インスタンスIDは、何でもよいのでしょうかねぇ。「Sample-DB」を入れてみます。そして、パスワードは「生成」をクリックしてみましょう。

　ちょっと理解に苦しみますが、、、これは、大文字がダメだった、ということでしょうか。小文字に変えてみます。予想通り、小文字なら大丈夫でした。「生成」も成功したので、今度こそ、「インスタンスを作成」をクリック！

　一瞬、「インスタンスを作成しています。」のようなメッセージが出た後、画面が切り替わり、しばらく「アップロードとSample-DBのオペレーション」の「sample-dbを作成しています」が右下に表示されます。

　まだ、作成中のような気がしますが、一応、できたのかな。いや、もうしばらく待ってみましょう。。。と、いうことでインスタンス作成完了まで、11分とちょっとかかりました。できました！

データベースの作成

　次はデータベースを作成します。MySQLはデータベースを複数作成できる、ということで作成してみます。

　Cloud SQLの「データベース」メニューを選択します。

　「データベースの作成」をクリックしてみます。

　「データベース名」は何にしましょうかねぇ。ルールがあるようですが、とりあえず「Sample-DB」と入力してみます。

　おお、なるほど、英数字とアンダースコアなので、ハイフンがダメなのですね。ハイフンをアンダースコアに変更してみます。

　オッケーでした。「文字セット」と「照合」を決めなければいけませんね。utf8はいいけど、「照合」って何でしょうね。選択値は「utf8_bin」とか「utf8_czech_ci」とか文字コードっぽいですね。選択した「文字セット」によって、選択値が変わりました。ま、後で変更できるようなので、デフォルトでも問題ないでしょう。「作成」をクリックします。一瞬作成中のような雰囲気になりましたが、すぐにできました。「照合」は「utf8_general_ci」が選択されたようですね。

テーブルの作成

　次にテーブルを作成します。まずは、MySQLに接続しなければいけないのですが、、、どうやるのでしょうか。「概要」の「このインスタンスと接続」にありました！

　インスタンスに接続するさまざまな方法については、ドキュメントに書いてあるようですが「詳細」はあとにして、「CLOUD SHELLを開く」をクリックしてみました。

gcloud sql connect sample-db –user=root –quiet

というコマンドで接続できるようです。Enterキーを入力したところ、、、

　Cloud Shellの承認画面が表示されました。「承認」をクリックします。

　おお、アクティブなアカウントが選択されていない、と申されましても。。。現在どのアカウントでログインしているのでしょうか。試しにもう一回実行してみます。おや、エラーが変わりました。

　今度は「Cloud SQL Admin API」がこのプロジェクトではまだ使われておらず、有効になっていない、ということのようです。APIを有効にするには、表示されたURLをクリックせよ、ということでクリックしてみますと、ブラウザで別のタブが開きました。

　なるほど、「gcloud sql」コマンドを使うには、このAPIを有効にしないといけないのですね。承知いたしました。「有効にする」をクリックします。くるくるして、次の画面が表示されました。

　とりあえず、Cloud SQL Admin APIが有効になったようです。ターミナルから再度実行してみます。

　おお、コネクションのために5分必要なのでしょうか。。。パスワードを聞かれたので、先ほど自動生成したパスワードを入力して、Enterキーを押下すると、、、できました！！！

　先ほど作ったデータベースを確認してみましょう。「show databases;」と入力してみます。

　次に、データベースの選択ですね。「use Sample_DB;」を実行して、テーブルが無いことを確認します。「show tables;」を入力してEnterキーを押下します。

　やっと、テーブルが作成できます！「create table sample_table ( id int auto_increment, t text, primary key(id) );」実行してみます。さらに結果を「show tables;」で表示してみます。

　データをインサートしてみます。

　入りました。念のため、結果を確認します。

できました！

インスタンスの停止

　サンプルでしか使わないインスタンスですので、すぐに終了します。インスタンスが存在していると、利用していなくても放置しているだけで、課金されてしまいます。

　念のため、先ほどの接続ですが、データをコミットして、終了します。

　「概要」から「停止」をクリックします。

　すると、以下のようなメッセージが表示されますので、「停止」をクリックします。

　停止しました。

追記（2021-09-30）

　作成直後に確認したときは、請求予定金額が0円でした。作成には請求がかからないようになっている、というのもちょっと変な話なので、タイミングを改めて請求金額を確認してみようと思っていて、確認してみました。

　およそ一週間で176円、ということでした。データベースインスタンスを停止したので、もう課金は発生しないはず、というふうに思っていたのですが、予想が外れました。一体何に課金されているのでしょうか。ということで見てみました。

• Cloud SQL for MySQL: Zonal – IP address reservation in Americas　139.62 hour　¥154
• Cloud SQL for MySQL: Zonal – Low cost storage in Americas　1.97 gibibyte month　￥19
• Cloud SQL for MySQL: Zonal – Micro instance in Americas　2.19 hour　¥3

　上から青い線、赤い線、オレンジの線、の順番です。オレンジは最初だけですが、他のは安定していますね。青はIPアドレスの予約、ということなので、利用していなくても課金されてしまう、ということなのでしょうね。赤は、安いストレージ、ということなので、容量を使用している分が、課金されている、ということですね。オレンジはインスタンスなので、停止したから課金されない、ということのようです。微々たる金額ではありますが、使わなくても存在しているだけで請求が発生することがわかりました。IPアドレスは毎日およそ30円なのですね。

まとめ

　やはり、書籍やWebで調べることも大事ですが、実際に試してみてよかったです。かなり長くなってしまいましたが、ここまで読んでくださって、ありがとうございます。Cloud SQLのMySQLインスタンスの作り方がわかりました。実際の業務で利用しようと思うと、クライアントのPCから接続する方法とか、他のGoogle App Engineサービスなどから接続する方法など、もうちょっと調べる必要があると思います。とりあえず、試せる環境ができました。

　今日も見に来てくださって、ありがとうございます。石川さんです。

　先日、何となくGoogle Cloud Platformコンソールを眺めていると、ふと、目に留まるものがありました。

　そうそう、Google Cloud Platformのスタートガイドにあった「Hello Worldアプリをデプロイ」というメニューです。先日「デプロイってなに？」と尋ねられたとき、ウェブサーバーにプログラムを配備して使えるようにすること、だけど、それでホントにあってるかなぁ、と、心配になったのでした。ここに、ありましたよ！デプロイが！！

　スタートガイドなので、初心者にも優しいはず。GCP、契約はしているんだけど、このWordPressのホームページ以外、ほとんど活用できていないのですよねぇ。会社を始めたときは、ぼくはGCPのプロフェッショナルになろう、と、思っていたのですけどねぇ。おぼれそうになって、しばらくお休みしていました。と、いうことで動かして見ました。

　クリックすると右側に概要が現れます。こんな感じです。

　はい、では、右下の「開始」をクリックして始めたいと思います。でもその前に、チュートリアルの左にある「←」をクリックして見ます。

いろいろなチュートリアルがあるのがわかりました。今回は「App Engineを試す」ということでもう一度クリックして戻ります。

　今回はPythonを選択します。いったん戻らないとGoが自動的に選択されてしまうので、違う言語でチュートリアルをやりたい方は、同じ手順でやってくださいね。上のPythonを選ぶとまた元の画面に戻ります。あと、環境は二つあって、上の「Python」は「スタンダード環境」下は「フレキシブル環境」と、異なります。違いについては、こちらに記載があります。自由度の高いシステムの場合は「フレキシブル環境」を選択する必要がありますが、今回は「スタンダード環境」で問題ありませんので、こちらを選択します。

　では、チュートリアルなので、そんなに難しく考えず、とにかく「開始」です！やってみて、初めてわかることって、けっこうあるんです。

　お、プロジェクトを選ぶか、新しく作成するのですね。既存のプロジェクトがチュートリアルで汚れる（？）のはイヤなので、新しくプロジェクトを作りましょう。「新しいプロジェクトを作成」のところをクリックしてみます。

　なんと、新しいプロジェクト作成画面が開きました。お試しで作った時はプロジェクト名を変えて作成したのですけど、どうせ後で削除するプロジェクトなので、このまま「作成」をクリックします。

　はい、通知が表示されて「My Project 60925」が作成されました。あ、前回と、、、前々回のプロジェクト作成履歴が表示されていますね。(笑)実は、二回も実験しています。慣れるまで、何回かやる必要があるかと思って、今回、三度目の正直ですね。

　プロジェクト設定の画面、新しいプロジェクトがセットされた状態になりました。「次へ」をクリックして進みましょう。

　次に、Cloud Shellを使う、ということですね。Cloud Shellとはいったい何なのか、全体を見渡すと、ありました。このアイコンですね。

　ボタンが見つけられましたので、クリックして見ます。何やらプロビジョニングしています、、、というのがしばらく表示された後、でました！

　なるほど、クラウド上のシェルだから、CLOUD SHELLなのですね。そのまんまやん。そして、次は、サンプルコードのクローンを作成して、「Hello World」コードに移動するのですが、このクローン作成、ちょっとだけ注意が必要です。

　よく見てください。なんと、続きがあるのです。

　ぼくは、「git clone https://github.com/GoogleCl」と入力してEnter、エラーになったくちです。いちばん右側のアイコンでコピーできますし、その左隣のアイコンでCloud Shellにコピペしてくれます。便利ですね。コピペして、実行しましょう。

　はい、しばらくクルクルしてから終了しました。次はチュートリアルの指示に従ってディレクトリを移動します。クローンとして作ったフォルダへ移動します。ホームディレクトリの配下にできた「python-docs-samples/appengine/standard_python3/hello_world」へ移動します。こちらもボタンのコピペで実行できますね。（追記：2021年8月29日に実行して確認したところ、ディレクトリ名が画像と異なっていました。ま、コピペすれば大丈夫ですね。）

では、チュートリアルの「次へ」ボタンを押して進みます。ステップ3/8です。

　デプロイの構成、ということでmain.pyの内容表示してみます。コメントがたくさんあって、必要なところは以下の部分だけでした。

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello():
    """Return a friendly HTTP greeting."""
    return 'Hello World!'

if __name__ == '__main__':
    app.run(host='127.0.0.1', port=8080, debug=True)

　Flaskというのは、Python用のWebフレームワークです。このスクリプトはルートにアクセスされると単に挨拶として「Hello World!」を戻します。

　ここでは、構成ファイルを表示ということで中身を出力してみましたが、

runtime: python37

　というふうに、ランタイムにpython37を使う、ということがわかりました。「次へ」をクリックします。（追記：2021年8月29日時点で、こちらは「python39」になっていました。時代は進みますねぇ。ちなみにチュートリアルの記載は「python38」でした。更新漏れですね。(笑)）

　次は、アプリのテストです。virtualenvを実行して仮想環境を作成して、それを有効にする、ということですね。コピペで実行します。

　次に、pipでFlaskに関連するモジュールをインストールしてmain.pyを実行します。

（追記：2021年8月29日 pip実行時、pipのバージョンが古いですよ、と、WARNINGが出力されました。アップグレードの方法が記載されていましたが、ま、放置していても問題ありませんよね。）

　次に、ウェブでプレビューボタンをクリックします。ここにありました。

クリックします。

　ポート8080でプレビューを選択します。すると、

　やっと、たどり着きました。念願の「Hello World!」です。単に「Hello World!」の文字を出力しているだけです。ふ～。これでやっと半分終了ですね。Ctrl＋Cキーでアプリーションのインスタンスが終了しました。「次へ」をクリックします。

　ほう、リージョン内に、アプリを作成して、それからデプロイですね。やっとでました、デプロイです。ちょっとここまでやってみましょう。

＃＃＃＃＃＃＃＃＃＃　2021年8月29日 追記開始　ここから 　＃＃＃＃＃＃＃＃＃＃
「gcloud app create」を実行したところ、Cloud Shellの承認というポップアップが表示されました。途中で作業を中断して再開したせいかもしれません。

「承認」をクリックしましたが、画面上にはエラーが出ていました。どうやらうまく承認はされなかったようです。

　現在、アクティブなアカウントが選択されていません、ということのようですので、言われるがままに、「gcloud auth login」を実行してみました。以下のようにURLが示されました。その下に「Enter verification code:」と書いてあるので、URLで表示された先で認証コードが取得できるのでしょう。

　と、いうことで示されたURL（https://accounts.google.com/o/oauth2/…）をクリックすると、ブラウザの別タブに「アカウントの選択」が表示されましたので、こちらのGCPで使用しているアカウントを選択しました。

すると、以下の通りリクエストの許可を求めてきました。

「許可」をクリックしたところ、以下のとおり、ログイン用のコードが表示された画面が出てきました。

これをコピーして「Enter verification code:」のところへ貼り付けます。すると、ログインできた、というメッセージが表示されました。

ここで改めて「gcloud app create」を実行したところ、上記の「gcloud app create実行結果 」の結果が表示されました。
＃＃＃＃＃＃＃＃＃＃　2021年8月29日 追記終了　ここまで 　＃＃＃＃＃＃＃＃＃＃

　おっと、「Please enter your numeric choice:」と言われています。あなたのApp Engineアプリケーションを置くリージョンを選んでください、ということで、まあ順当に[1]番でしょうねぇ。

　リージョンを選択すると、10秒ほどクルクルして完了しました。「Success!」と言ってますね。次に「gcloud app deploy」を使ってあなたの最初のアプリをデプロイしてください、と言ってますね。チュートリアルの方はもうちょっとたくさん記述があって「gcloud app deploy app.yaml \ –project t-system-277912」と書いてありますね。チュートリアルの方を実行してみましょう。

　おっと、続けますか？と、聞いてきています。もちろん続けますよ。「Y」を入力してエンター。

　5分ほど経ったでしょうか、デプロイが完了いたしました！

　「アプリにアクセスする」をクリックして、見事、「Hello World!」が出力されました。

　「次へ」をクリックして6/8へ行きましょう！

　次は、アプリのステータスを表示する、ということですね。[App Engine]を選択するのですね。

App Engineをクリックすると次の画面があらわれました。

　「次へ」をクリックします。

　設定ページに行って、アプリケーションを無効にすれば、課金されなくなるそうです。

　「アプリケーションを無効にする」をクリックしてみます。

　おお、無効にしますか？と、聞いてきました。アプリIDを入力しないと無効にならないようです。間違って無効にしちゃった、という事故が起きにくい仕組みになっているようです。アプリIDを入力して、「無効にする」をクリックします。

　次は、「プロジェクトを削除」ですね。[IAMと管理]を探します。

　「IAMと管理」をクリックします。

　次に、「リソースを管理」をクリックします。

　今回作成した「My Project 60925」をチェックして「削除」をクリックします。

　おお、削除の確認画面ですね。ここでもプロジェクトIDを入力しないといけないようです。間違って違うプロジェクトを削除しにくい仕組みですね。それに30日間の猶予もあるのですね。プロジェクトIDを入力して「シャットダウン」をクリックします。削除なのに「シャットダウン」なのですねぇ。ちょっと不思議な感じがします。

　「OK」クリックしたところ、プロジェクトが消えました。

まとめ

　いや～、チュートリアルを順番にやっただけですが、長くなっちゃいましたね。ここまでお読みくださってありがとうございます。おつかれさまでした。

　前回のエントリーの続きです。やっとGoogle Cloud SDKがインストールできたところまで書きました。bq コマンドライン ツールの使用に関するクイックスタートに書いてありましたが、インストールした後にはBigQuery APIを有効にする必要があるそうです。

• 

　「APIを有効にする」ボタンをクリックしてみます。

• 

　上記のGCPのページへ遷移しました。プロジェクトを選ぶ必要があるようです。

• 

　BigQuery APIはプロジェクトごとに設定するようですね。アプリケーションごとに設定することもあるのでしょうか。こちらは不明ですねぇ。とりあえず今回のために作ったプロジェクト（BigQuery challenge 2019)を選択して、「続行」ボタンをクリックします。左下に「APIを有効にしています」というポップアップがでて、次のような表示にかわりました。

• 

　なるほど、APIは有効でしたか。次は、適切な認証情報ということで、「認証情報に進む」ボタンをクリックしてみます。

• 

　おお～、これはなんだか難しそうですねぇ。あ、でも、お手伝いしていただけるようです。使用するAPIは、「BigQuery API」がセットされているので、これで問題ないでしょうね。App EngineまたはCompute EngineでこのAPIを使用する予定、あるのかなぁ。。。将来的には、App Engineでアプリケーションを作って、BigQueryのデータを呼び出して使いたいから、「はい、1つまたは両方を使用しています」を選択すべきか、今回のテーマはあくまでローカルファイルをアップロードすることだから、「いいえ、使用していません」を選ぶべきか、悩むなぁ。お、よく読むと、App Engineでは必要ない、と、書いてあるような気がするなぁ。と、いうことで「いいえ、使用していません」を選ぼう。そして、「必要な認証譲歩」ボタンをクリックします。

• 

　画面が変わって、次は、「サービスアカウントを作成する」必要があるようです。サービスアカウント名は、自由でいいのかな？「？」をポイントすると「このサービスアカウントで行うことを説明します」と、ヒントがポップアップしました。役割は、おお、意外といっぱいありました！

• 

　今回は、テーブル定義が作られた状態からのデータを投入する、ということで考えているので、「BigQuery データー編集者」が適切なのかな。「BigQuery ユーザー」とはどう違うのでしょうか。。。わかりませんが、とりあえず選択して進めましょう。 では、サービスアカウント名を「サンプルデータをロードする」くらいにしてと。おお、サービスアカウントIDが勝手に入力されました。そして、選択すると、おお、内容説明がポップアップした上に、複数選択できるのですね！とりあえず進めるって、必要ですねぇ。悩みが減りました。クエリ実行するためには、BigQueryユーザーを選ばないといけないようです。BigQueryデータ閲覧者はデータセットを表示することができるけど、クエリは発行できない、ということですね。

• 

　「キーのタイプ」は、たぶんデフォルトの「JSON」のままでよいでしょうね。「次へ」ボタンをクリックします。

• 

　おお、自動でファイルがダウンロードされてしまいました。このJSONのファイルを利用するのでしょうか。「閉じる」をクリックします。

• 

　すると、認証情報のページが出てきて、どうやら「サービスアカウントキー」というものができたようです。む～、とりあえずこれでBigQuery APIが有効になった、ということでしょうか。
　そういえば、前回のエントリーでCloud SDKをインストールしたけど、動作確認してませんでしたね。クイックスタートにも書いてありましたが、確か、bqコマンドが使えるはずですね。試しに実行してみます。

bg show bigquery-challenge-2019:books.books

　失敗しました。。。「Not found: Dataset」ということですね。もしかしたら、大文字小文字を気にするのかもしれません、ということで、再度入力します。

bg show bigquery-challenge-2019:BOOKS.BOOKS

• 

　 おおっ、出ました！成功したよ～！！
大したことはしていないんだけれど、うれしいですねぇ。BigQueryのテーブル名は大文字小文字を気にする、ということがわかりました。今後、気を付けます。
　クイックスタートは続けてクエリを発行していますが、今回ぼくはクエリを実行する権限を与えていないつもりなので、失敗するのかも。ちょっとやってみます。

bq query "SELECT * FROM bigquery-challenge-2019:BOOKS.BOOKS"

• 

　予想通りエラーになりましたが、エラー内容が予想と違いましたねぇ。予想外に”-“が登場したと言っています。そういえば、演算のマイナスとの区別ができないから、テーブルを指定するときには括弧「[]」でくくること、という記述がどこかにあったような気がしますね。（追記：オライリー・ジャパンの『Google BigQuery』P.219 7.2 BigQueryのクエリ言語 のところに記述がありました。ISBN978-4-87311-716-4）ちょっと試しにやってみます。今度は想定通りのエラーになるかな？

bq query "SELECT * FROM [bigquery-challenge-2019:BOOKS.BOOKS]"

• 

　あら、想定外にデータが取得できてしまいました。そういえば、さっきダウンロードしたJSONのファイル、何にも指定していないよね。なるほど、ということは、bqコマンドの承認は、前回のエントリーでSDKをインストールしたときにやったものが有効になっているのですね。（あれです、’gloud init’を実行して、ログインして承認したやつですね！）

　ええと、ということは、BigQueryのAPIを有効にしようと一生懸命やったこと、って、無意味だったのかな。。。？

　はい、気を取り直して、新しく書籍のデータを作って入れてみます。

C:\work\NEW_BOOKS.csv
10,やさしいみつのりさんのデータベース,2020-05-14,9999-12-31
11,きびしいみつのりさんのデータベース,2021-05-14,9999-12-31

　コマンドは、以下の通りです。「–noreplace」オプションを付けると、テーブルに追加してくれるそうです。上書きしたい場合は「–replace」で、何もつけなければ、テーブルが空の場合にのみ書き込みされるということですね。「–source_format」で指定できるフォーマットは、「CSV、AVRO、PARQUET、ORC または NEWLINE_DELIMITED_JSON です。」と、書いてありますね。CSVとNEWLINE_DELIMITED_JSONしか分かりません。（汗）ええと、いつか余裕が出てきたら、他のフォーマットも調べてみたいと思います。

bq load --noreplace --source_format=CSV BOOKS.BOOKS C:\work\NEW_BOOKS.csv

さて、実行してみます。

• 

　おお、なんか成功したっぽい！ほら、タイムスタンプが変わってるし！

• 

　データも、ほら、、、

• 

　ぐはっ！！文字化けしてる。。。(笑)
そういえば、確かUTF-8にしないとダメだって、どこかに書いてあった気がしますねぇ。やっと終了、って、思ったのに～♪

• 

　おお、確かにSJISになってます。サクラエディタの文字変換機能でSJISをUTF-8に変換して、再度コマンドを実行して確認してみます！

• 

　やっとこ、できました！
でも、なんだろう、この書名は、ねぇ。。。(笑)

　これで、実現方法は完了ですね。サーバーでCSVファイルをUTF-8で作成して、bqコマンドを実行するバッチファイルをスケジューラに登録すれば、自動でデータロードできるところまで確認できました。注意点は文字コードを気にすることと、’cloud init’の権限ですね。テストはこれで動いたということで問題ないですけど、本番環境のサーバーでは、どのユーザで権限を設定するのか、というのが課題になりそうです。

　BigQueryのAPI、有効にしたのが無意味だったか確認してみます。先ほど作成した認証情報を削除してみます。

• 

　「削除」ボタンをクリックします。

• 

　おお、脅されますねぇ。脅しには屈しませんよ！「削除」をクリックします。数秒で消えましたので、再度データをロードしてみます。問題なく動きましたので、BigQuery APIの利用は、データのロードには関係ない、ということがわかりました。やりたいことはできるようになったけど、プロの仕事としては、いまいちだなぁ。GCPをプロとして使っていくためには、権限、認証を理解することが課題ですね。またそのうち調査したいと思います。では、今回のエントリーはこのあたりで終了とします。

　先日のエントリーで実験的にやりましたが、WebのUIからINSERT文を記載することで複数件データを投入することができました。しかし、実業務で毎日WebのUIにINSERT文を書くわけにはいきません。Googleさまの担当者さまからそのやり方が記載されているというURLを二つ、教えていただきました。

• Oracle data (ETL) to Google BigQuery using Google Cloud Dataflow and Dataprep
• Cloud Storage からの CSV データの読み込み

　いずれもGoogle Cloud Storage(GCS)にあるCSVを読み込むことを推奨しているように見えますね。確か、いったんGCSに保存しておけば、そこからBigQueryへはGoogle内のネットワークで完結できるので速い、と、聞いたような記憶があります。確かに何度もGCSからBigQueryのテーブルを再作成し直すならそれは最適でしょうが、そこがおすすめの理由でしょうか。どちらの方法にどんなメリットがあるのでしょうかね。
　ぼくが想定しているのは、オンプレミスのオラクルデータベースからデータを抜き出して、BigQueryへ入れるという流れを構築することです。でも、上記の最初のリンクではサードパーティのETLツールを使えばとっても便利で時間の節約になる、ということと、DataPrep、DataFlowのGCPサービスがとっても便利なのでそれを使っているということが書いてありました。とっても便利なのかもしれないけれど、ツールとサービスの概念や使い方を新たに学ばなければならないというハードルの高さがあって、くじけそうです。ええと、DataPrepは、「分析や機械学習に使用するデータを視覚的に探索、クリーニング、準備するためのインテリジェント クラウド データ サービス」ということですので、データクリーニングが視覚的に実行できて時間が節約できる、ということですかね。そして、DataFlowは「信頼性と表現力を損なうことなく、ストリーム データ処理とバッチデータ処理を簡素化」ということなので、データを流すためのジョブを作れるサービスなのでしょうかね。
　と、いうことで、いったんは、CSVファイルを作るのはオラクル側で処理を作成してファイルを作るとして、そのファイルを直接BigQueryへ読み込む方法を探ってみます。上記の二つ目のリンクからたどっていった先に、ローカルのCSVファイルを読み込む方法もありました。

• データをローカル データソースから読み込む

　こちらをよく読んでみた結果、Webのユーザインターフェースを使った方法とコマンドラインから実行する方法が書かれてありました。ぼくは、自動的にアップロードされる仕組みを作りたい、と思っていますので、当然、コマンドラインからの実行方法を選択します。これを使うためには、「bqコマンドライン」というものが使えるようですが、当然ローカルマシンにはそんなコマンドが入っていないので、インストールする必要があるでしょう。bqコマンドラインが使えるようになるためのチュートリアルがありました。

• bq コマンドライン ツールを使用したクイックスタート

　なるほど、Cloud SDKをインストールして初期化する必要がある、ということですね。インストーラをダウンロードして、Cloud SDKシェルを起動、gloud initを実行する、と言う手順ですね。そして、Google Cloudライブラリをインストールすれば、開発言語から簡単に呼び出せるようになるようです。Windows ServerではInternet Explorerでセキュリティ強化の構成がセットアップされている場合は、注意が必要のようです。今回はお試しでこちらのWindows10のクライアントマシンからの実行なので気にしなくてよさそうですが、オンプレミスのWindows Serverにセットアップするときは、注意が必要そうですね。
　さて、手順に従って、やりましょうかねぇ。まずは、ダウンロードします。

• 

「GoogleCloudSDKInstaller.exe」というファイルがダウンロードされました。ウィルススキャンして脅威は見つかりませんでした(笑)ので、実行してみます。

• 

　Google Cloud SDK Setupの、ようこそ画面が表示されました。GCPのリソースを管理したり作成したりすることが簡単にできるようになるライブラリやツールが入っているそうです。使用した統計情報が自動的に送られますが、ここは使わせていただいているので協力させていただきましょう、チェックしたままにします。
「Next >」をクリックします。

• 

　契約条項に同意するために内容をよく読んでから、「I Agree」をクリックします。

• 

　次はインストールタイプの選択です。今回はローカルPCなのでどちらでもよいでしょう。ただ、Windows Serverでバッチを動かすときは、All usersにしておいた方がよいのかな、と、いうことでAll usersを選択してみます。管理者権限が必要になりました。

• 

　「Next >」をクリックします。すると、ユーザアカウント制御の画面が表示されます。

• 

　場合によっては管理者ユーザとパスワードが聞かれるかも知れませんね。「はい」をクリックして続行します。

• 

　インストール先を尋ねられます。特に変更する必要はありませんので、「Next >」をクリックします。ディスクスペースは、89MBytes必要ですね。

• 

　やっとインストールできそうですね。「Cloud SDK Core Libraries and Tools」はチェック必須ですね。「Bundled Python」は、Python2.7がインストールされるようです。先日Anacondaをインストールして、Python3.7.3をゲットしたばかりなので、正直2.7のPythonは必要ないのですけど、これが入っていないとSDKが使えないそうなので、仕方ありません、このままにしておきます。「Cloud Tools for PowerShell」はWindowsのPowerShellからGCPのリソースを管理するのに使えるようです。今のところPowerShellから利用する予定はありませんが、初期設定を外す理由もないのでそのままにしておきます。「Beta Commands」はベータ機能を使いたい人向けですね。新しい物好きなぼくには、とっても気になるチェックボックスですが、こうやっていつも目的を見失うので今回はチェックを外したままとします。いつもなら、とりあえず全部チェックしちゃえよ～、ってなるのですけど。(笑)
　さあ、「Install」ボタンをクリックします。

• 

　いろいろインストールされて、、、終了。1分もかかりませんでしたね。

• 

　「Next >」をクリックします。

• 

　インストール完了しました。あとは、チェックボックスに従った内容を実行してくれるわけですね。上の二つはスタートメニューとデスクトップにショートカットを作ってくれる、という一般的なものなのですね。そして、Google Cloud SDKシェルをスタートして、’gcloud init’を実行して設定してくるそうです。そういえば、インストールの手引きにこのチェックを受け入れてね、と、書いてありましたね。このままで「Finish」をクリックします。そうすると、想定通り、コマンドプロンプトが起動されました。

• 

　ログイン必須ということで、「Y」を入力してEnterキーを押しますと、ブラウザが開いて「Googleにログイン」画面が表示されました。

• 

　一覧から、GCPのアカウントのアドレスをクリックするとアカウントへのアクセスをリクエストする画面に切り替わりました。

• 

• 

　許可しないと使えるようになりませんので、「許可」ボタンをクリックします。

• 

　おお、認証が完了しました！で、終わったのでしょうか。。。
コマンドプロンプトを見てみると、続きがありました！

• 

ええと、使用するクラウドプロジェクトを選べ、ということで、先日作った「bigquery-challenge-2019」プロジェクトを選択します。「1」を入力して、Enterキーを押します。なるほど、’gcloud init’で、プロジェクトを選択しておくことができる、ということでしょうね。変更したいときは切り替えコマンドがあるのか、新たに設定を追加するのかはわかりませんが、気にしておく必要がありますね。

• 

　すると、いろいろとメッセージが出てきて、終了しました。
今度こそ、完了したようです。まだ、やりたいことは終わっていませんが、長くなってきたので、いったん終了して次のエントリーへ続きます。

　先日の投稿の最後に、「データポータルで調べる」というボタンが気になるということを言い残していたのですけど、さっそくクリックして見てみました。クリック後に表示されたのは以下の画面です。

• 

　初めて使う人には、こんなダイアログが表示されるようです。もちろん、使ってみますよ。そのためにクリックしているのですから。ということで「使ってみる」をクリック。

• 

　思い切ってクリックしたのに、また何やら聞かれました。こういうとき、ぼくはすぐにくじけそうになります。初めての、よく知らないものに出会ったときに、ここであきらめることが多いのですけど、今日はがんばりますよ～。「承認」をクリックします。

• 

　また何か聞かれました。もうそろそろ限界ですよ。データへのアクセスは先ほど承認したはずなのですけど、、、む～、今度はアカウントへのアクセス、どこが違うのでしょうか。

• 

おお、下の方にボタンがありました。「許可」をクリックします。

• 

　これで先ほど検索したデータを使えるようになったようです。右側にグラフのアイコンがあって、これを切り替えることで表示が変わるようですが、、、いかんせん分析できるようなデータではなかったので、どれを選んでもうまく表示されませんね。レコード件数しか分析できる情報がないですからねぇ。

　ちなみに、グラフ＞表のアイコンは、左上から「表」「棒付きデータ表」「ヒートマップ付きデータ表」「スコアカード」「数字が短縮表示されたスコアカード」「時系列グラフ」「スパークライングラフ」「平滑時系列グラフ」「縦棒グラフ」「積み上げ縦棒グラフ」「100%積み上げ棒グラフ」「棒グラフ」「積み上げ横棒グラフ」「100%積み上げ横棒グラフ」「円グラフ」「ドーナッツグラフ」「地図」「複合グラフ」「積み上げ複合グラフ」「折れ線グラフ」「平滑線グラフ」「積み上げ面グラフ」「100%積み上げ面グラフ」「面グラフ」「散布図」「バブルチャート」「ピボットテーブル」「棒付きピボットテーブル」「ヒートマップ付きピボットテーブル」「ブレットグラフ」と、いろいろなグラフが選べます。

　データ部分には、「データソース」「期間のディメンジョン」「ディメンジョン」「指標」「ページ当たりの行数」「集計行」「並べ替え」「サブの並べ替え」「デフォルトの日付範囲」「Interactions」と項目名だけではなんとなくしか分かりませんが、選べるようです。今回のこのデータではいろいろと試すことができなかったので、また別のデータを作って動作確認のため、再チャレンジしてみたいと思います。どんなデータがいいかなぁ。。。

　いろいろとデータポータルを触って満足したので、BigQueryにちょっと戻ってみてみました。先ほどまではあまり気にならなかったのですけど、「クエリ履歴」が見られるのですね。

• 

　こちら、ぼくが先日実行したクエリ以外にも、先ほどデータポータルから検索したときに発行されたクエリもこちらに出てくるようです。この履歴をクリックすると詳細が表示されました。

• 

　各クエリはこんな風に自動で保存されて、再利用が簡単にできるようになっているのですね。ちなみに、あて先テーブルは「期限切れの一時テーブル」となっていますが、一時テーブルは、グーグルさまによって、だいたい24時間ほどは再利用できるようになっているそうです。そういえば、クエリ実行時にあて先にテーブル名を指定できるようになっていましたね。なので、再利用が必須の時は名前を付けて、今回限りのときは名前を付けずにクエリを発行する、という感じになるでしょう。

　そういえば前回、後で再利用できるかも、と、こっそり作業していたのですけど、クエリにも名前を付けて保存することができるのですよね。上の画像だと「ThirdSelectBooks」と名前を付けて保存してあります。「保存したクエリ」から確認できます。

• 

　この中の一つ「ThirdSelectBooks」を選択してみます。内容が表示されて「クエリをエディタで開く」をクリックすることで再利用することができました。

• 

　よく見ると「個人用（本人のみが編集可能）」を選べるようになっていますね。ほかの選択肢は、一つだけですね。

• 

　試しに、「プロジェクト（プロジェクトメンバーが編集可能）」を選択してみました。

• 

　おお、プロジェクトのすべてのメンバーと共有できるようです。ただし、元には戻せないと脅されました。今回は一人プロジェクトなので、キャンセルです。きっと、保存したクエリの下にある「プロジェクトクエリ」を選択することで見られるようになるのでしょう。あと、リンク共有をオンに変更すると「クエリURLの共有：」という欄が出現します。おそらくこのURLを知っている人にだけ共有できる、という機能なのでしょうね。組織で利用するときには、必要な機能になってきますね。

　あと、残ったメニューの「ジョブ履歴」は、文字通りジョブの履歴ですね。今回の作業中にも発生してました。BOOKSテーブルがうまくなくて再作成したときにバックアップとしてテーブルをコピーしたときにジョブが発生していました。ほかにもジョブとして扱われるものもあるかも知れませんが、現時点ではとりあえず不明です。

• 

　そして、「転送」と「スケジュールされたクエリ」を選択したところ、両方ともBigQuery Data Transfer APIのページが表示されました。おそらく、このAPIを有効にして、API経由で実行するのでしょうね。あと、「BI Engine」は、同名のベータ版の機能のページが表示されました。ええと「BigQuery 内の複雑なデータセットをインタラクティブに探索できる高速なインメモリ分析サービスです」ということが書いてありました。む～、違いがよくわからないサービスが登場してきましたなぁ。インメモリで処理できるということで、速さが必要なときに使えばいいのかな。余力があれば、また調べてみよう。今回はこれくらいで。

　やっとクエリの準備ができました！
と、いうことで、どんな話をしようとしていたかというと、リソースに開始日と終了日を持つと、ある期間に有効だったデータを取得するのが難しくなるかどうか、という議論です。そんなデータの持ち方したら、複雑になってしまうのでダメだというご指摘を受けたことがあって、意外と簡単になりますよ～、という話です。
　先ほどのデータ、ビジュアル的に表すと以下のようになります。2001年1月1日から2004年12月31日の期間に販売されていた書籍を取り出すとどうなるでしょうか。

• 

このような有効期間のある問い合わせの場合、考えなければならないバターンを単純化すると、以下のように、６パターンになります。

• 

ここで、StartからEndの範囲内で有効だったリソースは、②、④、⑤、⑥の４種類となります。まじめにやると、

②（Start ≦ 開始日 AND 終了日 ≦ End）
　　　　　　　　OR
④（開始日 ≦ Start AND End ≦ 終了日）
　　　　　　　　OR
⑤（開始日 ≦ Start AND Start ≦ 終了日）
　　　　　　　　OR
⑥（開始日 ≦ End AND End ≦ 終了日）

と、いうことになります。確かにこれは手間だし、複雑になるのが嫌だという抵抗も、もっともかもしれません。これをSQLで表現すると、以下のようになります。

SELECT BookNo, BookName
  FROM BOOKS.BOOKS
 WHERE ('2001-01-01' <= StartDate AND EndDate <= '2004-12-31') 
    OR (StartDate <= '2001-01-01' AND '2004-12-31' <= EndDate)
    OR (StartDate <= '2001-01-01' AND '2001-01-01' <= EndDate)
    OR (StartDate <= '2004-12-31' AND '2004-12-31' <= EndDate)

BigQueryで実行してみると予想通り、ちゃんと6件取得できました。

• 

　それでは、お待ちかねの改案です。実は、この問い合わせ、上記の①と③以外を検索する、と読み替えられます。

NOT（　①（終了日　＜　Start）　OR　③（End　＜　開始日）　）

意外とシンプルですね。SQLで表現すると以下の通りです。結果も変わりませんね。

SELECT BookNo, BookName
  FROM BOOKS.BOOKS
 WHERE NOT (EndDate < '2001-01-01' OR '2004-12-31' < StartDate)

• 

ド・モルガンの法則で書き換えて整形すると以下のようになります。さらにシンプルになりました。結果も同じになりました。

SELECT BookNo, BookName
  FROM BOOKS.BOOKS
 WHERE '2001-01-01' <= EndDate AND StartDate <= '2004-12-31'

• 

　ある四角形の領域に重なる線分を探す、という問題を見つけましたが、今回のケースと同じ問題として考えられますので、興味のある方はチャレンジしてみてください。

BigQueryまずは使ってみましたが、実際の業務で使っていくためには、もう少し調査が必要ですね。

• CREATE TABLE文などのスクリプトでテーブル作成するやり方
• 利用可能なデータ型
• NO以外のカラム名として利用できない予約語
• オンプレミスのデータをBigQueryへ読み込むやり方

あと、上の画像のクエリ結果のところにある「データポータルで調べる」が気になります！ユーザーにも使えるようなものなのかどうか、後ほど調べてみます。
今回はここまでです。

　先日の続きです。
空のテーブルはできましたが、データの入れ方がわかりません。RDBならINSERT文ですよね、ということでお試しでINSERT文を書いてみました。

• 

何と、エラーが出ました。「VALUES」のリストかクエリが想定されているんだけど、違いますよ～、と、言われていますね。完全に当てずっぽうで書いてみたのですけど、行けましたねぇ。続きを書いてみます。文字列の表現はシングルクォーテーションでいいのか、日付はどうやって表現するのか分からないけど、とりあえずの形で「INSERT INTO BOOKS VALUES (1, ‘CASEツール ‘, 1989-11-01, 1999-11-01);」を書いてみたところ、やはりエラーが。。。「Table name “BOOKS” cannot be resolved: dataset name is missing.」ということで、データセットの名前が必要ということですね。。。いやいや、これはいつ終わるかわからないパターンですよ。
　と、いうことでまじめにやりましょう。こういう時はマニュアルを参照します。右上の方にアイコンがありましたよ！

• 

ヘルプをクリックしたら、「人気の記事」一覧が表示されましたので、その中の「BigQuery」を選んでみました。すると、いろいろ書いてありますが、、、「よく参照されるトピック」の中に、「BigQueryへのデータの読み込み」がありました。ポチリと押してみましたら、書いてありましたねぇ。データは次の方法で読み込むことができます、、、

• Cloud Storage から
• Google アド マネージャーや Google 広告などの他の Google サービスから
• 読み取り可能なデータソース（ローカルマシンなど）から
• ストリーミング挿入を使用してレコードを個別に挿入する
• DML ステートメントを使用して一括挿入を行う
• Cloud Dataflow パイプラインの BigQuery I/O 変換を使用して BigQuery にデータを書き込む

ということで、今回は5番目のDMLステートメントでチャレンジしている、ということですね。で、マニュアルをよく読んでみると、INSERT文はカラムを指定する必要があるということで、気を取り直して実行してみますが、、、今度は、「Syntax error: Unexpected keyword NO at [1:26]」というエラーメッセージ。どうやら、カラム名に「No」を使っていたのがいけないのでしょうか。イライラしますねぇ♪
　はい、気を取り直して、No→BookNoに変更してテーブルを作り直します。今度は前回の経験をもとに、スキーマをテキストとして編集で作成してみました。カンマ区切りか、JSON形式で作成できるようです。

• 

さあ、気を取り直してINSERT文作成の続きです。日付の指定方法が分かりませんでしたが、文字列としておけば問題なさそうです。なんとか成功しそうです！どやっ！？

• 

成功しました！

• 

「テーブルに移動」して「プレビュー」を選択すると、データが入っていました。数行でも並列で投入されるのでしょうか、順番はバラバラになっていました。

• 

　それにしても、項目に予約語は使えないなら、作るときに教えてくれればいいのにねぇ。日本語の項目が作れないのも不親切な教え方でしたけど、テーブル作成上の注意点はこのあたりでしょうか。データ作成時の注意点は項目の指定は省略できないという点でした。で、やっと最初に話したかった話題の準備ができましたが、ちょっと長くなってきたので、次のエントリーとします。