That did it. I tweeted, in succession:

• Actually, I vote for Hadoop as the lungs of the EDW — first place of entry for essential nutrients.
• Data integration can be the heart of the EDW, pumping stuff around. RDBMS/analytic platform can be the brain.
• iPad-based dashboards that may engender envy, but which actually are only used occasionally and briefly … well, you get the picture.*

*Woody Allen said in Sleeper that the brain was his second-favorite organ.

Of course, that body of work was quickly challenged. Responses included: 

• Re: your metaphor, oxygen is used in the combustion process that turns nutrients into energy, so Hadoop is more mouth-ish* (Seth Grimes)
• Data Quality/Governance can be the liver, filtering out toxins (Josep di Paolantonio)
• what’s nice is that BI (DSS) used to be the colon, but now it’s the Krebs Cycle (Neil Raden)

*Linda agrees with me that oxygen is a nutrient, and she’s taught both physiology and English at the college level.

But seriously, folks — I disagree with Jim’s follow-up post a lot less than I do the first one. He’s still overstating the case, of course, and he still seems confused about how some of the pieces of technology work. Even so, I agree that Hadoop is likely to play an important role in many enterprises’ analytic ecosystems, both for its big bit bucket and parallel analytics capabilities.

Meanwhile, in unrelated puns, Chris Kanaracus and I had something of a pizza party:

“Too many [midsized] businesses’ ideas for slicing data don’t get far past the pie-chart level,” said analyst Curt Monash of Monash Research. “‘Big data’ isn’t even the issue for them; they could get much more value than they do now just from personal-sized data sets.”

That’s not the case with Northeast pizza chain Papa Gino’s, which is using IBM analytics software to crunch business data in many ways, said Martha Lieber, director of business systems for the 280-restaurant company, which also includes a number of D’Angelo sandwich shops.

This work has resulted in some delicious insights …

That post seemed to go over well, even if I’m a little disappointed at how few people joined in with stories of their own. So I’m opting for strange-but-true this year also, just more aligned with the usual subjects of my blogging. And thus, without further ado, here’s the story of

The client that was confused about security

It’s a consulting rule of thumb that what a client thinks they’re hiring you to help with often isn’t their biggest issue. I’ve been hired to help decide which columnar DBMS should replace Oracle Standard Edition in a CRM SaaS application, only to discover that the real issue was handling 50,000 updates/minute (a couple of years ago, before there were good NoSQL alternatives). I’ve been hired to help decide whether Exadata or a columnar DBMS should replace Oracle Standard Edition in a CRM SaaS application, only to discover that the real issue was each web page request spawned 400 short-running queries — if not 1600 — in a loop.

Yeah, our user clients are often software sellers, SaaS or otherwise.

Based on those examples and many more, the description of our services for users will evolve to increasingly stress consulting, listening, discovering what the real problem is, uncovering surprises, getting colleagues to talk to each other, and all that touchy-feely stuff.  I think we do that better than anybody else, in part because of consulting style and skills, but also because I have the breadth of knowledge needed to have a chance at pulling it off.

Hey — if you think you understand all your potential future scenarios perfectly, and just want a quick sanity check to see if you missed something on your vendor short list, we’re up for that too. Just don’t be flabbergasted if what you choose and implement isn’t meeting your needs two years down the road.

But on with the story. My best example of all may be one from late in the previous century. (1996, if I recall correctly.) Along with database technology, I was then an expert on application development tools, and so I got a gig helping a large Swiss bank* decide among several different fourth-generation languages. Lots of variability in tech savvy there; when they took me down Mahogany Row to meet execs, the EVP of sales crawled out from under a desk where he’d been doing PC support for his secretary. Anyhow, it was six days of work at $10K/day. Sweet deal.

*Not a software-seller client! Whoops, never mind — a big part of why I was there was to help decide whether to spin their internal software out into a separate line of business.

