Hadoop: When grownups do open source
theregister.co.uk
theregister.co.uk
He may have some points in there, but any real content is drowned by the noise of the baseless insults, ad-hominem attacks, and poor writing. The angry rant style can be made to work, but it needs to be backed up by actual skill at writing, and it definitely doesn't substitute for content.
This article makes me sad.
It may be bad writing, but that doesn't matter. It's good enough.
(Actually, I've been avoiding The Register for a few years now, but I gave them the benefit of the doubt when this appeared on hacker news. It was a mistake.)
Rants, raves, or a negative, cynical tone suggests an ill-conceived idea; it's likely an emotional reaction.
Edit: Oops, I totally misread your post. Sorry about that. For some reason I thought you were justifying the tone of the article. I hear that learning to read can solve this sort of problem ;-)
I agree that a good writer can discuss something without an angry rant, but I disagree that an angry/cynical tone implies an ill-conceived idea. I'd suggest that bad writers will try to use the angry rant format to hide the poverty of their ideas, but just as often a good writer will use it well as a rhetorical device, making an otherwise dull article more amusing, and driving home the important points. But either way, the format of the writing is (or rather, should be) secondary to the content.
Edit: Clarified what I wrote a bit
Does anyone disagree that an angry rant, as a rule of thumb, probably means an ill-conceived idea?
EDIT: If you misread my comment, that's my fault. I should have written better.
I don't think the article is great. But it -does- accomplish exactly what the author wants. People talk about it. It reaches the top of HN. And despite of our distaste of The Register... we still read it.
So when I say it's "Good enough" it just means it gets the job done. The purpose of the article is clearly attracting attention. Being ignored worse than being disliked, after all. And it does attract a lot of (negative) attention. The poor writing even contributes to the goal.
Along with the data processing framework, Doug Cutting also included a fault tolerant, replicated, distributed file system with Hadoop just because fuck you. -- I laughed!
Also, it makes fun of Ruby so another point for it.
It's unlikely this article is accurate or really serves any purpose whatsoever other than immature linkbaity sort of content, but that's fine with me because I never put it in the category of "real journalism."
"Starling is the Ruby-based messaging system that runs Twitter's backend. Yes, Twitter, the nonprofit web service known widely for its downtime, dropped its disaster-producing shitpile on the world."
(For the record I like Hadoop and Lucene.) I still remember the concurrency problems Lucene had a few years back which would result in index corruption (a lot of Java programmers experienced this). This was the reason that while I was excited about Hadoop when it 1st came out I was also hesistant. It was by the same guy who didn't fix concurrency problems for his previous major project - would history repeat itself? Well Hadoop first came out it had a similar problem which caused it to fail a task in some scenarios.
All of this may have been fixed by now, but I just want to show that nothing is perfect (regardless of language) and unless you are; you really shouldn't be a jerk about other people's hard work
I've setup a hadoop cluster for a start-up I am working in. Initial reason? The amount of incoming log data was getting too slow to process on a single machine and having had a single graduate course in distributed systems I knew a) what is required to go from a single script to a system distributed across nodes b) that I am not in the capacity (alone) to create this system in a time window that will meet business needs.
As a result, I saw hadoop as offering a solution to: implement a distribute process where by records are processes in parallel by multiple machines without having to worry about implementing locking and message passing; distribute disk seek times across a cluster of nodes, pool together disk space with ability to add disk space by simply adding new commodity machines to a cluster.
If you have these specific needs: a) need to rapidly and robustly process more data than a single machine can handle (think of it this way -- if you do data processing with a Perl script on a single machine, will the data be simply too old by the time the Perl script is done?) b) ability to add storage for new data without powering machines down c) the data is non-relational (i.e. you aren't exporting data from MySQL and then re-importing it again - if your data can be stored effectively inside a MySQL cluster and queried in a relational manner, you don't need to use hadoop).
Now, if you still think you need hadoop (in most of the cases, answer is "you don't"):
To get hadoop going minimally to be useful right away is actually almost trivial.
However, as your dataset grows, the amount of jobs and the size of the cluster grow as well as the expectation of hadoop to also be a reliable data store grow, you will run into plateaus that you'll need to overcome.
To answer your questions directly: - Getting it going is easy, trivial. Do it first on your desktop (if you run Linux directly, if not under VMWare). Process is straight forward. - Peeking into the source is not required to get it going - Pitfalls: * Use enough memory, JVM is a memory hog. Always make sure you have sufficient swap (4x your memory) * Find the optimal size of input data for your task (if you are using compressed files for input).
(Yes, I will write these learnings up eventually).
I'll give it a shot on my desktop to start - thanks for the tips!
(Another post on parameter settings and machine configurations for Hadoop cluster in the making, once that's done I'll post to news.y.c)
I actually think he makes one good point, that virtually no one actually needs to use MapReduce, let alone implement it, let alone write a blog tutorial on how to implement it. That said, virtually no one needs to write a compiler either, and yet understanding compilers (or even writing one) is not a waste.
Also, his comparison of a message queue (Starling) to MapReduce almost makes you wonder if he really understands MapReduce. Starling has nothing to do with MapReduce, and MapReduce is completely unrelated to Twitter's scaling problems.
Well, not really epic. Mini-series proportion is probably more apt.
-Classic.