My advice: don't do it. Leave content that needs managing in a CMS. Content is not data. 

I have had several migrations to a headless cms and it just doesn't make sense if it is just to store content. You want publish dates, versions, urls, authors. workflows. images etc etc. Content is always in context and the editor or comunication professional wants to have control over the way the content is delivered.

Only developers have a mind set where storing content in a data lake makes sense. Not meaning to be offensive here but it is a different profession with a different view.

DNN is basically a decoupled CMS that allows for reuse as well but with all the features you want as a content manager.

I agree with Tycho. But there is always the exception, a sensible reason for using a datalake is to store data gathered by DNN, (logs or data forms or admin data, etc..) And move that to the datalake. It's then the datalake systems job to interpret the data and give sensible results that can be used for all kinds of data reporting.

My thought would be to use an API, leave the data in DNN and copy the required data to the datalake. Maybe the logs could move directly into an API in real time, by having a module created to do this. I use our bespoke modules to connect to the AWS API with our backups and data storage everyday, I presume a datalake will be much the same.

My feeling on datalakes are that they are nothing new, the concept has existed way before "datalake" name was attached to it. However, the big change is the way the data can now be interrogated by the AI tools that have been developed over the last few years. How much of an advantage that is for the company, is a matter of debate, but if the budget is there, why not try.

If copying the data into another data storage solution, then I'd suggest creating and maintaining forked providers for those specific features (e.g., SqlDataProvider and or DBLoggingProvider. Some people might take the "easier" or "obvious" solution of using database triggers or something instead. There are many downsides to that. This is especially true in environments where there isn't a formal DBA on staff and maintaining the database/data storage.