Those aren't OLAP replacements though, right? You would still need to manually build an OLAP db from the lower level to report on them. Maybe I'm wrong since I haven't used Azure...
Azure is our cloud provider. Interface is flexible, since our current implementation leverages Prisma ORM connected to Postgres & SQL Server. We're going to have to rebuild it anyway.
Heavy disclaimer; I'm a dev for MS azure notebooks team, but even prior to this role (and largely WHY I joined the team) is that I'd been using the notebooks in an analytics/devops role, managing dataset existence/movement/endpoint calls (the underlying work was rather mundane, forecasting/strategic analytics, textual analysis).
From a purely infrastructural side, the potential of that fusion is a large reason why we include the azure management libs out of box in our notebooks offering. Even from a non-azure-specific perspective, I found it very nice to be able to do things like "Oh I'm running an existing analytics script on a new team's target DB, let me run the cell that creates a new set of tables and blobs for that novel flow" and have that all within the same workspace and UX.
Perhaps obviously, it's not a replacement for all the sort of things you need ops scripts for, but of the class of "ad-hoc tasks"/"ops tasks relating heavily to the logical code" I found it made my life easier.
(After writing this I went poking around to see if I could follow this up with "real examples"; we have one of those mixed-mode examples I mention above in our own docs ([1] and [2]); again let me echo the very "my own team" bias warning :) All of what I'm discussing can be accomplished with core Jupyter, in some form or another.)
For all of the faults of Azure, they let you do this reporting directly in the Portal. You can slice and dice the data without having to spin up infrastructure.
In general I have issues with the Azure documentation. I can't put my finger on it as to why, but for some reason the information doesn't seem to be presented in coherent ways, it's often disconnected and gets outdated very quickly. I can't speak as to the performance of the drivers (in general using the database drivers or a gRPC/thrift equivalent should be better than REST), but I agree with the lack of SLAs.
The lack of SLAs in the documentation is one of the major issues we've had when assessing the suitability of Azure managed services (e.g. Postgres, Cosmos DB, Bus, Event Hubs, etc.). To Azure's defence (not sure I should be doing this), a lot of these services are new and they are made available before they are operationally ready. For example, I was looking at the SQL warehouse offering a few months back [0] and if you want to use it you'd have manually maintain the statistics of the DB to keep the query plans optimised. It just seems like more overhead than necessary.
You're probably getting downvoted just because of Azure, but you are right. ADX/Kusto and KQL is an extremely powerful query language that answers exactly what OP questions about SQL.
Here's an example of a KQL query that I have in my browser...
Things
| where DeviceTags has "Installed"
| order by LastHeardFromTimeStamp desc
| take 10
KQL also takes ideas from R's Tidyverse and magrittr package. It takes datasets and pipes them into a new function. Like this...
car_data <-
mtcars %>%
subset(hp > 100)
From the Microsoft auto downvoters out there, all Azure dashboards and infrastructure analytics run on KQL (think Graphana, but on Azure). There are billions of KQL queries executing continuously, so it is absolutely a good example of a non-SQL query language that is active and mature.
reply