![]() ![]() There’s a team (of elves) that has info on people and their addresses. Let’s say we work at a logistics company that is arranging the deliveries (or, ya know, we’re Santa). It’s the time of year where home deliveries for gifts are probably the highest, and probably also the time with the most delays. Let’s imagine it’s the holiday season (which it was just recently). Finally, I’ll show you how to connect data from Panoply to Cumul.io to be used in your dashboards. I’ll walk through some of the most common problems you may have with messy data. However, it should give you an idea of what you can achieve with Panoply before getting into the data visualization step. I won’t be going into extreme levels of complexity (there are so many levels/types/layers to what ‘data modelling’ can be). In this blog, I will show you an example of how I achieved a simple level of data modelling on distributed data sources with Panoply. You can also have a look at this article on the importance of single source of truth, by Panoply! How? ![]() A data warehousing tool such as Panoply.io is a great way to achieve this. This means you refer to one source, rather than risking having multiple versions of the same data. When you come to the stage of thinking about these requirements, a good practice to consider is to make sure you have a single source of truth. You may also need to clean the data, making sure there are no errors or duplicates, and a number of other requirements depending on your use case. But you soon realize that you need to bring these databases together in some way, in order to achieve the analytics and visualizations you need. A Common Scenarioįor example, a common scenario is one where different sets of databases are managed or have been accumulated by different teams for various reasons. In most cases, it requires a deeper technical understanding of the existent data, and an idea of how it should be re-modelled to meet the requirements. Before you start creating dashboards using this data, a good idea is to start thinking about how that data might need to be re-modelled to achieve the insights you require. Ultimately, when there’s a need for an analytics/visualization layer, you most probably already have the data you want to analyze somewhere. Lastly and possibly most importantly, a single source of truth for your data would allow you to ensure consistency by avoiding error prone duplicates.Performant to your specific dashboard needs.By decoupling complex JOINs, data cleaning steps from within your data visualization tool, your designers can make sure they focus on building dashboards Ultimately, this reduces the complexity for your designers. Decoupled from your analytics and visualizations layer.Reusable and easy for your designers to implement dashboards and visualizations with.Why?Ĭreating a performant data model before adding your visualization layer allows you to make sure you model is built in such a way that it is: But before we get into that, let me give you some idea as to why you might want to start thinking about your data before you start a visualization step. In this blog post, I’ll go through a simple demo of how you can use Panoply in this respect. ![]() ![]() Cumul.io has connectors to a number of data sources that make this possible. Luckily, there are plenty of tools to help you unify and clean your data in some meaningful way, so you can leverage it to its full potential. It’s perfectly normal for you to arrive at this stage only to notice that your data is distributed across different places, doesn’t match in some cases and overall looks messy. A common pain point for anyone who needs a layer of analytics and visualizations for the data they’ve accumulated, is often getting that data ready to be used. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |