hatunina’s blog

メモと日記です

「達人に学ぶDB設計徹底指南書」を読んだ

読みました。

www.shoeisha.co.jp

今後、データマートを作ることがありそうなので読みました(本当はDWHに関する本を探していたけれど良さそうなのが見つからなかった)。 真面目に仕事やってれば感覚的に知ってるよね、みたいなことが中心ですが、正規化の章でコラムとしてまとめている言葉がとてもよかったです。

常識を定式化することで誰もが利用可能なツールにすることができ、道を外れた設計を防ぐことができるようになります。


カラムに配列を持てるのとRDB木構造を扱う方法は初耳でした。 RDB木構造を扱うのは更新をあまり必要とせず検索中心であればアリなのかもしれない。 詳細は下記へ。

tech.core-j.co.jp

www.slideshare.net

絶対プロキシ突破するマン!(Win10, 認証あり, pip)

オラァ!!!!!

set HTTP_PROXY=http://user_name:passward@proxyserver:8080
set HTTPS_PROXY=http://user_name:passward@proxyserver:8080

pip --trusted-host files.pythonhosted.org --trusted-host pypi.org install hoge

user_nameにメールアドレス等が使われている場合、アットマークはhoge%40hoge.comのように%40を使うことでエスケープできます。
また、プロキシの設定だけではCERTIFICATE_VERIFY_FAILEDが発生することがあり--trusted-hostオプションをつけています。

参考

github.com

AWS Step FunctionsでTaskにParametersを設定してAWS Lambdaで読み込む

Parameters周りの話があまり見当たらなかったのでまとめました。

やりたいこと

AWS Step FunctionsとAWS LambdaでETLっぽいことをしたい!
初期パラメータはPassで渡し後ろのTaskでもパラメータを渡したい!

想定

下図のようなステートマシンを想定します。 select_taskでDB(RDS)からデータをセレクトしそれをinsert_taskでインサートします。
このとき、select_taskではParamsSettingsで設定した接続情報を使い、insert_taskではParametersで設定した接続情報を使うことにします。 f:id:hatunina:20190116215747p:plain

ステートマシンの定義

定義は下記のようになります。

{
  "Comment": "ETLフロー",
  "StartAt": "ParamsSetting",
  "States": {
    "ParamsSetting": {
      "Type": "Pass",
      "Result": {
        "rds_host": "host_1",
        "user_name": "user_1",
        "password": "password_1",
        "db_name": "db_1"
      },
      "ResultPath": "$.initial_params",
      "Next": "select_task"
    },
    "select_task": {
      "Type": "Task",
      "Resource": "Lambdaのリソース_1",
      "InputPath": "$",
      "ResultPath": "$.select_result",
      "OutputPath": "$",
      "Next": "insert_task"
    },
    "insert_task": {
      "Type": "Task",
      "Resource": "Lambdaのリソース_2",
      "InputPath": "$",
      "ResultPath": "$",
      "Parameters": {
        "rds_host": "host_2",
        "user_name": "user_2",
        "password": "password_2",
        "db_name": "db_2",
        "select_result.$": "$.select_result"
      },
    "End": true
    }
  }
}

DB接続城はキーバリュー形式でそのまま書くことができますが、select_taskの結果を参照するためには$を用います。
"select_result.$": "$.select_result"という部分ですが、キー部分にも$を含めないとバリューが変数として見なされず文字列としてTaskへ渡されてしまうので要注意です。

AWS Lambda関数

ステートマシンで定義した二つの関数です。

# select_task

def lambda_handler(event, context):
    rds_host = event['initial_params']['rds_host']
    user_name = event['initial_params']['user_name']
    password = event['initial_params']['password']
    db_name = event['initial_params']['db_name']

    # DBからデータをSELECTする処理
    # 結果をselect_dataへ格納

    response = {
        'select_data': select_data
    }
# insert_task

def lambda_handler(event, context):
    rds_host = event['rds_host']
    user_name = event['user_name']
    password = event['password']
    db_name = event['db_name']

    select_data = event['select_result']['select_data']

    # DBへINSERT処理

Parametersで設定した値はeventに格納されておりそのままのキーで読み込むことができます。
またevent['select_result']['select_data']でステートマシンで定義したキーで前のTaskの結果を読み込むことができます。

まとめ

Parametersで新しく設定する値自体は単純に読み込むことが可能ですが、前のTaskの結果を参照する場合には$を使う必要があるので要注意です。

参考

xp-cloud.jp

「データサイエンスのための統計学入門」を読んだ

読みました。

www.oreilly.co.jp
だいたい前半が統計学で後半が機械学習の話です。 数式はほぼ出てこずで各手法の特徴や使い所を中心に書いてあります。 「統計学者はこう使うがデータサイエンティストはこう使う」という話がちょいちょい出てきて面白いです。 また、アルゴリズムの説明を箇条書き風にまとめているので他の本で数式を追う際の副読本としてもいいかも。

EDAから始まり最後はブースティングで終わるなど2018年2月初版なだけあって最近の情勢に合わせている気がします。 サンプルコードはRですがモデルを動かすだけなのでほぼ気にならず。

kaggleを通して雰囲気で使っていた手法に関して確認ができたり、「あー、あれってこういうことなんだー」となる部分が所々あり、コンペが終わったタイミングだったのでちょうど良い本でした。

2018年の振り返りと2019年の目標とか

ポエムです。 僕は2016年10月からWebエンジニア(特定派遣)に転生したマンです。 会社では建前上MLエンジニアかデータサイエンティストということになっています。 Webエンジニア転生前は営業マンでした。

2018年

主にkaggleのプライベートリポジトリですが、家に帰ってコードを書くという習慣がついた1年でした。虫食いで汚いですが僕にとってはこれぐらいがストレスなく続けられる水準かなと思います。
f:id:hatunina:20190105044447p:plain

ブログ

あんまり書いていません。
f:id:hatunina:20190105044702p:plain:w150
書いても読書記録だったりStack Oveflowを和訳しただけだったりと有益なことは書いていません。 文章をたくさん書くのは大変なので、今年もウェブから検索できる自分のメモというノリで続けていこうと思います。

振り返り

以下、時系列でざっくり振り返りです。

1 ~ 2月

色々あり社内待機しつつ機械学習の勉強をしていました。 はじぱたに載っているアルゴリズムをnumpyで実装する等していました。 SMOアルゴリズムを実装するのにヒーヒー言っていた気がします。

2 ~ 5月

業務

ECサイトアサインが決まり自然言語処理をやっていました。 システムではCRFを使っていましたが、僕はモデリングはほぼ行わず前処理・後処理、その他ルールベースの便利ツールとかを作っていました。 メンバーとのコミュニケーションが英語だったり初めて業務でPythonを使ったりでヒーヒー言っていた気がします。 ビジネス側とミーティングを行い直接要望を聞く等の経験ができたのは良かったなと思います。

業務外

Pythonの練習でビットコインの約定履歴を取ってくるスクリプトを書いて公開したりしていました。 ビットコインの売買Bot界隈が盛り上がっていたこともあり、ちょっとStarをもらえて嬉しかったり。 github.com

6 ~ 12月

業務

某物流系企業で機械学習チームの立ち上げに関わっています。 まだ機械学習を使えるほど解決すべき課題やデータがなかったりで、アソシエーション分析をやったりBIツールの選定・インフラ構築をやったりしています。 一時期、SparkやDockerを使う機運が高まりAWS EMRやAWS Fargateを使ったりもしました。 だいたいオーバースペックなので本番には乗せられずちょっと残念です。 MLエンジニアというよりデータ基盤エンジニア?っぽい業務が多く面白いけど若干不満だったり不安だったり。

業務外

この辺りから本格的にkaggleをやり始めました。
f:id:hatunina:20190105051519p:plain:w250
7 ~ 9月にHome Creditコンペに参加しましたが、Kernelsをコピペするのに精一杯で7198中1667のTOP24%という結果でした。 色々なモデルや特徴を作ってもスコアが微動だにしなかったりPrivate LBでめちゃくちゃ順位が下がるなど、自分で理解していない処理を加えてもうまくいかないことを痛感しました。
10月はコピペを反省しつつコンペの復習と気分転換にビットコインMACDを通知するBotを作ったりしていました。
11 ~ 12月にPLAsTiCCコンペに参加し1094中43のTOP4%に入りシルバーメダルを獲得できました。 自分なりに特徴を加えたりモデリングしたりしていましたが、「Discussionの内容をひたすら試す」ということが主に効いていたので、あまり自分の実力でメダルが取れたという実感はないのですが、ひとつひとつの処理を理解できるようにはなってきているので、Kernelsコピペマンからは脱却できたのかなと思います。

2018年所感

シェアハウス住まいから同棲して半年で解消したり身内がアレしたりでドタバタした中でよくがんばったと思う。えらい。

2019年の目標とか

・転職する
・kaggle expertになる
OSSにプルリクだす

の3本です。公表する目標は曖昧でちょっと頑張れば届きそうなものにしておくとだいたい実現するというライフハックがある(僕の中で)のでこんな感じです。今年もがんばるぞい!