※ こちらはミツモアAdvent Calendar 2021の16日目の記事です。 こんにちは ミツモアのエンジニアの渡辺（@takumawatanabe-0920）です。 ミツモアは「リモートワークが増えてエアコンを綺麗にしたい」「引っ越しで出た不用品を回収してもらいたい」といった生活のあらゆるシーンであなたにぴったりの専門家を無料で探せるサービスですので、ぜひ気軽に使ってみてください！ meetsmore.com 今回は、ターミナル環境があまりに無機質で使いづらかったので、bashからZshに乗り換え、Zshのプラグインマネージャーであるzinitを導入することに決めました。 プラスアルファとして、Zshのおすすめプラグインやおすすめのiterm2の設定を紹介したいと思います。 現在のターミナル環境が以下のようになっております。 themeを特に入れてないので、フォントやターミナルの背

AirbyteでBigQueryにデータ移送 データ分析チームを立ち上げ, データ分析から基盤整備まで取り組むハイボール大好きエンジニアです。 社内のデータ基盤刷新の際にAirbyteを導入したので、こちらでまとめようと思います。 Airbyteとは何か 公式サイト: https://airbyte.com/ OSSのELTツール。有料版もあるが、無料版でもGUIが使え様々なデータソースと接続できる十分な機能が備わっている。 ※AirbyteはDBTと連携しておりETLツールとしても機能できるが今回は、独自のDBTとの接続は行わずデフォルトを使用する。 Airbyteを試してみる 実行環境: airbyte version 0.4.21 こちらにもある通り上のコードを実行することで、airbyteを始めることができる。 docker-composeを実行してからしばらくして上のログが出たら

こんにちは。今回は、データ基盤の構築の一部を実際に体験してみたいと思います。 データ基盤を作成するにあたり、まずは、社内に眠る様々なデータを集めてくる必要があります。 前回の記事では、その機能を「収集」と紹介していました。 データ基盤とは何か？ 収集・変換・統制の3つの構成要素に分けて解説 本記事では、データ基盤の収集機能をOSSで構築し、実際に体験してみたいと思います。 これからデータ基盤を開発していく方に、少しでもお役に立てたら幸いです。 データ連携に必要なELTについて データ抽出機能に特化したAirbyteについて ELに必要な環境のセットアップ Airbyteのセットアップ PostgreSQLのセットアップ BigQuery のデータセットの作成 Airbyte上での設定 AirbtyeによるELの実行 まとめ データ連携に必要なELTについて 収集機能を構築していくあたり、大

Airbyteとは OSSのETLツールでGUIも提供している。 データ取得元はMySQL、Salesforce、Marketo、Google Analyticsなど デフォルトである程度のコネクタが用意されている。 データ配置先もBigqueryやsnowfrakeなどのクラウドDWH系にも接続も可能。 有償版も存在する。 特徴 ツール自体が、dockerのコンテナとして稼働する。 未対応のコネクタなどは、カスタムコネクタとして自ら作成可能。 コネクタはすべて個別のdockerコンテナとして取り扱われる。 ETLの流れ Extract(抽出)→Load(読込)→Transform(変換)の流れ。 データ配置先の形式に合わせるためのデータ変換は最後に実施する。 コネクタ種類 以下にデフォルトで対応。 結構豊富。 データ取得元コネクタ ​Amazon Seller Partner​ ​Amp

この記事は 一休.com アドベントカレンダー 2017 の 13 日目です。 一休データサイエンス部の id:kitsuyui です。データエンジニア兼データサイエンティストをやっています。 この記事はもともとアドベントカレンダー上では「脱・神 Excel (仮)」という名前で枠で取っていたのですが、 少し主語が大きすぎたかな？と反省しています。 書いているうちに全く主旨が変わってきましたので、副題とさせていただきました。 今回は一休社内でのデータエンジニアリングにまつわる負担、それらを解決する Redash, Embulk, DatabaseMEMO の導入の流れを書こうと思います。 また、その過程で副次的に発生した FLOSS へのコントリビューションなどなどについては、 14 日目のエントリで説明したいと思います。 一休とデータ活用 一休は今日まで上質な宿・レストランの予約サービス

Airflowを導入するとcronのバッチ処理でエラーが起きてログファイルを漁った結果、Log出力が甘くて原因特定できないぐぬぬぬぬもうやだまじつらい、みたいなことが仕組みで防げるようになります。 Airflowってご存知でしょうか？ Airbnb社がオープンソースで公開しているデータパイプラインのスケジュールとモニタリングツールです。簡単に言うとジョブツリーを構築できる高機能なcron。Python2系で開発されていてpip install可能なオープンソースのソフトウェアです。AWSが年1で開催している大規模イベントre:Invent 2015で複数の会社がAirflowを利用していると発表し注目を集めました。Yahooの発表を読んで興味を持ちました。この記事はAirflowをプロジェクトに導入すべきか検討、検証したメモです。 ■ プロジェクトの解析タスクをAirflowに乗せてみた

データ分析をしている人にとっては，データのクオリティを日々モニタリングするのは頭痛の種です．最近のシリコンバレーでは，Data Engineer とは別に Data Quality Engineer というポジションで募集をしている企業もたまに見かけます．それぐらいデータの「質」には，気を配る必要がありリソースが掛かる分野といえるでしょう．とは言え，専任のポジションを設けるのはなかなか難しいので，それでもできるだけ簡単にモニターリングしたいです． Airflow と Slack を組み合わせることで，データのクリティを日々モニタリングすることができます．データエンジニアリングにユニットテスト的な概念を持ち込めないかと模索してきましたが，Airflow + Slack は個人的には一つの理想形と言えます． Apache Airflow とは？ Apache Airflow は，プログラムでジ

概要 こんにちは。クラウドワークス SREチームの@kangaechuです。最近好きなラジオ番組は空気階段の踊り場です。 企業にとってデータは非常に重要です。さまざまなデータを組み合わせて分析を行うことにより、ユーザをより深く知ることができ、それによりサービスやビジネスモデルを継続的に変革することが可能になります。 クラウドワークスでも同様に、施策やマーケティング、新サービスの開発など、さまざまな取り組みの源泉としてデータを活用しています。 crowdworks.jpではマスタデータベースにAWS RDSで稼働するMySQLを使用し、分析系のデータベースにはAmazon Redshiftを使用しています。Redshiftに同期されたテーブルは約270テーブル、レコードにして約30億件あり、1か月に1.5億件のレコードが同期されています。 今回はMySQLからRedshiftへの同期の仕組み

前置き 本記事では、Googleスタイル形式でのPython Docstringの書き方について必要最低限に絞って説明する。 これから、Python Docstringを覚えようとしているエンジニアの参考になれば、幸いである。 Python Docstringとは Pythonにおけるクラスや、メソッド(関数)についての説明を記載したコメント文のこと。 Docstringは、__doc__という変数に格納されている。 以下は、printメソッドのDocstringを表示させたもの。 >>> print(print.__doc__) print(value, ..., sep=' ', end='\n', file=sys.stdout, flush=False) Prints the values to a stream, or to sys.stdout by default. Opti

このところAirflowについて公式資料を読んできた中で、重要概念としてしばしば登場した各種の日付概念をおさらいしておきます。 データ区間（data interval） ワークフロー（DAG）の実行中に処理対象となるデータの区間（期間）。 バッチ処理の対象となるデータを特定するための情報。 開始日時（data_interval_start）と終了日時（data_interval_end）で示される。 例えば一日ごとに起動するワークフローならば、 「今回」2022-07-23 00:00:00に起動した回のデータ区間は 2022-07-22 00:00:00 から 2022-07-23 00:00:00、 次回のデータ区間は 2022-07-23 00:00:00 から 2022-07-24 00:00:00、 次次回のデータ区間は 2022-07-24 00:00:00 から 2022-0

はじめに Apache Airflow ハンズオンに続いて、The Complete Hands-On Introduction to Apache Airflow で理解を深める。本記事では、デフォルトで設定されている SQLite と SequentialExecutor での挙動を確認した後、それらを PostgreSQL と LocalExecutor に変更し、並列処理を試す。 デフォルト設定の確認 Apache Airflow では、初期化した段階でデフォルトの設定がなされている。設定は以下コマンドで確認できる。 $ airflow config get-value core sql_alchemy_conn sqlite:////home/airflow/airflow/airflow.db $ airflow config get-value core executor S

はじめに Gaiax Group Advent Calendar 2018の13日の記事です。ギリギリロスタイム以内なので13日目です。（すみません） 最近Djangoで開発したアプリケーションの中でジョブキューを使いたいシチュエーションがあったのでCeleryを用いて実現ししました。その際に学んだことについて備忘録的に記録しておきたいと思います。 django+Celeryの環境構築についてはいろんな記事があると思いますので、私が勘違いしたりなどして詰まった部分などを中心に共有します。 そもそもジョブキューとは ジョブキューとは読んで字のごとく、何かしらの処理（ジョブ）をキューと呼ばれる先入れ先出しのリストに登録して順番に処理していくものです。主にウェブアプリケーションなどで、例えばクロールやcsv吐き出しなどの実行に時間がかかる重い処理がユーザからリクエストされた際などに利用します。

