タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
2023 年はビジネスとオープンソースの関係が難しくなった年であったように思います。 6 月には、フルタイムの Ruby コミッターとして研究開発を行っていたお二人がクックパッド社の人員削減の影響を受けたことに端を発して、オープンソースに深く関わってきた一部のソフトウェア・エンジニアを中心に、ビジネスとオープンソースの関係について議論がありました。 8 月には HashiCorp 社が自社のオープンソース製品群のライセンスを Business Source License 1.1 (BSL) に変更したことも話題になりました。 また 2023 年は、一年を通して大規模言語モデル (Large Language Models; LLM) が話題になった年でもあり、ビジネスにも大きな影響がありました。 大規模言語モデルとオープンソースの関係に焦点を絞っても、「非オープンソースのライセンスで公開
こんにちは。マッハバイトを運営するアルバイト事業部エンジニアの 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
はじめにこんにちは、Finatextで証券プラットフォーム（Brokerage as a Service、以下BaaS）の開発に携わっている石橋（@bashi0501）です。過去のFinatextテックブログではTerraform、CDKとIaCをテーマにした記事しか書いたことがなかったのですが、今回はログの分析活用をテーマとします。 概要弊社の証券事業ではECSによるワークロードを組んでいます。本テーマのアプリケーションログについては標準出力したものをawslogsログドライバーが回収してCloudWatch Logsに送信しています。 ログの検索という観点ではCloudWatch Logs Insightsというサービスでかなりリッチにフィルターや集計を行うことができるのですが、ログデータを元にしたユーザーのファネル分析や業務改善（後述します）に活かしていきたいという意図があるため、マ
(この記事は www.embulk.org にある Looking for long-term maintainers around the Embulk eco-system の日本語訳と、同じ筆者によるもう少しぶっちゃけた追記です。) 古橋さん (@frsyuki) が最初に Embulk をリリースしてから、まもなく 10 年になります。もう Embulk はかなり成熟・安定して、いまも企業などで実際に使われています。近代化にも引き続き取り組んでいて、もうすぐ Embulk v1.0 を出せるだろうと考えています。 EEP-8: Milestones to Embulk v1.0, and versioning strategies to follow その傍らで、実は多くのものが置き去りになっています。たとえば https://github.com/embulk にあるほとんどの「
こんにちは、エムスリー エンジニアリンググループ / 製薬企業向けプラットフォームチームの鳥山 (@to_lz1)です。 これは エムスリー Advent Calendar 2020 の19日目の記事です。 エムスリーでは現在、各システムのオンプレ環境からクラウドへの移行を急ピッチで進めているところです（勉強会の配信アーカイブをYouTubeでもご覧いただけます。公式テックチャンネルのご登録、ぜひお願いします!） www.youtube.com これに関連して私のチームでも最近「データ基盤（Digdag + Embulk）のクラウド移行」を行ったため、そのときに考えたことや移行して良かったことを共有したいと思います。 エムスリーのデータ基盤について それまでの構成 クラウド環境でのアーキテクチャ DigdagとEmbulkの分離 Digdag on AWSからBigQueryを操作する 併
はじめに こんにちは！Data Platformチームでデータエンジニアとして働いている @shota.imazeki です。 分析基盤の構築・運用などの側面から社内のデータ活用の促進を行っています。 BASEではAurora MySQLにあるデータをEmbulkを用いてBigQueryに連携しています。BigQueryへ連携されたデータは分析基盤としてLookerなどを通して社内利用されています。 このデータ連携処理にはいくつかの課題があり、それを解決するためにEmbulkからAurora S3 Export機能を用いた連携処理に切り替えることにしましたので、それについて紹介していきたいと思います。 ※この切り替えについては現状、試験的に一部のDBのみの切り替えとなっていますが、運用上の大きな課題が出てこなければ徐々に切り替えていく予定です。 切替前のデータ連携処理 先述した通り、BAS
オープンソースのプラグイン型データ・ローダー Embulk のメンテナをここ何年かやっている @dmikurube です。 Embulk はオープンソースですが、本体 (core) のメンテナンスは Treasure Data でおこなっている、いわゆる「企業発オープンソース」でした。ライセンスは Apache-2.0 で、その意味でちゃんと「オープンソース」ですが、メンテナンス体制や意思決定は実質的に Treasure Data で握っていました。 [1] この Embulk のメンテナンス体制を、このたび、よりオープンにしていくことになりました。まだ準備を進めている段階ですが、本記事は、その概要のご紹介です。 オープンって、具体的には? 大きくは次の 2 点です。 特にプラグイン互換性に影響があるような大きな変更の意思決定プロセスを整備する Treasure Data の外からも Em
SREチームの安達(@adachin0817)です。最近ではランサーズ本家のインフラをコンテナに移行しまくっております。今回ランサーズとMENTAで運用しているEC2/分析基盤サーバー(Digdag + Embulk)をECS/Fargateに移行完了しました。では早速概要と苦労した点、今後の展望などを振り返っていきたいと思います。 分析基盤の紹介 > ランサーズの分析基盤(capybara)と運用について紹介 > MENTAをAWSに移行しました ちなみに私が入社して3年経つのですが、運用して変わったことは3年前よりデータの量が膨大になっていることと、現在、社内の分析チームにとって欠かせないシステムとなっております。その中でDigdagによるスケジューラーとEmbulkによるマルチソースバルクデータローダーである分析基盤専用のEC2サーバーがあり、毎日夜中にデータをBigQuryにシンク
プラグイン型バルク・データ・ローダーの Embulk をメンテナンスしている @dmikurube です。 今後の Embulk のロードマップについて、一年ほど前に、記事を (英語ですが) 出したり、ミートアップで話したりしていました。その内容は、開発版 (非安定版) として Embulk v0.10 でしばらく大改造を行い、そこから次期安定版の v0.11 を経て v1.0 を出しますよ、というものでした。 Embulk v0.10 series, which is a milestone to v1.0 More detailed plan of Embulk v0.10, v0.11, and v1 -- Meetup! Java plugins to catch up with Embulk v0.10 from v0.9 それから一年経ち、その v0.11.0 のリリースがいよ
Author: @dmikurube Created at: 2025-11-10 On October 15, 2025, I sent the following email to those who were in the GitHub organization: https://github.com/embulk (... snip: greetings in Japanese ...) To all who have been or are involved in Embulk, and who belong to Embulk's GitHub organization, I'm sending this email to addresses confirmed publicly in Embulk-related git log, or addresses confirmed
目次 ワーカーノードの作成 DigdagとEmbulkのDockerビルド KubernetesにDigdag/Embulkをデプロイ Redashの導入 まとめ Kubernetes上に分析環境を構築する機会があったのでどのように構築したかを紹介します。同じような構成でKubernetes上で構築するのは3回目になったので構築方法も洗練されてきました。構成は以下のようになっています。 MySQL(RDS): サービスのデータベース。ここのテーブルからBigQueryにEmbulkでデータをエクスポートします。 PostgreSQL(RDS): Digdagのデータベース。今回新たにつくりました。 Digdag: データベースのエクスポートなどを実行するタスクスケジューラ。失敗したときにリトライもできます。 Embulk: プラグインを使ってデータベースをMySQLからBigQueryにエ
この記事は trocco Advent Calendar 2023 の6日目の記事となります。 はじめに 今回はtroccoの内部でも利用されているETLのためのOSSであるEmbulkについて、core部分のソースコードリーディングを通して、そのしくみを紐解いていきたいと思います。 おことわり Embulkの基本的な使い方などについては解説しません。 筆者はembulk-coreにコントリビュートしているわけではないので、間違いなどがあればお気軽にご指摘ください。 今回見ていくcoreの実装自体は、比較的変更が少ないとされる各種プラグインが従うべきインターフェース部分(embulk-spi)から隠蔽されているため、今後この記事の内容が正しくなくなる可能性は容易にあります。 Embulkにはguessやpreviewやresumeといった機能も含まれていますが、今回は単純なembulk r
こんにちは。Feature2 Unitのうなすけです。我々のチームの担当範囲のひとつには「データの入出力」というものがあり、お客様からAPI呼び出しやファイルアップロードなどで受け取ったデータを適切に処理するコンポーネントの運用・開発をしています。 我々の担当している機能のひとつに、お客様からアップロードしていただいたCSVファイルの内容をデータベースにインポートするというものがあります。これは裏側ではEmbulkを使ってMySQL(Aurora)に投入するということを行っています。 このとき、アップロードされるCSVの内容に日本語(マルチバイト文字列)を含められるように機能追加しようとしたところ、日本語のデータがインポートできていないという問題が発生しました。冒頭画像で ??? となっている部分には日本語の文字列が表示されていてほしかったのですが、データの取り込みに失敗しています。 どこ
こんにちは、theLetterの荻田です。 データ分析基盤を作る機会があり、拡張のしやすさ・現状のデータ量や仕様に合うか・予算問題などを考えた結果どう判断したのかという過程と実装を紹介します。 今後運用する上で出てきた改善点や課題などは半年後くらいに振り返りの記事を書こうと思います。 気になることがあれば気軽にDM(@kai_ogita)してください 一緒に技術選定から実装までゴリゴリやりたい人募集中です！ theLetter採用ページ About me サーバーサイドエンジニアの人 TreasureDataやBigqueryは本当に少し触ったことある ETLやデータ分析基盤などの知識は０ GCPよりAWSに触れてきた About theLetter theLetter はニュースレターメディアを誰もがつくれるプラットフォームで、現在はリリース数ヶ月で読者数15 万人を突破しており、初期フ
Latest Versions Stable v0.11.5 Note that v0.11 is not fully compatible with v0.9. Several plugins for v0.9 would not work with v0.11. Take a look at this article for details. Past stable v0.9.25 Recent Articles Looking for long-term maintainers around the Embulk eco-system Shutting down dl.embulk.org Installing Maven-style Embulk plugins 'embulk gem install' may fail in Embulk v0.9: incompatibilit
Looking for long-term maintainers around the Embulk eco-system Author: @dmikurube Created at: 2024-11-28 The 10th anniversary of Embulk’s first release (by @frsyuki) is approaching. Embulk has matured, stabilized, and been used in the real world. We have also been working on modernizing Embulk, and we’d say that Embulk v1.0 is coming sooner. EEP-8: Milestones to Embulk v1.0, and versioning strateg
GMOアドマーケティングのT.Kです。バッチサーバーでEmbulkを使っていますが、古いv0.8系なので更新する事にしました。 embulk selfupdate で更新すると何かあった際に切り戻しが出来ないので、追加インストールして切り替える方針を取りました。 手順 Gemfileを作成 プラグインも新しいバージョンに更新します。インストール先を被らないようにするためGemfileを使います。 既存環境はプラグインをGemfileで管理していないので、コマンドでインストール済みのリストを抽出します。 既存のembulkのインストール先はold/embulkとします。 $ old/embulk gem list | grep embulk- $ mkdir bundle_dir $ cd bundle_dir $ vi Gemfile
こんにちは。宿泊開発チームの菊地です！ このエントリは 一休.com Advent Calendar 2023 12日目の記事です。昨日は id:rotom によるSlack Enterprise Grid における情報バリアの設計でした。その他の素敵なエントリも以下のリンクからご覧ください。 qiita.com 私はEmbulkを使って、各プロダクトの請求データを集約する機能を担当しました。今回は、Embulkの紹介とふりかえりをしていきたいと思います！ 背景 課題 解決策 Embulkとは？ 今回の課題に対してEmbulkがマッチした理由 union: 複数のデータソースを連結する config.ymlの記述例 lookup: 複数のデータソースを結合する config.ymlの記述例 ふりかえり とくに良かったこと config.ymlの取り回しのよさが開発スピードをあげてくれた c
Kubernetes上に分析環境を構築する機会があったのでどのように構築したかを紹介します。同じような構成でKubernetes上で構築するのは3回目になったので構築方法も洗練されてきました。構成は以下のようになっています。 MySQL(RDS): サービスのデータベース。ここのテーブルからBigQueryにEmbulkでデータをエクスポートします。 PostgreSQL(RDS): Digdagのデータベース。今回新たにつくりました。 Digdag: データベースのエクスポートなどを実行するタスクスケジューラ。失敗したときにリトライもできます。 Embulk: プラグインを使ってデータベースをMySQLからBigQueryにエクスポートします。Digdagと同じDockerコンテナでDigdagのタスクから実行されます。 BigQuery: すべてのエクスポートされたデータをここに集約さ
プラグイン型バルク・データ・ローダーの Embulk をメンテナンスしている @dmikurube です。 前に Embulk v0.10 に関するアナウンス (英語版) を出してからおよそ一年が経ち、ついに v0.11 のリリースが視界に入ってきました。 その Embulk v0.11 と、それに続く v1.0 は、今までの安定版の v0.9 とは大きく変わります。本記事では、その v0.11 での変更について、ユーザー向けの概要をまとめました。 (ユーザーではなくプラグイン開発者向けのまとめはこちら) (Embulk 公式サイトにある英語版 の翻訳ですが、同一人物が書いているので、おそらく同じ内容になっていると思います。もし違いがありましたら、英語版の方を一次情報として解釈しつつ、ぜひ筆者までご連絡ください) Embulk System Properties とディレクトリ Embul
現在、Embulkは次の安定版であるv0.11.0に向けた開発版としてv0.10がリリースされています。 メンテナであるdmikurubeさんのアナウンスに依ると、0.11.0以降はJRubyがデフォルトでembulkに組込まれなくなるため、プラグインは基本的にJavaで作ることが推奨される様になります。 また、JRubyがデフォルトで入らなくなるため、基本となるプラグインの配布プラットフォームはMavenリポジトリになる予定です。 JavaのプラグインのAPIもいくつか変更されており、新しいバージョンに対応するためには多少の修正が必要になります。 基本的な開発ガイドについては、以下の記事を参考にすると良いでしょう。 zenn.dev zenn.dev ある程度embulkのプラグイン開発に慣れていれば、上記の記事で実装とビルドまでは何とかなるんですが、当分の間0.9系が生き続けることは間
この記事はZOZOテクノロジーズ #2 Advent Calendar 2020 17日目の記事です。 はじめに こんにちは @civitaspo です。先日新しい Embulk Plugin の embulk-input-union をリリースしました。この記事ではこの embulk-input-union の使い方や実装内容について紹介しようと思います。 なにするやつか 皆さん SQL の union 句はご存じだと思いますが、この Plugin は複数のデータソースを union して input として利用出来ます。 example を見ると雰囲気が伝わるかと思います。 in: type: union union: - in: type: file path_prefix: ./example/data01.tsv parser: type: csv delimiter: "\t"
カウンターワークスで主にDevOpsなところでお手伝いしている@tchikubaです。ベンチャー企業のTech支援やアジャイルコーチ、エンジニア向け研修など複数社に関わっています。 ✍️ はじめに Cloudflare Workers を本番環境で運用していると、避けて通れないのが「ログ基盤」の問題です。 カウンターワークスの環境では、Workers は単なるフロントの CDN としてだけではなく、 リバースプロキシとしての役割を持ち パスルールに応じて Vercel（Next.js） Rails API（ECS/Fargate） Go API（ECS/Fargate） メディア（WordPress or Cloudflare Workers） へリクエストを正しく振り分ける という、複数バックエンドの“ゲートウェイ”として機能しています。 カウンターワークスのシステム構成 この構成では、
はじめに こんにちは, 基盤開発チームの奥山(okue)です. High Link では, BigQuery を活用してデータの分析や可視化, 機械学習への活用を行っています. アプリケーション DB の BigQuery へ転送には, AWS ECS Fargate + Embulk という構成でバッチ処理を実行していましたが, いくつか運用上の問題点がありました. 本記事では, BigQuery へDBのデータを転送するバッチ処理を, AWS Step Functions + AWS ECS Fargate + Embulk で実装し改善した話をします. 改善前の構成と問題点 構成 改善前のバッチ処理は下図のような構成でした. AWS RDS MySQL には 60個以上のテーブルがありますが, それらを BigQuery へ転送する処理を1つの ECS Task で実行していました.
差分転送するモチベーション 機械学習を使った情報推薦を行なうために、RDSのテーブルをBigQueryに定期転送しています。細かいことは気にしたくなかったので、一日一回の洗い替え(全データ送信で全部上書き)していましたが、もう少し鮮度を上げたくなりました(新しい情報に対して推薦ができないため)。何も考えずに定期転送の頻度を上げると 1: 転送のためのCPUコスト 2: AWSからGCPへのデータ転送量 が気になってきます。個人の趣味プロジェクトでは、特に2が大きい。先月のAWSの利用料金を見て、涙を流していました...。というわけで、情報の鮮度は上げつつもう少し効率的に定期転送するべく、Embulkでの差分転送をすることにしました。 やり方 差分だけBigQueryに転送する 基本的にはメルカリメソッドそのままです。いつもお世話になっております。 updated_atのような最終更新日時が
風音屋では、データエンジニア、データアナリスト、データコンサルタントを募集しています。 書籍執筆者やOSSコントリビューターなど、業界を代表する20名以上のアドバイザーと一緒にベストプラクティスを追求できる環境です。 ご興味のある方は、ぜひご応募ください。 風音屋 データエンジニアの濱田（@hrkhjp）です。 datatech-jp Advent Calendar 2023 の4日目の記事です。 本記事では、 Digdag / Embulk と、任意のバージョンの Python の両方をインストールした Docker イメージを作成する方法について解説します。 想定する要件 Python の Docker 公式イメージ以外のイメージをベースにする Digdag と Embulk を使うため、Java 8 が必要になる そのため、ベースイメージに eclipse-temurin:8-jre
はじめに データの高速処理に長けたDWH（データウェアハウス）へと統合、連携したBIツールでデータの可視化を行うというデータ分析基盤の構築にあたってキーワードになるのが「ETL」です。 初めてデータ分析を行うという方はまずはETLについて書かれたこちらをご覧になるとEmbulkについての理解が深まります。 このETLを行うには大きく分けて３つのやり方があり、 各サービスのデータをcsvなどの形式でダウンロードし、転送先のサービスに手動でアップロード 各サービスや各DWHのAPIを利用して自分でETL環境を構築 ETL用のフレームワークやサービスを利用 そのうち、今回はETL用のフレームワークからEmbulkについて解説します。 データ分析基盤の構築を検討している方はぜひご覧ください。 Embulkとは？ Embulkはトレジャーデータ株式会社が提供するオープンソースのETLツールで、Emb
はじめに EmbulkでTreasure Data(以降、TD)のテーブルからAWS S3にCSV出力しなくても、TDの機能で出力すればいいでしょ、と思いますが、TDの機能でCSV formatterなど制約があって少し不便な時があるようです。 本記事では、EmbulkでTDテーブルからAWS S3にCSV出力する方法を記載しました。そして、TDで現状できないダブルクォーテーションでデータを囲ったCSVの出力を確認します。 前提 バージョン Embulk v0.9.23 embulk-input-td v0.2.3 embulk-output-s3 v1.5.0 その他 TDをまあ知っている。 Embulkをまあ知っている。 TDでの制約 TD WorkflowのResult Setting、QueriesのExport Resultsでは以下の制約があります。 CSV formatter
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く