(-> % read write unlearn)

All opinions expressed are solely my own and do not express the views or opinions of my employer.

phpbrew install 7.3.12 on MacOS

phpbrew で Mac に PHP7.3 をインストールしたかっただけ。

phpbrew install 7.3.12したら以下エラーが出た。

configure: error: OpenSSL version 1.0.1 or greater required.

どうも brew で入れた新しい openssl を参照してくれないらしいので、参照させるように +openssl=$(brew --prefix openssl) を足してやる。そうして phpbrew install 7.3.12 +openssl=$(brew --prefix openssl) としたら以下エラーが出た。

ld: file not found: /usr/lib/system/libsystem_darwin.dylib for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make: *** [ext/opcache/opcache.la] Error 1

これも ld をちゃんと参照してくれるように環境変数でフラグをするように LDFLAGS="-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/system" を足してやる。

最終的にこれでビルドできた。

LDFLAGS="-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/system" phpbrew install 7.3.12 +openssl=$(brew --prefix openssl)

phpbrew はビルドに成功するとプロンプトに Enjoy! って出てくるよ。

これで OK かと思ったら composer require bref/bref したときにこける

$ phpbrew use 7.3.12

$ composer require bref/bref
PHP Fatal error:  Uncaught Error: Call to undefined function Composer\Json\json_decode() in phar:///usr/local/Cellar/composer/1.9.1/bin/composer/src/Composer/Json/JsonFile.php:156
Stack trace:
(省略)

どうも json と ctype の extension をインストールし忘れているらしい。

$ phpbrew list
# WARNING: ctype extension might be required for parsing yaml file.
* php-7.3.12
  php-7.2.25

追加でインストールするために phpbrew ext install json ctype したら Warningは出なくなった。けど composer require bref/bref は相変わらずこける。

$ composer require bref/bref
PHP Fatal error:  Uncaught Error: Call to undefined function JsonSchema\Uri\filter_var() in phar:///usr/local/Cellar/composer/1.9.1/bin/composer/vendor/justinrainbow/json-schema/src/JsonSchema/Uri/UriResolver.php:82
Stack trace:
(省略)

ひたすら、モジュールを追加していく・・・。最終的にこれだけ入っていれば composer require bref/bref は通った。

phpbrew ext install json ctype filter hash curl

たぶん、最初に 7.3.12 をインストールするときにまとめて指定するオプションあるんだろうけど。最終的に以下のような状態。もっと入れといたほうが良い気がするけど、とりあえず事足りた。

$ phpbrew ext
Loaded extensions:
 [*] ctype        7.3.12
 [*] curl         7.3.12
 [*] date         7.3.12
 [*] dom          20031129
 [*] filter       7.3.12
 [*] hash         7.3.12
 [*] json         1.7.0
 [*] libxml       7.3.12
 [*] openssl      7.3.12
 [*] pcre         7.3.12
 [*] phar         7.3.12
 [*] reflection   7.3.12
 [*] session      7.3.12
 [*] simplexml    7.3.12
 [*] spl          7.3.12
 [*] standard     7.3.12
 [*] tokenizer    7.3.12
 [*] xml          7.3.12
 [*] xmlreader    7.3.12
 [*] xmlwriter    7.3.12
 [*] xsl          7.3.12
 [*] zlib         7.3.12
Available local extensions:
 [ ] bcmath
 [ ] bz2
 [ ] calendar
 [ ] dba
 [ ] enchant
 [ ] exif
 [ ] fileinfo
 [ ] ftp
 [ ] gd
 [ ] gettext
 [ ] gmp
 [ ] iconv
 [ ] imap
 [ ] interbase
 [ ] intl
 [ ] ldap
 [ ] mbstring
 [ ] mysqli
 [ ] mysqlnd
 [ ] oci8
 [ ] odbc
 [ ] opcache
 [ ] pcntl
 [ ] pdo
 [ ] pdo_dblib
 [ ] pdo_firebird
 [ ] pdo_mysql
 [ ] pdo_oci
 [ ] pdo_odbc
 [ ] pdo_pgsql
 [ ] pdo_sqlite
 [ ] pgsql
 [ ] posix
 [ ] pspell
 [ ] readline
 [ ] recode
 [ ] shmop
 [ ] snmp
 [ ] soap
 [ ] sockets
 [ ] sodium
 [ ] sqlite3
 [ ] sysvmsg
 [ ] sysvsem
 [ ] sysvshm
 [ ] tidy
 [ ] wddx
 [ ] xmlrpc
 [ ] zend_test
 [ ] zip

ストリーム分析の手法の分類

バッチ処理による分析では、通常分析対象のデータが出揃っていて目的の範囲で容易に取り出すことができる。 例えば、12/2に行うバッチ処理で「11月いっぱいの全取引データを分析する」とか。 しかし、ストリームを扱った分析では、データの対象範囲をどう決めるかがもっと重要になってくる。 流れてくるデータを次々にじゃんじゃか処理しないといけないので、対象範囲の切り方がうまくないと当然パフォーマンスに影響が出てしまう。