Celeryはアプリケーションで非同期タスクを実行するためのフレームワーク メッセージを送受信するためにメッセージブローカーという別のサービスが必要になる メッセージブローカーにはRabbitMQやRedisなどがある 今回はRabbitMQを使う RabbitMQ # install $ brew install rabbitmq $ export PATH=$PATH:/usr/local/sbin # start $ rabbitmq-server Configuring logger redirection ## ## RabbitMQ 3.8.18 ## ## ########## Copyright (c) 2007-2021 VMware, Inc. or its affiliates. ###### ## ########## Licensed under the MPL

仕事でApache AirFlowを使う機会がありましたので、調査がてらに、Dockerで環境を構築し、簡単なジョブを定義します。 AirFlow AirFlowはジョブのスケジューリング・監視を、コード(主にPython)で定義・制御するためのプラットフォームです。ワークフロー、データフローの実装・運用に使われます。 github.com 類似のソフトウェアには、前回・前々回で紹介したLuigiや、Treasure DatasのDigDagなどがあります。 AirFlowではスケジューラも提供されているため、Luigiよりも広い範囲をカバーします ワークフローを、AirFlowではPython、DigDagでは.dagファイルで定義します Dockerで環境構築 ローカルに環境をインストールすることもできますが、Dockerでサクッと環境構築します。 以下のレポジトリからdocker-c

はじめに こんにちは。ジールの@________________-_です。 DAG実行タイミングのクセがスゴイんじゃ すいません。これが言いたかっただけです。 DAG実行タイミングをわかったつもりになっていたのですが、 改めてちゃんと理解しようと思い自分用にまとめました。 結論 DAG初回実行タイミングは、start_date以降直近のschedule_interval完了時点となる。 それ以降はschedule_intervalが完了する毎に実行される。 これだけだと全くわからないな。。。 詳細 DAG実行タイミングはstart_dateとschedule_intervalを利用して計算される。 start_date：DAG実行タイミングを計算するための基準となる時間 start_dateとschedule_intervalを組み合わせて初回実行タイミングが計算される schedule_

概要Airflow 利用にあたって知っておいたほうが良いんじゃないかなと思う情報をまとめました。いわゆるハマりどころです。 Airflow 自体の基本的な説明(用語,DAG 定義方法,etc..) は省略しています。 基礎参照先 公式 Tutorial Dockerfile バージョン Airflow 1.10.4 Postgres 10.7 Tips 11 選 1. 日時 2. リトライ 3. start_date の変更ができない 4. 開始日時を過去日時にすると過去ジョブが自動実行される 5. context の活用 6. Macros 7. Task 間で値を受け渡す方法 8. dags ディレクトリ以下のディレクトリの切り方 9. UI の表示が UTC 固定 10. Web UI 上からジョブのパラメータを渡せない 11. DAG/Task の同時実行数制御 1. 日時Airf

builderscon2018で発表した資料。

この記事は一休.com Advent Calenrad 2017の11日目です。 データサイエンス部小島です。 現在はレコメンドまわりを担当しています。 試験的に導入予定のETLツールAirflowについて書こうと思います。 Airflowについて 一言でいうと、高機能なcronです。 Pythonでかけて、タスクごとの依存関係を定義できます。 元々はAirbnbが独自で開発し、今はApacheのIncubetorのプロジェクトになっています。 一休のデータフローを考えてみる 一休ではセッションごとの情報を集約してまとめています。 そのデータをDWHに加工するまでの流れをまとめると以下のようになります。 上記のデータ処理を日次で行うようなものをAirflowで実装していきたいと思います。 環境の構築 今回は簡単にgithubに環境を公開してくれている方のをおかりしてセットアップしていきます

データ・アナリティクス事業本部の森脇です。 先日、Redshift用のコマンドラインインターフェースであるAmazon Redshift RSQLされました。 従来RedshiftのCLIツールと言えばpsqlが定番でしたが、とうとうRedshift用のツールがリリースされました！ 発表によると Amazon Redshift RSQL は、Amazon Redshift 固有の機能の追加セットを備えた PostgreSQL psql コマンドラインツールの機能をサポートしています。 とのことなので、psqlの機能が使えつつ拡張でRedshift固有機能にも対応しているようです。 これであればpsqlからの乗り換えも容易そうです。 早速Amazon Linux2にインストールして試してみました。 インストール ユーザーズガイドを参照すると、まずはODBC関連ツールをインストール/設定する必

Amazon Redshiftで複数クエリを投げる時にめちゃくちゃ苦労したので、まとめてみる。 利用環境はMacです。 前回の記事に引き続いて検証しました〜！ 【背景】 Athenaで複数のクエリを投げてみました（こちらご参照ください）が、Redshiftも同じ感じで出来そう？ 出来るなら検証しちゃった方がいいしやってみよう！！ こんな課題感で手を動かし始めました。 【実際にやったこと/考えていたこと】 cliからクエリ投げられる方法を探す 全然見つからない💦 rubyのgemを使ってみる 何使ったらいけるのかわかりにくい！！ 英語のドキュメントでわかりにくい！！ 結局二つ目のgemで複数クエリ投げることができましたので、詰まった一つ目と一緒にまとめていきたいと思います〜！ （会社の先輩にとても助けていただきました🙇‍♂️） cliからクエリを投げられる方法を探す 公式ドキュメントを参

このハンズオンについて このハンズオンでは、Redshiftのクラスターとそのクラスタに対してクエリを発行するインスタンスの作成を実施します。 クエリの発行には、「psql」を利用します。本手順では、Amazon Linux上へのインストールと利用方法を説明します。 前提条件 バージョン確認 このハンズオンは以下のバージョンで動作確認を行いました。

こんにちは。 DSOC R&D グループの高橋寛治です。 あるプロジェクトにおいて、 「DB からデータを取得し整形した結果を出力する」という一連の処理をパイプラインパッケージである Luigi を用いて行いました。 ワークフローの監視や記述が簡単に記述できて良かった*1と感じたため、ここで流れを紹介したいと思います。 Luigi Luigi は Spotify が開発・運用しているオープンソースの Python のワークフローパッケージです。 pip install luigi で簡単に導入できます。 Luigi は単独で動作させたり、スケジューラによりスケジューリングや依存関係の可視化、タスク履歴を閲覧することができます。 ワークフローはタスクから構成されます。 ざっくり説明すると、一つのタスクは一つのクラスで表現されます。 クラスは Luigi が準備しているクラスを継承し、必要な実

データプラットフォームグループの野本です。主に機械学習基盤の構築やそれにまつわるアプリケーションの開発をしています。 以前までの記事で現在 Kubernetes を利用して機械学習基盤の構築を進めているという紹介をしましたが、機械学習システムに付きものだと思われるワークフローのジョブ管理に Argo という Kubernetes 上で動作するワークフローエンジンを導入し使いはじめまてみました。まだ色々試している段階でもあるのですが現状でどんな感じで使っているのか紹介してみようと思います。 ワークフローエンジンの選定に関して 現在機械学習基盤では先に紹介した以前の記事 や マルチコンテナ構成による機械学習アルゴリズムとアプリケーションの疎結合化 のような形で機械学習システムの構築を進めています。特に後者の具体例のように各アプリケーションを疎結合にうまく動かせるように出来るのが理想です。 これ

「DigDag」はTreasure Data製のワークフローエンジンのOSSです。ワークフローエンジンを使うことでバッチ処理の依存関係を明確に定義できたり、ジョブの管理をしやすくなります。また、Dockerと組み合わせることで、言語や環境を自由に選ぶことができます。 🤔 紹介スライド2017/6/9に発表したDigdagの紹介LTのスライドです。Web画面からタスクの実行状況がわかったり、再実行ができたりするのは便利です！ 🚕 Digdagの特徴 手動で行っている操作をYAML(.dig) で「ワークフロー」に書いて定義できます 依存関係のある複数のタスクを管理・実行しやすくするためのしくみです タスクが失敗した場合、時間内にワークフローが終了しない場合の通知を行うことができます PostgreSQLだけを維持すればDigdagサーバはいつでも立てたり落としたりできる本番環境に優しい設

1. Modern businesses are eager to utilize data science and ML​In the past, data scientists and ML engineers had to rely on a medley of point solutions and custom systems to build ML and data science applications. 2. What is common in DS/ML applications?​Applications can be built quicker and more robustly if they stand on a common, human-friendly foundation. But what should the foundation cover? 3.

この記事はBrainpad Advent Calendar 2018の1６日目の記事です。 はじめに こんにちは。BrainPadでエンジニアをしている高橋です。 今年4月にBrainPadに中途入社して自社サービスの開発をしています。 現在開発中の機能のワークフロー管理にCloud Composerを採用しているため、ここ３ヶ月はAirflowのOperatorに触れてきました。その中で利用したOperatorの一部について今回は書きたいと思います。 Cloud Composer(Airflow)について まずCloud Composerについて説明します。 Cloud ComposerはGCP(Google Cloud Platform)が提供するマネージドなAirflowです。 Airflowの詳細については今回省略しますが、簡単に言うとワークフローを管理するOSSです。 Cloud

