Choosing the right architecture and tools for your big data location analytics needs

In this ebook, we explore the different options and architectures to build and deploy software for visually analyzing big location data sets. We share the considerations we made (and are still making) at xyzt.ai with our technology and architecture.

The importance of good architecture

We take so much for granted these days. Think about this; at the touch of a button, you can look up the address of any place on earth, on a map, on your smartphone while walking down the street shopping. Amazing! However, how much engineering went into providing this value to you?

Mapping engines were developed to visualize the streets and places around you.
Databases were implemented and populated with Point of Interest data.
Satellites were engineered and launched to provide your cellphone with an estimate of its location on earth.
Cloud technologies ensure that you and other smartphone users can use the service simultaneously.

It took billions of engineering and research dollars to bring you the value of being able to search for that shop on your smartphone. Yet, we all take it for granted.

The combination of satellites, cloud servers, smartphone apps, and their interactions is called the system’s architecture. Think about how an architect designs and defines the structure and foundations of a house; your location lookup feature is possible not just because of these individual engineering feats but also by the architecture that combines them into a system.

In this article, I will not discuss the architecture of satellite systems or database engines. Instead, I will explore the different options and architectures to build and deploy software for visually analyzing big location data sets. Why? Because that is what we are building with xyzt.ai. In this whitepaper, I will share the considerations we made (and are still making) with our technology and architecture.

Architectural considerations

I have been a Computer Graphics professional for over 20 years and have seen many technologies emerge to visualize and analyze location data. Each of these technologies has its pros and cons. Interestingly, few tools scale while still allowing interactive analysis and visualization of all data.

To put things in perspective, I will outline the key design considerations we put forward when founding xyzt.ai:

Bring your own device (BYOD). Our technology should be accessible on any device, ranging from laptops to your iPad and even smartphones in your pocket.
Our technology should scale to billions of location records because our customers are dealing with this amount now, and data aggregation will only increase in the future.
Our solution should be interactive, easy to use, and beautiful to look at.

Designing an architecture that fulfills each of these individually is one thing, but we aim to achieve all three together. This means running on your iPhone, for billions of location records, with smooth and interactive interaction.

A fourth, more technical consideration is that we set out to fulfill these three together without needing a vast distributed server farm. Instead, our solution should scale to at least two billion data points on a single 4-core, 32Gb computer in the backend.

There are several dimensions to explore when defining and implementing an architecture for big data location visual analytics. Below are the top three that I will discuss in this article.

Client-side versus server-side visualization and analysis
Browser-based or dedicated clients
GPU acceleration or software implementation

Client-side versus server-side visualization and analysis

This is probably the most important architectural consideration. The architect can put algorithms to work server-side or client-side in a SaaS cloud-based visual analytics solution. This is the case for analysis and visualization. The pros and cons of each approach are outlined in the below matri

	Pros	Cons
Server-side algorithms	Algorithms operate close to the data; no large amounts of data need to be sent to the clients You only need a single implementation and don’t need to care about the plentitude of devices, operating systems, etc. that your customers use You can scale compute resources server-side transparently to the client It is easy to support low-end client hardware.	When multiple clients connect to your server, the server will need to be able to handle all computations Requires a way to make your algorithms interactive with network latency and bandwidth considerations GPU-enabled server nodes are still expensive When doing server-side visualization, it is easier to handle 2D than 3D Dependency on connectivity to the server
Client-side algorithms	You exploit the compute and visualization capabilities of your customers and avoid more heavy workloads on the server It is easier to make things interactive as you are less dependent on network throughput (at least when the client downloaded the data) Client-side visualization can be easily done in 2D and 3D with WebGL and supporting modern browsers.	Your solution will be able to handle a couple millions of data points but sending over your billions of records to each client is not feasible. You depend heavily on the capabilities of the client hardware and have no control over the compute resources

Going back to our three considerations (any device, billions of records, smooth and interactive user experience), you can see that these will influence the choice between server-side or client-side implementations. More on that in the next section but first to our second consideration - browser-based versus dedicated client implementations.

Browser-based or dedicated clients

When using Office 365, you probably use many of its tools in your browser but often switch to a dedicated desktop application. Even in these cloud-enabled times, we employ dedicated client software.

What option do you choose for a visual analytics tool or big data location intelligence architecture? The answer depends, and it is also related to the first dimension.

	Pros	Cons
