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

Digdagではcronのように定期的にジョブを実行したり、指定した時間内に処理が終わらなければい警告を出すことができます。 🍮 schedule:指定した時間にジョブ実行timezone: Asia/Tokyo schedule: minutes_interval>: 1 +current_date: sh>: echo `date` +echo_hello: sh>: echo hello
Mercari Advent Calendar 2017 の9日目はメルカリ SRE(Site Reliability Engineering) チームの @syu_cream がお送りします。 メルカリでは様々なデータを BigQuery に格納して、データ利用を可能にしています。 BigQuery に格納しているデータの具体例としては、 Web サーバや API サーバのアクセスログやアプリケーションのログ、 以前当ブログで紹介した Pascal のイベントログ などが挙げられます。 メルカリのデータ分析基盤に関する情報はこれまでに以下のようなブログやスライドで紹介しております。 Pascal〜Puree + ngx_lua + Fluentd + BigQueryでつくるメルカリのログ分析基盤〜 fluent-agent-hydraで省エネログ転送 メルカリのデータ分析基盤 / me
こんにちは!! 私はメルカリでSREをしている k-oguma ( ktykogm ) です。 ちょうど1年くらい前にジョインしました。 よろしくお願いします! 今日は、タイトルの件で対応した方法をご紹介したいと思います。 それはある日突然やってきた TL;DR BigQueryへLOADさせる方法を考える 初期の検討 見直し Embulk Embulk 説明 Digdag Digdag 説明 Digdag呼び出し処理 Dry-run いざ、実行 補足: もっと高速化させたいなら 終わったあとは 最後に 参考にしたURL それはある日突然やってきた ある日、ETL作業 (データ分析基盤運用)の依頼がUSチームからやってきました。 要件は次のようなものでした。 1.4TB サイズの MySQL innodb tableを1つをBigQueryに上げる 約1年分。期間指定。 期限数日、なる早
こちらは Gunosy Advent Calendar 2018、7日目の記事です。なお、昨日の記事は @yutanim さんの RxSwiftにおける孫からの祖父母孝行 でした。 qiita.com はじめに こんにちは、広告技術部の キヴィタスポ(人工知能) (@Civitaspo) / Twitter です。 Gunosy に入社してから早いもので1年が経ちました。昨年の Gunosy Advent Calendar では僕は読む専門だったのですが、『Gunosyのパーソナライズを支える技術 -ワークフロー編-』を読んで非常に感銘を受けたのを覚えています。 tech.gunosy.io ここではそのとき感銘を受けた言葉を紹介しておきます。 ワークフローは、いわばシステム上における兵站といってもいいでしょう。「戦争のプロは兵站を語り、戦争の素人は戦略を語る」という名言もあるくらいで
SRE所属の @siroken3 です。最近はもっぱらパートナー会社様とのデータ連携環境構築を主に、時々プロダクションのMySQL環境と分析基盤との連携インフラの構築が多いです。 本記事は、メルカリに出品された過去すべての商品をBigQueryへ同期するにあたって取り組んだ時のお話です。 背景 当社では分析目的などでBigQueryを以前から使用しており、プロダクションのMySQLからBigQueryへデータを同期して分析に活用してきました。特に商品を表すテーブルは重要です。 しかし、後述する課題によりBigQueryにアップロードすることができなかったため、分析用のMySQLDBのスレーブとBigQueryを併用せざるを得ませんでした。とはいえ不便なので以前からBigQueryのみで商品テーブルも分析対象としたい要望がありました。 課題 メルカリでは販売済み商品を物理削除していないため、
はじめまして。アプリケーションエンジニアの中野です。 以前、MicroAdのデータ基盤の記事で紹介されていましたが、マイクロアドではデータ基盤刷新のタイミングでワークフロー管理ツールのDigdagを採用しました。 今回の記事では、Digdag採用の経緯やワークフローを作成する際に注意した点を紹介します。 Digdag採用の経緯 マイクロアドのDSP*1であるBLADEではBidRequestやImpression*2、Click、Conversion*3、その他BLADEから出力される様々なログやマイクロアドの他のプロダクトのログ、他社から提供されるデータなど、様々なデータを広告配信最適化の分析に活かしています。 これらのログを分析するバッチ処理は各々のジョブが複雑な依存関係を持っています。 これまではcronやJenkinsを用いてこれらの処理を行っていましたが コード管理が出来ていない
Digdagとは ワークフローエンジンと呼ばれるもので、データ分析基盤を構築する際に、Shell ScriptでPythonバッチを順に流しているような場合に、実行順序をyamlで定義できます。 serverモードというものがあって、複数ホストによる分散コンピューティングもできるので、場合によってはCeleryを導入しなくても、すべてDigdagで済ますこともできるのではないかと思い、調査を始めました。 ハマりポイント Language API - Python を使うに当たって、Pythonエンジニアが事前に知っておいた方がよいこと。 1.digdagのPythonパッケージはどこで配布されているか 次のサンプルを見てみましょう。 import digdag class MyWorkflow(object): def step1(self): digdag.env.store({'my_
Mercari Advent Calendar 2017 の9日目はメルカリ SRE(Site Reliability Engineering) チームの @syu_cream がお送りします。 メルカリでは様々なデータを BigQuery に格納して、データ利用を可能にしています。 BigQuery に格納しているデータの具体例としては、 Web サーバや API サーバのアクセスログやアプリケーションのログ、 以前当ブログで紹介した Pascal のイベントログ などが挙げられます。 メルカリのデータ分析基盤に関する情報はこれまでに以下のようなブログやスライドで紹介しております。 Pascal〜Puree + ngx_lua + Fluentd + BigQueryでつくるメルカリのログ分析基盤〜 fluent-agent-hydraで省エネログ転送 メルカリのデータ分析基盤 / me
この記事はVASILY DEVELOPERS BLOGにも同じ内容で投稿しています。よろしければ他の記事もご覧ください。 こんにちは、バックエンドエンジニアの塩崎です。 さて、VASILYではData WarehouseとしてGoogle BigQuery(BigQuery)を利用しています。 BigQuery内にはプロダクトのマスタデータとユーザーの行動ログが格納されています。 そして、それらに対する横断的なクエリを発行することでプロダクトの成長のためのKPIをモニタリングしています。 そのためAmazon Relational Database Service(RDS)に保存されているマスタデータをBigQueryに同期する処理を定期的に実行する必要があります。 先日、ワークフローエンジンであるDigdagとバルクデータローダーであるEmbulkを利用して、この処理を行うシステムを構築
S3にあるファイルを加工したり中間結果のファイルを保存したりTreasureDataに格納するような処理を書いていったときに発生したエラーメモ。 digdag version 0.9.24 github.com サーバーモードでdownload_fileオプションが使えない プロジェクトディレクトリ内にダウンロードしたはずのファイルが次のタスクで消え去った ファイルに保存せずにスクリプトを書いてDigdag.envを使ってクエリ結果を変数に保持させて対応 別の方法も(参考 digdagのtd>のdownload_file) プロジェクト外のディレクトリを参照できない SQLファイル動的に生成してtdオペレータに渡すようなタスクを作った 生成したファイルをプロジェクトディレクトリに保存するようにしたが次のタスクでNo such file or directoryになり参照できず(ローカルモー
はじめに この記事はMicroAd Advent Calendar 2017の1日目の記事です。 Digdagはジョブをコンテナで実行する事ができ、スケールが容易なワークフローエンジンです。 本エントリではそんなDigdagサーバ自体もコンテナで動かしながらジョブもコンテナで動かす際の設定やハマり所を紹介します。 使用ソフトウェアとバージョン digdag: 0.9.21 docker: 1.12.6 全体像 先にどんな感じの構成を実現しようとしているか、全体像を図示します。 _export: docker: image: python:3 +-------------+ | | | | +---+----+ +----v---+ | | | | docker run | digdag | | python | +---------> server | | (job) | | | | |
2月19日に開催された PLAZMA: TD Tech Talk 2018 Internal Day で、Treasure Dataがユーザに提供している機械学習・自然言語処理の機能の実体をお話しました。 録画もあがっているようです: PLAZMA TD Internal Day: TD Tech Talk 2018 - YouTube 「業務またはプライベートで機械学習に触れている方」という問いに対して聴衆の半数以上が手を挙げたのには正直驚きました。エンジニアリングとサイエンスの垣根が低くなっているというのは、大変喜ばしいことだと思います。 そんな聴衆の皆様は、まさか2018年に、機械学習に関するトークでロジスティック回帰とTF-IDFの話だけ聞かされるとは思っていなかったことでしょう。 わかりますよ。僕だってもっとゴツい手法をドーンと実装してバーンッって感じの結果を見せてドヤりたい。
DatabricksとSparkではじめる [ビッグデータETL処理/データ可視化] 実践入門 / Databricks and Spark with ETL and Visualization
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く