4 comments

[ 2.6 ms ] story [ 22.5 ms ] thread
This article is nothing more than a thinly masked advert for Treasure Data.
It really isn't (Disclaimer: I work there and wrote the entry)

In fact, you can replace Treasure Data with anything that is:

1. Schemaless storage

2. Allows you to output results easily and reliably to MPP databases.

What I noticed is that a lot of people tout various MPP engines, cloud or on-premises, as the only storage layer with any queryable interface that they need, and we think that's a bad approach.

Some folks are starting to realize this. For example, here is an article by Martin Fowler: http://martinfowler.com/bliki/DataLake.html that talks about the concept of "data lake". The problem is, most data lakes are utterly inaccessible to the data scientist/analyst camps.

EDIT: some grammatical clarifications

I agree that the problem of schema rot is an issue, and I'm sure that Treasure Data is a great solution. I'm also sure you had good intentions posting this. However, that said your article reads like an advert rather than the kind of detailed technical explanation that HN readers deserve.

A visitor is probably looking for a technical answer to "How can I prevent schema rot?" and the only answer I see in this article is "Contact us to learn about Treasure Data".

If the technical details about how Treasure Data works and what it does under the covers beyond just sit between my app and RedShift were more prominent and the sales pitch was less prominent that would be fine. But instead it just looks like self promotion of an advert article.

Thanks for the good feedback.

>I agree that the problem of schema rot is an issue

I am glad to hear that, and as someone who once landed a patch on PHP (proof! https://bugs.php.net/bug.php?id=61124&edit=3), I feel terrible that it read like an advert. I will consider writing a more technically sound followup.

Curious: do you feel this "schema rot" pain today? If so, can you elaborate on it?