How do you guys handle the constant shifting of analytic schema that happens when handling a fast iterating application?
Why We Chose Redshift
21–30 of 45 posts
Re: Why We Chose Redshift
#22Curious if your funnels are just queries directly in Redshift or if there's more going on behind the scenes.
Amplitude here - Most of our dashboards are powered separately from Redshift. We offer Redshift access as a way for our customers to answer more complex questions not offered by the dashboards.
Why not power your dashboards with it? What do you use?
I am considering using a columnar data store (maybe redshift) with a BI tool like bimeanalytics.com specifically to do dashboards.
Re: Why We Chose Redshift
#23Curious if your funnels are just queries directly in Redshift or if there's more going on behind the scenes.
Amplitude here - Most of our dashboards are powered separately from Redshift. We offer Redshift access as a way for our customers to answer more complex questions not offered by the dashboards.
[deleted]
Re: Why We Chose Redshift
#24Redshift is like a prison, but with excellent accommodations. It's a great platform but it pretty much the perfect example of vendor lock-in.
How is Redshift a vendor-lock in though?
Put your data in S3, in csv/tsv/json format, if you want to switch to other provider, just figure out how to import it, and your are all set. How to figure out the limitation of the different platforms and tuning and optimizing is the difficult part.
Data migration is almost always painful and time-spending. When choosing your data provider, you have to be careful because it is very likely to be a long-term commitment. In that sense, in DW world there is always vendor lock-in. Only it is largely driven by the essence of the application itself, less so by the intention of the provider.
Re: Why We Chose Redshift
#25Is each customer given their own redshift cluster for their data?
Re: Why We Chose Redshift
#26Earlier quoted context omitted.
If we took a poll I suspect the majority would be thinking of the Amazon service - I know I was. The date the projects were introduced isn't necessarily relevant.
The UI colorizer is what I thought of immediately, too. If we took a poll I suspect the majority would be thinking of the Amazon service That's just personal projection, and is as irrelevant as an argument beginning with, "I think most people would agree that..." Personally, regardless of Amazon vs UI hack, I'm really tired of ambiguous naming in tech projects.
I'm much more tired of comments on ambiguous naming. There are at least two other people in my city who have my name, and many more who share either my first or last name. Somehow life goes on and this is not a topic of major controversy. But when two pieces of software have similar names, people just can't resist commenting endlessly and upvoting this content-free bikeshedding at the expense of actual discussion.
Re: Why We Chose Redshift
#27Earlier quoted context omitted.
Yeah, but a data warehouse isn't supposed to have great response times. Data warehouses are for large, low-value sets of historical data that you don't always know how you want to use. If you want to use data in real-time, you should be driving it from your transactional systems. Redshift and other data warehouse solutions are for doing reporting and dashboards, not triggering real-time reactions.
Well, used to be true, but now those systems are converging. -- Full disclosure, I work for a company working on exactly that problem called Treasure Data.
Most companies are generally more concerned about reducing their data warehouse costs than they are about improving the performance of their data warehouses. Many companies implement a multi-tiered DW structure to get a mix of the two, but the core driver is managing the cost of storing petabytes of data while keeping performance acceptable.
Re: Why We Chose Redshift
#28[deleted]
Re: Why We Chose Redshift
#29[deleted]
Re: Why We Chose Redshift
#30Is each customer given their own redshift cluster for their data?
No, clusters are multi-tenant. We have a cap on the number of customers per cluster and we monitor usage to make sure no one customer is hammering the cluster.