こんにちは、みかみです。 Python で実装されている Job 管理ツール Apache Airflow。 WebUI のJob 管理画面で直感的に分かりやすい操作が可能で、エラー発生時などの通知機能もあり、スケールアウトにも対応していて複数サーバで分散実行もできます。 Python でバッチ Job 開発経験のある方には多分おなじみの Airflow、私も存在は知っていましたが、実際使ったことはありませんでした。 やりたいこと Airflow の構成（アーキテクチャ）を知りたい Airflow の使い方（Job 作成＆実行方法）を知りたい Airflow のアーキテクチャ Airflowは、 管理画面表示部の Webserver と、Job実行のスケジュール管理部の Scheduler 、Job実行部の Worker(Executer) から成り立っているようです。 各モジュールは管理

この記事は一休.comアドベントカレンダー2017の20日目です。 データサイエンス部所属のエンジニア 笹島 id:sisijumi です。 今日はクラウド環境へのデータ分析基盤構築にまつわるお話をさせていただこうと思っています。 データ分析基盤の構築に関して 夏にデータ分析基盤を Azure SQL Data Warehouse を中心にした構成で構築 構築はしましたが、残念ながらこの構成での運用には至りませんでした。 一休では元々社内にデータ分析基盤を構築し運用していましたが、運用負荷の増大に伴いその基盤のクラウド環境への移行を進めました。 下記は今年の8月のあるイベントでの発表資料ですが、イベントではデータ分析基盤は Azure SQL Data Warehouse を中心としたものに と話しさせていただきましたが、現状そうはなっていません。 二度の作り直し 実は上記は二度目のチャレ

有向非巡回グラフ（Directed Acyclic Graph: DAG）とは、閉路のない有向グラフのことである。サイクルが存在しないため、ある頂点から同じ頂点に戻ってこれないという特徴がある。 有向非巡回グラフは要素の因果関係や物事の依存関係をモデル化するのに有効である。例えばあるタスクを行う前に別のタスクを完了させておく必要がある場合、タスクを頂点、順序の制約を有向辺とみなすと、各タスクの依存関係を有向非巡回グラフで表現することができる。また後述するトポロジカルソートを使用することで、制約条件に従ってタスクを完了させるための適当な順序を得ることができる。ただしジャンケンのグー・チョキ・パーのように依存関係（強さの順序）がサイクルを形成するような場合、巡回グラフとなるため順序付け（トポロジカルソート）を行うことはできない。 トポロジカルソート（Topological sort）は、有向非

背景 お題 技術の差別化 差別化から分かること 情報資産からToBeを考える 俯瞰的・相対的な技術選定 これまでの話から学んだこと 最後に はじめまして、MonotaROでデータエンジニアをやっています、芝本です。 エンジニアのみなさん、技術を使って何か作ってみるのって楽しいですよね。 私は、公私ともに日々物作りに励んでいます。プライベートだと、最近はマイクロフロントエンドについて学んでいます。 技術を使うためには、技術を学ばなければいけません。 プライベートにおいては、好奇心に従って自由に学びますよね。 とりあえずgit cloneして動かしてみたり、書籍を購入して読んでみたりします。 というようにプライベートでは主に次のような選択肢があると思います。 書籍を読んで好きなものを選ぶ 実際に手を動かしてみて好きなものを選ぶ 人に教えてもらって好きなものを選ぶ 基本的にプライベートの場合は何

2023年1月20日 Harajuku.ts Meetup 〜 Recoilの事例集めました〜 にて発表した資料です。

Harajuku.ts Meetup 〜 Recoilの事例集めました〜

現職のコンサルっぽい仕事・インフラアーキなエンジニアな仕事も大好きですが, やっぱデータを見ると興奮するぐらいにデータ好きな人です. startpython.connpass.com 本日（2023/1/19）, ありがたいご縁がありまして, 「機械学習エンジニアが目指すキャリアパスとその実話」というお話をさせていただきました. 参加者の方々, ご清聴ありがとうございました&参加されていない方も気になるポイントあればぜひ御覧ください. 1/19の #stapy で「機械学習エンジニアが目指すキャリアパスとその実話」なるトークをすることになりました, 自画自賛ですが思ったよりいい内容に仕上がった気がします, 機械学習とかデータサイエンティストとかのキャリアでお悩みの方に届くと嬉しいです, 来てねhttps://t.co/KHxAXYY5mr pic.twitter.com/eguUyEnfb

有限会社安井ファーム @yasuifarm Q. ブロッコリーの揚げ物でオススメのレシピはありますか？ A. めんつゆに一晩漬けたブロッコリーに片栗粉をまぶし、中温の油でカラッとするまで揚げると、スナック感覚で無限にブロッコリーをキメられるようになるのでオススメです。 pic.twitter.com/4N3ryBBX5U

このブログは、どこにでもある材料で、誰にでもできる料理を載せています。 ◆大さじ１杯の生クリーム、卵黄５個分などの「残りどうすんねん」という使い方 ◆ローリエ、バルサミコ酢、ワインビネガー、バーニングマンダラー、備中ぐわ、千歯こき・・・ などオシャレな調味料や必殺技、農具は使いません。 どうぞゆっくりしていってください。軽い気持ちで。足をくずして。みんなでバナナになって。 これめっちゃオススメです！！ ブロッコリーをクタクタに煮て潰してソースにした、イタリアのプーリア地方のパスタが好きなんで、それを真似して作ってみました。プーリア地方では食べたことないけど。（詐欺師か）←そこまで言われなあかんか ブロッコリーは昆布だしと同じうまみ成分のグルタミン酸が多く含まれていて、茎からもゆで汁に旨味がめっちゃ出るんで、調味料が主に塩だけとは思えないぐらい美味しくしあがります。 まあ 正直にんにくの力が

40歳で子供ができた。 私にそっくりな顔のその子は、もう4歳になって幼稚園に通っている。 毎日楽しそうに友達と走り回っている。何がそんなに楽しいのか。 子育てをしていると、嫌でも昔の自分が思い返されてしまう。 幼稚園。なぜだろう、先生の声は私の耳には届いてこないことが多かった。 みんながわいわい遊びはじめても、私の世界はよく半径1mほどに縮まる。 足元への焦点はよく合った。 ひとり無表情で考えていたことは、「自分に子供ができたら、うん子と名づけていじめてやろう。」だった。 学校が嫌だった。 ひとりぼっちの休み時間は、早く終われと数を数えて、長すぎる地獄のような時間をやり過ごした。 学年が変わるたび、なんとか黒い内面を隠し「普通の子」に擬態して、周りに溶け込めないかと期待したが、いつも失敗した。 私の母親は明るく楽しい人だった。 平日は遅くまで仕事をしていたが、休みの日には色んなところへ連れ

はじめに データ分析をするにあたって、データ収集、加工、蓄積をするための基盤をGCPを使用して構築しました。 自分がやったことの記録として記事にまとめます。 前提 スクレイピングをされる際は自己責任にてお願い致します。 GCPに課金される可能性があります。 PCはmacを使用しています。 Google Cloud SDKが使用できる必要があります。 まだの方はGoogle Cloud SDKのインストールを実行して、パスを通しておきましょう。 全体像 以下に実装するアーキテクチャの全体像を示します。 上の図に示すような基盤を構築しました。 以下にざっくりとしたデータの流れを示します。 1. Compute EngineからPythonでスクレイピングを実施し、カーセンサーからデータを取得します。 2. 取得したデータをCloud Storageに格納します。 3. Cloud Storag

ビットキーでアナリティクスエンジニアをしている三河内です 2022年時点では以下のような業務を担当しています（アナリティクスエンジニアについての詳細はこちら） 今回は注力領域であるDWH構築において、2022年10月から取り組んできたdbtの導入について、その 導入背景や実際に使ってみた中でのメリットを紹介します！ 想定読者 データ分析基盤の構築 や データのパイプライン整備をしたいな と考えている方 データ分析基盤のデータを用いて分析しているデータアナリスト/サイエンティストの方 dbt(data build tool)の導入を検討している方 ちなみにdbtって何？については「Data Engineering Study 第13回」でとてもわかりやすく紹介されているので、ご参照ください！ TL;DR dbt導入以前のデータ分析基盤には、データ生成と開発体験の面で課題があった dbtでデー

AWSのサービスを活用したビッグデータ分析基盤 今日、様々なサービスで大量のデータが発生し、それを分析するニーズが出てきています。 その中で、ビッグデータ分析基盤としてAWSの各サービスを組み合わせる例が増えてきています。 ここでは下記の流れでどうやって分析基盤を構成するかを考えてみます。 IoTのデータや、サービスのログなどをKinesis FirehoseでS3に保存（前段としてAWS IoTがあったり、サービス自体が出しているログがあったり、など） ↓ AWS Glueでカタログ（Athenaで分析するためのテーブルのようなもの）作成 ↓ Athenaでクエリを投入、分析 （さらに、QuickSightで可視化など） サービスの追加やアップデートなどで今後もっと組み合わせやすくなる可能性はあります。 それぞれの設定の仕方 Kinesis Firehoseの設定 クラスメソッドのブログ

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA) 本書では、分析システムのあるべき形として、「SQL中心アーキテクチャ」というものが提唱されている。 BigQueryを中心に据えたデータ基盤を作りたいと思っていたので、大変参考になった。 SQL中心アーキテクチャとは 1. 必要なデータを1つのデータベースに集める 2. データの加工には原則としてSQLだけを用いる 3. データベース内を論理的にソースデータ層・DWH層・アプリケーション層の3層に区分する SQL中心アーキテクチャの利点 企業のデータはほとんどRDBMSかHadoopにある RDBMSもHadoopも共通点としてSQLが使える サイズの制約がない データ量が数MBでも数PBでも制約なく使える BigQueryのような強力なデータベースの力を活かせる エンジニアとプラン

