Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # user >> risks of using Hadoop

Copy link to this message
RE: risks of using Hadoop


Normally someone who has a personal beef with someone will take it offline and deal with it.
Clearly manners aren't your strong point... unfortunately making me respond to you in public.

Since you asked, no, I don't have any beefs with IBM. In fact, I happen to have quite a few friends within IBM's IM pillar. (although many seem to taking Elvis' advice and left the building...)

What I do have a problem with is you and your response to the posts in this thread.

Its bad enough that you really don't know what you're talking about. But this is compounded by the fact that your posts end with your job title seems to indicate that you are a thought leader from a well known, brand name company.  So unlike some schmuck off the street, because of your job title, someone may actually pay attention to you and take what you say at face value.

The issue at hand is that the OP wanted to know the risks so that he can address them to give his pointy haired stake holders a warm fuzzy feeling.
SPOF isn't a risk, but a point of FUD that is constantly being brought out by people who have an alternative that they wanted to promote.
Brian pretty much put it in to perspective. You attempted to correct him, and while Brian was polite, I'm not.  Why? Because I happen to know of enough people who still think that what BS IBM trots out must be true and taken at face value.

I think you're more concerned with making an appearance than you are with anyone having a good experience. No offense, but again, you're not someone who has actual hands on experience so you're not in position to give advice.  I don't know to write what you say out of being arrogant, but I have to wonder if you actually paid attention in your SSM class. Raising FUD and non issues as risk doesn't help anyone promote Hadoop, regardless of the vendor.  What it does is cause the stakeholders reason to pause. Overstating risks can cause just as much harm as over promising results.  Again, its Sales 101. Perhaps you're still trying to convert these folks off Hadoop on to IBM's DB2? No wait, that was someone else... and it wasn't Hadoop, it was Informix. (Sorry to the list, that was an inside joke that probably went over Tom's head, but for someone's  benefit.)

To help drill the point of the issue home...
1) Look at MapR, an IBM competitor who's derivative already solves this SPOF problem.
2) Look at how to set up a cluster (Apache, HortonWorks, Cloudera) where you can mitigate this by your node configuration along with simple sysadmin tricks like NFS mounting a drive from a different machine within the cluster (Preferably a different rack for a back up.)
3) Think about your backup and recovery of your Name Node's files.

There's more, and I would encourage you to actually talk to a professional before giving out advice. ;-)



PS. My last PS talked about the big power switch in a switch box in the machine room that cuts the power. (When its a lever, do you really need to tell someone that its not a light switch? And I guess you could padlock it too....) Seriously, there is more risk to data loss and corruption based on luser issues than there is of a SPOF (NN failure).
> Subject: RE: risks of using Hadoop
> Date: Wed, 21 Sep 2011 06:20:53 -0700
> I am truly sorry if at some point in your life someone dropped an IBM logo
> on your head and it left a dent - but you are being a jerk.
> Right after you were engaging in your usual condescension a person from
> Xerox posted on the very issue you were blowing off. Things happen. To any
> system.
> I'm not knocking Hadoop - and frankly making sure new users have a good
> experience based on the real things that need to be aware of / manage is
> in everyone's interests here to grow the footprint.
> Please take note that no where in here have I ever said anything to
> discourage Hadoop deployments/use or anything that is vendor specific.