I've done quite a bit of netsuite integration with PowerBI - although it's an old question, here's a quick brain-dump:
We were based around netsuite ODBC with an on-prem data gateway; however this was extremely slow - there seem to be rate limits, and there are some very low level driver problems with power BI being able to optmize the ODBC queries that aren't going to be fixed any time soon. The thirdparty ODBC drivers are a bit better for this (CData). However you're still shifting a lot of data around as PowerBI data partitioning isn't really compatible with netsuite, as records can be updated.
Rather than change to using the REST API (which would require a fair amount of custom work as there is specific paging and the schema is subtly different), we decided to use a simple thirdparty data integration system (Stitch) that supported NetSuite to incrementally replicate most of the data into a data-lake style database, and build the semantic model from there. For some of the less straightforward tables (e.g. where there's a filter needed to cut down volume), we use logic apps to schedule java azure functions (as they can use the jdbc driver for both NetSuite and the staging database). Deletions and transaction-line amendments are handled from the deletion table via a periodic clean-up process on the database.
It would be great to do something like this in Fabric pipelines into a data-lake, and while I hold out hope for a 3rd party connector marketplace to mature, Netsuite ODBC drivers aren't supported right now among other limitations. So we'd be back to managing a gateway and bespoke incremental refresh code.
One other tip is the NS tables are extremely wide, so make sure your semantic model build starts small just to cover your reporting and keep things from getting out of hand.