はじめに ラスベガスでAWSの最大規模のイベント「re:Invent2018」が絶賛行われているようですね。 ビッグデータ分析基盤のセッションでAWSリソースを用いた網羅的な解説してくれたものがあったらしく内容を簡単にまとめてみました。 Big Data Analytics Architectural Patterns and Best Practices 名前は知ってるけどユースケースよくわからんという自分にとっては嬉しい情報だったので、似たような人の手助けになればと思います。 ビッグデータ基盤の網羅的な技術候補 ビッグデータのアーキテクチャを考える上で 正しいツールを使えているか データの構成,レイテンシ,スループット,データへのアクセス形式によって最適なものを選ぶ必要がある マネージドやサーバーレスのサービスを効率よく使えているか コストを最適化できいるか 機械学習基盤が必要かどうか

BigQuery と Cloud DataFlow でデータ分析基盤を作る練習（準備編） のつづき 3. Cloud Dataflow を使って加工 前回 Java と Python 使わずに Scio 使うと書きましたが まずは練習のために Java と Python を使ってみました。 今回は Scio まで行きませんでした。 やりたいことは 素のデータが入っている BigQuery から、加工したデータを BigQuery にいれる です。 環境は Python 2.7.13 + Apache Beam 2.5.0 Java 1.8.0_25 + Apache Beam 2.4.0 ググっていると Cloud Dataflow 1系の記事が大量に引っかかるのでかなり苦労しました。 公式ドキュメントすら 1系がかなり引っかかってきます。 Apache Beam を頑張って読むのが一番よ

前提 本記事で想定するデータ分析基盤とは、「本番環境とは切り離された、集計・可視化・レポーティングのようなデータ集計・分析をするための基盤」を指します。 知見が更新された場合、随時情報を追加更新していきます。 モチベーション データ分析基盤構築プロジェクトについては情報が少ないので、現時点での知見をまとめておき、この記事を叩き台にさらに良い方法を模索していきたいです。 サマリー 利用用途（ユースケース）は、重要で集計できていないデータを使った集計・分析が出来る状態を提供するのが良いです。活用される可能性が大きくなります。 データ分析基盤を最初に導入するのなら、「BigQueryとCloud Composerの構成」がオススメです。 データの可視化のためのBIツールも最初に展開する場合は、無料かつ無制限アカウントで発行可能な「Google Data Portal」がオススメです。 テーブルの

この記事はdbt Advent Calendar 2022 4日目の記事になります。 はじめまして、日頃 dbt を用いてデータ分析基盤の開発をしている K と申します。 現在、株式会社ベーシック(以下、ベーシック)にて Analytics Engineer としてデータ分析基盤開発のお手伝いをしております。 データ分析基盤の開発には dbt Cloud(以下、dbt) を利用しており、今回は実際に dbt を用いてどんな風に実装しているかをご紹介できればと思います。 ※1:DWH には BigQuery を利用しています。 ※2:ご紹介する内容が、ベストプラクティスを保証するものではございません。 ※3:現在も絶賛開発中で、紹介する内容には一部実装予定のものも含まれております。 データ層の分け方 データ分析基盤開発において、データ層の分け方はとても重要な要素になります。 今回データ層の分

概要 データ分析基盤（概念モデル）におけるデータカタログに関する整理を実施します。 本記事にて、下記の記事におけるデータカタログの詳細を記載します。 最強のデータ分析基盤を目指して～汎用的なデータ分析基盤の選定方法の提案～ 定義 データカタログの定義 データモデルとData Integration and Interoperability（データ統合と相互運用性）のメタデータに関する、カタログの作成（定義・抽出・蓄積）、および、カタログの利用（探索・把握・共有・配信）によるデータガバナンス支援システム層。 コンポーネント詳細 番号 データ基盤におけるレイヤー コンポーネント名 説明 サービス例

概要 データ分析基盤（概念モデル）におけるサービスレイヤーに関する整理を実施します。 本記事にて、下記の記事におけるサービスレイヤーの詳細を記載します。 最強のデータ分析基盤を目指して～汎用的なデータ分析基盤の選定方法の提案～ 定義 サービスレイヤーの定義 データ活用を行う上で最適なクエリを発行できるようにデータを保持する層。 物理レイヤー（サービスレイヤー）の定義 物理的にデータを保持することで、最適なクエリを発行できるようにする層。 論理レイヤー（サービスレイヤー）の定義 論理的に構造化したデータモデルを保持することで、想定文脈内での意味を結びつけたクエリを発行できるようにする層。 コンポーネント詳細 番号 データ基盤におけるレイヤー コンポーネント名 説明 サービス例

要求要件 業務システム データ分析基盤での管理対象がであるため、特になし。 マスターデータ管理システム（MDM） データ分析基盤での管理対象がであるため、特になし。 ストレージサービス データ分析基盤での管理対象がであるため、特になし。 メッセージング データ分析基盤での管理対象がであるため、特になし。 データ仮想化サービス データ分析基盤での管理対象がであるため、特になし。 参考情報 業務システム 特になし。 マスターデータ管理システム（MDM） DAMAが下記のように定義しており、本概念モデルにおける認識と相違はあまりないです。 Master Data Management (MDM) Processes that control management of master data values to enable consistent, shared, contextual use

データパイプラインは、次々と受け渡されていくデータによって構成されるシステム。 データパイプライン全体の動作を管理するために、ワークフロー管理が用いられる。毎日決まった時間にバッチ処理をスケジュール実行したり、エラーが発生した場合に管理者に通知したり。 データ収集 データ取集方法 説明

はじめに 先回、ログ集約の文章を書いてからログ集約のお仕事を多く頂くようになり、ログを積極的にビジネスに活かす分析基盤構築の機会に恵まれました。それに伴い、いろいろなところで分析基盤にどのような技術を取り入れているか伺う機会が多くなりました。 分析基盤で利用されるツールの種類は多岐に渡り、企業様や事業の性格でいろいろ使い分けが出てきます。それなのに今回はそのような分析基盤の全体感を包括的に説明してしまう無謀な挑戦をしながら、私がおよそメジャーどころの分析基盤ツールを構築した際の使用感(と苦労話)を紹介したいと思います。 全体図 今回の記事で紹介する内容の構成イメージです。AWSとGCPのマルチクラウド、クロスプラットフォームの図になっています。AWSは極力クロスプラットフォームで環境を構築せずにAWSだけで囲い込みたい方針のようですが、世の中はクロスプラットフォームの流れに向いていくと思い

はじめに CYBIRDエンジニア Advent Calendar 2016、今年も16日目担当の@yuichi_komatsuです。 データ分析のエンジニアをしています。 一緒に精進できる仲間も絶賛募集中です！ 興味がある方はこちら！！ 昨日は@sakamoto_kojiさんの「サブスクリプションのサーバサイド開発で得た知見」でした。 まさに現場で奮闘してきたからこその実用的で貴重なTipsですね！ すばらしい！！ では本題です。 今回のネタ 去年は「embulkとBigQueryが黄金コンビすぎる話」を書きましたが（こちらはコメントを記載する際に誤って削除してしまいました・・・すみません）、 そこに新戦力である Digdagでワークフローを組むことによってembulk、BigQueryコンビが一段とパワーアップする！ という話です。 Digdagとは？ 穴掘りゲームではありません。 世界

データ分析基盤の調査及びまとめ データ分析基盤を構築するのに紆余曲折あったので、まとめていく Part.1ではOSSツール用いて開発したが、途中で開発を中断した事について書く Part.2では構築した際に用いたツールについて記載予定 背景 分析基盤が存在していなく、データ分析やAIの開発はローカル環境で実施しており、作業が非効率となっていた 目的 データ分析基盤を作る事で作業のスピードを上げ、DX推進を図る 構成図 ざっくりとした構成図は以下の図の通り データレイク・DWH・データマートの3層構造でデータ活用を予定 データ分析基盤を構築する上で、以下3点を調査・検討する必要がある ①：クラウド(DWH)の選定 ②：ETLツールの選定 ③：ワークフローの選定 調査 DWHの選定 (AWS or GCP どっちなのか？) 分析の要となるDWHを決める必要がある 様々な記事を見る限りどうやらRe

データ基盤はサービスにあるすべてのデータを集めて、分析できるようにする基盤です。 例えば、Mysql、Postgresqlにあるようなマスターデータだったり、Nginxのアクセスログだったり、Google Speadsheetにあるデータとか、 SalesForceにあるデータを集めて、中間テーブルを作ったり、Tableauで可視化するためのデータを作ることがあります。 ワークフローエンジンとしてはいろんな候補がありますが、現職の会社の要件に合ったワークフローを選定したいです。 要件 私は２年間データ分析基盤のワークフローをDigdagで安定運用していたので、 そのノウハウから安定稼働するために必要な要件を下の表にまとめて、各ワークフローエンジンを調べました。 要件 Digdag Airflow Luigi Perfect Argo

