I used to be an Oracle DBA ... but now I'm a Big Data guru
Dominic Connor shows you how to jump the bandwagon
As the demand for Oracle skills fades along with VB and as even Java loses its shine, the smart developer is looking at what will pay the bills for the next decade.
As an ITpro you have to bet your career every few years and Big Data is too obvious an opportunity to pass up. The problem being that it’s not a single product that you can cross-train into, but rather a new set of methods as well as tools.
You can’t handle the (Big) truth
Apparently I’m not the most valuable writer at The Reg, our wise leadership has crossed sales of adverts with click data to work that out. However, I’m too petty to tell you who is #1 because that is actionable data, since a rational response is a positive feedback loop pushing the parts of your business that make money and fixing or junking parts that don’t.
Talking to Duncan Ross, who evangelises Big Data for Teradata, I discover that the first skill you need to develop is the mindset of working out what would be good to know so that you can use it. Being interesting is necessary but not sufficient.
This illustrates that like most industry buzzwords, “Big” is a cynical spin on what should more often be called “awkward”. A billion rows of normalised data in a well-designed schema might be large, but it's hard to see a big pay packet coming from running an aggregate function like Average on it. To be a lucrative skill there has to be some pain that you can overcome for your patient employer.
Crossing databases can be deliciously hard and that’s why I commend it to you as a skill in which to invest. Easy skills may shine brightly for a while, but market forces (people reading this article and job ads) will drag your price down. This is far more than getting Oracle to coexist with SQL Server using toolsets like DTS, because increasingly a large percentage of your most useful data is in clouds - like BlackLine for accounts or Salesforce for (surprise) sales which can use SQL, as does your in-house HR DB. Be clear that they are each different flavours of SQL, with entities not in any kind of mutually consistent form. Also note that inter-cloud interoperability is still at a laughably primitive stage, so that’s your opening. Part of the joy of integration is that the set multiplies with each system you add to the mix - meaning there is lots of work to be done for which they will pay you.
We’ve been crossing databases together for decades, often with extra indexes, or massive slow batch imports of data followed by an equally slow (and often less than reliable) batch download. That’s not only clunky, but is rapidly going downhill as a career option and because it’s just you and me here, we can be honest about this.
YOU know how the Fat Controller (yes, it’s called that at one bank) sucks in data and no one else does, not well enough that they’d ever dare lose you. That’s good until the day that some jerk whispers “Hadoop” into the ear of your CIO. Then what you have are non-portable skills that can only be used in one firm which is phasing them out. This is so bad that you must be that jerk. It's better to be leading the charge than be ridden over and even if the project goes titsup, Hadoop is a pretty good word to have on your CV.
Hadoop’s open-sourciness and use of commodity hardware is both good and bad for your CV upgrade because this means the barrier to entry is a bit lower than it would be if learning the skill required access to a huge pile of expensive hardware and software. This means the clock has already started ticking quietly while the other seven million people who read this article pile in... Nevertheless, the value of this information won’t degrade anything like as fast as your expertise in proprietary system. As IT Pros we're always walking up the down escalator, but it’s best to pick one that’s moving slower and has fewer people in the way.
Sponsored: Are DLP and DTP still an issue?