本記事はMakuake Product Team Advent Calendar 2018の23日目の記事です。
今日は僕の誕生日です。誕生日の7時間をかけて書きました。笑
最初にdata lake managementの話をしたいので、ちょっとWEBから外れた話をします。(話題にする箇所のプロトコルはRESTですので許してください) 車のボディにカラーを噴霧塗布する装置がありますが、その噴霧を最適化するための機械学習型コントローラの話です。
ここでしない話
以下は話題が組み込みに寄りすぎるんで割愛します。- 噴霧機のコントロールI/Fの話
- 噴霧状況と、塗布クオリティを確認するセンサーのI/Fの話
塗料のデリケートさに関連するパラメータ
塗料は本当にデリケートで、どんなに均一に塗られた麺を見ても、X-Lay Scannerで見ると少なからずまだら模様になっています。 こうしたマダラの薄いところから錆が浮いてきたり、厚いところの塗装がペラっと剥がれてきたり、ということが経年劣化とともに起こるのですが、均質な塗装は互いが補完しあって長持ちするとされており、そうした状態を目指して自動車の塗装工場では塗布機に様々な工夫が凝らされています。- 天気
- 気温
- 湿度
- 定着照度
- 室内照度
- ボディの表面温度
- 直前に塗布した塗料の付着率

性能要件の実現ジャーニーと切り分け
こうしたシステムの場合、要望として出る性能要件とセンサリングからのインプットを真に受けてストレートに実現しようという形ばかりが正解であるとは限りません。要は- 入口:様々なセンサーのデータを取得している
- 出口:10秒単位で状況に応じた噴霧の最適化ができている
- もれなく)センサーからのデータを収集
- 研究対象)データをモデリングしてdata lakeを生成し、raw dataはバックアップへ(バックアップはブラッシュアップが済んだら捨てる想定)
- 研究対象)噴霧データへのCalculate
- 正確性・回復性)噴霧コントローラ(1のデータも利用)
- もれなく)噴霧状況のフィードバック → 1に戻る

data lake management
data lakeは「データを活用できる状態にすること」です。 どう活用できる状態になっているべきなのかを管理するのがdata lake managementです。 アーキテクチャ上は、溜まっているデータそのものに意味も価値もなくて、data lakeが済んだ状態で初めて価値が出ます。 なので出自が同じデータでも、その活用の方向性や頻度によって、全く違う保存の仕方を複数のdata storeに対して行うことがよくあります。 これは、入れたデータを万能に活用できるデータストアがまだ存在しないからです。 データストアそれぞれが特徴的な性能傾向を有している2018年では、アプリケーションエンジニアにはそれらをうまく使い分ける動きが求められます。 僕はよくdataの用途と傾向に合わせて- Faced(今目の前)
- Proximate(計算しないでそのまま使う)
- Calculatable(計算前のゴミ箱手前)
- Calculated(計算後の即戦力)
- Trash(ゴミ)
- Faced
- 室内照度
- ボディの表面温度
- 直前に塗布した塗料の付着率
- Proximate
- 定着照度
- 天気
- 気温
- 湿度
- Calculatable / Calculated
- 定着照度
- 天気
- 気温
- 湿度
- 室内照度
- ボディの表面温度