EMBULKとDIGDAGの話がしたくて仕方がないんですけど、うちの会社でDIGDAGとかEMBULK知ってる人が全くいなくてここに残します。 サーバー　→　Bigquery　→　Mysql　→　SQL Server　の流れでデーターを毎日ロードするシステムを作ってます。 SQLServerの後もバッチプロシージャで集計したり色々大変な作業が待ってるんですけど、それはDBAがやってくれるとして…　その前のETLだけを自分がやってます。 Bigqueryは普通こんなETLの流れの最後の部分に位置するんですけど、うちの会社のいろんな事情で…BigqueryからRDBMSへのフローを作らなくちゃならなくなったんです。 Bigqueryからのダウンロードはembulkでやってますけど、思ったより大変でした。 最初はembulk-input-bigqueryとembulk-output-mssqlと

この記事は BrainPad Advent Calendar2021 18日目の記事となります。 プロダクトビジネス本部、開発部の吉田です。 データ処理パイプラインとしてよく名前が挙がるワークフローエンジンを紹介します。 近年、ワークフローエンジンの利用は 業務システムではバッチの依存関係の解消のため MLops と呼ばれる分野でデータ処理、モデル更新に 様々なシーンで活躍しており、広がっている印象です。 ここでは、ワークフローエンジンの紹介を行っていきたいと思います。 データ処理パイプライン｜ワークフローエンジン 本稿では、ワークフローエンジンの紹介を行いますが、一番良いのは利用シーンから様々なワークフローエンジンの良し悪しを出していくことが望ましいと思います。 近年、ワークフローエンジンも多く増えてきており、開発のしやすさ、コードの書きやすさ、利便性（ワークフロー内部にサブセットのワー

先日ラスベガスで開催されたre:Inventに参加し、その際にデータ分析基盤系のセッションはほぼ参加したのですが、Job管理ツールの話がかなり出ていたのが印象的でした。 AWSにはData PipelineというJob管理サービスがあるのですが、それではなくOSSのJob管理ツールを使っているところが多い印象でした。 日本では自分の観測範囲だとまだ使っているところがあまり多くない印象ですが(実際自分もほとんど使ったことない)、いくつか候補を絞って触って見たので感想を書きます。 あくまでJenkinsしか使ったことがないような個人の感想としてお読みください。。 Airflow Airbnbが開発元 re:Inventでは多くのセッションで紹介されており、一番勢いがある印象を受けた。 依存関係はPythonで書く タスクの登録はUIからやるのではなく、コマンドラインから登録 Python力を前

AWS Data Pipelineについて調べてみました。 AWS Data Pipeline（データの移動や変換を簡単に自動化）| AWS 概要 データの移動や変換を簡単に自動化 指定された間隔で、AWS のサービスやオンプレミスのデータソース間で信頼性の高いデータ処理やデータ移動を行うことを支援するウェブサービス 保存場所にあるお客様のデータに定期的にアクセス 必要なスケールのリソースで変換と処理を行い、その結果を Amazon S3、Amazon RDS、Amazon DynamoDB、Amazon EMR のような AWS サービスに効率的に転送 耐障害性があり、繰り返し可能で、高可用性を備えた、複雑なデータ処理ワークロードを簡単に作成 3行でまとめると、 というかんじでしょうか。 メリット 信頼性 使いやすさ 柔軟性 スケーラブル 低コスト 透過的 イメージ AWS Data P

※ このブログはヌーラバー Advent Calendar 2020 6日目の記事です。 こんにちは。インハウスシステム課の大塚です。「管理部」所属の社内エンジニアとして活動しています。 私達の大きなミッションは以下の二つです。 社内の業務プロセスの定義、改善、自動化という業務ハックを推し進める 社内のデータ分析、活用、及びデータマネジメントを推し進める この活動は企業が成長していく上でとても重要ですが、残念ながら大きくリソースを割り当てることはできません。 私達は小さなチームの限られたリソースでこのミッションを達成するため、AWSサービスをどのように選定して、活用していくかについて、その方針を事例と合わせながら書きたいと思います。 TL;DR 社内エンジニアがAWSサービスをマネージドなサービスを導入する理由 企業の成長で課題は増えていく 目的達成のために注力する Airflowを運用し

Apache AirflowのマネージドワークフローによるAWS DatabricksのワークロードのオーケストレーションAWSairflowDatabricks 本書では、Databricksの強力なjobs APIとAmazonマネージドApache Airflow(MWAA)をどのように活用するのか、有効非巡回グラフ(DAG)をモニタリングするためにどのようにCloudWatchとDatabricksベースのタスクを連携させるのかを説明します。さらに、DAGのパフォーマンスメトリクスに基づくアラートの作成方法も説明します。 Databricksにおけるオーケストレーションおよびアラート Databricksにおけるジョブオーケストレーションは完全にインテグレーションされた機能です。お客様はジョブのAPIとUIを用いて、ジョブやモニタリングのためのメールアラートのような機能を活用、管理

サービス比較各サービス別に、Good/Challenge に分けて記載しています。 GoodMWAA Pythonで実現できることは基本すべて実装可能で、実装の制約が少ない UI が充実しており、実行履歴、ログ、実行時間等の様々な情報を参照することが可能 UI 上でワークフローの任意の位置からリトライ可能 各種クラウドSDK/OSS API を呼び出しを簡易化するための provider がサードパーティ提供されている Providers packages reference — apache-airflow-providers Documentation provider を pip でインストール後、各 provider に実装されている operator 関数を呼び出すことで実現可能 Step Functions AWS サービスの呼び出しをローコード(パラメータ指定程度)で実現可能

Google Cloud Composerのリリース（2018年7月19日GA）から遅れること2年数ヶ月、AWSは2020年11月24日に Managed Workflows for Apache Airflow (MWAA) をリリースした。 Introducing Amazon Managed Workflows for Apache Airflow (MWAA) それから1年、遅ればせながら自分でも軽く試してみた。AWSコンソールからAirflow UIに飛ぶのに違和感を覚えつつも1、種々のAWSサービスとの連携を考えると「むしろなんで今まで無かったんだろう」という気さえする。 概要 公式のデモ動画が分かりやすいので、まずはそれを見てみよう。 ポイントは次の通り。 DAGファイル（Pythonコード）は専用のS3バケットに置く OSSのAirflowに完全準拠 （事前に設定した上限値

<2023年12月19日追記> 本記事中に「①失敗したジョブから再実行が出来ない」という課題の記載がありますが、現時点で解消されています。詳しくは、「AWS Step Functions 待望の『リドライブ』機能がGAされました | TECH | NRI Digital」の記事をご参照ください。 こんにちは、NRIデジタルの島です。 AWSパブリッククラウド上でバッチジョブのワークフローを構築する際の選択肢はあまり多くありません。 弊社社内においても「JP1 ※1」や「Senju ※2」等のジョブ運用管理ツールを使ってAWSサービスと連携している事例が多いと思っております。 AWSサービスでは「Amazon Managed Workflows for Apache Airflow (MWAA)」や「AWS Step Functions（以下Step Functions」、「AWS Glue

「ワークフローエンジン」を活用することで、コンピューターの定期的な作業などをワークフローで自動化できるため、業務の効率化に役立ちます。本記事では、ワークフローエンジンの特徴や、代表的なワークフローエンジンについて解説します。 ワークフローエンジンとは 「ワークフローエンジン」とは、コンピューターの作業プロセスを自動で管理するソフトウェアです。これまで手動で行っていた業務プロセスの自動化・高速化を目的としており、ビジネスで活用される「ワークフローシステム」と同様に、申請・承認業務のプロセスを管理する働きをします。 ワークフローエンジンを使わずとも、タスクを決められた日時に行う場合にLinuxを使用する方法もありますが、これだとタスクが失敗したときにカバーできません。また、タスクの成否を確認するために、担当者がファイルをチェックしたり、失敗時の調査用ログを調べたりといった手間も発生します。 ワ

はじめに マイクロアドでサーバサイドエンジニアをしている高橋です。 今までの技術ブログでも記事になっていますが、マイクロアドでは主にDigdagとPythonを用いてデータ処理バッチを開発しています。 developers.microad.co.jp developers.microad.co.jp developers.microad.co.jp 今回はバッチの並列実行数を制御する必要が生じた際のお話をします。 バッチの並列実行数を制御する必要があるとき 定期実行されているバッチは、基本的に次の実行までに処理が完了するように実装されています。 毎時実行される場合は1時間以内に、毎日実行される場合は1日以内に処理が完了します1。 しかしながら、設計によってはある1つのバッチが並列実行されることもあります。例えば以下のような場合です。 不定期に実行され、1回1回時間をかけて処理するバッチ 他

はじめに こんにちは、yokatsukiです。 先日6月18日、第五回ゲームサーバ勉強会に参加してきました。 そこで、トレジャーデータのサポートエンジニアマネージャー高橋様から、直前の6月15日にオープンソース化されたばかりのDigdagの説明がありました。その時の発表スライドは下記です。 Digdagは弊社でも何名かが既に触ってブログで公開(下記)しているので、名前と目的は知ってましたが、説明とデモを見るうちに自分でも試してみたくなりました。 Embulk界隈で話題になっている分散ワークフローエンジン「DigDag」について調べてみた #digdag Treasure Data社のOSSワークフローエンジン『Digdag』を試してみた #digdag｜Developers.IO という訳で、簡単ではありますが共有します。 テーブル定義の無いTSVファイルをRedshiftへロードする 通

