はてなブックマーク

GitHubActionsを使ってCI/CDパイプラインを構築する際には、以下のようにService AccountのJSONキーを使用して認証を行うことが多いです。 - name: Set up Cloud SDK uses: google-github-actions/setup-gcloud@master with: service_account_key: ${{ secrets.GOOGLE_APPLICATION_CREDENTIALS_JSON }} export_default_credentials: true しかし、この方法は既に非推奨になっており、代わりにWorkload Identityを使うように案内されています。 The following inputs are for authenticating to Google Cloud via a Service

Scrapyでクローリングをするときにダウンロード間隔をどうするべきかは悩ましい問題です。 クローリング対象のシステムの負荷を考えると、短すぎるダウンロード間隔は避けるべきです。 ですが、適切な間隔値は対象サイトごとに異なり、また時間帯によっても異なります。 そのため、サーバーのレスポンスタイムやレスポンスコードによってダウンロード間隔を動的に変えることが出来れば便利です。 Scrapyにはそのための機能であるAutoThrottle Extentionがあるため、これを利用してみます。 使い方 使い方はかなり簡単で、settings.pyに以下の設定を書くだけです。 あとはこれだけで自動的にダウンロード間隔を調整してくれます。 仕組み さて、この拡張機能はどのように動作しているのでしょうか？ 以降ではその仕組を説明していきます。 まずクローリング対象サイトに対して並列リクエストをしたい目

注意 注: この記事の内容は古いです。IntelliJのバージョンが2021.1以上の人は以下の方法で接続したほうが良いです。 IntelliJ便利ですよね。 JavaのIDEとして有名ですが、その他にも様々な言語のIDEとしても使えますし、さらにはDBクライアントとしても優秀です。 対応しているDBの種類が豊富ですし、機能もリッチです。 ですが、BigQueryにはデフォルトで対応していないので、そこだけちょっと惜しいです。 この記事ではIntelliJ系のIDEからBigQueryに接続する方法を説明します。 参考にした手法とその問題点 IntelliJ BigQuery でGoogle検索すると以下の記事が最初に見つかります。 https://blog.jetbrains.com/datagrip/2018/07/10/using-bigquery-from-intellij-bas

2つのテーブルの差分をBigQueryで求めてみます。 テーブルをFULL OUTER JOINで結合して、排他的論理和を求めても良いですが、テーブルのすべての列をON句の後ろに書く必要があり、そこそこ面倒です。 https://www.codeproject.com/articles/33052/visual-representation-of-sql-joins というわけで、 except を使って差分を出してみました。 このクエリの結果が0行であれば、2つのテーブルはすべての行が一致しています。 # standardSQL with table1 as ( SELECT 1 as a, 2 as b, 3 as c union all SELECT 2 as a, 4 as b, 6 as c ), table2 as ( SELECT 1 as a, 2 as b, 3 as c

# standardSQL with chars as ( SELECT * FROM UNNEST(['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', null]) as char ) select str from ( select concat(ifnull(a.char, ''), ifnull(b.char, ''), ifnull(c.char, ''), ifnull(d.char, ''), ifnull(e.char, ''), ifnull(f.char, '')) as str from chars as a cross join chars as b cros

多くの人は {"hoge" => "12:34"} という結果になると思いますが、実は違います。 このYAMLのパース結果は、{"hoge" => 754} です。 この記事の後半では754 という謎の数字の正体に迫って見ようと思います。 仕様書確認 とりあえず、YAMLの仕様書を確認してみます。 こちらが最新版のYAML仕様書なので、この中にそれっぽい仕様があるかどうかを確認してみます。 YAML Ain’t Markup Language (YAML™) Version 1.2 ですが、このドキュメントを読んでも、この挙動に関する記述は見つからなかったです・・・ ソースコード確認 さて、仕様書を見てどうも解決しかなったので、ソースコードを読んでみましょう。 読み取った文字列の雰囲気を見て、いい感じにいろんな型に変換変換している部分に謎を解く鍵が見つかりました。 https://gith

