nokoのブログ

こちらは暫定のメモ置き場ですので悪しからず

nginx設定項目メモ

nginx設定項目メモ(一部)

  • プロセス起動ユーザ
    • user
  • デーモン化
    • daemon
    • foregroundかbackfroundか。デフォルトはon。(backfround)
  • ワーカープロセス数
    • worker process
    • マスタープロセスは1つのみですが、ワーカプロセスは
    • ワーカプロセス数をCPUのコア数で自動決定出来る機能もあり
  • pidファイル
    • pid
  • 最大同時接続数
    • worker connections
    • workerプロセスによって開くことができる同時接続の最大数を設定する
  • リクエストの同時受け付け
    • multi accept
  • エラー時のバージョン情報非表示
    • server tokens
  • HTTPキープアライブタイムアウト
    • keepalive timeout
    • HTTP通信をタイムアウトせずに待つ秒数
    • デフォルトの設定では、「keepalive_timeout」は75秒
  • ログフォーマット(X-FORWARDED-FOR)
    • http_x_forwarded_for
    • 接続元IP(X-Forwarded-For)を設定
    • X-Forwarded-For: HTTPヘッダの一つ。ロードバランサやプロキシを経由する時に送信元を判別するために利用
    • remote_addr: 直前のIPを持ってしまっている
  • ヘルスチェックのログ抑制
    • healthcheck
  • listen設定
    • listen
    • listenディレクティブにはバーチャルサーバがリクエストを受け付けるIPアドレスやポート番号あるいはUNIXドメイン ソケットを設定します。
  • ルートアクセス設定
    • location /
    • locationディレクティブではURIのパス毎の設定を記述できます

参考

qiita.com

qiita.com

tcpdumpコマンド

オプション(一部)

-i : インターフェイス指定。tcpdump -Dで一覧確認する

-n : IPアドレスをホスト名に変換させないで表示させる

-nn : プロトコル名をポート番号で表示させる

-A: 通信内容をASCIIで表示させる

-w tcpdump.pcap: パケットキャプチャをファイルで出力する

-W1 -G60 : 60sローテ+ローテ1回のみで終了

コマンド例

$ tcpdump -D
$ tcpdump -i 1 -n -nn -A -w tcpdump.pcap -W1 -G120 &
# -> wiresharkで確認、など。(csvファイル出力なども可能)

Kaggleスニペット

テーブル

  • pandas csv読み込み
import pandas as pd
df = pd.read_csv(INPUT_DATA_PATH_DIR + 'train.csv')
df.columns
import pandas_profiling as pdp
pdp.ProfileReport(df)
df_gb_label_group = pd.DataFrame({"count": df.groupby("label_group").size()})
  • pandas 検索
posting_id = "AAABBBCCC"
image = df.query('posting_id == @posting_id')['image'].iloc[-1]
  • pandas for文
for index, raw in df.iterrows():
    sentence = raw["title"]
    print(sentence)
  • ベクトル探索 faiss
# faissインデックス作成
dimension = len(feature_texts[0])
nlist = min(100, len(feature_texts))
quantiser = faiss.IndexFlatL2(dimension) 
faiss_index = faiss.IndexIVFFlat(quantiser, dimension, nlist, faiss.METRIC_L2)

# faissインデックスの学習・追加
faiss_index.train(feature_texts)
faiss_index.add(feature_texts)

# 近傍探索
faiss_index.nprobe = 10

s = time.time()
distance_similar_texts, idx_similar_texts = faiss_index.search(feature_texts, 3)
e = time.time()
print("search time: {}".format(e-s))
  • グラフ

テキスト

# from cuml.feature_extraction.text import TfidfVectorizer
from sklearn.feature_extraction.text import TfidfVectorizer
model = TfidfVectorizer(stop_words = 'english', binary = True, max_features = FEATURE_TEXTS_DIM)
feature_texts = model.fit_transform(df['title']).toarray()
  • BERT
    • shopee

画像

  • resnet

    • shopee
  • OCR tesseract

import pytesseract
# バッチ実行
result = pytesseract.image_to_string('./image_path.csv', lang="eng", config='--psm 3')
  • 画像表示
import numpy as np
from matplotlib.pyplot import imshow
import matplotlib.pyplot as plt
%matplotlib inline

#画像の読み込み
im = Image.open(INPUT_DATA_PATH_DIR + "train_images/" + image, 'r')
#画像をarrayに変換
im_list = np.asarray(im)
#貼り付け
plt.imshow(im_list)
#表示
print(image)
plt.show()

その他

  • chunk
  • cudf
  • cuml