オープンソースの SQLAlchemy (sqlalchemy-redshift) と Apache Airflow フレームワークのネイティブサポートが Amazon Redshift で利用可能となりました。SQLAlchemy 向けの更新された Amazon Redshift ダイアレクトは、Amazon Redshift のオープンソース Python ドライバーをサポートします。このリリースでは、アイデンティティプロバイダー (IdP) でシングルサインオンを使用して Redshift クラスターに接続し、認証情報の管理の手間を省くことができます。SQLAlchemy および Apache Airflow の最新の Redshift ダイアレクトに移行する際の TIMESTAMPTZ および TIMETZ といったデータ型の使用など、Amazon Redshift の新しい機能を

Amazon MWAAでapache-airflow-providers-amazonを使ってRedshiftと繋いでみた どーもsutoです。 今回はAmazon MWAAのv2.2.2の環境を構築して、AWSプロバイダーパッケージのRedshiftモジュールを利用したDAGを作成して、Redshift Serverlessにクエリを実行するジョブを動かしてみようと思います。 下記リンクのとおり、Amazon MWAAで構築可能なApache Airflow v2.2.2には　apache-airflow-providers-amazon がデフォルトでインストールされているので、その中にある RedshiftSQLOperator 、 RedshiftToS3Operator といったRedshift操作のモジュールを使える、と言うことなので実際にDAGを作って検証してみました。 環境