BigQueryへデータロードする時に圧縮をしていると、ロード時間が伸びることがあります。 この記事では圧縮の有無によってどの程度の時間差が出るのかを紹介します。 検証方法 S3に配置したファイルをEC2上のembulkによってBigQueryに転送します。 この時に使用したEC2インスタンスは c5.xlarge で、awsとGCPの間の通信は専用線ではなくインターネット回線を利用しています。 転送対象のファイルの作成 転送対象のファイルをS3に配置します。 以下のYAMLをembulkで実行することによって、gz圧縮されたcsvファイルがS3に配置されます。 ファイルのサイズは1.8GBです。 exec: min_output_tasks: 1 max_threads: 1 in: type: random rows: 10000000 schema: col1: integer co

こんにちは、VASILYバックエンドエンジニアの塩崎です。 最近ニューラルネットワークが流行っており、毎日のようにニューラルネットワークを活用した技術のニュースを目にします。 アメリカの調査機関であるGartnerが今年に発表した資料によると、「期待のピーク期」にあるそうですね。 Top Trends in the Gartner Hype Cycle for Emerging Technologies, 2017 VASILYでもファッション分野におけるユーザー課題を解決するために、データサイエンティストが様々な試みを行っています。 それらについては、以下のTECH BLOG記事に成果が書かれているので、興味のある方は是非お読みください。 VAEとGANを活用したファッションアイテム検索システム ディープラーニングによるファッションアイテム検出と検索 さて、この記事ではそのような課題解決

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この記事はVASILY DEVELOPERS BLOGにも同じ内容で投稿しています。よろしければ他の記事もご覧ください。 こんにちは、バックエンドエンジニアの塩崎です。 さて、VASILYではData WarehouseとしてGoogle BigQuery（BigQuery）を利用しています。 BigQuery内にはプロダクトのマスタデータとユーザーの行動ログが格納されています。 そして、それらに対する横断的なクエリを発行することでプロダクトの成長のためのKPIをモニタリングしています。 そのためAmazon Relational Database Service（RDS）に保存されているマスタデータをBigQueryに同期する処理を定期的に実行する必要があります。 先日、ワークフローエンジンであるDigdagとバルクデータローダーであるEmbulkを利用して、この処理を行うシステムを構築

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この図からも検索ノイズを減らすことと検索漏れを減らすことがトレードオフの関係にあることがわかります。 しかし、これら2つを併用することによって、それぞれを単独で使用する場合に比べて、検索漏れの数を減らし、検索ノイズの数を実質的に減らすことが可能です。 併用するための具体的な手法は以下のようなものになります。 インデックス生成処理 ドキュメントに対してNgramによるインデックスを生成する 形態素解析によるインデックスも生成する 検索処理 Ngramと形態素解析によるインデックスに対して同時に検索を行う 形態素解析によるインデックスの結果が先頭になりやすいように重みを付けて検索結果をマージする 2つの検索結果をマージすることによって、検索漏れを減らします。 しかし、ただ単にマージしてしまうと、検索ノイズが増えてしまいます。 形態素解析の結果を先頭になりやすいようにマージすることが、この併用処

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

