SnowflakeでVARCHARの最大サイズを指定せずにLookerに接続する際に注意すること #looker #SnowflakeDB

SnowflakeのVARCHAR型は、最大サイズを指定しないとデフォルトで最大長を指定します。

今回は、VARCHAR型の最大サイズを指定せずに、Lookerに接続した際に注意しなければならない点や、Lookerでの挙動を確認してみます。

SnowflakeでVARCHAR型を最大サイズを指定しない場合の挙動を確認する

下の画像のようにVARCHAR()のままでcreate tableを走らせます。

作成されたテーブルの詳細を確認すると、公式ドキュメントの通り、VARCHAR（16777216）で指定されています。

Looker側で考慮する点

Lookerではviewファイルでテーブルの行が一意になるキーとして、primary_keyを指定する必要があります。このプライマリーキーは単一のコラムである必要はなく、CONCATで連結した複数コラムで指定することも可能です。

ここで問題なのが、プライマリーキーを構成するコラムの合計が16MBを超える場合、CONCATが処理できずにエラーが出てしまう点です。

下の画像は、16777216+1+1=16777218で16MB超えでエラーが出ました。

以下では、16777214+1+1=16777216で16MBに収まっているため、無事に処理が走りました。

SnowflakeのVARCHAR(16777216)に対するLookerの挙動を確認する

公式ドキュメントに、以下の気になる記述があります。

一部の BI/ETL ツールは、ストレージまたはメモリ内の VARCHAR データの最大サイズを定義します。列の最大サイズがわかっている場合は、列を追加するときにサイズを制限できます。

Lookerはデータベースに対してSQLを発行して、返ってきた値を表示しているだけなので、Looker側で最大サイズを指定してしまうことはないだろうと思いつつ、確証はないので確認してみます。

確認方法は、先ほど作成したテーブルをLookerのExploreから呼び出して、その値をダウンロードしてその値にスペースが入っていないかで判断します。

まずは、Exploreで値を呼び出します。

LookMLはこのように定義しました。

view: test_varchar {
  sql_table_name: "HORIMOTO_TEST_DB"."PUBLIC"."TEST" ;;

  dimension: c1 {
    type: string
    sql: ${TABLE}."C1" ;;
  }
  dimension: c2 {
    type: string
    sql: ${TABLE}."C2" ;;
  }
  dimension: c1_plus_c2 {
    sql: concat(${c1},${c2}) ;;
  }
  dimension: length_c1 {
    type: number
    sql: length(${c1}) ;;
  }
  dimension: length_c2 {
    type: number
    sql: length(${c2}) ;;
  }
  dimension: length_c1_plus_c2 {
    type: number
    sql: length(${c1_plus_c2}) ;;
  }
}

長さも確認できるように、LENGTHで各値の長さを確認できるようにしました。

無事に値は表示されています。

そして...このExploreに表示されているデータをダウンロードしたのがこちら！

特にスペースは入れられていませんでした。

まとめ

SnowflakeのVARCHARの公式ドキュメントにある、

一部の BI/ETL ツールは、ストレージまたはメモリ内の VARCHAR データの最大サイズを定義します。列の最大サイズがわかっている場合は、列を追加するときにサイズを制限できます。

の一部のBIツールにLookerは含まれないことが確認できました。

しかし、プライマリーキーを複数のコラムを連結して指定する場合は、合計が16MBを超えてしまうとCONCAT関数が動かないので注意です。