ストリームを対象とした分析において、ストリームをどのようなタイミングで分析するか、どのような範囲で区切って分析するかにはいくつかの分類があるようです。 以下を参照した自分なりの理解を書いてみます。

innu.hateblo.jp

github.com

ストリーム分析の手法について HopSizeWindowSize という2つのパラメータで考える。

  1. HopSize: ストリーム(対象データ)を、どのような時間間隔で分析するか。
  2. WindowSize: ストリーム(対象データ)を、どのような範囲に区切って分析するか。

例えばHopSizeが1秒でWindowSizeが5秒なら、「1秒間隔で直近5秒のイベントを対象に分析をする」という感じ。 そして、この2つのパラメータによって、分析手法をいくつかに分類している。

1. Hopping Window 分析

HopSize が定数で、かつ HopSize < WindowSizeの分析。

上記の「1秒間隔で直近5秒のイベントを対象に分析をする」というのはまさにこれ。 この場合に、分析の度に対象となるデータ範囲が重複することがある。 正確には WindowSize - HopSize の時間範囲のデータが前後の分析で重複した対象範囲となる。

例えば

  1. 14:00:10 に 14:00:05 以降 14:00:10 未満 のデータを分析し、
  2. 14:00:11 に 14:00:06 以降 14:00:11 未満 のデータを分析し、
  3. 14:00:12 に 14:00:07 以降 14:00:12 未満 のデータを分析し、
  4. ・・・

という流れ。 この場合に、1番目の分析処理と2番めの分析処理を比べると、 14:00:06 〜 14:00:10 の4秒間のデータが重複している。

2. Tumbling Window 分析

HopSize が定数で、かつ HopSize = WindowSizeの分析。

HopSize と WindowSize が同じ値の場合、分析の度に対象となるデータの範囲に重複が無く排他的となる。 この場合は、とくに Tumbling Window という呼ぶ。

3. Sliding Window 分析

HopSize を事前に決定することはせず(できず)、イベントが発生する度にWindowSizeの範囲を対象に分析を行う。 HopSizeはイベント発生によって(事後的に)決定されるイメージ。

Sliding Window は、分析処理の起動を分析側で制御できない(しない)ので、負荷などに対してかなり考慮が必要そう。

オブジェクトストレージ と ファイルストレージ と ブロックストレージ

ストレージの話をする際、この3つをはっきりと比較して考えたことがありませんでした。 それぞれの意味や用途は分かっているのだけど。

ファイル・ストレージは、データを階層構造で保持しており、ファイル自体にはメタデータは含まれません*1。 階層構造自体が一種のメタデータの役割を果たしているとも言えます。 例えば、/home/hata/tmp/nginx/access.logというファイルであれば、このファイルはhataユーザの持ち物でNginxのアクセスログを一時的に置いているのかな、というのが分かります。 このファイルを/直下に移動してしまえば、上記のような情報(メタデータ)はなくなります。 代表的なファイル・ストレージとしてはNASです。

オブジェクト・ストレージは、ファイルを階層構造で格納せずフラットに保持し、ファイル自体にメタデータを付属させます。 こうすることで、ファイルストレージのような構造(ディレクトリ)の区切れを意識することなくファイル単位で柔軟に分散、再配置ができます。 そのため、ブロックストレージは大容量ストレージの構築に向いています。 一方で、データ更新のレイテンシが高く更新の頻繁な用途には向きません*2 代表的なオブジェクト・ストレージといえば、やはりAWS の S3でしょう。

ブロック・ストレージは、ファイルをブロックというさらに細かい単位ににおいて管理します。 通常、1つのファイルは1つ以上のブロックにまたがります。 ファイル・ストレージはファイル・システムやファイル共有機能を経由してデータ転送されるため、ブロックストレージに比べるとレスポンスが遅い。

もちろん、ブロック・ストレージをOSがファイルシステムとしてフォーマットして使えば、そのOSを介してアクセスするユーザからはファイル・ストレージとしてアクセス可能になります。

itpro.nikkeibp.co.jp

この視点でAWSのサービスを眺めると、↓な感じでしょうか。

レスポンス 容量の拡張性
S3 (Simple Storage Service) オブジェクト・ストレージ
EFS (Elastic File System) ファイル・ストレージ
EBS (Elastic Block Store) ブロック・ストレージ

この記事の下のほうの比較表がとてもまとまってて分かりやすいです。

www.fujitsu.com


このブログの全ての意見は個人のものであり、所属する団体や企業とは一切関係がありません。
All opinions expressed are solely my own and do not express the views or opinions of my employer.

*1:ファイル作成日時や作成者などのごく簡単なメタデータは保持しています

*2:なんで、他と比べてレイテンシが高くなるんだろう?HTTPによるAPIアクセスだから?HTTPが使われているのは一般的な実装の話なだけであって、オブジェクトストレージ自体の定義とは関係ないような気もするけど。