Browser-based client	Your internet browser is probably the only app available on all your devices. The browser is the most evolved visualization technology on the market, with ample tools for UI development and 2D/3D visualization. You are forced to design an architecture with a clear model-view architecture. There is no installation step; your users can just browse to your solution. It is extremely easy to update and rollout bug fixes and new features.	Each tab in a browser is limited to a certain amount of resources, such as memory. Running in a browser can be slower than running a dedicated application. There is not just one browser, but at least a handful of common browsers to support.
Dedicated client	Access to much more resources, especially memory, but also GPU resources, multi-threading, etc.	The software needs to be downloaded and installed. Dependency on OS, hardware can lead to supporting a limited number of platforms or the need of multiple implementations with additional maintenance requirements. Less evolved tools to implement UIs, interaction flows, etc.

The final key dimension we discuss is considering whether to use GPU acceleration.

GPU acceleration or software implementation

The Graphics Processing Unit (GPU) has become powerful and can be used for visualization and analytics . These days, all our devices have a GPU, from your laptop to your smartphone. Many so-called big data visualization tools claim they can handle big data because of the GPU. The unfortunate truth is that it is the opposite; they often cannot handle big data because their solution is using the GPU . I’ll explain why, but first the matrix:

	Pros	Cons
GPU based implementations	Every client-side device these days has a GPU GPUs are made for visualization and for crunching numbers in a highly parallel way, so they can aid in providing fast and smooth user interactions They can handle 3D using z-buffering or ray tracing.	Server-side GPUs are expensive (e.g., on AWS EC2 they are at least double as expensive as non-GPU nodes) Implementing advanced algorithms using GPUs is often not easy and requires highly skilled engineers and a lot of development days GPU drivers and capabilities are vendor specific with a wide range of conformance and bugginess between vendors and driver versions GPUs are limited as well. In fact, for visualization they can typically handle millions of data points, not billions at interactive rates The bottleneck of the system is often latency in network and memory, which is not solved by using a GPU.
Software-based implementations	No GPU needed, so cheaper hardware-wise and easier to deploy server-side More flexibility in implementing specialized algorithms and visualizations. Probably easier to implement advanced algorithms exploiting language features and libraries. Can exploit multi-core CPUs to provide some level of parallelism	Hard to handle 3D at interactive rates Lower level of parallelism (10ns of cores versus 1000nds of cores). Can be slow, especially on lower-end hardware.

A visual analytics tool is not a big data tool because it uses a GPU. GPUs are limited as well, and in fact, they are quite limited for big data visualization. Tools that rely on the GPU client-side often claim to be big data visualization tools, but they crumble under a load of a couple of millions of data points. It needs more than a GPU to handle big location data sets.

To conclude, it is clear that the choice in architecture and tools is influenced by the pros and cons of the three dimensions above. Still, it is also clear that there is an interplay between the different dimensions.

The xyzt.ai architecture

How does xyzt.ai handle billions of records on your iPhone with smooth interaction when navigating and filtering your data? Did we choose for server-side or client-side, for browser-based or dedicated clients, for GPUs or not?

The answer is it is a mix. The xyzt.ai architecture is as follows:

We perform analytics and visualization close to the data. This means (mainly) server-side.
We use a browser-based client.
We use software implementations server-side and GPU implementations client-side.

Keeping the algorithms close to the data allows us to scale to billions of records without overloading the network or your devices with gigabytes or terabytes of downloads.

By using a browser-based implementation, we can run on your laptop and your iPhone.

Using server-side software implementations, we can be cost-effective and provide an affordable solution to your location analytics needs.

By using client-side GPU visualization, we can provide smooth and interactive UIs.

Does this hybrid architecture mean we need to make compromises? How can we keep interactivity when performing the computations and visualizations server-side? Well, that is where our expertise comes in. We developed custom data structures and algorithms specifically for time-based location data of the form (x, y, z, t, attributes) that allow us to handle billions of records while maintaining interactivity on any device.

Need advice on deciding on a big data visual analytics architecture? Get in touch.

More information

You can find us at www.xyzt.ai, try for yourself by registering here, or contact me at [email protected] for more information or a live demo.

Request a demo

Description of the form

If you want to learn more about how xyzt.ai can help you and your organization, please schedule a live demo with one of our experts. During the demo, we can discuss your requirements, answer any questions you may have, and review how our platform can benefit you.