3 ms·

Perhaps I've missed it but my number one request for these tools is to support time series data and analyses (or other data "structures" in general). The focus

Perhaps I've missed it but my number one request for these tools is to support time series data and analyses (or other data "structures" in general). The focus on beautiful visualization and easy graphical interfaces is great, but thinking outside the tabular box would be very helpful.

wswope 2y ago
IME trying to use Tableau & kin for analysis, especially time-series work, is a case of holding the tool upside down: you can do it, but it’s not the intended use-case and you’re likely to wind up frustrated. The viz tools are just viz tools, and the real number crunching should ideally happen in SQL or a toolkit like Pandas/Polars/Spark/etc. - because they’re designed to do those computations efficiently and have a well-established, battle-tested syntax for it. YMMV, but I strongly encourage you to try keeping everything before final presentation and rendering OUT of the viz layer next time you have a chance.
- sroerick 2y ago
  Or you could take the “offshore Power BI asset” approach and compress as much program logic and transformation into the DAX and R layers as possible
- anakaine 2y ago
  I moved us away from Tableau towards a Python based stack for processing, in-memory structures for queries on data relevant in our typical time windows, and on demand retrieval from cloud into the same data structures for historic data. We were trying to handle 200m data points per day into a SQL database when I joined, and then display via Tableau for time and location series slicing in what were particularly complicated workbooks. To say that it was a terrible approach is an understatement. Adding detailed geospatial and meteological data to the mix, matching with IoT sensor data, other ETL data from.dispatch systems, and many more has basically required some custom thinking to make it all work in an efficient manner. My personal bug bear is that I still want great looking easy configuration for front end display of analytics dashboards. It becomes far harder to achieve when you go sufficiently far down the rabbit hole. I'm currently leaning towards python driven dashboards since we can connect them to a REST api which will talk to our data structures and keep everything humming along. Note: not a single database in use here - though the timeseries sensor data could use one.
  - mnky9800n 2y ago
    What do you work on? And where? That all sounds super interesting.
  - wswope 2y ago
    Yeah, time-series on that scale has unique requirements that can really cripple most DBs. > I'm currently leaning towards python driven dashboards since we can connect them to a REST api which will talk to our data structures and keep everything humming along. Give Bokeh a try if it's not already on your radar - I've found it to be really useful for composable & dynamic python dashboards: https://docs.bokeh.org/en/latest/index.html https://docs.bokeh.org/en/latest/index.html.
- lamename 2y ago
  We're actually in agreement. Lots of my time is doing what you suggest, which is why I wish there was a time series capable version

wswope 2y ago

IME trying to use Tableau & kin for analysis, especially time-series work, is a case of holding the tool upside down: you can do it, but it’s not the intended use-case and you’re likely to wind up frustrated. The viz tools are just viz tools, and the real number crunching should ideally happen in SQL or a toolkit like Pandas/Polars/Spark/etc. - because they’re designed to do those computations efficiently and have a well-established, battle-tested syntax for it. YMMV, but I strongly encourage you to try keeping everything before final presentation and rendering OUT of the viz layer next time you have a chance.

sroerick 2y ago
Or you could take the “offshore Power BI asset” approach and compress as much program logic and transformation into the DAX and R layers as possible
anakaine 2y ago
I moved us away from Tableau towards a Python based stack for processing, in-memory structures for queries on data relevant in our typical time windows, and on demand retrieval from cloud into the same data structures for historic data. We were trying to handle 200m data points per day into a SQL database when I joined, and then display via Tableau for time and location series slicing in what were particularly complicated workbooks. To say that it was a terrible approach is an understatement. Adding detailed geospatial and meteological data to the mix, matching with IoT sensor data, other ETL data from.dispatch systems, and many more has basically required some custom thinking to make it all work in an efficient manner. My personal bug bear is that I still want great looking easy configuration for front end display of analytics dashboards. It becomes far harder to achieve when you go sufficiently far down the rabbit hole. I'm currently leaning towards python driven dashboards since we can connect them to a REST api which will talk to our data structures and keep everything humming along. Note: not a single database in use here - though the timeseries sensor data could use one.
- mnky9800n 2y ago
  What do you work on? And where? That all sounds super interesting.
- wswope 2y ago
  Yeah, time-series on that scale has unique requirements that can really cripple most DBs. > I'm currently leaning towards python driven dashboards since we can connect them to a REST api which will talk to our data structures and keep everything humming along. Give Bokeh a try if it's not already on your radar - I've found it to be really useful for composable & dynamic python dashboards: https://docs.bokeh.org/en/latest/index.html https://docs.bokeh.org/en/latest/index.html.
lamename 2y ago
We're actually in agreement. Lots of my time is doing what you suggest, which is why I wish there was a time series capable version