BFScalping用、約定、OHLCV、板情報データー保存プログラム（bitFlyer）

こんにちは、はぐです。
2019年7月頃まで自作のフレームワークを使っていたのですが、BFScalping互換のバックテストを作ってからBFScalpingばっか使うようになってしまいました。

2020.08.20
今まで録り貯めたohlcvのsell_volとbuy_volの変換をするプログラムをアップしました。
ご迷惑をおかけしましてすみませんでした。
noteの一番最後に使い方を記載しております。

2020.08.14
Ohlcvの保存のさいに、buy_volumeとsell_volumeのヘッダー位置が逆だった。
とりあえず保存プログラムだけ修正しましたが、今まで録り貯めていたOhlcvファイルを変換するプログラムを後日書きます。
お手数ですが、もし手作業で行うのでしたらヘッダー（1行目）のbuy_vol、sell_volを入れ替えてもらっても同じです。
ご迷惑おかけいたしました。

2020.08.05
新しいgenerate_candle.pyに対応したpatch差分をノートの最後にアップ

2020.06.30
約定とOHLCVの保存ファイル名が、PCの時刻で決めていたので、データーの日付からファイル名を作成するようにした。
（今までは6/1のファイルでも、遅延のために5/31の23:59:59のデーターも6/1のファイルにはいってしまっていた）

くもすけさんの機械学習note付属のgenerate_candle.pyを、こちらで作成した約定履歴でも動くように改造したdiff差分を用意。（記事の一番最後）

2020.05.19
05.09の対応では不十分だったようで、別の箇所も修正してみました。
2日ほど回しましたが同じ足の保存はでていないです。

2020.05.09
同じ時間のohlcvが2個保存されているのを発見したので、それの対策をしました。
同じ時間の足が存在した場合、2個め以降は保存しない。
（ずっと1秒足で動かしっぱなしでしたが、初めてなりました。）

2020.01.12 追記
BFS-X付属の、backtest-scalpingmode.py に、このプログラムで保存した約定ファイルを読み込ませる場合、jst_epoc列が増えているので、backtest-scalpingmode.pyに下記の変更をお願いします。

・設定ファイルで、exec_header_write: False　(ヘッダー無し)の場合

# 115行目
    df = pd.read_csv('./'+filename, names=('exec_date', 'jst_epoc', 'side', 'price', 'size', 'id', 'latency') ) # CSVファイル読み込み

・設定ファイルで、exec_header_write: True　(ヘッダー付き)の場合

# 115行目
    df = pd.read_csv('./'+filename) # CSVファイル読み込み

2019.12.10
一度、websocketsの同じチャンネルが２つ受信して、ファイルが2倍になった時がありました。
その対策をしました。（ただそれ以来一度もない）
ただ、現在ベーター版のver2.11ではその修正を行ってあるそうです。
まだ一般公開されていないので、BFScalpingの正式版は2020年までお待ち下さい。
あと、今回のプログラムの動作に関係はないですが、ファイル保存する際の拡張子チェック(data_filesave_class.py)で、ドットが抜けていたので修正しました。

---------------------------------------------------------------------------------
もしかしたら、下記のvfs-workerの件、Cloud9の左側のツリーで保存フォルダをツリー展開すると、その監視でCPUを食うのかもしれません。
ツリーをおおもとで閉じて、Environmentを押してツリーが隠れるようにすればいいかもしれないです。
ツリーを開けばCPU使用率があがり、閉じれば下がるのを確認しました。
ただ、常時そうなのかはわかりません。
------------------------------------------------------------------------------------

バックテストをするには約定データーや、板のデーターが必要です。

そのためのデーター保存プログラムも自前のフレームワークで動かしていたのですが、今回BFScalpingに移植してみました。

3つの情報（約定、ローソク足、板）が保存できるので、1個500円として合計1500円のnoteとしました。

・--- 気をつけること ---

・くもすけさん作、BFScalpingをもっていないと動きません。
持っていない人は購入しないでください。

・ファイルサイズが大きい
約定履歴は同じIDのものが連続して来たときはまとめて合計を保存するようにして、ファイルサイズを小さくするようにしていますが、それでも一日１００～３００Mです。（約定数で変わってきます。）
また板情報は全ての価格を1秒間隔で保存すると1日１ギガです。
OHLCV情報は１秒足で８M程度です。
各情報は保存するかしないか設定yamlで選択できます。