There was the usual religious conflict about competing programming languages, but that was all manageable. The really big debate was that some people had gotten the idea that, for security reasons, the application shouldn’t be client/server at all; rather, it should rely on X terminals (X terminals were like what might be called a thin client today, but too dumb to be useful). For security. At great cost in application functionality. One thing I wasn’t much of an expert on in those days was security, but that struck me as pretty wrong-headed even so.

Ironically, I’d been brought into the project by Charles Wang of Computer Associates, which in those days passed as a leader in security technology. The bank in question had let CA a couple billion dollars, and its CEO had asked him for the favor of some advice as to who to hire as a consultant.

When I pressed the issue, it turned out that the group I was working with thought the X terminal idea was silly too, but the security guys were insisting on it. I suggested that they might have misunderstood, and we should maybe ask the security folks to make sure. They got a security guy on a conference call accordingly; he had no idea why anybody would be opposed to PCs on a security basis; and poof — the problem was solved.

So the best thing I did in the whole engagement was get different people at the client to talk with and listen to each other. Not a shock. As a second-generation consultant, I learned that trick from my parents.

My principal contact let on that this outcome wasn’t really surprising. After all, he opined, any security system could be defeated just by spending however much money was required to suborn a clerk. You could wonder why one crooked clerk sufficed, but otherwise he surely had a point in those pre-web-hacking days. Anyhow, the security problem was put to bed, I threw cold water on the idea of spinning out the banking application software they hadn’t even decided how to build yet, a reasonable course was set for picking application development tools, and everybody was happy.

Some months later, I noticed a small article about the bank in the newspaper — one still read from dead trees in those days — and guess what? That EVP of sales I’d seen crawling out from under a desk had been convicted of embezzling from the bank.

Obviously, the choice between PCs and X-terminals had been the least of their security problems.

• HP hired a software guy, Leo Apotheker, as CEO, and a software guy with a liking for high-end services, Ray Lane, as chairman. Now a Leo Apotheker conference call suggests HP will increase its emphasis on software, and maybe high-end services as well. No surprise. The article suggests, however,  that HP at this point has no clear strategy along these lines. That’s no surprise either.
  • And then there’s Sarah Lacy’s take, of which the interesting part reads “Separately, Andreessen has said that he thinks enterprise software is ripe for disruption and his firm is going to fund a new generation of Oracle-killers.”
  • I added more on Ray Lane’s tenure at Oracle over on Software Memories.
• Netezza had a falling out with its original supplier of geospatial technology, Intelligent Integration Systems (IISi), and a lawsuit ensued over alleged copying. Now ISSi has upped the stakes, essentially alleging that Netezza’s new geospatial software doesn’t work, and that hence the CIA (evidently a Netezza user) is killing the wrong people via drone strikes. Netezza has wisely selected from its short list of acceptable responses, including versions of:
  • “All our classified customers are happy, and if we told you anything more than that, that would kind of defeat the purpose of being classified, wouldn’t it?”
  • “Copy, schmopy. A polygon is a polygon, and has been since Euclid.”
  • “We don’t have no steenking bugs.”
• OCZ, whoever they are, are trying to offer solid-state drives with PCIe-like bandwidth, which makes sense in that most observers except Teradata think the SAS interface isn’t fast enough for solid-state.
• Speaking of Teradata, I’d been wondering somewhat as to why they just shut down Kickfire’s product line after acquiring its assets. Well, somebody who tested a Kickfire box told me that — great TPC-H results notwithstanding — it turned out not to be nearly as fast as one might think, on real-life data sets that didn’t fit entirely into RAM. Hard though such a thing may be to imagine, it turns out that Kickfire’s TPC-H results were yet less significant than I thought they were.
• I haven’t been looking at High Scalability nearly as much as I should, and that’s an understatement. It’s an outstanding blog.
• A couple of Google execs offered some predictions about the future of online advertising, which might be of interest to anybody selling analytic (or text analytic) technology to the online/digital media market.
• The BBC shows us what a single 133-character tweet plus its metadata look like in JSON. (All 1582 characters.)
• Huffington Post’s CEO made some comments about influencers which are additive to what I’ve been saying about influencers over on Strategic Messaging. (If you don’t read that — well, it’s my blog about marketing.)
  
