yiksanchan
Code: https://github.com/yiksanchan/misbrands
Check it out!
What Does the Web3 Demo App by Cloudflare Do?
Google Translate: China Is Aids
A statement about my Scala open source work
A minimal site that Googles how selected tech companies design a system
On the future of Akka and Lightbend
The Past, Present, and Future of TiDB as an HTAP Database
On the Future of Play Framework
This SQL-intensive actually reminds me of the feature store solution by Splice Machine (https://splicemachine.com/press-releases/splice-machine-laun...). They implement a HTAP database and use that in a similar as you use PL/SQL. I had a writeup on this as well (https://yiksanchan.com/posts/splice-machine-feature-store)
> How do you handle historical backfill for new features?
Currently, our feature store doesn't come with inbuilt feature backfilling. In order to do that, some manual work needs to be done. We're working on a brand new version of feature store that hopefully addresses this need.
> Who is responsible for keeping the Flink jobs running: the data scientists, or do you have a separate streaming platform team?
We have a separate data infra team who is responsible for managing the YARN cluster for us.
> do they have a feature store with built in time-travel functionality?
My feature store hasn't supported time-travel yet. But many SaaS implementations do, including Tecton, Hopswork, Splice Machine, etc. Open source feature stores haven't implemented this critical feature AFAIK.
> Why I didn't write about it? Because it was implemented in PL/SQL running on Oracle ExaData and in SAS. No one cares about feature stores implemented with tech like that.
Haha, I do. Actually I am thinking about implementing feature stores using some "old-school" DB technology. By the way, just curious since I've never used PL/SQL: Are you able to implement the time-travel functionality using pure SQL?
> This thing reads like it was written a few years ago.
Yah the technology here is nothing novel, Hive, Kafka, Flink, Redis are around for years. What I find missing in the internet is that people who have been doing this for years are not writing about this. Uber has done a relatively good job on publishing how they build Michelangelo, but still, not enough details for outsiders to replicate.
> it takes time for the lessons in this article to be learnt by a large enough amount of people that it becomes humdrum.
Maybe :)
> two clients who built feature stores - one with an open-ended goal of enabling people and one because they had some specific things they wanted to achieve.
Could you add more color to this part, what are their goals and what do they end up achieving? I didn't fully get it.