S3 へアップロード Airflow から Python をつかって S3 にファイルをアップロードする小さいサンプルです。BashOperator も混ざっていいますが、S3 にあげる処理とは関係ありません、サンプルとしていおいてあるだけです。 import datetime as dt import boto3 from airflow import DAG from airflow.operators.bash_operator import BashOperator from airflow.operators.python_operator import PythonOperator default_args = { 'owner': 'me', 'start_date': dt.datetime(2021, 2, 11), 'retries': 1, 'retrby_delay

広告運用自動化関連のプロジェクトで、他部署のデータサイエンティストがアルゴリズムの開発担当として、私がシステム担当兼レビュワーとしてアサインされました。 ただまだ分析以上のプログラミング経験はあまり無いそうで、知らない単語が芋づる式に出てくる状態のようです。それぞれの考え方を教えようにも、このコロナ影響下ではホワイトボードも使えないし、zoomのミーティングの時間を取るのもお互い負担が大きかったので、まずQiitaで共有することにします。 同僚に間違ったことを教えていたら困るので、もし誤っている箇所やアドバイスがあればコメント頂けると嬉しいです。 バッチプログラムの実行について 現在開発している広告運用自動化システムでは、AWS Data Pipelineを使っておおよそ以下のような環境で動いています。 事前にソースコードをまとめてzipファイルにしてS3にアップロードしておく この処理は

はじめに 機械学習基盤/MLOpsについて知らなければと思い立ち、勉強したときに参考にさせていただいた記事の自分用メモです。 1. アーキテクチャ例 Apache Airflowでエンドユーザーのための機械学習パイプラインを構築する 概要 「本連載では、Apache Airflowを用いて機械学習の専門家ではないユーザー(=エンドユーザー)が、機械学習を活用するためのパイプラインの構築を目指します。」 ポイント、所感 既存の機械学習パイプラインがどのような処理を行なっているかをサーベイし、それを受けてApache Airflowで構築した事例 機械学習パイプライン全体を俯瞰することができる Airflow流行っている？AWSでもマネージドサービス出して欲しい、、、。 関連技術 Airflow,機械学習パイプライン Jupyter だけで機械学習を実サービス展開できる基盤 概要 GCPを活用

今年の10月からグロービスのデータサイエンスチームに配属され、2ヶ月間データ基盤構築をしてきました。実際やってきたことを踏まえて、データ基盤の構築時に気をつけるべきポイント7つを紹介していきたいと思います。 最強だと思う分析用データベースを選ぶ ワークフローエンジンでジョブを管理する ステークホルダーとの調整を優先度高くする 権限(IAM)の運用ルールを決める 監視設定を忘れずに メタデータ管理ツールを用意する SQL中心アーキテクチャを意識する 1. 最強だと思う分析用データベースを選ぶ ここが一番大事です。自分が最強だと思う分析用のデータベースを選んでください。ちなみに、私はBigQuery信者なので、BigQueryを強くおすすめしますが、いろんなデータベースがあるので今の環境に一番あった分析用データベースを選んでください。 分析用データベースの全体像を掴むには渡部徹太郎さんの資料「

概要 データパイプラインの管理にワークフローエンジンを導入したいのですが、今の要件に対してどれが合っているのか判断しきれない部分があるので整理してみました 最近の導入事例や発表をみるかぎりAirflow, Argo, Digdagあたりが人気なのかなと思います ワークフローエンジンとは ワークフローエンジンとは定期的なバッチ処理をうまく処理できるように、バッチ実行を管理してくれるソフトウェアのことです 古典的な実現方法としては適当なlinuxサーバーの上でcron実行させることが考えられますが、以下のような問題があります ジョブごとの依存関係を表現できない。cronの時間指定で実現させようとすると、タスクAを１時に開始してそれが完了するとみなして依存するタスクBを２時に開始するというような書き方をすることになるが、実際にタスクAが２時までに終わらなかった場合に処理が上手く実行できない タス

書籍化されました 本記事をベースに監修者の村上さんが１冊の本にまとめてくれました（感謝） データサイエンティストのキャリア面やポートフォリオの細かい部分をさらに追加・ブラッシュアップした内容になっています。 まえがき はじめに 皆さん、「データサイエンティスト」という職種をご存知でしょうか？ この数年間で、AIやディープラーニングといったバズワードと共にデータサイエンティストというワードも、よく耳にするようになりました。最新の技術を扱えて、年収も高い非常に魅力的な職業なため、データサイエンティストへの転職を検討されている方もいらっしゃるのではないでしょうか？ 実際、データサイエンティスト職への就職・転職希望者は年々増加しています。しかし、未経験の人材を育成できる会社はまだまだ少なく、未経験からの転職は転職希望者の増加に伴い高まっています。 データサイエンティストは求められるスキルの幅が広く

みなさんこんにちは。技術創発推進室の高岡です。 気の早い桜は咲き始めたようですが、そろそろ年度末、みなさまいかがお過ごしでしょうか。 このところの私は、これまでの AI 関連の開発を振り返って、実験管理、結構面倒くさかったな、という反省をしているところです。機械学習系の案件に関わっている皆さんには、ご同意いただけるんじゃないでしょうか。 ■実験管理は必須。でも面倒！ 機械学習モデル開発のワークフローでは、次のような作業がよく発生します。 あるデータと設定で、機械学習モデルを訓練して、パラメータを得る訓練済みの機械学習モデルの性能を調べて、記録するモデル同士の性能を比較する こうした「条件設定と訓練、性能測定、比較」のサイクルを「実験」と呼び、実験を繰り返しながら、より良いモデルを模索するわけです。経験者の皆さんにはおなじみですね。 このとき「このモデルはどういう条件の下で得られたか」「それ

はじめに ワークフローを作成、実行、監視するためのプラットフォーム「Airflow」が、近年人気を集めていて、多くの企業に利用されています。Airflow Summit 2022 のようなグローバルイベントも開催されるようになり、世界中から2000人以上のコントリビュータ（私もその1人）が貢献しているアツいプロジェクトです。 この記事で Airflow を使う意味と主要コンセプトを説明します。最後に、100行未満で実装できる本格的なデータパイプラインの実例をお見せしたいと思います。 Airflowとは 概要 Airflowは ワークフロー を作成、実行、監視するためのプラットフォームです。ここで言う「ワークフロー」は、依存関係にある複数の タスク を、下図のように繋いだ形で、パイプラインとして実行していくものと思ってください。 Airflowを使うと、より早く、よりロバストなワークフローが

はじめまして、普段はサービス開発やら収集したデータをごちゃごちゃ整形したりしているakito1986です。 この記事はIDCフロンティア Advent Calendar 2015の7日目の記事です。 さてあれよあれよという間に7日目もあと残すところ一時間！ 担当した日に公開しないとあまり意味がないと思い、さっと書けそうで最近興味があり必要性を感じているワークフローについて調べたことを書きます。 はじめに 冒頭に書いた収集したデータをごちゃごちゃ整形の部分の話。 サービス事業者でエンジニアをしていると、「このデータとこのデータをがっちゃんこして、こういう形式のデータにして欲しい」と頼まれることが多いのではないでしょうか？ 私も頼まれることがあり、「定期的に送られてくるCSVをテーブルにインポートしてクエリで集計してその結果を出力するだけでいいんでしょ？」という最初は軽い気持ちで引き受けたので

皆さんはどのような方法で最新の技術や、コードのTipsを収集していますか？ はてなブックマークやTwitter, GitHubなど様々あると思います。 私はテックブログを使った情報収集をしています。今回はエンジニアが見るべきおすすめのテックブログをいっきにご紹介します。 テックブログとは？ ご存知の方も多いと思いますが、テックブログとはWEBサービスやゲーム等を提供している企業が、自社で使っている技術や開発手法を紹介するブログです。デベロッパーブログとも呼ばれます。 エンジニアが持ち回りで書くことが多いので、そこで働いている人のこともわかっちゃいます。 普段使っているサービスがどのような言語でできていて、どのようなフレームワークを使っているか、どんなツールを利用して開発しているのかが載っているのでとても刺激的な内容ばかりです。 転職、新卒の会社選びにも役立つ!? 転職する際に気になるどんな

はじめに こんにちは。MA部MA施策・運用改善チームの辻岡です。MA部では、ZOZOTOWNのメルマガ・アプリPUSH通知などの配信・分析等の用途で約数十TBのデータを運用しています。今回は長年MAのデータ基盤として利用してきたオンプレDWHをBigQueryに移行したおはなしをします。 この記事はこんな方におすすめ オンプレDWHからBigQuery移行を検討・実施してる方 ジョブ・スケジューラ、ETLツールの移行を検討・実施してる方 概要 オンプレDWHからBigQuery移行する前後の構成イメージを元に、今回の移行の話について概要を説明します。 次の図が移行前の構成図です。オンプレ環境のWindowsサーバ上でジョブ・スケジューリングと実行を基盤処理として、データウェアハウス（以後オンプレDWH）に対してデータ生成や外部システムとの連携をしていました。 今回、以下を目的にオンプレDW

こんにちは、データ基盤の開発、運用をしていた谷口（case-k）です。最近は配信基盤の開発と運用をしています。 ZOZOではオンプレやクラウドにあるデータをBigQueryへ連携し、分析やシステムで活用しています。BigQueryに連携されたテーブルは共通データ基盤として全社的に利用されています。 共通データ基盤は随分前に作られたこともあり、様々な負債を抱えていました。負債を解消しようにも利用者が約300人以上おり、影響範囲が大きく改善したくても改善できずにいました。 本記事では旧データ基盤の課題や新データ基盤の紹介に加え、どのようにリプレイスを進めたかご紹介します。同じような課題を抱えている方や新しくデータ基盤を作ろうとしている方の参考になると嬉しいです。 データ基盤の紹介 旧データ基盤の紹介 旧データ基盤の課題 変更があっても更新されないデータ 性質の異なるテーブルを同じ命名規則で管理

自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

この記事はfreee データに関わる人たち Advent Calendar 2019の11日目です。 シンプルにAWS Glueで RDB(MySQLとか)から巨大なテーブルデータを取り出すときの話です。 tl;dr Glueを使ってMySQLなどRDSから億単位のデータを引っこ抜くときは、Glueの並列取り込み機能を使わず、sparkの機能を使おう やりたいこと & 問題 RDB(MySQL)の一つのテーブルが 1億件以上データを持っている そのままGlueで取り込むと遅い -> なんかGlueで並列読み込みする機能があるらしい Glueの並列読み込み機能試したけど、クソ遅い Spark自身の機能を使った -> めちゃ早くできた Glue と Sparkの関係 用語・語弊を生みそうなので、最初に整理 Glue は Managed Sparkと言い換えられます。Sparkを使いやすくしたも

まえがき 最近、AWS Glueが一般人でも使えるようになりました。そこでどんなものかと、調べてみました。一人で調べ物した結果なので、機能を正しく把握できているかいまいち自信がありませんが、理解した限りで公開します。 ハンズオンは他にゆずることにして、概観的な話を中心とします。 AWS Glueは、日々行われるデータ集約やETL処理を自動化、およびサーバレス化するサービスです。 いま、未加工のCSVやJSONによるログデータや、 アプリケーションで使用している既存のデータベースなどがあるものの、 そのままでは分析が難しく、データ分析のために整備された領域が求められているとします。 AWS Glueの文脈では、前者をデータストア、後者をデータカタログと位置づけます。 データカタログは主に、フルマネージドなHDFS上のストレージ領域です。 たとえば、Amazon Athenaからデータカタログ

add_time.php 現在時刻をtxtファイルに追記するだけのプログラムです。 cronで処理を実行する場合、ファイルパスは絶対パスで記述する必要があります。requireやincludeを使用するときも同様です。 <?php // time.txtに現在時刻を追記する $file = '/usr/local/var/www/htdocs/batch_test/time.txt'; $current = file_get_contents($file); date_default_timezone_set('Asia/Tokyo'); $current .= date("Y-m-d H:i:s")."\n"; file_put_contents($file, $current);

これまでの業務経験をもとに、バッチ処理の仕様で検討する必要がありそうな主な点をまとめてみました。あくまで参考程度なので、他にもいろいろあるとは思います。 ◆バッチ実行時の入力パラメータ（あるのであれば...） 入力パラメータの数 入力パラメータの桁数 入力パラメータの型 入力パラメータの範囲 ジョブスケジューラ製品を使用する場合、その製品の特徴、制約を把握する必要があります。 ◆実行契機、周期 いつ、何をトリガーにして実行を開始するのかの仕様を決めます。 ◆入力ファイルの仕様 拡張子 ファイルの内容項目 文字コード（テキストファイルの場合） ファイル名規則 ファイルの生成契機 ファイルの削除契機（貯めるとディスク容量を圧迫するので削除が必要な場合） 格納ディレクトリ（ディレクトリ構成） 入力ファイルなしの場合の挙動 入力ファイルが空の場合の挙動 入力ファイルが複数ある場合の読込順序 空行の

バッチ系の考慮点 いつ行うか（日次/週次/月次の処理頻度） どの程度処理に時間がかかるのか(1回当たりの処理件数) バッチ処理中はその期間内のデータ更新を不可としているか 許容時間より処理がかかった場合はどうするのか DB更新ならCommitする単位(件数)をどうするのか ログ出力が考慮されているのか(異常箇所の把握) 異常終了した場合の再実行の考慮をしているか(運用含め) 再実行する場合、データ全体を処理前に戻して再実行する方法と、異常終了した時点から再実行する方法があります。 仮処理(締め前に現在の集計結果をみたい)でバッチを流すことも考慮する(完了フラグを更新するかしないかの違い) バッチの場合、バインド変数を使わずリテラルSQLにした方がいい場合もあります。 【Oracle】クエリパラメータ(バインド変数)を使うとパフォーマンスが悪くなることもあるバインドピーク問題 日次バッチ 事

バッチ処理のデータストア バッチ処理では大量データを扱うことが多いため、まずはそのデータを扱うデータストアを確認する必要があります。バッチ処理の入力データはファイルなのかRDBなのか、バッチ処理した結果をファイル出力するのかRDBに出力するのか等です。このように目的や用途に応じてファイルシステムに保存するのかRDBに保存するのかを検討します。また、ファイルの場合はTSVなのかCSVなのかXMLなのか等のファイル形式も検討します。 ジョブと順序制御 業務的に意味のある1つのバッチ処理を、ジョブと言います。通常、バッチ処理は多くのジョブで構成されているため、以下を検討する必要があります。 何をジョブとするのか 各ジョブの実行順序は問題ないか（その実行順序でデータの不整合は発生しないか） エンハンス開発等の場合、既存ジョブと実行順序は問題ないか オンライン処理とのデータの排他制御（これに関しては

はじめに Python Advent Calendar 2020 25日目です。 時代はサーバレースですが、オンプレミスのサーバやクラウド（IaaS）などのインスタンスでバッチを運用しているシステムもまだたくさんあると思います。 本記事ではサーバ上で動かすバッチを前提とし、前半はアンチパターンなどを踏まえながらバッチ設計のポイントについてまとめています。後半はPythonでバッチ開発する際のTipsになります。 ※本記事の内容は、あくまで考え方の一例であり、必ずしも全ての考え方がシステムに適合したり、ここに書いている内容で満たされている訳ではありません。 バッチ処理はひとまとまりのデータに対して、一連の処理を連続で実行する処理方式のことです。語源を辿ると、汎用コンピューターの時代まで遡ります。 データを一括で処理することを目的とし、Unix系OSではcronを利用して指定した日時で運用する

はじめに バッチ処理を作る際に検討項目が多く手が動かない。。。。 そんな状況にならないためにフォローできる記事になれば良いと思い書き込んでみました。 そもそもバッチ処理とは 簡単にいうと一定量のデータを集めて、一括で処理する方法のことです。 主にユーザアクションに起因しない処理です。 実行についても定期実行、手動実行など様々な用途で用いられます。 バッチ処理にするメリット 大量のデータを一括で処理できること 稼働する時間を調整できる。（業務システムが稼働していない夜間などに処理を行える） バッチ処理の構成 基本としてバッチ処理は以下の構成となっている。 入力して加工して出力する 例 入力 DBのデータ CSVファイル 加工 抽出する 削除する 集計する マージする 出力 DBに登録する CSVファイルに書き起こす メール送信 ファイル作成して転送 バッチを作る際の検討事項 構築する際に迷っ

TL;DR ひとくちにバッチといっても色々ある 夜間バッチをもう作るな オンラインバッチはSQL以前にDB設計がんばれ はじめに Twitterのタイムラインで以下のようなツイートが回ってきました。 バッチ処理をみんな舐めてかかったり、ショボイとか思ってる人多い印象なんだけれども、数十万～数千万件規模のデータを処理したことあるのかな。テンプレ通りのコードじゃ動かないよ？ネットに本にも答え載ってないよ？低レイヤも意識しないと動かないよ？ 2020年1月10日 ツイートされたわだっしーさんの意図がどこにあるかは確認してないですが、極限の世界でテンプレート的な処理では対応出来ないのはあるよな、と思いつつもある程度はバッチの作法としての書き方があると思っています。 このツイートとその関連ツイートを読みながら、そういえばバッチ処理に関して書いてある記事はあまり見ないなぁ、とおもったので他のネットや本

D. M. です。レガシーの crontab が肥大化して困っています。今日はそのリプレイス候補である Digdag を使ってみた話です。 やりたいこと crontab は Linux のスケジューラの仕組みで定期バッチの実行用途でよく利用されますが低機能です。順序の依存関係やアラートは毎回独自に作りこまなければいけません。そのため近年は代替スケジューラを利用するケースが多いです。その候補のひとつである Digdag について検証したいと思いました。 Digdag を使うべき人 一般的にバッチスケジューラに求められる要件的には以下のようなものがあります。 ・スケジュール実行 ・複数バッチの順番の制御（ワークフロー） ・GUIでの管理 ・失敗時のアラート ・SLA 機能（長時間実行していたらアラートを飛ばす） ・分散実行 などなど 代替として広く知られているものですと Jenkins でのワ

2016/06/15に、トレジャーデータがオープンソースとして公開したワークフローエンジンDigdagのリンク集です。内容は随時更新します。またトレジャーデータではDigdagを自社でTreasure Workflowとして提供しています。こちらの情報も収集しています。 変更内容が気になる方は変更履歴をご覧ください。 1. 開催されるイベント 2. オフィシャルページ オフィシャルページ ソースリポジトリ 3. チュートリアル Getting started (英語) Treasure Data社のOSSワークフローエンジン『Digdag』を試してみた #digdag (日本語) Digdag 入門 Digdagのアーキテクチャとコンセプトを理解する Treasure Workflow for ビギナー 環境構築編 digファイル書き方編 Digdag公式ドキュメントからDigdagを学ぶ

SREチームの安達(@adachin0817)です。最近ではランサーズ本家のインフラをコンテナに移行しまくっております。今回ランサーズとMENTAで運用しているEC2/分析基盤サーバー(Digdag + Embulk)をECS/Fargateに移行完了しました。では早速概要と苦労した点、今後の展望などを振り返っていきたいと思います。 分析基盤の紹介 > ランサーズの分析基盤(capybara)と運用について紹介 > MENTAをAWSに移行しました ちなみに私が入社して3年経つのですが、運用して変わったことは3年前よりデータの量が膨大になっていることと、現在、社内の分析チームにとって欠かせないシステムとなっております。その中でDigdagによるスケジューラーとEmbulkによるマルチソースバルクデータローダーである分析基盤専用のEC2サーバーがあり、毎日夜中にデータをBigQuryにシンク

Motive twitter分析ページを作成して約2年が経ちました。従来はTwitterAPIで取得したデータをMySQLにストックしていましたが、 あるテーブルは約2億レコードと膨大になってしまったためorder by でなくてもselect count(*) from TWEET などといったシンプルなSQLでも約数十分かかります。システム構造もEC2にMySQLを導入したサーバーにデータを追加してたので、仮に /etc/my.cnf でメモリサイズを最大化し、EC2自体の t3.micro から t3.large に変更しても限界があります。 それで解決方法としてはGoogle Cloud Service の Bigquery を使うこととしました。利点としては数テラのかなり大きめのテーブルでも約数１０秒で結果が出力されることです。金額はクエリを使うごとに発生はして、数テラのかなり大

SRE所属の @siroken3 です。最近はもっぱらパートナー会社様とのデータ連携環境構築を主に、時々プロダクションのMySQL環境と分析基盤との連携インフラの構築が多いです。 本記事は、メルカリに出品された過去すべての商品をBigQueryへ同期するにあたって取り組んだ時のお話です。 背景 当社では分析目的などでBigQueryを以前から使用しており、プロダクションのMySQLからBigQueryへデータを同期して分析に活用してきました。特に商品を表すテーブルは重要です。 しかし、後述する課題によりBigQueryにアップロードすることができなかったため、分析用のMySQLDBのスレーブとBigQueryを併用せざるを得ませんでした。とはいえ不便なので以前からBigQueryのみで商品テーブルも分析対象としたい要望がありました。 課題 メルカリでは販売済み商品を物理削除していないため、

こんにちは。 インフラエンジニアの村上です。 マネーフォワードのインフラチームは、サービスに関わるインフラから、自社の作業環境、開発環境、さらにはサービスのインフラの中でも物理的なものからOS・ミドルウェア・アプリケーションのメンテナンス・ビルド・リリース・運用まで幅広く関与しています。 今回はGoogle Cloud PlatformのBigQueryを活用してアクセスログの分析環境を構築した時の話を紹介します。 この記事に書かれる事 データ分析基盤としてBigQueryを使用した話と データ量を例示しながら使用を開始した時のトラブルシュートとパフォーマンスについて紹介する。 データ移行のコツもうまく含めながら書いていく。 BigQueryを採用した訳 マネーフォワードの家計簿は350万人以上のお客様に利用いただき、 アクセスログは日々2.500万件程度増えております。 サービス開始から

はじめにこんにちは、Finatextで証券プラットフォーム（Brokerage as a Service、以下BaaS）の開発に携わっている石橋（@bashi0501）です。過去のFinatextテックブログではTerraform、CDKとIaCをテーマにした記事しか書いたことがなかったのですが、今回はログの分析活用をテーマとします。 概要弊社の証券事業ではECSによるワークロードを組んでいます。本テーマのアプリケーションログについては標準出力したものをawslogsログドライバーが回収してCloudWatch Logsに送信しています。 ログの検索という観点ではCloudWatch Logs Insightsというサービスでかなりリッチにフィルターや集計を行うことができるのですが、ログデータを元にしたユーザーのファネル分析や業務改善（後述します）に活かしていきたいという意図があるため、マ

こんにちは。マッハバイトを運営するアルバイト事業部エンジニアの mnmandahalf です。 先日、マッハバイトの販売管理システムで使っているデータベースをオンプレPostgreSQLからAmazon Aurora MySQLに移行しました。 本記事では移行に至った背景、吸収する必要があった差分や苦労した点についてお話しします。 環境 移行前のバージョン: PostgreSQL 9.4 ※ドキュメントはバージョン14のものを添付しています 移行後のバージョン: Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23) 環境 MySQL移行の背景 データ移行方法の検討 Embulkの実行で考慮したポイント Embulkの設定 scram-sha-256認証への対応 タイムスタンプが9時間巻き戻る FK制約を無効化できない PostgreSQLとM

