A Fine Slice Of SQL Server
Mark Litwintschik does some plotting:
In this post, I’m going to extract Monaco’s road network data from OpenStreetMap, import it into PostgreSQL and render it out using a minimalist tile server. I’ll also show how the Formula 1 circuit can be highlighted using an open source geospatial desktop application.
Click through for the code and the end result in pg_tileserv and QGIS.
Comments closedHyukjin Kwon, et al, lay out some monitoring advice:
Streaming is one of the most important data processing techniques for ingestion and analysis. It provides users and developers with low latency and real-time data processing capabilities for analytics and triggering actions. However, monitoring streaming data workloads is challenging because the data is continuously processed as it arrives. Because of this always-on nature of stream processing, it is harder to troubleshoot problems during development and production without real-time metrics, alerting and dashboarding.
Read on to see how you can use the Observable API for alerting in PySpark—previously, it had been a Scala-only API.
Comments closedRobert Cain continues a series on the Kusto Query Language:
So far in my Fun With KQL series, we have used the column tool, found on the right side of the output pane and described in my original post Fun With KQL – The Kusto Query Language, to arrange and reduce the number of columns in the output.
We can actually limit the number of columns, as well as set their order, right within our KQL query. To accomplish this we use the
projectoperator.
Read on for several good uses of the project operator.
Kevin Wilkie explains what distributed transactions are and why you probably don’t want to use them:
In the version of transactions that we going to discuss today, we’re going to discuss doing transactions on multiple servers!
A Distributed transaction is defined by HazelSet to be “a set of operations on data that is performed across two or more data repositories”. In even simpler terms, it’s a command run against data on more than one server.
Click through for the warnings about what might possibly go wrong.
Comments closedJared Poche explains my favorite type of join:
Nested loops joins are the join operator you are likely to see the most often. It tends to operate best on smaller data sets, especially when the first of the two tables being joined has a small data set.
In row mode, the first table returns rows one at a time to the join operator. The join operator then performs a seek\scan against the second table for each row passed in from the first table. It searches that table based on the data provided by the first table, and the columns defined in our ON or WHERE clauses.
Read on for more information about nested loop joins.
Comments closedDinesh Asanka wants to verify some Type 2 slowly changing dimension results:
As we discussed in a previous article, Implementing Slowly Changing Dimensions (SCDs) in Data Warehouses, there are three main types of slowly changing dimensions, such as Type 1, Type 2, and Type 3. Out of these Type 1 is the simple dimension where you will simply maintain only the latest version of the attribute. For example, if the employee got promoted to Senior Software Engineer from Software Engineer, you will simply overwrite the existing value to the new value so that the historical aspect is lost.
Type 2 Slowly Changing Dimensions are used to track historical data in a data warehouse. This is the most common approach in dimension. This article uses a sample database of AdventureworksDW which is the sample database for the data warehouse.
Click through for one way to compare, one which you could build using dynamic SQL.
Comments closed