kafka-delta-ingest VS dipa

Rust can offer incredible cost savings when you can use it in place of spark to interact with your delta lake. One such project was kafka-delta-ingest. The developers were able to reduce the cost of running the pipeline by over 90%. However, most of this stuff is still very experimental and not ready for production but you will definitely be seeing more projects like this just based on how much money can be saved.

This independence from a catalog allows for path based reads and writes. This is handy when writing from Kafka directly to Delta Lake for the first layer of ingestion. You don’t need a catalog (or even Spark). https://github.com/delta-io/kafka-delta-ingest/tree/main/src

As far as I know no. You certainly could use events on a streaming ledger like Kafka or Redpanda and then store to delta with https://github.com/delta-io/kafka-delta-ingest and process them with all the gis goodness of spark. However, this is fairly complicated and much different from a simple postgis drop in replacement. There are specialized meaning faster and more efficient systems out there for specialized tasks such as geo fencing in real-time

kafka-delta-ingest is a good project to get streaming data into a Delta Lake. Here's a great talk on the topic.

What about https://github.com/delta-io/kafka-delta-ingest?

Have you seen https://github.com/chinedufn/dipa or https://docs.rs/serde-diff? I haven’t used either yet but they sound similar.

You could use something like this: https://github.com/chinedufn/dipa

For diffing, I used json patch, which allows me to have a history of changes in an easy to serialize manner. There are other more efficient and space saving diffing libraries, such as this new one: https://github.com/chinedufn/dipa, however I found json patch is supported in a number of languages, easy to read and store in a db.

So I started working on dipa in 2019, took over a year and a half away from it and then came back and finished it over the last few weeks.