@import url(https://fonts.googleapis.com/css?family=Poppins:700); .price { color: #c70506; text-shadow: 2px 0 0 #fff, 0 2px 0 #fff, -2px 0 0 #fff, 0 -2px 0 #fff, 5px 4px 3px rgba(0,0,0,0.5); font-weight: bold; font-family: Poppins; letter-spacing: -3px; } .price1 { font-size: 78px; margin-right: -5px; font-style: italic; } .price2 { font-size: 59px; margin-right: 10px; font-style: italic; } .yen {

通信系のプログラムを書いていると、誤り検出のためにパリティビットを使用することがあります。 この記事ではuint32_t型の数値が与えられたときに、そのパリティを計算する関数を効率化することを紹介します。 関数の仕様 関数の仕様を以下のように決めます。 入力 uint32_t型の整数 出力 入力された整数を2進数で表現したときに、ビット1の数が偶数ならば0、奇数ならば1 とりあえず愚直に実装 とりあえずは、仕様を愚直に実装してみます。 32回のループを回して、1の数を数え上げています。 int parity(uint32_t val) { int count = 0; for(int i = 0; i < 32; i++) { if(val & 0x00000001) count++; val <<= 1; } return count & 0x00000001; }

Qiitaのあるタグがついた投稿一覧ページのページングの末尾まで飛ぶリンクをクリックした時に、レスポンスが明らかに遅い気がします。 体感的には、2〜3倍は遅い感じがします。 計測してみた 方法 とはいえ、なんとなく、遅いと言うのはただの言いがかりなので、どのくらい遅いのか計測をしてみました。 今回はページングのパラメーターを大きくしながら、リクエストを投げて計測します。 測定するメトリクスはTTFB(Time To First Byte)です。 TTFBの計測は以下のようにcurlコマンドを使って行いました。 結果 測定結果を箱ひげ図にしたグラフを以下に示します。 横軸はページングのパラメーター(そのまま表示させると、グラフの横幅が大きなってしまうので、幅15のビンを作成しています) 縦軸は、TTFB(Time To First Byte)です。 ページ番号300を境界にして、振る舞いが大

この記事はVASILY DEVELOPERS BLOGにも同じ内容で投稿しています。よろしければ他の記事もご覧ください。 こんにちは、VASILYバックエンドエンジニアの塩崎です。 VASILYでは様々なログデータの分析にBigQueryを使用しています。 インデックスについて何も考えなくても良いのが特に便利です。 さて、そんなBigQueryですが、数か月前にStandard SQLという新しい仕様のSQLがサポートされました。 BigQuery 1.11, now with Standard SQL, IAM, and partitioned tables! VASILYでも徐々にStandard SQLに移行をしているので、使い勝手や従来のSQLからの移行方法についてまとめておきます。 Standard SQLとは SQL:2011に準拠しつつ、配列や構造体等の構造化データを扱えるよ

Google BigQueryの課金体系はスキャンしたテーブルのサイズに対して課金されるシステムです。 そのため、無からテーブルを生成し、それに対して計算を行えば、理論上は無料で計算を行うことができるはずです。 というわけで、その1つの実例として、円周率の計算をしてみます。 計算には以下のライプニッツの公式を使います。 $$ \sum _{n=0}^{\infty }\,{\frac {(-1)^{n}}{2n+1}}\;=\;{\frac {\pi }{4}} $$ [出典] https://en.wikipedia.org/wiki/Leibniz_formula_for_%CF%80 円周率を計算する公式の中では収束が遅い方ですが、式の形が簡単なので、計算のサンプルには良さそうです。 SELECT SUM(4 * POW(-1, n) / (2 * n + 1)) as pi FRO

概要 Apache Solr(以下、Solr)で商品検索のサジェスターを作ったので、それを紹介します。 サジェスターを作るにあたり、どのようにスキーマやサーチコンポーネントを定義すれば良いのかを説明します。 なお、この記事はsolr 4.10.4を対象にした記事です。 それ以外のバージョンでは設定項目が変わってくる場合があります。 サジェスターとは サジェスターとは、ユーザーが検索用のフォームに単語を入力している途中に、その入力途中の単語を補完する機能です。 例えば、Google検索でサジェスターについて調べようとした時に、「さじぇ」と入力した時点で以下のように「さじぇ」に続く単語が候補として現れます。 このような機能を実装することによって、ユーザーがテキストを入力する手間が省けたり、入力間違いをした単語で検索をしてしまうことを防げたりする効果があります。 日本語のサジェスターの難しいとこ

はじめに 私の所属しているVASILYでは非同期処理を行うためにsidekiq(http://sidekiq.org/ )というライブラリを利用しています。 sidekiqでは非同期処理用のジョブをRedis上のキューで管理します。 このキューにどのくらいの数のジョブが入っているのかという情報をmackerelのカスタムメトリクスとして管理するためのプラグインを書いたのでご紹介します。 mackerel-agentはgoで書かれており、その影響か公式のプラグインもgoで書かれています。 https://github.com/mackerelio/mackerel-agent-plugins 公式ライブラリを幾つか見るとgoの練習にちょうどよさそうな難易度でしたので、goの勉強も兼ねてmackerelプラグインを書いてみることにしました。 このプラグインのソースコードはhttps://git