@LucaJune: tak naprawdę zależy co tam robisz tym notebooku. Ale generalnie chodzi o to, żeby to było w miarę logicznie podzielone. Żeby jasno było widać twój ETL/ELT flow i np. jeden notebook odpowiadał jednemu outputowi docelowemu (np. przetworzonej tabeli) Np. jeżeli masz jeden notebook w którym ładujesz 5 tabelek (wymiarów np.) po kolei no to trochę to jest źle. Lepiej zrobić to odzielnie bo np. wtedy w pipelinach jesteś w stanie
@LucaJune: nie wiem jaki wolumen danych, nie wiem czy to spark notebook czy sql notebook. No jeśli zapisywanie do adls2 trwa długo to musisz sprawdzić jaki masz storage ustawiony, może cold tier? I czy ten sam region przede wszystkim co synapse. No i czy dane są popartycjonowanie jakoś sprytnie i w jakim formacie. Jeden duży .csv to zły pomysł. Powinno być wiele parquetów. Ale zbyt wiele małych plików to również zły
@cohontes: tak, wiem wiem. Spróbuję zrobić hybrid model czyli importowanie danych codziennie + querowanie live zmian i przetestuję też na dedicated poolu. Wychodzą drogo, ale pewnie zrobią robotę. Właśnie przeczytałem dokumentację serverlessa i sam Microsoft odradza, to co chciałem:

Consider caching the results on the client side by using Power BI import mode or Azure Analysis Services, and periodically refresh them. Serverless SQL pools can't provide an interactive experience in Power