タグ

2022年2月9日のブックマーク (5件)

  • 検索の応答性能を維持するための Benchmarking Automation | メルカリエンジニアリング

    ※この記事は、"Blog Series of Introduction of Developer Productivity Engineering at Mercari" の一環で書かれています。 はじめに こんにちは、メルカリMicroservices SREチームの藤(@jimo1001)です。 私は Embedded SRE としてメルカリJPの検索に関連するマイクロサービスを提供している サーチインフラチームに入り、サービスの信頼性向上やインフラ周りの自動化に従事しています。今回は、メルカリの商品検索の応答性能を維持するための Benchmarking Automation の取り組みについて紹介したいと思います。 検索基盤のアーキテクチャ まず、検索基盤のアーキテクチャについて簡単に説明します。主要なコンポーネントに絞ってシンプルに表現したものが以下の図になります。 各コンポー

    検索の応答性能を維持するための Benchmarking Automation | メルカリエンジニアリング
    sh19910711
    sh19910711 2022/02/09
    "Gatling: 検索クエリを並列で Search Middleware へリクエストし、レスポンスタイムやステータスを計測 / テストに使用する検索クエリは、BigQuery に保存されているクエリログからテストに必要な量のクエリを抽出"
  • No.38 Data Casual Talk - データとエンジニアリングのよもやま話

    先日、na0さんと、BIやデータマート、DWH等々について、カジュアルにお話する機会を頂きました。 その時に、良いお話ができたので、備忘も兼ねて、簡単に整理してみました。 (na0さんには、ブログに書くことを事前に了解頂いております。) 今回、まとめた内容は、あくまで、na0さんと私がお話した内容に基づくものであり、 それぞれが所属する組織の見解ではありませんので、その点は、ご了承頂けたらと思います。 また、先日、お話した内容を元に私の視点で追加整理している箇所も含まれていますので、 その点もご認識ください。 BI環境 データ基盤+BI環境 全体像 いわゆるBI(ビジネスインテリジェンス)のことですが、上記の図では、敢えて、データ基盤とは分けて表してみました。 様々なデータが整理され、活用できる形で格納されているデータ基盤環境に対して、各ユーザが、それぞれの目的・用途に応じて、 データ基盤

    No.38 Data Casual Talk - データとエンジニアリングのよもやま話
    sh19910711
    sh19910711 2022/02/09
    "データマート: 同じ社内でも、部門によっては、見たい単位が異なる場合がある / 自分が想定している「顧客」像が、別の部門では、粒度が異なっていた、そもそも、顧客の定義が違っていた、というのはよくあること"
  • Pull Request の関心事は一つにしよう | Wantedly Engineer Blog

    main branch を default の branch として運用することが多くなって来ていますが、 Wantedly このでは数多くの repository の CI 設定や自動化フローにおいて master をハードコードして利用してきました。 短期間での移行が難しいため、 2022 年 1 月現在では master branch を default で利用している repository が多数派です。 Pull Request が持っていると嬉しい性質よい Pull Request の分け方を考えるために、まずは Pull Request が持っていると嬉しい要素を列挙します。どれもそれだけを重視すると他のことが犠牲になる事があるという点に注意が必要です。あくまで「他にデメリットがないのであれば」という前提だということです。 diff の行数は少ないほうがいいこれは当たり前に実

    Pull Request の関心事は一つにしよう | Wantedly Engineer Blog
    sh19910711
    sh19910711 2022/02/09
    "関心事が多いと「リファクタリング部分にバグがないか」「この diff は純粋にコーディングスタイルの変更のみか?」のように確認が分散 / どこまで小さくするか > 関心事が増えないならできる限り詰め込んでしまえ"
  • 絶対的に使った方がいいLogstashのMultiple Pipelinesについて書いてみた - Qiita

    はじめに おはです! Logstashのフィルタの中でもGrokが好きなぼくが、Advent Calendar11日目を書かせていただきますー あ、でも今回は、Grokについては書かないですよ! じゃあ、何書くの?Grokしか脳のないお前が何を書くのさー そりゃ、あれだよ!Logstash 6.0がGAされたので、待ちに待ったMultiple Pipelinesについて書くしかないでしょ! てことで、LogstashのMultiple Pipelinesについて、ゆるーく書いていきます( ゚Д゚)ゞビシッ 構成について 今回テストするにあたって使用した構成は以下です。 Amazon Linux AMI 2017.09.1 (HVM) Logstash 6.0 logstash-input-s3 Elasticsearch 6.0 Kibana 6.0 X-Pack 6.0 ちなみに、もろ

    絶対的に使った方がいいLogstashのMultiple Pipelinesについて書いてみた - Qiita
    sh19910711
    sh19910711 2022/02/09
    2017 / "Multiple Pipelines: hoge.confに対して複数のデータソースを組み込んでいたものを、分割することができちゃう / Worker数などもPipeline毎に割り当てることができる"
  • 統計学を通して見える世界 - jnobuyukiのブログ

    今回は、統計学に基づいた研究の意義や世界の見え方について思うことを書きます。 研究にとっての統計的仮説検定というツール 研究では、何らかのアイデア(仮説と呼びます)が、実際に何かの現象をうまく説明できたり、何かに役立ったりすることなどを検証します。その際、多くの実証研究では統計的仮説検定という手続きを経て、主張の説得力(研究上の言葉で言えば妥当性)を高めようとします。統計的仮説検定では、帰無仮説と対立仮説という二つの仮説を立てます。 帰無仮説:研究者が主張したいこととは逆の内容にあたります。例えば、商品Aと商品Bは売れ方が違うと思っている時に、あえて商品Aと商品Bの売れ方は等しいと仮定するような仮説です。 対立仮説:研究者が主張したい仮説はこちらです。 統計的仮説検定は、主張したい内容と逆の帰無仮説を立てて、収集したデータの観測値が帰無仮説を前提にするとありえないことを示し、帰無仮説を取り

    統計学を通して見える世界 - jnobuyukiのブログ
    sh19910711
    sh19910711 2022/02/09
    "統計的仮説検定では、確率の概念の導入が肝 / 「ある事象の生起の可能性が非常に低い」という議論 / 研究の場合、「ないものをある」というのは危険なので、「あるものを見落とす」を犠牲にしながら"