IDEA Note

  • BigQueryのpartitioned-tables(分割テーブル)について

    BigQueryのpartitioned-tables(分割テーブル)について

    はじめに

    BigQueryは従量課金のモデルのため、スキャン量に応じて課金される。

    いかにスキャン対象を減らすかが非常に重要になる。

    通常のwhereで絞ったとしても、スキャンはされてしまうため課金を回避することができない。

    そこで、partitioned-tables(分割テーブル)である。

    partitioned-tables(分割テーブル)について

    現時点で大きく2つ存在している

    • 取り込み時間分割テーブル:
      データを取り込んだ(読み込んだ)日付またはデータが着信した日付に基づいて分割されたテーブル。
    • 分割テーブルTIMESTAMP 列または DATE 列を基準にして分割されたテーブル

    詳細はこちら

    https://cloud.google.com/bigquery/docs/creating-partitioned-tables

    通常のwhereのように使い、課金額を減らすのが目的であれ”取り込み時間分割テーブル”ではなく”分割テーブル”のが便利そうだ

    やってみた

    テーブル定義

    まずはテーブル定義

    [
      {
        "mode": "NULLABLE", 
        "name": "register_day", 
        "type": "STRING"
      }, 
      {
        "mode": "NULLABLE", 
        "name": "rtime", 
        "type": "STRING"
      }, 
      {
        "mode": "NULLABLE", 
        "name": "lesson_date", 
        "type": "TIMESTAMP"
      }
    ]

    テーブルを作成する

    bq mk --table --expiration 3600 --description "This is my table" --time_partitioning_field=lesson_date --time_partitioning_type=DAY --label organization:development logs.cccc bbbb 

    lesson_dateが分割テーブルのパーティションとなる

    読み込み

    データはこんな感じ

    {"register_day":"3320915", "rtime":"tsukada", "lesson_date": "2019-04-30 14:02:04"}
    {"register_day":"3320915", "rtime":"tsukada", "lesson_date": "2019-05-30 14:02:04"}
    {"register_day":"3320915", "rtime":"tsukada", "lesson_date": "2019-06-30 14:02:04"}
    {"register_day":"3320915", "rtime":"tsukada", "lesson_date": "2019-07-30 14:02:04"}

    読み込ませる

    bq load --source_format=NEWLINE_DELIMITED_JSON logs.cccc cccc.json 

    使ってみる

    #standardSQL
    SELECT
      *
    FROM
      logs.cccc
    WHERE  
      lesson_date BETWEEN '2017-01-01' AND '2019-10-01'

    少数のデータなので記事としては微妙だが、最小単位の10Mが課金対象となる。

     

  • gcloud(gcpのコマンド)をzshで使えるようにする

    gcloud(gcpのコマンド)をzshで使えるようにする

    はじめに

    gcloudコマンドしようとすると、デフォルトではbashへinstallすることが前提となってしまっている。

    zshでgcloudコマンドを設定する。

    前提

    gcloudコマンドがinstallされていること。

    まだの場合は公式手順を参考にinstallする。

    https://cloud.google.com/sdk/downloads?hl=ja

    gcloudコマンドのインストール場所を探す

    デフォルトでは “` ~/google-cloud-sdk/ “` にインストールされる

    もし存在しない場合はfindなどで調べる

    .zshrcの設定を変更

    google-cloud-sdk配下に

    “` path.zsh.inc “` というファイルがある。これを.zshrcへ追加する

    source /Users/sumito.tsukada/google-cloud-sdk/path.zsh.inc

    このような感じ。

    その後は再読み込みを実施する

    “` source ~/.zshrc “`

    以上。

     

  • ERROR 1064 (42000) at line 101: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1

    ERROR 1064 (42000) at line 101: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1

    はじめに

    mysqldumpで取得した結果を、そのままmysqlへ流しこもうとしたらエラーになった。

    実施したコマンド

    変数には適宜設定値が入る。

    やりたいことはmysqldumpでデータを取得し、標準出力で別のサーバへ流し込む。

    mysqldump -u$dbbackupuser $dbbackupname $table -h$dbbackuporiginal -p$dbbackuppass | mysql -u$dbrestoreuser -h$dbrestoreserver -p$dbrestorepass $dbrestorename 

    発生したエラー

    ERROR 1064 (42000) at line 101: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

    原因

    mysqldumpコマンドはデフォルトでmysqlの独自構文が入ってしまうことがあり、微妙なmysqlのversionの差異がこの独自構文を受け付けないことがある。

    対処

    ANSIフォーマットで出力させるオプション “` –compatible=ansi “` を追加する

     after

    mysqldump --compatible=ansi -u$dbbackupuser $dbbackupname $table -h$dbbackuporiginal -p$dbbackuppass | mysql -u$dbrestoreuser -h$dbrestoreserver -p$dbrestorepass $dbrestorename 

     

  • gitのリポジトリの引越しをする

    gitのリポジトリの引越しをする

    はじめに

    リポジトリが肥大化したり、プロジェクトが大きくなり、サービス名が変わったり、プロジェクトを進めていくといろいろなことがある。

    リポジトリの移行方法をまとめる。

    移行元(gitlab) -> 移行先(gitlabの別プロジェクト

    before projectからgit cloneする

    % git clone --mirror git@git.hoge.com:before/beforeproject.git
    Cloning into bare repository 'beforeproject.git'...
    
    

    移行先のプロジェクトへgit pushを行う

    % git push --mirror git@git.sumito.com:after/afterproject.git
    Counting objects: 1381, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (520/520), done.
    Writing objects: 100% (1381/1381), 266.47 KiB | 88.82 MiB/s, done.
    Total 1381 (delta 629), reused 1381 (delta 629)
    remote: Resolving deltas: 100% (629/629), done.% 

    最後に

    今回はgitlabのプロジェクトからgitlabですが、gitlabからgithubのような場合も同様の手順でいけます。

  • CannotStartContainerError: API error (500): failed to initialize logging driver: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. status code: 400,

    CannotStartContainerError: API error (500): failed to initialize logging driver: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. status code: 400,

    はじめに

    fargateでタスクを登録し、起動させた時エラーが発生。原因と対処をまとめる

    An error occurs when a task is registered and started with fargate. Summarize causes and actions

    原因

    CannotStartContainerError: API error (500): failed to initialize logging driver: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. status code: 400,

    CloudWatch のロググループが存在しない

    CloudWatch log group does not exist

    対処

    CloudWatchにロググループを作成する

    Create a log group in CloudWatch

    その後、再度タスクを実行すれば問題は解消できる。

    After that, the problem can be solved by executing the task again.

     

  • nodeのversion管理をnvmで行う

    nodeのversion管理をnvmで行う

    はじめに

    Linux/Macにてnodeのversion管理を手軽に行うよう、nvmで切り替えれられるようにする

    nvmインストール

    nvmのオフィシャルリポジトリはこちら

    https://github.com/creationix/nvm

    ここに記載があるように、installを行う。

    curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash

    ~/.bash_profileに環境変数を追加する

    export NVM_DIR="$HOME/.nvm"
    [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
    [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

    変更した~/.bash_profileを読み込む

    source ~/.bash_profile

    stableをインストール

    nvm install stable

    を行うと、stableをインストールすることが可能。

    執筆時のversionは以下の通り

    # node -v
    v11.12.0

    任意のversionをインストール

    nvm ls-remoteコマンドを実施すると、インストール可能なversionが列挙される

    # nvm ls-remote
            v0.1.14
            v0.1.15
            v0.1.16
            v0.1.17
            v0.1.18
            v0.1.19
            v0.1.20
            (略)

    version 8.9.4をインストールする際は以下の通り実施する

    nvm install v8.9.4

    aliasを切り替える

    # nvm alias default v8.9.4
    default -> v8.9.4
    

    version変更を確認

    # node -v
    v8.9.4
    

     

  • mysql 5.7で実行された全クエリをログに出力する

    mysql 5.7で実行された全クエリをログに出力する

    はじめに

    どのようなクエリが実施されたのかトレースする時に使う

    設定

    /etc/my.cnfの設定変更

    general_log=ON
    general_log_file=/var/log/mysqld-query.log

    general_logの記載を追加する

    パーミッション設定

    touch /var/log/mysqld-query.log
    chown mysql:mysql /var/log/mysqld-query.log
    chmod 640 /var/log/mysqld-query.log

    上記設定を入れたら再起動する

    systemctl restart mysqld

    確認

    cat /var/log/mysqld-query.log
    
    2019-03-14T05:39:18.710354Z	    3 Query	INSERT INTO s_bookmark (  id, bookmark_at, 

     

     

  • wordpressのDBをRDSに移行する

    wordpressのDBをRDSに移行する

    はじめに

    wordpressは1台のマシンにmysqlも、wordpress自体もinstallすることはよくあると思う。

    その状態からmysqlをRDSに移行する。

    multi-AZを使うことができるので、DBの可能性が向上するというメリットがある。

    前準備

    mysqlをdumpする

    mysqldump -uroot -p sample_wpdb > sample_wpdb.sql

    移行

    RDSを作成する。

    userを作成する

    RDSを作った際のroot権限を持ったIDでも可能だが、セキュリティを考慮し、1 wordpressあたり、1 user作成すると良いと思う。

    ユーザ作成

    sampleuserを作るとする

    パスワードはpassword123

    database名はsample_wpdb

    SELECT PASSWORD('password123');
    
    GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,ALTER,INDEX,DROP,LOCK TABLES
    ON sample_wpdb.*
    TO 'sampleuser'@'%' IDENTIFIED BY PASSWORD '*xxxxxxxxxxx';

     

    dumpファイルを読み込む

    mysql -uroot -ppassword123 -hsample.ap-northeast-1.rds.amazonaws.com  sample_wpdb < sample_wpdb.sql

    wordpressの設定ファイルでDBの設定を変更

    wp-config.php

    /** WordPress のためのデータベース名 */
    define('DB_NAME', 'sample_wpdb');
    
    /** MySQL データベースのユーザー名 */
    define('DB_USER', 'sampleuser');
    
    /** MySQL データベースのパスワード */
    define('DB_PASSWORD', 'password123');

     

    以上。

     

     

     

     

  • BigQueryのtimestampをUTCから日本時間JSTへ変更する

    BigQueryのtimestampをUTCから日本時間JSTへ変更する

    はじめに

    BigQueryのtimestampの戻り値はデフォルトでUTCである。

    クエリを修正することでJSTを表示できる。

    クエリ

    #standardSQL
    
    select
    created_at as UTC,
    FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', created_at, 'Asia/Tokyo') AS JST
    
    from `BQ.sample`

    結果

    参考情報

    ビッギデータ解析について分かりやすくまとまっているのでおすすめ。

  • EC2(Amazon Linux 2)のディスクサイズをオンラインで拡張する

    EC2(Amazon Linux 2)のディスクサイズをオンラインで拡張する

    作業前

    ディスクサイズを確認する

    $ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/xvda1       20G   20G  291M  99% /

    Elastic block storeで割り当てDISKを増やす

    何ギガに増やしたいのかサイズを指定する

    (増やす容量ではなく、現在のDISKと併せてトータルの容量にする)

    ブロックデバイスの変更作業

    ブロックデバイスの一覧を表示する

    $ lsblk
    NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    xvda    202:0    0  40G  0 disk 
    └─xvda1 202:1    0  20G  0 part /

    ブロックデバイスを拡張する

    (ここの手順がAmazon Linux1と2で異なる)

    以下の手順はAmazon Linux2。

    $ sudo growpart /dev/xvda 1
    CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=41938910,end=41943006 new: size=83881950,end=83886046

    ブロックデバイス一覧を表示する。

    変更された事を確認する。

    $ lsblk
    NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    xvda    202:0    0  40G  0 disk 
    └─xvda1 202:1    0  40G  0 part /

    パーティションを拡張する

    $ sudo xfs_growfs /dev/xvda1
    meta-data=/dev/xvda1             isize=512    agcount=11, agsize=524159 blks
             =                       sectsz=512   attr=2, projid32bit=1
             =                       crc=1        finobt=0 spinodes=0
    data     =                       bsize=4096   blocks=5242363, imaxpct=25
             =                       sunit=0      swidth=0 blks
    naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
    log      =internal               bsize=4096   blocks=2560, version=2
             =                       sectsz=512   sunit=0 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0
    data blocks changed from 5242363 to 10485243

    パーティションが拡張された事を確認する

    $ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/xvda1       40G   20G   21G  50% /

    参考情報

    https://dev.classmethod.jp/cloud/aws/expand-ebs-in-online/