タグ

2016年11月25日のブックマーク (5件)

  • Compression in Kafka: GZIP or Snappy ? | Neha Narkhede

    In this post, I’m going to compare Kafka performance with GZIP and Snappy compression codecs. Why compression ? It is a well known fact that compression helps increase the performance of I/O intensive applications. The reason is simple – disks are slow. Compression reduces the disk footprint of your data leading to faster reads and writes. But at the same time, you invest CPU cycles in decompressi

    Compression in Kafka: GZIP or Snappy ? | Neha Narkhede
    kimutansk
    kimutansk 2016/11/25
    GZIPとSnappyの場合、同一のデータ量を読むためにCPU負荷はGZIPが倍。ただ、1MB以上バッチ取得や、DC間レプリケーションならGZIPの方が有利、それ以外のケースや書き込みはSnappy有利と。
  • Google機械翻訳の仕組み&できるようになったこと/まだ難しいことについて、社内の機械学習勉強会で説明します - yasuhisa's blog

    社内の機械学習勉強会で最近話題になった機械学習関連のエントリを取り上げているのですが、ここ一ヶ月ではGoogle Neural Machine Translation(GNMT)がとても話題になっていました。GNMTで使われているEncoder-Decoderやattentionのような仕組みを直近で使う予定は特にはないですが、機械学習を使うエンジニアとして知っておいて損はないし、技術的に何が変わったことにより何ができるようになって、何はまだできないのかを知ろう、というのが目的です。技術的な項目は興味ない人も多そうなので、最後に持っていきました。 Google Neural Machine Translation(GNMT)の最近の進化について できるようになったこと 定量的な評価 まだまだ難しいこと 技術的な詳細 Encoder-decoder Attention based encod

    Google機械翻訳の仕組み&できるようになったこと/まだ難しいことについて、社内の機械学習勉強会で説明します - yasuhisa's blog
    kimutansk
    kimutansk 2016/11/25
    同じ単語をはきまくる問題の原因はそういうことだったわけですか。次の単語と隠れ状態を基に作って最後に到達するまで循環させるので、こうなる・・?
  • 新Google翻訳を使って3700ワードの技術文書を1時間で翻訳した - 科学と非科学の迷宮

    新しいGoogle翻訳がニューラルネットワークに基づく機械翻訳に移行して品質が向上した、というので早速使ってみました。 翻訳対象はHadoopのFair Schedulerに関するドキュメントです。 Fair Schedulerは、Capacity Schedulerと並ぶHadoopの2つのスケジューラの一つですが、挙動が少し複雑で、理解するのに苦労します。ドキュメント自体も長く、英語に不慣れな人には読むのがなかなか大変な文書で、前々から訳したいとは思っていました。しかし、3700ワード(A4に文字ぎっしりで7ページ近く)の技術文書を訳すとなると、かなりの労力が必要になります。少なくとも一日仕事になるのは間違いありません。私も仕事が忙しく、なかなか翻訳の時間がとれなかったため、翻訳作業はタスクキューの底に埋もれてしまっていました。 そこで、今回新しい翻訳がどれほどのものか試すのも兼ねて、

    新Google翻訳を使って3700ワードの技術文書を1時間で翻訳した - 科学と非科学の迷宮
    kimutansk
    kimutansk 2016/11/25
    実際新版になってから、技術系記事を張り付けてほぼ違和感なく読めてしまう。ただ、結果の日本語補正できても元の英文修正するまでは知識が至らないので、英語学習はまだまだ必要ですが
  • 高次元ベクトルデータ検索技術「NGT」の性能と使い方の紹介

    この結果を見て単語ベクトルが変わるとNGTの性能が変わってしまうように感じた方がいるかもしれません。しかし、実はこれらの単語ベクトルはデータの次元数や件数が違っているため、それぞれの条件をあわせてみる必要があります。興味がある方は論文を読んで見比べて欲しいと思いますが、ここで重要なことは、NGTが高い精度にも関わらず、せいぜい100ミリ秒程度で検索できるという規模感であるということです。その規模感を感じてもらうために、これらの実験結果をご紹介しました。この実験以外にも論文の中では単語ベクトルの応用としてアナロジーと呼ばれる合成ベクトルでの実験やその他の比較手法の比較、実験結果の考察などもありますが今回は割愛します。 これまで紹介した内容と同じような実験はLinux系のサーバーであれば公開しているExperimental softwareという実験プログラムを使うと簡単に試すことができます。

    高次元ベクトルデータ検索技術「NGT」の性能と使い方の紹介
    kimutansk
    kimutansk 2016/11/25
    特徴量ってたいていベクトルであらわされてるので、そこそこ汎用的に様々な近傍探索に使用できるということなんですかね?
  • Apache Igniteを分散キャッシュに利用したシステム負荷軽減 | CyberAgent Developers Blog

    秋葉原ラボ 飯島 賢志 シュティフ ロマン(@rshtykh) はじめに サイバーエージェント内の研究開発組織である秋葉原ラボは、大規模データ基盤の開発・運用に加えて検索・機械学習・データマイニングなどを活用して、弊社の各サービスと様々な形で連携している。今回、Amebaトピックスで使用しているレコメンドAPIに分散キャッシュを導入してシステム負荷を軽減した事例を紹介する。 Amebaトピックス Amebaトピックスでは、Amebaが展開するサービスの中でいまホットなトピックや記事を選定し配信している。誰にどのトピックを表示するかについていくつもの判定や処理が瞬時にされるが、今回の改善で一層速くレスポンスを返すことができるようになった。 図1. Amebaトピックスのブログヘッダへの配信 システム構成 今回、改善対象となったレコメンドAPI周りのシステム構成を以下の図2に示す。一部省略して

    Apache Igniteを分散キャッシュに利用したシステム負荷軽減 | CyberAgent Developers Blog
    kimutansk
    kimutansk 2016/11/25
    非常にポピュラーな構成だからこそ、他の分散キャッシュ系でなくあえてIgniteを使用したかが気になるところではありますね。