<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>desflow on Jaehyeon Kim</title><link>https://jaehyeon.me/tags/desflow/</link><description>Recent content in desflow on Jaehyeon Kim</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Copyright © 2023-2026 Jaehyeon Kim. All Rights Reserved.</copyright><lastBuildDate>Tue, 06 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://jaehyeon.me/tags/desflow/index.xml" rel="self" type="application/rss+xml"/><item><title>Defining Data-Streaming Simulations in YAML, Without Writing Python</title><link>https://jaehyeon.me/blog/2026-10-06-simulations-in-yaml-dynamic-des/</link><pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-10-06-simulations-in-yaml-dynamic-des/</guid><description><![CDATA[<p>A pipeline is easier to test when its input behaves like production: orders arrive at random, queues grow, a machine slows down. A simulation can produce that data, but when the simulation is a Python program, every change is a code change. Someone who only wants to double an arrival rate has to read and edit code, and a reviewer has to check that nothing else moved. A file that holds only settings is easier to read, to compare in a pull request and to run in CI.</p>
<p><a href="https://github.com/jaehyeon-kim/dynamic-des" target="_blank" rel="noopener noreferrer">dynamic-des<i class="fas fa-external-link-square-alt ms-1"></i></a> 0.16.0 adds that file. A YAML blueprint describes the whole simulation, and the <code>ddes</code> command runs it. Each of the seven examples in the repository now has a YAML version in plain YAML. The documentation was rebuilt around the three ways to write a simulation.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2026-10-06-simulations-in-yaml-dynamic-des/featured.png" length="811910" type="image/png"/></item><item><title>Keeping Game Leaderboards Up to Date in Real Time with Kafka and Flink SQL</title><link>https://jaehyeon.me/blog/2026-10-02-game-leaderboard-flink-sql/</link><pubDate>Fri, 02 Oct 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-10-02-game-leaderboard-flink-sql/</guid><description>&lt;p>A mobile game produces a score every time a player finishes a round, and players expect the leaderboards to move as they play. In this post, a simulation plays the game and sends each score to Kafka. Four Flink SQL jobs keep four top 10 leaderboards up to date in PostgreSQL, and a web dashboard shows them as they change. Everything runs on your own machine.&lt;/p></description><enclosure url="https://jaehyeon.me/blog/2026-10-02-game-leaderboard-flink-sql/featured.png" length="451195" type="image/png"/></item><item><title>Change Data Capture on a Simulated Online Shop with Debezium and Kafka Connect</title><link>https://jaehyeon.me/blog/2026-10-01-ecommerce-cdc-debezium-kafka-connect/</link><pubDate>Thu, 01 Oct 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-10-01-ecommerce-cdc-debezium-kafka-connect/</guid><description>&lt;p>Most databases change all day: users sign up, orders are placed, and each order moves from one status to the next. Change data capture (CDC) turns those changes into a stream of events that other systems can read as they happen. In this post, a simulated online shop writes to PostgreSQL in real time, Debezium streams every change to Kafka, and a sink connector saves the changes as files in object storage. Everything runs on your own machine.&lt;/p></description><enclosure url="https://jaehyeon.me/blog/2026-10-01-ecommerce-cdc-debezium-kafka-connect/featured.png" length="583526" type="image/png"/></item><item><title>Data Streaming and Machine Learning Projects That Run on Your Laptop</title><link>https://jaehyeon.me/blog/2026-09-30-introducing-benchtop/</link><pubDate>Wed, 30 Sep 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-09-30-introducing-benchtop/</guid><description><![CDATA[<p>Reading about a data tool only goes so far. The hard part is getting several tools to run together and seeing how data moves between them. <a href="https://github.com/jaehyeon-kim/benchtop" target="_blank" rel="noopener noreferrer">Benchtop<i class="fas fa-external-link-square-alt ms-1"></i></a> is a collection of hands-on demos for data engineering, stream processing, machine learning, AI engineering and MLOps. Each demo runs locally on the odctl stack, and works from a fresh clone of the repository, with nothing to install beforehand but Docker and uv. Each one builds a working system from open-source tools and explains the ideas behind it, so you learn a tool by running it rather than only reading about it.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2026-09-30-introducing-benchtop/featured.png" length="15991" type="image/png"/></item><item><title>Learning MLOps with a Feature Store: A New Series</title><link>https://jaehyeon.me/blog/2026-09-28-mlops-with-a-feature-store/</link><pubDate>Mon, 28 Sep 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-09-28-mlops-with-a-feature-store/</guid><description><![CDATA[<p>Learning MLOps one tool at a time leaves out the hard part: how features, training and serving fit together as one system. This series learns it by building complete systems. I follow Jim Dowling&rsquo;s <a href="https://www.oreilly.com/library/view/building-machine-learning/9781098165222/" target="_blank" rel="noopener noreferrer"><em>Building Machine Learning Systems with a Feature Store</em><i class="fas fa-external-link-square-alt ms-1"></i></a> and rebuild its hands-on projects with open-source tools, running on my laptop.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2026-09-28-mlops-with-a-feature-store/featured.png" length="516299" type="image/png"/></item><item><title>Building an Agentic Analytics System over an Iceberg Lakehouse</title><link>https://jaehyeon.me/blog/2026-07-18-agentic-analytics-system/</link><pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-07-18-agentic-analytics-system/</guid><description><![CDATA[<p>Generative AI has made conversational analytics feel within reach, yet direct text-to-SQL systems remain hard to operate reliably. A database schema tells you the tables, columns, and types, but it says nothing about which datasets are canonical, which join paths are approved, how a governed metric is calculated, or what the business actually means by &ldquo;revenue&rdquo; or &ldquo;active customer&rdquo;. Ask a language model to infer all of that from raw tables and, sooner or later, it will confidently invent an answer.</p>
<p>I built a proof of concept to explore a more disciplined approach: put a semantic layer between the model and the data, and let the agent reason over governed business concepts instead of guessing at raw schemas. It runs entirely locally on an open-source stack, and it happens to tie together two of my other projects along the way.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2026-07-18-agentic-analytics-system/featured.png" length="160825" type="image/png"/></item><item><title>Dynamic DES: A Declarative API with Postgres and Redis Connectors</title><link>https://jaehyeon.me/blog/2026-07-17-dynamic-des-declarative-connectors/</link><pubDate>Fri, 17 Jul 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-07-17-dynamic-des-declarative-connectors/</guid><description><![CDATA[<p>Simulated data is most useful when the code that produces it is easy to read, and when it reaches the same places as production data, such as a PostgreSQL table or a Redis stream. Since I wrote about <a href="/blog/2026-05-25-dynamic-des-parquet-support/">Dynamic DES v0.8.1</a> and its data lake support, the project has grown in both directions: a cleaner way to write a simulation, and more places to send and receive data.</p>
<p>Here is what changed on the way to <strong>v0.11.1</strong>.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2026-07-17-dynamic-des-declarative-connectors/featured.png" length="64671" type="image/png"/></item><item><title>One Simulation, Two Pipelines: Batch Training and Live Inference with Dynamic DES</title><link>https://jaehyeon.me/blog/2026-05-25-dynamic-des-parquet-support/</link><pubDate>Mon, 25 May 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-05-25-dynamic-des-parquet-support/</guid><description>Training a machine learning model on simulated data is straightforward until you try to deploy it. The disconnect usually happens at the pipeline level: training requires massive, historical batch data (like Parquet files in an S3 bucket), but production inference requires real-time, event-driven streams (like Kafka or Redis).
Maintaining two separate simulation codebases, one for generating training data and another for streaming live events, introduces friction, schema mismatches, and duplicated engineering effort.</description><enclosure url="https://jaehyeon.me/blog/2026-05-25-dynamic-des-parquet-support/featured.png" length="168665" type="image/png"/></item><item><title>Building an Event-Driven Hybrid Digital Twin with dynamic-des</title><link>https://jaehyeon.me/blog/2026-04-28-digital-twin-dynamic-des/</link><pubDate>Wed, 29 Apr 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-04-28-digital-twin-dynamic-des/</guid><description>Asynchronous Gap A true Hybrid Digital Twin does more than just mirror reality. It actively forecasts the future by running a simulation against live operational states. We established this in Part 1.
If you have ever tried to build one of these systems from scratch, you immediately hit a fundamental architectural clash.
Standard simulation clocks (like those in traditional SimPy implementations) are logically synchronous and not designed to handle high-frequency asynchronous I/O without explicit decoupling.</description><enclosure url="https://jaehyeon.me/blog/2026-04-28-digital-twin-dynamic-des/featured.png" length="177036" type="image/png"/></item><item><title>Why Digital Twins Are Rewiring Industry 4.0</title><link>https://jaehyeon.me/blog/2026-04-23-digital-twin-industry-4-0/</link><pubDate>Wed, 22 Apr 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-04-23-digital-twin-industry-4-0/</guid><description>A simulation and a digital twin are often treated as the same thing, but they are built differently. A traditional simulation runs offline on assumed inputs. An operational digital twin stays aligned with one real system as it changes. This post walks through the layers that separate the two, and an event-driven hybrid that combines them.
Beyond CAD Models There is a project by Dassault Systèmes called the Living Heart that illustrates the trajectory of this technology.</description><enclosure url="https://jaehyeon.me/blog/2026-04-23-digital-twin-industry-4-0/featured.png" length="73776" type="image/png"/></item><item><title>Building a Real-Time Industrial Digital Twin with Apache Flink and Online Machine Learning</title><link>https://jaehyeon.me/blog/2026-04-21-digital-twin-online-machine-learning/</link><pubDate>Tue, 21 Apr 2026 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2026-04-21-digital-twin-online-machine-learning/</guid><description>Overview Imagine using a rolling pin to flatten out a thick piece of dough. A Hot Strip Mill does the exact same thing, but with glowing red-hot steel slabs (often heated over 1000°C) and massive mechanical rollers. The steel is passed through a series of these rollers, crushing it down from a thick block into a long, thin sheet.
Calculating the exact Rolling Force required to crush the steel is critical.</description><enclosure url="https://jaehyeon.me/blog/2026-04-21-digital-twin-online-machine-learning/featured.png" length="130846" type="image/png"/></item></channel></rss>