Help with recursive dataflow

Hi @imelendez 

Will the historical dataset increase in size or is it static? (Will it pull in 3 weeks + 1 day ago or be stuck at the end date where you first pulled the historical data?)

What is your lookback_date? Is that going to be the current date or are you allowing the user to filter based on that date?

If it's based on the current date then typically what I'd do is have two dataflows a historical and a live version.

(In my example the data can continue to update / change for 28 days)

The historical version would pull the data via SQL from 29 days ago.

select *
from `table`
where current_date - interval '29' day = DATE(`date`)

I then make sure I set the dataset to append rather than replace. This allows us to save time not having to import the entire dataset over and over (and should make querying faster assuming you have the proper indexes / partitions in place)

The live dataset pulls the data from the last 28 days (typically I'll exclude the current date since it isn't finished yet and it only runs once a day)

select *
from `table`
where DATE(`date`) >= current_date  - interval '28' day
and DATE(`date`) < current_date

I set this one to be replace so it'll overwrite the current dataset and keep things up to date.

Once those are in place I'll do a simple dataflow to append the two datasets together.

@GrantSmith gave a very nice walkthrough so not too much more to add. If you haven't looked that the KB article, it gives a nice step by step guide that may help you.

https://knowledge.domo.com/Prepare/DataFlow_Tips_and_Tricks/Creating_a_Recursive%2F%2FSnapshot_SQL_DataFlow

You can also do recursive dataflows in Magic ETL. Here is the KB article for Magic ETL.

https://knowledge.domo.com/Prepare/DataFlow_Tips_and_Tricks/Creating_a_Recursive%2F%2FSnapshot_ETL_DataFlow

Sorry late to the game!  But my ten cents.  Don't build a recursive dataflow.

Yes, a recursive dataflow will work for your use case, but recursive dataflows don't scale with data volume.  If we're talking 100M+ row datasets, you'll start having to wait in excess of 20 minutes to i've seen 5, 10 and 23.999 hours.  (23.999 b/c Domo kills dataflows that take longer than a day.

RDs are fine with small dattasets, but if it's going to get huge, you'll want to do something else.

Why don't RDs scale?

B/c every time you run an RD dataflow, the ETL has to transfer your entire dataset to the ETL engine, transform the dataset, then write the entire dataset to disk (Vault).  then transfer the dataset to Domo's database layer (Adrenaline). 

Imagine you have a 100M row historical dataset, and a 10k row new_data.  You have to transform 100M+10k rows... every day.  This can get ugly fast.

TLDR:  the better solution

Ask your CSM about Data Assembler or UPSERT.  

With Data Assembler, your historical dataset gets chunked into partitions (imagine old-school encyclopedia books partitioned by date).  When you get new data, data assembler says "what partitions (new dates) exist in  my new data?"  If that partition already exists in my historical data, DROP the existing partition, and replace with New Partition.

Domo can run this operation much faster because it only has to delete the encyclopedia volume and replace it with a new volume.  Because the volumes are stored as separate files, it's figuratively just a case of replacing a file.

UPSERT works like a MERGE statement in SQL if your historical_data table has a 'primary key'.  when you load new data, Domo asks "does this primary key already exist in my historical table?  if yes, then replace the row, if no, then create a new row.

https://docs.microsoft.com/en-us/sql/t-sql/statements/merge-transact-sql?view=sql-server-ver15

Both UPSERT and DA are much faster than recursive dataflows because you write significantly less data as your data volumes get larger and larger.