Salesforce is buying Tableau for $15.7B

Post by initself » Mon, Jun 10, 2019, 9:27 PM UTC

remus wrote: post #156

kfk wrote: post #141

So I have to deal with both tools at my company. The reality is that it all feels so incomplete from a BI standpoint. Managers are throwing money at front end tools like Salesforce and Tableau, but the entire back end stack is still pretty much the same as 20-30 years ago (big expensive Oracle-ish databases). I think the development of Python and Jupyter and other less known things like Vega are much more interesting…

> the entire back end stack is still pretty much the same as 20-30 years ago (big expensive Oracle-ish databases). Other than the expensive part, is it really such a bad thing? I feel like relational databases are a pretty good fit for a wide set of use cases and have a huge amount of tooling.

Post by initself » Mon, Jun 10, 2019, 9:31 PM UTC

prepend wrote: post #234

kfk wrote: post #159

Earlier quoted context omitted.

The businesses are coming with requests that require complex SQL on millions of records of data that normally is sitting in various sources (warehouse, salesforce, etc.). Unless you hire expensive data engineers, you can't do this type of work reliably. You can stick things together with expensive GUI oriented prep tools like Alteryx, but you pay in reliability and, quite frankly, sleep. And forget IT, IT is so stuck…

Tableau has a data etl tool called “Prep” that helps with this problem. But it only goes so far. But I think that’s where the problem truly requires a data engineer.

Post by initself » Mon, Jun 10, 2019, 9:34 PM UTC

oarabbus_ wrote: post #214

anonu wrote: post #164

One thing I've had to remind myself of - coming from a CS/Engineering background similar to most folks on HN (I'm guessing) - is that there are 2 types of people: Those who program and those who don't. To me, Salesforce looks like a big shared Excel file with a bunch of sheets. Tableau... well I can do the same thing with some scripts or spin up a web server. To others, this tech is just magical. Pay the money, do th…

>well I can do the same thing with some scripts or spin up a web server. That's a massive waste of your time and effort. The maintenance costs become massive as well should you choose to create your own system. At the VERY least you should leverage existing free open-source tools such as Metabase or Superset or Dash, or free tools such as Google Data Studio or Mode Analytics, if you're not going to spend cash to get…

Post by matwood » Mon, Jun 10, 2019, 9:41 PM UTC

markus_zhang wrote: post #284

radicalbyte wrote: post #281

Earlier quoted context omitted.

Yes it is :) You have to normalize data taken from various sources of various age and complexity. So you really have to understand the data. You also have to really understand the questions. I've worked with (and on) lots of these tools and projects; the complexity is never in the frontend, it's dominated by getting the data, getting the data right and into the right format. If all you want in the end is a good looki…

from my humble experience if you have a sales or product team keeps pumping out spreadsheets in weird formats you need someone dedicating a few hours to get a proper etl, and if they are constantly changing the format or adding new things you need a dedicate person just for that. Modern tools like Python or Power Query are not enough for this eternal war.

Post by theyard » Mon, Jun 10, 2019, 9:43 PM UTC

prepend wrote: post #234

kfk wrote: post #159

Earlier quoted context omitted.

The businesses are coming with requests that require complex SQL on millions of records of data that normally is sitting in various sources (warehouse, salesforce, etc.). Unless you hire expensive data engineers, you can't do this type of work reliably. You can stick things together with expensive GUI oriented prep tools like Alteryx, but you pay in reliability and, quite frankly, sleep. And forget IT, IT is so stuck…

Tableau has a data etl tool called “Prep” that helps with this problem. But it only goes so far. But I think that’s where the problem truly requires a data engineer.