In Digdag, workflows are typically defined in YAML files with a “.dig” extension. Developers usually write these workflows, which consist of tasks to be executed. However, tasks can also be added dynamically using the Digdag Python API or by downloading a “.dig” file from a remote HTTP server and incorporating it as a subtask. This approach is useful when a web service or app generates customized workflow files based on web app conditions, allowing the workflow logic to be managed externally. You can add webhooks to make it reactive.
Tagged: Data Pipelines
You can set up a failure alert task _error in Digdag to alert you when a workflow fails. But sometimes you want to get an alert even if the task runs successfully but takes more time than expected. For this, you can use sla feature.
Embulk needs a YAML file configuration for each data load. It’s a simple format, very human-readable. But there are cases where I want the YAML files to generate dynamically. Embulk does support an experimental feature that involves liquid templates. But my team is well versed in Python and Jinja2. Hence that is what we use.
We have a data stack that we have been using for years now. We have used it with medium to large customers, and they have worked very well. The goal has always been simple, stable, composable tools that can be used on the developer’s machine and scaled to work with massive data on production. You can self-host them, host them on the cloud, or get managed services based on your need.
Very similar to my web stack. It’s called “Boring” not because it’s dull but because there are minimal unwanted surprises. So my current stack for data looks like this. This stack is both “Modern” and “Boring.”
Embulk is a bulk data loader. It helps transfer data between different types of databases, storages, file formats, cloud services, etc. It’s like a Unix tool. It’s simple, robust, and works well with other tools.