Embulkとは　〜Pluggable Bulk Data Loader〜 並列データ転送ツール Fluentd開発者　古橋氏が開発 Fluentdのバッチ版 プラグインアーキテクチャ Embulkの概念図 特徴その1 プラグインが多数用意されている、かつ日々増殖 独自プラグインの簡単実装追加可能 ( ruby, java ) リトライとレジューム Embulkでは失敗したタスクだけを後からやり直すリジューム機能 オープンソース（Gitに公開） guess機能 入力データを自動で推定し、設定ファイルを生成 対応していないプラグインもある 特徴その2〜Fluentdとの違い バッチ（バルク）処理に特化 fluentdはstream, embulkはstorage 巨大なデータに対応（並列分散処理） 高速性 トランザクション制御あり すべて成功しなかったら、実行前の状態に巻き戻る スキーマを使

本記事では、様々なシステムからデータを収集・蓄積・加工してデータ分析用に提供するデータパイプラインにおいて、処理の単位を考える上での考慮すべき点をいくつか書き殴ってみようと思います（書き殴りなので重大な抜けはあると思います）。 ここでの処理の単位というのはちょっと曖昧ですが、外部から呼び出されるスクリプトをどの単位で書くかということを指してると思ってください。Airflowを使っていればタスクを、JP1を使っていればジョブをどの単位にするかということと言い換えても良いかもしれません。 処理の単位を決める観点は複数あり、要件や制約に応じて判断するものなので、常にこうすべきという方針があるわけではないことはご了承ください。 1. 想定する処理内容 具体的な例がないと説明しづらいので、以下のようなシステムAとシステムBからデータを取得して、汎用的に分析に利用可能なテーブルを作成し、その後に特定の

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

こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する

最近、TreasureDataと自社のDBのデータを合わせた集計をバッチ処理することが多くpythonでいったんcsvに書き出してEmbulkでアップロードしていましたが、データソースが増えると面倒になっていくのでより簡単で汎用化した書き方を考えました。 結局はWF使ってやったらいい話なので需要があるか不明ですが、WF勉強するのも時間がかかるので慣れてる言語でてっとり早くETLを作りたい人向けの内容です。 前提条件 この記事が適している人 普段はpythonを書いているのでなるべくその範囲でETLしたい pandas-tdの動きが不安定すぎて使えない シェルでの実現方法を調べる時間もない 達成したい機能 SQLさえ作ればバッチを追加できるETLの箱を作る 入出力のテーブルが変わっても手間がかからない 記述した順番に処理が実行され、進捗が通知される 環境の準備 Embulkのインストール す