from cuml import PCA
from cuml.neighbors import NearestNeighbors

データエンジニアリング実践

はじめに

  • データエンジニアリングまわりを復習したときのメモです。
  • Webアプリから発生するデータを使ってモデルを継続的に学習させるためのデータ基盤を想定しています。

データエンジニアリング導入以前ver

概要

  • CSVファイル
    • PoC時点などのシンプルな実装だと、サーバ腹持ちCSVファイルのみでデータを管理する、ということもあると思います
  • リレーショナルデータベース(RDB
    • 同時実行制御・耐障害性
    • 一貫性・拡張性・信頼性・速度

関連技術要素

課題

  • Webアプリケーションデータベースとは疎にしたい(分ければ良いが)
  • 性能が出ない
    • 統合データ環境として作られていると、分析用途のクエリは性能が出にくい(アドホックな分析を想定して設計されていない)
  • インフラコストが高い
    • 利用するデータを格納する→事前に必要になりそうなデータをとにかく集めておく

データウェアハウス導入ver

概要

  • データウェアハウス
    • ELTがメイン
    • SQL/非構造化データを扱わないなら
    • 集約することで、データのサイロ化を防ぐ(Dx条件の一つ)
    • 設計のポイント
      • データ保存量の拡張手段(制約がないか)
      • データの取り出し手段

関連技術要素

  • 【DWH】BigQuery(GCP
    • コスト
      • マルチテナント方式であるため、事前のプロビジョニングのコストが発生しない
        • コンピュートまたはストレージのどちらか大きいほうのピークに合わせてサイジング調整する必要などがない
      • クエリでスキャンした容量に対して課金
        • カラム指向ストレージなので、LIMITは意味なし
        • デフォルトで作られるキャッシュテーブル(24h)は、スキャン料金の対象にならない
    • データ取り込み
      • バルクロード: BigQuery Data Transfer Service, など
      • ストリーミング挿入: Fluentd, Dataflowのコネクタ, StriimなどのCDCソリューション(MySQLなどと同期)
      • フェデレーション: 外部テーブルを指定
    • データマート用途での利用
      • クエリキャッシュ、データマートテーブル作成、ビュー、マテリアライズドビュー
      • INSERTはいいが変更DMLは苦手なので、中間テーブルを次々にCTASで作成するのが良い(テーブル有効期限も合わせて設定)
      • データマートも兼ねたり。中間データの作成など。
    • 1レコード500バイトと仮定すると、1千万レコードで5GBで、それくらいならRDBをデータマートにしても良い?
    • cdc

課題

  • 非構造化データを扱うことが増えてきている
    • 顧客接点のデジタル化
    • 「2025年までに、全世界のデータのうち80%が非構造化データを占めるようになる」

データレイク導入ver

構成イメージ

スクリーンショット 2021-03-14 11.56.15.png

概要

  • データレイク
    • 未加工のデータを収集して蓄積するための場所
    • 「データを中心としたアーキテクチャとなっており、データのサイロが最小化され、スケーラブルな分散環境でデータの処理が互いに干渉し合うことなく実行される場所」
  • データマート
  • ストリーミング処理
  • ETL
    • 1ファイルあたり128MB-512MBが良い
    • パーティション含めたデータの持ち方の設計が大事
  • ワークフロー管理
    • 処理の依存関係を制御、処理のタイミングを適切にコントロールする
  • メタデータ管理
    • データリネージ
      • あるデータがどのデータからどういう過程を経て作られたか

関連技術要素

  • 【データレイク】S3
    • オブジェクトストレージに格納するデータは、1MB~1GBくらいが良い
  • 【ストリーミング処理】Fluentd
  • 【ストリーミング処理】Kafka
  • 【ストリーミング処理】Pub/Sub(GCP
    • データ量の急なバーストに耐え得るスケーラビリティ
  • 【ストリーミング処理】Dataflow
    • Apache Beam
    • リアルタイムに整形・集計などのデータ処理をするパイプラインを構築する
    • 外部サービスとのI/Oコネクタが標準で提供されている
    • Pub/Subで収集→Dataflowで処理→BQで蓄積、など
    • S3に書き出すこともできる
    • DataflowSQLもある
    • ノートブックもある
    • SpotifyはリアルタイムレコメンドにApacheBeamを利用
  • 【ストリーミング処理】Kinesis Data Firehose
  • 【ETL】DataProc(GCP
    • マネージドHadoop/Spark
    • ファイルパスの接頭辞をhdfs://からgs://へ変更するだけでGCSにアクセスすることができる
    • 90sで起動
    • メモリを追加してPresto, GPUを追加してSparkで機械学習もできる
    • DataProcHubでJupyterNotebookも利用可能
    • DataProcでGCS上にHiveパーティションデータを作る→それをBQで直接触る、などもできる
    • BQのストレージをDataProcから直接触ることもできる(BigQueryStorageAPIの利用)
  • 【ETL】Glue(AWS
    • DataCatalogとETLという2つのコンポーネントから構成されるサービス
    • 「S3のデータファイルから、AWS Redshift Spectrum と AWS Athenaのテーブルを作成する」ツール
      • Glueでデータカタログと呼んでいるテーブル定義は、Apache Hive のTableのことで、 Glueは、S3のファイルから、Hive Tableを作るツール
    • Glueはクローリングによるテーブル定義作成・更新に加えて、Apache Sparkを使って、プログラミングにより、ユーザーがより細かくデータ加工することもできます。
    • AWS GlueのジョブにはSparkとPython Shellの2つのジョブタイプがあります。
    • データの圧縮やParquet変換
    • マスキングやパーティション
  • 【ETL】Athena(AWS
    • Presto
      • Hiveと違って、速い分、エラーが起きると最初からやり直す(Hiveは大規模なバッチ処理を着実に実行することに長けたクエリエンジン)
        • データの構造化は、HiveやSparkで実行する
    • S3以外もデータソースにできる
    • 読み込むサイズで料金が変わる→gzipするだけでも安くなる
  • 【ワークフロー管理】CloudComposer
    • Airflowに必要なコンポーネントが自動で起動する
      • GKE
      • GCS
      • CloudLogging
      • CloudMonitoring
      • CloudSQL(バックエンドDB)
  • メタデータ管理】DataCatalog(GCP
    • GCSのデータやBQのデータを横断的に検索・管理することができる

その他メモ

参考

Kaggleコンペ開始直後にやっていること

はじめに

  • はじめてKaggleのコンペに参加してみたので、初動でやったことの大まかな流れを備忘までに残しておきます。

やったこと

0. 前提

  • Kaggleアカウントは作成しておくこと

1. コンペ参加登録

  • Kaggleページ→compete→sample_compete(対象コンペ)→Join Competition

2. GitHubリポジトリ作成

3. Issue(初期)作成

  • フォーマット
    • タイトル
    • 完了要件
    • 実施内容
  • Issueタイトル
      1. 環境構築
      1. サンプル公開ノートブック確認
      2. Input/Outputデータ確認
      3. 処理フロー確認
      1. EDA
      1. サーベイ
      1. 実験計画立て・実験管理シート作成
  • (補足)ノートブックコンペの場合は、スプレッドシート作成(「Issue」シート)

4. 環境構築

  • (補足)ノートブックコンペの場合は対応不要

4-1. Docker環境構築

4-2. Kaggle API認証設定

  • kaggleのpipパッケージインストール
    • → requirements.txtに kaggle を追記してコンテナを再作成する
    • (暫定) pip install kaggle
  • kaggle認証
    • 事前にkeyを確認しておく
    • ホスト側でexportしておく
    • → コンテナ起動時にそれを引き継ぐようにrun.shを修正する
# ホスト側で実行(bashrcなどに設定しておく)
$ export KAGGLE_USERNAME=kaggle_username
$ export KAGGLE_KEY=xxxxxxxxxxxxxx
...
-e KAGGLE_USERNAME=${KAGGLE_USERNAME} \
-e KAGGLE_KEY=${KAGGLE_KEY} \
...
  • Kaggle API 動作確認
$ kaggle competitions list

4-3. Readme作成

  • README作成
    • 概要
      • コンペのリンク+α
    • 環境構築手順
      • 上記の環境構築手順(KaggleAPI用環境変数設定、コンテナ起動)
    • スクリプト実行手順
    • Input/Outputデータサマリ
    • 実験結果サマリ
  • → git pull requestまで

5. サンプル公開ノートブック確認

  • Input/Outputデータを確認する
    • Readmeに追記する
      • Input/Outputデータ
        • データ種
        • データ量
        • カラム
  • 処理フローを確認する
    • 前処理→学習→推論
    • スクリプト(ノートブック)・関数の切り方

6. EDA

  • このタイミングで、Inputデータ取得・読み込み周りを実装する
  • 手法
    • pandas profiling など
    • head(), info(), shape, unique, display image, wordcloud, basic nlp -> count, distributed

7. サーベイ

  • 公開ノートブック・関連論文を調査する
    • 処理フローの枠+IFを固める(関数をつないでいく)
    • 試し得る手法の洗い出し、優先順位付けをする

8. 実験計画立て・実験管理シート作成

  • EDAサーベイの結果を元に、実験計画を立てる
  • 予実管理用の実験管理シートを作成する
    • No, タイトル, 関連IssueNo, スクリプト, 変更元, 変更内容, 補足, 結果

9. 個別Issue起票・対応

  • 実験計画に従い、Issueを起票し、合わせてブランチを作成して実験していく
  • ブランチ切り替え(別Issueに取り組む度に実施する)
# mainブランチを最新にする
$ git checkout main
$ git status
$ git pull origin main
# → 上記同様、新たなブランチを作成する

10. ベースライン作成

  • データ
    • train / trainの一部 / test に対応
  • コード
    • 拡張性
      • 関数化
      • 関数ごとにON/OFFの切り替え、アンサンブル
      • 関数ごとに処理時間を計測(呼び出し側)
    • パラメータチューニング
    • 評価関数
      • 定量
      • 定性
        • スコアも並べて表示
      • -> 混同行列など。課題を、スコアへの影響度(予想)順に整理しておく
      • submissionファイル間の差分表示
    • CV
    • ノートブックの章分け
1. Requirements
2. Conf
3. Utils
4. Models
5. Submit
6. Evaluate

11. サブ環境構築

  • ノートブックコンペの場合は、GPU使用時間制約の問題があるので、サブの環境を構築しておく
  • 要件
    • ディレクトリ構成を揃えることができる
    • ライブラリを揃えることができる
    • データセットを落としてこれる
    • ノートブックを同期できる

バックアップリストア改廃を復習してみた

はじめに

  • バックアップリストア改廃を復習してみたときのメモです
  • 5W1Hを意識して漏れなく設計します

一覧

  • 取得元
  • バックアップ
    • 方式
    • トリガ
    • タイミング
  • リストア
    • 方式
  • 改廃(取得元)
    • 方式
    • トリガ
    • ローカル保存世代数
  • 改廃(バックアップ先)
    • 方式
    • トリガ
    • タイミング
    • ローカル保存世代数

データエンジニアリングを復習してみた

概要

スクリーンショット 2021-03-14 11.56.15.png

選定ポイント

  • MPPデータベースは、最初にETLプロセスなどでデータを取り込むための手順が必要
    • 元のデータがCSVJSONで、複雑な加工処理が不要なら、オブジェクトストレージからデータウェアハウスに直接転送してSQLで加工、でも良い
    • BIツールとMPPデータの組み合わせは実績があるので、可視化のためのデータマートとして使える
  • Hiveは大規模なバッチ処理を着実に実行することに長けたクエリエンジン
  • PrestoはHiveとは逆で、速い分、エラーが起きると最初からやり直す
    • データの構造化は、HiveやSpark
  • 1レコード500バイトと仮定すると、1千万レコードで5GBで、それくらいならRDBをデータマートにするのが良い

補足

  • ポイントは
    • データ保存量の拡張手段(制約がないか)
    • データの取り出し手段
  • 分散ストレージとしてNoSQLを使うときもある
  • オブジェクトストレージに格納するデータは、1MB~1GBくらいが良い
  • データフローは、分散ストレージに格納した後から
    • オブジェクトストレージなどからデータ読み込んで、構造化されたテーブルを作成する
    • ETLプロセスの一種
  • Glue
    • 「S3のデータファイルから、AWS Redshift Spectrum と AWS Athenaのテーブルを作成する」ツール
      • 実質、AWS GlueはAWS EMRで作られていて、テーブル定義はAWS EMRのHive Tableでも作ることができます。
    • Glueでデータカタログと呼んでいるテーブル定義は、Apache Hive のTableのことで、 Glueは、S3のファイルから、Hive Tableを作るツール
    • Glueはクローリングによるテーブル定義作成・更新に加えて、Apache Sparkを使って、プログラミングにより、ユーザーがより細かくデータ加工することもできます。
    • AWS GlueのジョブにはSparkとPython Shellの2つのジョブタイプがあります。
      • Sparkジョブではutf-8形式のデータのみにしか対応していない
  • Athena
    • Athena は初期状態で AWS Glueデータカタログと統合されており、さまざまなサービスにわたるメタデータの統合リポジトリを作成できます。データソースのクロールとスキーマの解析、新規および修正したテーブル定義とパーティション定義のカタログへの入力、スキーマのバージョニング保持が可能です。
  • データマートは集約と可視化の間に挟む
  • Hive metastoreは内部でPostgresを使ったりする

参考