・AWSではファイル保存を連続して行うと、vfs-workerなるプロセスがCPUを食いつぶす（コード内で暫定対策済み）
なぜかはわからないのですが、AWS上でファイル保存をしていくとvfs-workerというプロセスがCPUを食いつぶし、どんどん重くなっていき、websocketsの切断を繰り返すようになり、最終的にはインスタンスの再起動をしなければならなくなります。
これはBFScalpingだけではなく自前のフレームワークのファイル保存でもなりました。
しかもあるインスタンスではならない、こっちのインスタンスではなる、という状態でした。なるならない、も同じインスタンスでも再起動すると変化しました。
なのでメモリーリークを疑ったのですが、どうも違うようです。
自前のサーバー（CentOS7 + Cloud9）やローカルPCのWindows10に入れてみてもそんな現象にならないです。
どうやらAWSのバグ？のようです。（こんなこと書いて自分のバグだった場合・・・超恥ずかしい）
「vfs-worker {“pi」 で検索すると何件かヒットします。
これを機に自前Cloud9サーバーを立ち上げよう！
（そのうちnote書くかもしれません。）
仕方がないので、vfs-workerのCPU使用率がある値を超えたらプロセスをkillすることにしました。
vfs-workerは、Cloud9のIDEの接続をしているみたいで、殺してもすぐ再起動しますので（たぶん）問題ないです。
ただ、殺しても殺してもすぐまたCPUを使い始めるので、その場合はインスタンスの再起動をした方がいいです。
昨日、実際にあったことですが、何回も殺しても復活してCPUをいっぱい使うので、インスタンスの再起動を行ったところ、安定して書き込みを行え、すでに24時間以上経過しています。
参考URL
https://codeday.me/jp/qa/20190815/1453702.html
https://archegirl.net/ptips/aws-cloud9-vfs-worker/

・上記のこともあり、AWS Cloud9で運用するのでしたら、できれば新しいインスタンスを作成して、そこで運用してください。
もしかしたら新しく作るインスタンスではそのバグが治っているかもしれません？
Cloud9のセットアップシェルスクリプトも同梱しておきます。
必要なモジュール(TA-LIBも)のインストールと東京時間変更を行います。

・あと、ファイル保存クラスを作りました。別スレッドでキューに積まれたデーターを保存していきます。
1データー保存ごとにスレッド立ち上げたほうがいいのかなぁ、とも思ったのですが、OS側で遅延書き込みするだろうし1スレッドでいいか、と考えて1スレッドです。
参考になれば。

本プログラムで設定できる項目は以下になります。
ご購入の参考にしてください。

parameters:                       # 下記パラメータはself._strategy_config['xxx'] でアクセス

 data_folder: "data/"

 # ----- 約定情報 -----
 exec_save_enable: true        # trueだと約定情報を保存する
 exec_header_write: false      # trueだと、ファイル一行目に、どんなデーター列なのかのヘッダーを書き込む。
                               # BFScalpingのバックテストで使うのであればfalseにしておく。
 exec_id_sum_up: true          # trueだと約定の重複IDはまとめて保存。ファイルサイズ削減。
 view_exec_data: false         # デバッグ用に約定情報をコンソール表示(exec_save_enable: true　のときだけ)
                               # 表示は流れてきたパケットの１個めだけにしてあります。

 # ----- OHLCV（ローソク足）-----
 ohlcv_save_enable: true       # trueだと本ファイル30行目の設定、timescaleの足のOHLCVを保存する。
 ohlcv_header_write: true      # trueだと、ファイル一行目に、どんなデーター列なのかのヘッダーを書き込む。
 view_kakutei_ashi: true       # デバッグ用にローソク足をコンソール表示(ohlcv_save_enable: true　のときだけ)
 
 # ----- 板情報 -----
 board_save_enable: true       # trueだと板情報を保存する。falseだとしない。
 board_save_price_width: 0     # 板情報を、best値からの指定の金額まで保存する、０だと全部。
 board_save_interval_sec: 1    # 板情報の保存のインタバール時間[sec]

 # AWSのvfs-worker対策 CPU使用率が上がったらプロセスを殺す。AWS側でvfs-workerはすぐ再起動になるので無問題(だと思う。)
 # centOSやWindows等であればvfs-workerなるプロセスは存在しないので無問題。
 aws_vfs_worker_watch_interval_sec: 60   # vfs-workerのCPU使用率をこの秒間隔で監視
 aws_vfs_worker_cpu_percent_limit: 20    # vfs-workerのCPU使用率がこの%を超えたら殺す。0～100の値。

以下、有料部分にコードを置いておきます。