• Speaking of my other blogs, I’m not bothering to put up a separate post like this over on Text Technologies, where thee posts I have put up recently tend to be (at least by my standards) relatively link-heavy anyway, but I have a couple more to share even so:
  • Paul Carr’s 7 rules for TechCrunch/AOL employees are really funny.
  • Some major search engine marketing experts are sounding defeatist about web spam.

• Neil Raden points out that business intelligence dashboards can be dangerously misleading. His reasoning (sound) is that whatever you measure is apt to be distorted by the fact people know they’re being measured. His solution (implied) is to hire a good-looking consultant like himself to do it right.
• I’ve had my issues with Fred Holahan, who was VP of Marketing when I posted that EnterpriseDB was not to be trusted. (That said, Fred is long gone from EnterpriseDB and my opinion hasn’t changed.) But he’s put up a good series of posts on the basis of the open source “progressive engagement” marketing funnel, including this gem on why you shouldn’t count on monetizing your community/free users.
• Oracle plans to increase its acquisition budget. The figure given is $70 billion over the next 5 years. Edit: But see this funny Register followup.
• Clayton Christensen wrote a phenomenal article on how to live a good life, from a very business-y perspective. (Only in one anecdote was it too religiously-oriented for my tastes.) Takeaways include:
  • Your core goals probably revolve around something other than business success. (E.g., family.) Don’t lose sight of that.
  • To the extent you’re a manager or leader, you may have a huge impact on other people’s lives. Use that power in admirable ways.
  • Teach people how to fish for answers, rather than just giving them answers. They’ll probably come to better conclusions than you would have anyway. (This is a core principle in my own consulting.)
  • Take time to reflect. And by the way, the same techniques you use for strategic analysis in business can be applied to your life as well.
