Snowflakeのワーカーノードがアップグレードされていた!
Snowflakeのワーカーノードのスペック調べてみた。
ローカルディスク容量が倍に、CPUアーキテクチャがx86_64からaarch64になってた。
いつのまにかスペックが上がってました。
現在のワーカーノードのスペック
2024年1月現在は、以下のようなマシンでクエリが実行される。
パラメータ | 値 |
---|---|
インスタンスタイプ | C6g.2xlarge |
プラットフォーム | Elastic Kubernetes Service |
オペレーティングシステム | Amazon Linux 2(Linux Kernel 5.4.181) |
CPU コア | 8コア/ノード |
CPU アーキテクチャ | aarch64(arm64) |
ディスク容量 | 400GB(392156184576 bytes)/ノード |
裏付けを取るため調べて知ったが、昨年5月の決算で「Graviton2に移行済み」とCFOが発言した記録があった。
We've fully migrated all of our customers in AWS to Graviton 2. [1]
もしかしたら、現在はGraviton3を使っているかもしれない。
それ以前のワーカーノードのスペック
SELECT社によると、2022年11月時点では c5d.2xlargeが使われていたらしい[2]
AWSでは各ノードがc5d.2xlarge EC2インスタンスで、16GBのRAMと200GBのSSDを搭載していることはよく知られている。
この情報と比較すると、以下のように変化したようだ。
項目 | 2022年11月 | 2024年1月 |
---|---|---|
インスタンスタイプ | C5d.2xlarge | C6g.2xlarge |
OSバージョン | 不明 | Amazon Linux 2(Linux Kernel 5.4.181) |
コア数 | 8コア/ノード | 8コア/ノード |
アーキテクチャ | x86_64 | aarch64(arm64) |
ディスク容量 | 200GB/ノード | 400GB/ノード |
以下に詳細な検証手順を示す。
検証手順
1. Pythonで情報を集める
pythonのplatform
モジュールを使うと、ノードの情報を出力できる。
import platform system_info= { 'system': platform.system(), 'release': platform.release(), 'version': platform.version(), 'architecture': platform.architecture(), 'machine': platform.machine(), 'processor': platform.processor(), 'python_version': platform.python_version(), 'python_compiler': platform.python_compiler(), 'python_build': platform.python_build(), 'os_version': platform.uname(), 'disk_usage': shutil.disk_usage("/"), 'environment_variables': dict(os.environ), }
実行結果を示す。
{ "system": "Linux", "release": "5.4.181-99.354.amzn2.aarch64", "version": "#1 SMP Wed Mar 2 18:50:47 UTC 2022", "architecture": [ "64bit", "" ], "machine": "aarch64", "processor": "", "python_version": "3.11.5", "python_compiler": "GCC 11.2.0", "python_build": [ "main", "Sep 11 2023 13:15:12" ], "os_version": [ "Linux", "PYTHON-UDF", "5.4.181-99.354.amzn2.aarch64", "#1 SMP Wed Mar 2 18:50:47 UTC 2022", "aarch64", "" ], "disk_usage":[ 392156184576, 6392868864, 385763315712 ], "environment_variables":{ "USER":"udf", "LOGNAME":"udf", "HOME":"/home/udf", "TZ":"America/Los_Angeles", "OMP_NUM_THREADS":"1", "OPENBLAS_NUM_THREADS":"1", "MKL_NUM_THREADS":"1", "BLIS_NUM_THREADS":"1", "VECLIB_MAXIMUM_THREADS":"1", "NUMBA_NUM_THREADS":"1", "NUMEXPR_NUM_THREADS":"1", "CONDA_PREFIX":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx", "PROJ_LIB":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx/share/proj", "GDAL_DATA":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx/share/gdal", "GDAL_DRIVER_PATH":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx/lib/gdalplugins", "GEOTIFF_CSV":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx/share/epsg_csv" }, }
Pythonランタイムはconda。デフォルトのタイムゾーンはロサンゼルスなのか。プロセッサ名は隠されてそう。環境変数を見ると、ワーカーノードごとに処理がシングルスレッドに制限されていた。
2. /procから調査する
プロセッサ名が知りたいので/proc
を調査した。
Linuxでは/proc
フォルダ以下を見ることで、システムの情報を収集することができる。
CPUの情報が格納されているのは/proc/cpuinfo
だが、読み取り権限がなかった。
せっかくなので、読み取り権限のあった以下のファイルについて見る。
- /proc/self/exe
- /proc/self/stat
- /proc/self/maps
/proc/self/exe
はUDFのプロセス名を示す。これは/bin/python_udf_server_3.11
であった。
/proc/self/maps
はメモリのマップファイル。
長いので今回はスキップ。読み込まれたPythonの標準ライブラリなどが見れて面白い。
/proc/self/stat
はプロセス自身の状態を示す。
これは以下のようなテキストになっている。
/proc/self/stat 4858 (python_udf_serv) S 4857 4858 4788 0 -1 4194560 5530 601 0 0 9 1 0 0 25 5 2 0 9957 57290752 6351 18446744073709551615 2097152 16947760 281473996413216 0 0 0 0 17305601 17640 0 0 0 17 7 0 0 0 0 0 17475264 17517840 318431232 281473996417949 281473996423137 281473996423137 281473996423137 0
興味深いのはCPUの番号だった。
17 7 0
の7の部分は0から始まるプロセスの実行CPUの番号を示す。
UDFを複数回実行したが必ず0~7
のどれかだった。このことから8コアのCPUだと推測できる。
感想
ローカルディスク2倍増し無料、助かる。
古い情報ではx86_64
と書いてある事が多いので、SPCSでハマらないようにしよう。
おすすめの記事
UDFでユーザー管理のキャッシュ領域がほしい
/tmpと/dev/shmが使えた。Snowpark Optimized Warehouseに新たなユースケースを見出したかもしれない。
GA4もSnowflakeで分析する時代がついに来たぞ!
2024年1月29日、GA4とSnowflakeの公式コネクタがリリースされました。従来のソリューションと比較してGA4コネクタの何が素晴らしいのかを解説し、試用の際の注意点を記載しました。
SnowflakeでAWS S3 Express One Zoneを使うとどれだけ速いのか
SnowflakeにS3 Express One Zoneで外部ステージを作成してみました。読み取りワークロードでは、最大16%ほどクエリが高速化していました。
SELECT LENGTH('🙆♀️')= 4 ←???
SnowflakeのLENGTH関数は一部の絵文字や外国語(書記素クラスタ)を正しくカウントできない。正しくカウントするPythonUDFを掲載した。