メルカリの今年1年間の機械学習の取り組みとこれから
これはMercari Advent Calendar 2017 の2日目の記事です。 昨日は @stanaka の分散ファイルシステムはブロックチェーンの夢を見るか でした。 今回は@Hmj_kd が、メルカリの機械学習の取り組みや機械学習エンジニアの今年行ってきた活動のいくつかをご紹介したいと思います。 以下、一部にて機械学習をMLと略します。 この1年間で機械学習で取り組んだこと 私が入社したのは2017/01で、社内では二人目の機械学習エンジニアでした。 その当時は speakerdeck.com にあるように、プロダクトにMLに関するものはありませんでした。 現在は、チーム全体でマネージャも含めて約10人ほどの組織になり、活発に実験や開発が行われています。 いくつかを列挙しますと - 商品出品時の価格推定とサジェスト - 一部カテゴリについて商品タグの推定 - 商品出品時のカテゴリ
分散ファイルシステムはブロックチェーンの夢を見るか | メルカリエンジニアリング
今年からメルカリでもMercari Advent Calendar 2017と称してAdvent Calendarを始めることとなりました。 初日は id:stanaka / @stanaka がロンドンよりお届けします。 分散ファイルシステムという言葉を聞くと、トラウマを刺激され、うっと頭を抱える人も多いかと思います。私もその一人で、以前にPBクラスまではいかずとも数TBのHDDを数百台並べたシステムのお守りをしたことがあり、日々壊れ続けるHDDに負荷に悲鳴を上げるメタデータDBなどネタには困らない状況でした。そういう時にAWS S3を触ると、「ああ、これは天国だ..」ともはや過去には戻れない思いをしたものです。 最近では分散ファイルシステムを運用しているところもめっきり減っていて*1もう過去の分野かな、と思っていたのですが、ここ数年で「ブロックチェーン x 分散ファイルシステム」という
cachectld〜無駄なページキャッシュの削除を自動化〜 | メルカリエンジニアリング
原稿の執筆が一段落して心に余裕が出てきた@cubicdaiyaです。 今回はサーバを運用しているとありがちなページキャッシュに関する問題とメルカリのアプローチについて解説します。 Fluentdによるログ転送 話は変わりますが、メルカリの各サーバ上ではプログラムが吐いたログデータをKibanaやNorikraといった各種コンポーネントに転送するためにFluentdが稼働しています。各ログデータは原則単一のファイルに追記されてFluentdのtailプラグインによって各所に転送されていきます。 ログデータのサイズはまちまちで、1日で数GB程度のログデータもあれば数十GB以上のログデータもあります。 ページキャッシュと巨大なログファイル 各サーバに吐かれるログデータのサイズはサーバに搭載されているメモリのサイズと比べると1日分だけでもかなりの量になります。そして、このように絶えず書き込まれる巨
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