• Mark Suster has a pretty good post expanding on my first Christensen takeaway, highlighting a point too often missing from articles in that genre: It’s not just family; it’s also all the cool things around us.
• I haven’t gone through the Hadoop Summit archives yet, but it looks as if there’s a lot of insight there about current Hadoop application activity.
• If you’re a cat lover and don’t hate simple/traditional music, check out Marc Gunn’s cat filksongs, especially the infectious “What Shall We Do With a Catnipped Kitty?” and “Lord of the Pounce”, both playable from the right sidebar of that page (#7 and #10 respectively). Gunn is also a chief perpetrator of the justly (in)famous Do Virgins Taste Better? cycle of filksongs.
• Former SAP exec Dennis Moore offers a theory as to why SAP cares so much about in-memory DBMS. It’s to integrate business processes, because SAP has no other software layer good at doing same. Interestingly, Dennis originated SAP’s previous attempt at meeting a similar need via its composite applications initiative. However, in Dennis’ view this benefit would only be achieved by a major rewrite of SAP’s applications.

Have you heard of the wonderful one-hoss shay,
That was built in such a logical way
It ran a hundred years to a day,
And then, of a sudden, it — ah, but stay,
I’ll tell you what happened without delay,
Scaring the parson into fits,
Frightening people out of their wits, –
Have you ever heard of that, I say?

Seventeen hundred and fifty-five.
Georgius Secundus was then alive, –
Snuffy old drone from the German hive.
That was the year when Lisbon-town
Saw the earth open and gulp her down,
And Braddock’s army was done so brown,
Left without a scalp to its crown.
It was on the terrible Earthquake-day
That the Deacon finished the one-hoss shay.

Now in building of chaises, I tell you what,
There is always somewhere a weakest spot, –
In hub, tire, felloe, in spring or thill,
In panel, or crossbar, or floor, or sill,
In screw, bolt, thoroughbrace, — lurking still,
Find it somewhere you must and will, –
Above or below, or within or without, –
And that’s the reason, beyond a doubt,
A chaise breaks down, but doesn’t wear out.

But the Deacon swore (as Deacons do,
With an “I dew vum,” or an “I tell yeou”)
He would build one shay to beat the taown
‘N’ the keounty ‘n’ all the kentry raoun’;
It should be so built that it could n’ break daown:
“Fur,” said the Deacon, “‘t ‘s mighty plain
Thut the weakes’ place mus’ stan’ the strain;
‘N’ the way t’ fix it, uz I maintain,
Is only jest
T’ make that place uz strong uz the rest.”

So the Deacon inquired of the village folk
Where he could find the strongest oak,
That couldn’t be split nor bent nor broke, –
That was for spokes and floor and sills;
He sent for lancewood to make the thills;
The crossbars were ash, from the straightest trees,
The panels of white-wood, that cuts like cheese,
But lasts like iron for things like these;
The hubs of logs from the “Settler’s ellum,” –
Last of its timber, — they could n’t sell ‘em,
Never an axe had seen their chips,
And the wedges flew from between their lips,
Their blunt ends frizzled like celery-tips;
Step and prop-iron, bolt and screw,
Spring, tire, axle, and linchpin too,
Steel of the finest, bright and blue;
Thoroughbrace bison-skin, thick and wide;
Boot, top, dasher, from tough old hide
Found in the pit when the tanner died.
That was the way he “put her through.”
“There!” said the Deacon, “naow she’ll dew!”

Do! I tell you, I rather guess
She was a wonder, and nothing less!
Colts grew horses, beards turned gray,
Deacon and deaconess dropped away,
Children and grandchildren — where were they?
But there stood the stout old one-hoss shay
As fresh as on Lisbon-earthquake-day!

EIGHTEEN HUNDRED; — it came and found
The Deacon’s masterpiece strong and sound.
Eighteen hundred increased by ten; –
“Hahnsum kerridge” they called it then.
Eighteen hundred and twenty came; –
Running as usual; much the same.
Thirty and forty at last arrive,
And then come fifty, and FIFTY-FIVE.

Little of all we value here
Wakes on the morn of its hundreth year
Without both feeling and looking queer.
In fact, there’s nothing that keeps its youth,
So far as I know, but a tree and truth.
(This is a moral that runs at large;
Take it. — You’re welcome. — No extra charge.)

FIRST OF NOVEMBER, — the Earthquake-day, –
There are traces of age in the one-hoss shay,
A general flavor of mild decay,
But nothing local, as one may say.
There couldn’t be, — for the Deacon’s art
Had made it so like in every part
That there was n’t a chance for one to start.
For the wheels were just as strong as the thills,
And the floor was just as strong as the sills,
And the panels just as strong as the floor,
And the whipple-tree neither less nor more,
And the back crossbar as strong as the fore,
And spring and axle and hub encore.
And yet, as a whole, it is past a doubt
In another hour it will be worn out!

First of November, ‘Fifty-five!
This morning the parson takes a drive.
Now, small boys, get out of the way!
Here comes the wonderful one-horse shay,
Drawn by a rat-tailed, ewe-necked bay.
“Huddup!” said the parson. — Off went they.
The parson was working his Sunday’s text, –
Had got to fifthly, and stopped perplexed
At what the — Moses — was coming next.
All at once the horse stood still,
Close by the meet’n'-house on the hill.
First a shiver, and then a thrill,
Then something decidedly like a spill, –
And the parson was sitting upon a rock,
At half past nine by the meet’n-house clock, –
Just the hour of the Earthquake shock!
What do you think the parson found,
When he got up and stared around?
The poor old chaise in a heap or mound,
As if it had been to the mill and ground!
You see, of course, if you’re not a dunce,
How it went to pieces all at once, –
All at once, and nothing first, –
Just as bubbles do when they burst.

End of the wonderful one-hoss shay.
Logic is logic. That’s all I say.

Related links

• April Fool’s Day 2010 highlights
• April No-Fooling Day
• Netezza’s 2008 April Fool’s Day joke

The classic of that genre, of course, is a certain database-oriented xkcd comic strip. (If you haven’t instantly guessed what I’m talking about, you must see that strip.) And in a similar vein, I further offer six examples of xkcd’s “My Hobby” strips. (The last two are not for the sexually squeamish, but the others are pretty G-rated.)

One thing I just learned about xkcd — if you mouse over the strip, you get another joke. Some are almost as funny as the main strip. So even if you have already seen the database-classic xkcd linked above, you might want to revisit it.

In a very different vein is Dadhacker’s list of real or imaginary past shenanigans, (Edit: The original link is fried, but here’s a partial replacement) which starts:

I am not permitted to replace a coworker’s reference books (including his Knuth, Sedgewick, and C++ reference manuals) with several linear feet of steamy hardback romance novels.

I will not name my variables after nasty tropical diseases, or executives who are under indictment for fraud.

Elevators are not toys, nor should they ever be wired into the corporate net.

Funny and vaguely prankish (and not for the language-squeamish) is this non-xkcd comic about NoSQL. And finally (definitely also for the non-squeamish), see the first long comment in this Reddit thread, which seems to have successfully pranked a whole lot of readers.

The top two points from Q&A probably were:

• Big Data and the cloud actually have relatively little to do with each other, a few exceptions notwithstanding, especially if the data is in a shared-nothing DBMS (as opposed to, say, a MapReduce-oriented file cluster). Two principal reasons are:
  • Redistributing data from node to node is a little slow, undermining some of the elasticity benefits of the cloud.
  • Getting data into the cloud in the first place is a lot slow.
• The NoSQL movement is a lot like the Ron Paul campaign — it consists of people who are dissatisfied with the status quo, whose dissatisfaction has a lot to do with insufficient liberty and/or excessive expenditure, and who otherwise don’t have a whole lot in common with each other.

Anyhow, here are my notes for the talk, edited in just a couple of places for readability or linkage.

Quick introduction

• Big Data vs. cloud
• How big is Big Data?
• At the low end of that range, there’s little you can’t do with conventional technology if you have:
  • An unlimited budget for hardware
  • An unlimited budget for software
  • An unlimited budget for people, especially Oracle DBAs

Big Data in OLTP

• Hard-core OLTP
  • Focus of DBMS technology for a long-time
  • Big budgets because each transaction has significant value
  • Tough to get users to change technologies
• Lighter-weight OLTP
  • Classic example = web companies
    • Big ones — retail-oriented ones (eBay, Amazon) partially excepted — rolled their own technology stacks
    • Reluctant to give money to anybody
      • Open source, etc.
  • Difficulty finding market
    • Product vs. feature
      • Clustering/HA/DR/whatever
      • Ditto cloud enablement
    • True products haven’t found much traction yet

Analytic Big Data use cases

• Kinds of data for analytics
  • More of same != big
  • More detail and/or new kinds
    • Complete data sets
    • Transactions
    • Call details
    • Tick/trade history
    • Web clickstreams
    • Network event logs
    • Other machine-generated data
    • CAM bottom line
      • Anything human-generated should and will be retained in its entirety
      • Quantities of machine-generated data retained should and will grow roughly in line w/ computing cost reductions (Moore’s Law, etc.)
• Analytic uses of Big Data
  • Analytics is mainly about three things
    • Problem detection
    • Customer relationship improvement
      • (Those overlap when the customer relationship is bad)
    • Financial statements on steroids
  • Main kinds of analytics
    • What BI vendors traditionally sell
      • General reporting and dashboards
      • Ad-hoc query (now driven from those reports and dashboards)
      • Planning (allegedly integrated with BI)
    • Research
      • Ad hoc relational query (worth mentioning twice because it drives so much of the market)
      • Data mining
      • Most web search and web mining
    • Operational/near-real-time
    • Archiving/compliance
  • What gets Big?
    • Mainly research and archiving
    • But when reporting or operational get Big, you have really interesting computing problems

Technology issues and trends

• Moore’s Law
  • CPUs — All about cores, hence parallelism is key
  • RAM
  • SSDs – hence replace disks
  • Sensors – hence generate lots more data
• Kryder’s Law
  • But rotational speeds up only 12.5X since Eisenhower Administration
  • Hence solid-state memory (or RAM) will soon take over
• In the mean time, I/O bottlenecks have had to be beaten
  • Hence sequential scans
  • Hence index-light architectures
  • Hence columnar
• DBMS “overhead”
  • Raw license and maintenance fees – software increasing fraction of total
  • OLTP vestiges – locking and all that
  • DBAs
    • People costs = huge fraction of total
    • Index-lightness addresses
    • So does appliance
  • Many people don’t really know how to write SQL
• Configuration
  • Appliance/tightly-balanced
    • Netezza
    • Teradata earlier
    • Greenplum/Sun
    • Oracle
    • IBM
    • Microsoft/Madison
  • Commodity/do what you want
    • Vertica
    • Greenplum now
    • Infobright, Aster and others
    • MapReduce-oriented file systems
  • Extreme rigidity is silly
    • Teradata, Oracle have both signaled moving to more modularity
    • Big driver of that = heterogeneous storage
      • Cheap disk
      • Expensive disk
      • Solid-state
      • RAM
    • CPU/storage ratio is even more of a driver

Theoretically defensible ways to segment the market

• Latency requirements
  • High availability and low latency go together
• Query types
  • Simultaneous users for same
• Database size
• Budget

Actual segments right now

• Utter ADW/EDW
• Data mart
  • Size
  • Naturally columnar vs. naturally row-based
• Operational/frontline
• Less dramatic/smaller EDW

And it goes even further. For example, I was told by a guy who is now a senior researcher at Attivio: “How do you make a good speech recognition product? You start with a bad one and keep incrementally improving it.”

In particular, I’ve taken to calling the process of enhancing a product’s performance across multiple releases “Bottleneck Whack-A-Mole” (rhymes with guacamole)*. This is a reference to the Whack-A-Mole arcade game, the core idea of which is:

• An annoying mole pops its head up
• You whack it with a mallet
• Another pops its head up
• You whack that one
• Repeat, as mole_count increments to a fairly large integer.

You can see Whack-A-Mole:

• In a great picture here
• In a playable Silverlight-based game here. (June, 2011 edit: That link seems not to work any more.)

Improving performance in, for example, a database management system has a lot in common with Whack-A-Mole. Unclog your worst performance bottleneck(s), and what do you get? You get better performance, limited by other bottlenecks, which may not even have been apparent while the first ones were still in place. For example, Oracle is surely going through that now with Exadata. In its very first release, Exadata probably solved the basic I/O problem that had been limiting Oracle’s analytic query performance – edge cases perhaps aside. With that out of the way, Oracle now gets to:

• Attend to the edge cases
• Fix whatever other bottlenecks are next-worst in the highly engineered, highly complex Oracle DBMS.

When I spoke with Oracle’s development managers last fall, they didn’t really know how many development iterations would be needed to get the product truly unclogged. Of course, they professed optimism — which seemed quite sincere – that it wouldn’t be many iterations at all. But they confessed, as well they should have, to not truly knowing.

*In one way, the metaphor falls short – in the game, you have to whack a mole quickly or else you lose your opportunity entirely, while in software the problems just linger until you fix them. Well – who ever said games were PERFECT mirrors of reality?

Netezza is an even better example. Originally, Netezza had a “fat head,” in which a lot of query processing was done at a single master node. They fixed that, whereupon they had to get data redistribution right. Now Netezza’s performance focus is in yet different areas.

And in line with this theory – if you plotted a graph comparing analytic DBMS product age vs. maximum number of concurrent users supported, you could get a strong fit to a monotonically increasing curve. Evidently, concurrent performance is another of those things that takes multiple product revisions to get right.