異常検知ナイト（エンジニア向け）
異常検知ナイト！ 2017年頂戴した技術的質問の中でとても多かったものが、異常検知でございました。懇親会で研究者が質問攻めに会い、懇親会が終われない！ということもございました。異常検知の問題をいかに解くかは情報も限られ、教師無し学習、元になるデータ補正、等々様々な難しさがあります。しかし、やりたい人が多い。それならば、一線の研究者、エンジニアを集めて、異常検知問題を如何に解くか情報を共有する会を開催することにしました。Deep Learning Lab 初のエンジニア向けイベントです。 ＜アンケートにご協力ください＞ ご視聴いただいた皆様からのご意見・ご要望をぜひお聞かせください！ アンケートサイトはこちら： http://aka.ms/dllab-survey/
Facebookの予測ライブラリProphetを用いたトレンド抽出と変化点検知 - Gunosyデータ分析ブログ
Gunosyデータ分析部アルバイトの五十嵐です。 Gunosyには大規模なKPIの時系列データがあります。 今回はKPIの時系列分析を行なった際に得た知見についてまとめたいと思います。 具体的にはFacebookが開発した時系列予測ツール Prophetを用いて、KPIのトレンド分析を行いました。 時系列予測について Prophetについて 実装例 モデルの適用 将来のアクセス数予測 トレンド性と周期性の抽出 変化点抽出 Slackを利用した自動化 まとめ 時系列予測について 以前、 KPIのトレンド抽出について以下のブログで紹介しました。 data.gunosy.io ここでは時系列データをトレンド成分と季節成分に分解し、トレンドの把握を容易にする分析を行なっていました。 KPIのトレンドを知ることでサービスの状態を把握することが目的でした。 今回はこの分析をさらに進め、トレンドの変化点
AWS Python SDKからAthenaにクエリして結果をS3からローカルに保存 | DevelopersIO
Amazon Athena を使うと、Amazon S3内のデータに爆速でSQLで問い合わせられます。 便利ではあるのですが、管理コンソールから操作すると SQL の記載 SQL の実行 完了まで待つ ダウンロードリンクからSQLの実行結果を保存 と待ち時間が長く、まとめて実行した SQL が多くある場合は、少しばかり手間です。 このような問題を解決するため、API を使って SQL の実行から SQL の実行結果の保存までを API で行うスクリプトを紹介します。 実行イメージ $ cat foo.sql select count(*) from bar $ export AWS_DEFAULT_PROFILE=test $ python athena.py foo.sql $ ls -1 athena.log athena.py foo.sql # クエリーする SQL foo.sql
RDS for MySQL のスロークエリログを可視化して、パフォーマンスをモニタリングする | DevelopersIO
ども、藤本です。 2年前に RDS for MySQL のスロークエリログを Elasticsearch に取り込んで、Kibana で可視化するブログをエントリしました。 RDS for MySQLのスロークエリーログをAWS LambdaでElasticsearchに取り込む ちょいちょい使ってはいたのですが、RDS のログの取り扱いの難しさで完全な取り込みができていない状況でした。先日、RDS for MySQL/MariaDB にてログを CloudWatch Logs へ出力できるようになりました。 RDSのMySQL/MariaDBでログをCloudWatch Logsへ出力可能になりました これを使うことで以前の実装よりも簡単で、かつデータの完全性を高められそうだったのでやってみました。 概要 RDS for MySQL/MariaDB のスロークエリログは簡単に出力、閲覧で
DigdagのPython APIを使う - Qiita
Digdagとは ワークフローエンジンと呼ばれるもので、データ分析基盤を構築する際に、Shell ScriptでPythonバッチを順に流しているような場合に、実行順序をyamlで定義できます。 serverモードというものがあって、複数ホストによる分散コンピューティングもできるので、場合によってはCeleryを導入しなくても、すべてDigdagで済ますこともできるのではないかと思い、調査を始めました。 ハマりポイント Language API - Python を使うに当たって、Pythonエンジニアが事前に知っておいた方がよいこと。 １．digdagのPythonパッケージはどこで配布されているか 次のサンプルを見てみましょう。 import digdag class MyWorkflow(object): def step1(self): digdag.env.store({'my_
digdagの変数はoverrideできる - Qiita
digdagで変数を_exportで定義した時、局所的に変数を上書きしたい場合があると思います。 上書きするときの変数のスコープについて軽く調べたので共有します。 変数を上書きするdigdagの例 timezone: Asia/Tokyo _export: var1: hoge +setup: echo>: start ${session_time} +test1: echo>: var is ${var1} +test2: _export: var1: fuga echo>: overrided var is ${var1} +test3: echo>: var is ${var1} +test4: _export: var1: fuga +sub4: echo>: overrided var(in subtask) is ${var1} +teardown: echo>: finish
Amazon Athena/PrestoのLambda式・Lambda関数を触ってみた | DevelopersIO
サーバーレスのインタラクティブなクエリーサービスAmazon Athenaはバックエンドのクエリーエンジンに分散クエリーエンジンのPrestoを採用しています。 この度、Athena の利用する Presto のバージョンが 0.172 にアップデートされ、Lambda式・Lambda関数に対応したため、Prestoのオフィシャルドキュメントを頼りに実際に動かしてみました。 なお、最新の EMR である 5.10.0 の Presto のバージョンは 0.187 です。 Lambda 式について Presto 公式ドキュメントからの転載となりますが、以下のように、ほとんどの SQL 式を使えます。 x -> x + 1 (x, y) -> x + y x -> regexp_like(x, 'a+') x -> x[1] / x[2] x -> IF(x > 0, x, -x) x ->
GCPインスタンスに複数外部IPを設定 - Qiita
# 一覧表示 gcloud compute target-instances list # 取得 gcloud compute target-instances describe [TARGET_INSTANCE] # 削除 gcloud compute target-instance delete [TARGET_INSTANCE] # ポート80に来た `111.111.111.111` へのTCPリクエストを `[instance-name]` へ転送する gcloud compute forwarding-rules create [forwarding-rule-name]] \ --ip-protocol TCP \ --ports 80 \ --target-instance [instance-name] \ --address 111.111.111.111 # ポート8
ややこしいIPv6アドレス自動設定の話:Geekなぺーじ
IPv6の大きな特徴として、IPアドレスの自動設定機能がIPv6の根本的な仕組みとして組み込まれている点があげられます。 IPv4が誕生した当初はIPアドレスの自動設定のための手法が存在していませんでした。 IPアドレス自動設定のためのDHCP(Dynamic Host Configuration Protocol)を規定したRFC 1531が発行されたのは1993年です。 IPv4におけるIPアドレスの自動設定は、後から作られたDHCPを使うというものでしたが、IPv6では最初からIPアドレス自動設定が議論されています。 ただし、その議論の結果生み出されたものが非常にややこしくなっています。 IPv6には最初からIPアドレス自動機能が備わっているものの、IPv6用のDHCPであるDHCPv6も同時に存在しており、非常にややこしいのです。 この文章を執筆している時点では、IPv6におけるI
ニューラルネットワーク使ったAIなんかめっちゃ簡単だから。俺天才ｗｗみたいなフリすんのやめろ - bonotakeの日記
スイマセン。クソ煽りタイトルですが、下記の記事のタイトル意訳しただけです。草生やして更にクソさを増してはいます。 Neural network AI is simple. So… Stop pretending you are a genius 個人的にはぜひ本文読んでこの記事のクソ煽りっぷりを満喫してほしいのですが、英語読むのもメンドクセという方に、何が書いてあるかをさらっとだけ説明すると。 要はニューラルネットワークって、↓のPythonで11行のコード分の処理やってるだけじゃね？ こんなの使いまわした程度で「うはｗｗｗ俺天才ｗｗｗ」みたいな顔すんのやめろ、ってことのようです。 まぁハッキリ言って、クソ記事ｗｗｗ煽り乙ｗｗｗなんですけど。 でもぶっちゃけ、真実なんですよ。ある面においては。 僕も今の会社に入るまでディープラーニングに関する知識ほぼゼロだったけど、今は少なくとも、自分の業
日本郵便がハード保守契約を全面見直し、ITベンダーの反発は必至
日本郵便が情報システムで使うハードウエアに関する保守契約の方針を刷新する意向を固めた。日経コンピュータの取材で分かった。 24時間保守を原則として採用せず、故障機器の修理を1週間分まとめて実施するなど過剰サービスを減らして、ハード保守費を従来の2割程度に減らす。2018年夏以降の新規入札案件から新方針を適用する。既存の保守契約は既に条件を見直す交渉に入った。 鈴木義伯専務執行役員CIO（最高情報責任者）は「現行の保守契約はITの技術変化を反映していない。サービス過剰でコストが高止まりしている」と話す。NTTデータ出身の鈴木CIOは日本取引所グループのCIOを経て2017年4月に日本郵便のCIOに就任して以来、見直しを模索してきた。 新方針ではITベンダーと契約する保守のパターンを品質が低いほうから「スポット保守」「日中週1保守」「日中保守」「24時間保守」の4つに分ける。そのうえで、ハード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Recent EC2 Goodies – Launch Templates and Spread Placement | Amazon Web Services
羽生くんの作画は天野喜孝、宇野くんは萩尾望都という説に「この説も捨てがたい」「あの人は絶対に…」
DAGで表現するお気持ちネットワーク / Okimochi