The article makes the same conflation, but while reading it I noticed something interesting. The concrete examples cited are of clever consultants who crafted innovative data visualizations on the fly, to make conclusions patently apparent to even mathematically-challenged decision-makers. That kind of thing is important, and has been going on for over 140 years.*

*Yes, I’m trotting out the Florence Nightingale example again. I continue to be in awe of her.

What worries me is the article’s suggestion that the best data visualizations are done by visualization experts, as ways of making information apparent to other people. For as long as data visualization relies on hotshot visual-design experts doing one-off projects, its impact on enterprises overall will remain extremely limited. In other words, to the extent it is incorrect to conflate data visualization and data exploration, data visualization will remain a fringe technology.

To be fair, a primary decision support/business intelligence usage cycle has always been — where by “always” I mean “for at least the past 35+ years” –

• Data exploration. Power user uses technology to find something interesting.
• “Look what I found!” Power user then shows a report, chart, or other summary/representation to colleagues.

So to the extent modern interactive data exploration/visualization technology fits that paradigm, great. But to the extent that visualization experts are somehow integral to the technology’s use, it will remain stuck on the analytic fringe.

• Personally selected annual lists of 12 “Most influential” companies and 36 “Companies to watch” in analytics- and database-related sectors.
• Made it clear that these are his personal selections.
• Nonetheless has called it an Editors’ Choice list, rather than Editor’s Choice.

(Actually, he’s really called it an “award.”)

People advising Doug — who come to think of it actually are Contributing Editors to Intelligent Enterprise or something like that — included Cindi Howson, Seth Grimes, three others, and me.

And if past is prologue, I will now get a flood of PR emails calling my attention to this award that I already have both participated in and blogged about.

As usual, the sense:nonsense ratio on these lists was pleasingly high. Analytic DBMS vendors cited included IBM, Microsoft, Netezza, Oracle, Sybase, and Teradata in the “Most influential” group, with Aster, Greenplum, HP, Infobright, and Vertica among the “To watch” crowd. It’s tough to argue with those selections, whose most questionable element is probably the not-ridiculous supposition that HP could do something interesting over the coming year. Cloudera and Intersystems also made the list, deservedly.

All three of QlikTech, Tableau, and TIBCO made the list, which is appropriate given the potential for and interest in interactive data exploration technology.  The BI majors, independent or otherwise, were all on as well. In text mining, Doug included Attensity and Clarabridge, which I think is exactly right. (Plus OpenCalais.)  Upon reflection, I probably should have nominated Mark Logic, even though most of its business is non-enterprise; but hey, nobody’s perfect, and the same goes for lists. Open source was well represented, with Apache, Actuate, Jaspersoft, Eclipse, Infobright, Nuxeo and R all being cited (but not Ingres or Pentaho). Kalido made the list, with my endorsement, their silly I-CASE like marketing messaging notwithstanding.

Speaking of imperfections — there only are a few category names, and so category assignments can be pretty bizarre. (In an ideal world, middleware wouldn’t be included under “enterprise applications”.) Greenplum hasn’t really “extended” its DBMS with a “cloud” option. As much as I’d like Netezza to be more influential than SAP, that’s probably not the best way to rank them. And there are a number of “This company is on a roll!” kinds of comments that I wouldn’t necessarily endorse.

But those are all nitpicks. On the whole, it’s another nice job.

• The most important issue in database and analytic technology, in my opinion, isn’t technological at all – rather, it’s the legal and political steps needed to preserve liberty in the face of advancing, intrusive technology.
• Another important issue for society – and this one does involve a lot of technology – is scientific number crunching. In particular, database technology for scientific computing needs to be developed much further. I’ll have more to say on all this soon.
• More generally, technology needs to keep advancing for parallel analytics. Fortunately, it is. Watch this space over the next few weeks.
• Oracle has said, in effect, that its most important technological challenge of the decade is getting solid-state memory right. I agree.
• Data volumes will keep going up, up, up. Technology needs to keep evolving accordingly. Much of what I write is on that subject.
• Data needs to be processed and analyzed at very different latencies. And there’s much further to go in integrating disparate latencies.
• Analytic database management in the cloud hasn’t been solved yet, especially for Big Data. Among the reasons are the difficulty of moving data into the cloud (unless it originated there), the slowness of moving it from node to node in shared-nothing architectures (which reduces the elasticity benefit), and above all the long and unpredictable latencies of interprocessor communication while queries are running (a key subject of discussion at the Boston Big Data Summit).
• Better business intelligence user interfaces are increasingly available. I’m thinking particularly of approaches with buzzwords like visualization/interactive exploration or faceted. But they aren’t well-integrated into the overall analytic stack, as big BI vendors are trailing the smaller ones in this regards. (Part of the problem relates to my previous point.)
• Application development over text search isn’t in the same league as application development over relational DBMS. The choices are mainly XML (e.g., MarkLogic), SQL for text integrated into RDBMS (limited by the weakness of those integrations), and something like Attivio’s Java SDK. There’s a major conceptual barrier in building those apps, namely the unpredictability of query results. Still, it should be possible to do better.
• Similarly, text analytics and conventional analytics exist well side by side. They can even be in the same database and/or dashboard, although in practice that is limited by the strong SaaS focus of text mining vendors and users. But analytic integration of them is really hard. Linguistic imprecision is, in my opinion, only the #2 reason for this difficulty. The #1 reason is that trends detected by text analytics are much less precise than trends on tabular data – e.g., a 50% increase in a certain kind of complaint may be no more significant than a 5% change in a revenue variable.
• I’m increasingly persuaded that graph analytics can be handled without a graph-centric data model. But right now, it isn’t being handled well at all. Lots more needs to be done – although when it is, it will just exacerbate the privacy/liberty dangers that so concern me.

Other posts based on my January, 2010 New England Database Summit keynote address

• Data-based snooping — a huge threat to liberty that we’re all helping make worse
• Flash, other solid-state memory, and disk
• Interesting trends in database and analytic technology

One section covered recent/ongoing/near-future trends that I thought were particularly interesting, including:

Simpler database technology, by which I mean DBMS that are:

• Easier to administer than market-leading systems …
• … even if at the cost of being special-purpose
• E.g.,
  • MySQL and older mid-tier RDBMS such as Progress
  • Many analytic DBMS and appliances, most notably Netezza’s

For general purpose or OLTP uses, I’m not a big fan of MySQL (not enough progress in making it industrial-strength), PostgreSQL (no good company behind it – I’m a non-fan of EnterpriseDB), or Ingres (open source or not, it’s an antiquated system that hasn’t been invested in as much as Oracle, DB2 or SQL Server).

But I get the impression there are a lot of contenders among small startups, featuring very new architectures for OLTP or general-purpose database management. VoltDB comes to mind. NimbusDB is finally within range of getting funded. Dan Weinreb told me Friday he knows of a bunch of others as well. And that’s all before we even get into the NoSQL kind of alternative.

Flexible storage architectures. That’s starting out with an emphasis on hybrid columnar, as in the examples of Vertica and Greenplum. Oracle (to whom I’m under no NDA obligation) and other vendors (to whom I am) are going that way as well.

Multi-tier database architectures, by which I mean at least two things:

• The database tier/server tier split of Exadata
• Hybrid RAM/disk architectures, examples of which include
  • Vertica’s RAM-based write-optimized store
  • Sensage’s CEP-in-the-DBMS
  • This in-memory analytics stuff we keep hearing about from the BI vendors
  • Any true in-memory/disk hybrid, such as the regrettably sidelined solidDB
  • Smart thinking by numerous DBMS vendors about optimizing the use of RAM and/or Level 2 cache

Netezza is particularly interesting to watch in this regard because it:

• Had a pretty strict storage/other processing split in prior product generations and …
• … ditched that in its latest generation …
• … which however is focused on optimizing the use of RAM cache

Also noteworthy is Petascan, the stealth-mode –and therefore harder to watch right now – company I keep teasing about, which makes a strong case for carrying the database/storage tier split into the flash/solid-state memory technology generation. Calpont also has a server/storage tier split, but that’s of mainly theoretical interest unless and until Calpont actually ships an MPP version of InfiniDB.

Cheaper parts, which have of course been a huge trend for decades. Solid-state memory will soon conquer the world. Meanwhile, cheaper sensors drive that machine-generated data I keep talking about.

An ever-better understanding of scale-out technology, in several respects, including:

• Query, notably data movement for MPP DBMS
• Update, especially minimalistic DBMS approaches, be they sharded MySQL or more NoSQLish
• Number-crunching, especially via MapReduce and/or parallel analytic libraries integrated into DBMS

Cool trends I touched on more briefly include:

• More data being available for analysis. This was a core theme of my Enzee Universe keynote speeches; there are also some notes on it in my post based on my Boston Big Data Summit talk.
• More users being served by analytics. Ditto.
• Data exploration/visualization, ala QlikView, Spotfire, or Tableau, and also the faceted stuff.
• The democratization of data mining. But I’m not as sure of that one as of the others…

One area I flat-out forgot to mention is easy data mart spin-out.

Other posts based on my January, 2010 New England Database Summit keynote address

• Data-based snooping — a huge threat to liberty that we’re all helping make worse
• Flash, other solid-state memory, and disk
• Open issues in database and analytic technology

• Over a 20 week period, I had travel in 13 of them.
• 3 of those were vacation in November.
• As travel finally wound down:
  • It was time to focus a bit on my own business
  • Elder care got serious; e.g., my parents went to the hospital on consecutive days, Christmas week, the first one on their 52nd wedding anniversary
  • Linda and I both got really nasty colds
  • The holidays were happening
  • I started helping out a really cool startup company (first time I’ve taken stock in a private company in years; more on that soon)
  • There was less industry news going on anyway than in some other recent months

But of course I plan to speed up the research/analysis/writing soon. Here, FYI, are a few things I have on my plate.

For a couple of years now, the center of what I’ve written about has been high-performance analytic data processing. You can expect me to keep pursuing that in all its aspects. But there are two specific areas I’ve identified in which I want to redouble my efforts.

First, almost every BI vendor has an effort in “in-memory analytics” and/or “interactive data exploration.” I suspect there’s a lot of difference in underlying technologies, but I’m having trouble getting details. QlikTech (the worst foot-dragger of the three), Microstrategy, and Jaspersoft all owe me follow-up conversations with the people who know what’s going on well enough to explain it. Tableau keeps promising me a briefing and then not delivering. And I’m even further behind with the behemoth companies — Oracle, Microsoft, IBM/Cognos (arguably) et al.

Second, solid-state memory is coming to data warehousing. The obvious reasons are that it’s obviously close, and Moore’s Law still applies to bring it closer. More specific reasons for believing in solid-state include:

• Teradata has made large strides in making solid-state memory useful.
• The stealth start-up I mentioned above is poised to make further strides.
• (I’m not totally sure yet about this part) The in-memory analytics mentioned above might wind up working better in solid-state memory than in DRAM.

I’m spending quite a few cycles thinking about this area.

I’d also like to look further at analytic applications and advanced analytic functionality. I foreshadowed some of that in my Aster webinars. There’s some good stuff to talk about at Teradata I should try to write up soon. I need to have a follow-up conversation with fascinating anti-fraud guy I met at Netezza’s London event. But that’s all just scratching the surface.

Both the MySQL and PostgreSQL communities are in some disarray. Other non-behemoth OLTP/general-purpose DBMS seem to be, at best, thriving niche products. (I see little in the way of innovative new use for, say, Progress, Cache’, Ingres, or anything multivalue.) But it feels as if there’s more opportunity out there than is being met. And at a minimum, I’d like to learn more than the almost nothing I know about OLTP NoSQL alternatives.

I’ve already said that I expect to give an industry-overview talk at MIT on January 28. I also have an overviewy press article and overviewy white paper under discussion. If those come to fruition, I’ll of course let you know.

Besides the above, I of course have a number of specific posts that I need to get around to researching and writing at some point, often on topics I’ve already written about before.  Three subjects fairly high on the priority list are scientific data management, machine-generated data, and Oracle Exadata.

And finally, I have some subjects queued up for a couple of my other blogs as well. If you don’t already take our multi-blog integrated feed, this might be a good time to switch over.

Roman’s latest venture is business intelligence firm Gooddata. Gooddata was founded in 2007 and has been soliciting and getting attention for a while, so I was surprised to learn that Gooddata officially launched just a few weeks ago. Anyhow, some less technical highlights of the Gooddata story include:

• Gooddata believes it makes BI easy to adopt, unlike every other BI vendor on the planet — not excluding the many other BI vendors who say the same thing about themselves.
• Gooddata is entirely cloud-based, specifically in the Amazon cloud. I.e., Gooddata is selling SaaS-based BI.
• Gooddata wants to sell to enterprises that are large enough to have more than a couple of BI users, and small enough not to be well served by the BI market leaders.
  • In revenue terms, this is the ever-popular $100 million – $1 billion market.
  • Specifically, Gooddata believes that those enterprises may have decent “back office” BI, but don’t have much in the front office. Gooddata wants to provide them with front office BI, which seems to basically mean CRM analytics. Gooddata sees this as a market in which QlikTech is the major player. Generally, Gooddata wants to emulate and go after QlikTech.
  • Even more specifically, Gooddata wants to sell to Salesforce.com customers, who it believes are not well-served by what passes for built-in analytics at Salesforce. Partnering with NetSuite didn’t work as well, since NetSuite’s customers turn out to be smaller firms than are in Gooddata’s target market.
• Something I heard from both Jaspersoft and Gooddata is that there’s a hot market in providing cloud-based BI to online gaming companies. I gather these are mainly games running on mass communication platforms such as Facebook or the iPhone. Surely not coincidentally, it seems likely that:
  • These are small companies whose success – and hence data intake – can suddenly explode.
  • The data originates in cyberspace, with no particular need ever to come to the game companies’ own premises.
• Gooddata has 50 production customers.
• Gooddata had 2500 “projects” at the end of beta in June, and is adding 100 more per month. (Those numbers look weird together.) A “project” is a lot like a database, with associated reports, security privileges, etc.
• Gooddata has close to 40 people, mainly in development.
• I didn’t detect much of a sales strategy, nor much of a marketing strategy beyond the impressive early buzz generation. Perhaps that’s a partial explanation as to why the rate of Gooddata adoption fell even before the company officially launched.
• I forgot to ask what those 50 customers were actually paying, but considering Gooddata’s price list, it appears a typical price range for Gooddata’s stuff would be $500-$2,000/month.

Gooddata technical highlights include:

• Gooddata is building an entire BI stack – reporting, dashboards, ETL, in-memory database management, everything. I doubt Gooddata would claim that the pieces are best-of-breed in many ways other than BI ease of adoption and use.
• So far I’ve seen three Gooddata ease-of-use features or feature groups that strike me as differentiated – reusability (of metrics and/or reports), collaboration, and tag clouds. More on those below. Gooddata is also building toward an agility pitch, but those features aren’t all baked yet.
• Gooddata is MySQL-based today, but plans to move to a memory-centric compressed column store in 2010. Roman doesn’t reject analogies to SAP’s BI/BW/whatever Accelerator. Yes, folks – Gooddata is yet another BI vendor doing some form of memory-centric OLAP. That’s a big trend.
• I’m guessing that a big reason Gooddata is reinventing so many technical wheels is to ensure that the Gooddata stack is seamlessly multi-tenant from top to bottom. (Hasso Plattner of SAP’s comments on a similar idea suggest a similar emphasis.)
• Gooddata has its own multidimensional query language called MAQL (the A doesn’t seem to stand for anything). Today MAQL generates SQL for MySQL. The future columnar memory-centric data store will — I think – understand MAQL natively.

Now we get to the good stuff. When I wrote about reinventing business intelligence back in May, I focused on some interesting developments I see as actually underway — at least on an experimental basis and/or from small vendors – namely:

• Text-search interfaces. Well, while I didn’t see true text search in the Gooddata demo, I did see tag clouds, which have some of the same benefits.
• Collaboration tools. Well, Gooddata has a nice-looking approach to BI collaboration, heavily reflected in its UI metaphors. (That said, I haven’t really compared Gooddata to Microsoft SharePoint or SAP’s Portal/Rooms/whatever.)
• Memory-centric analytics (for speed of exploration). As noted above, Gooddata has that coming soon.
• Data exploration that tries to ignore fixed relational schemas, ala Attivio or Splunk. Roman says Gooddata is interested in or working on that, but offers no timetable.

Meanwhile, something I’ve been seeking for years, but haven’t seen much progress on since enhancement stopped on Cognos Metrics Manager, is more user-friendly metrics management. Well, it doesn’t have a lot of bells and whistles, but at least Gooddata has the basics – a list of already-defined metrics, and a reasonable way of compounding them into other metrics. I think that kind of thing will be a major BI feature going forward, to the point that a few years from now we’ll be worrying about how to port them from one BI vendor’s tool from another.

Bottom line: If you’re interested in BI, you should look at a Gooddata demo.

]]> http://www.dbms2.com/2009/12/27/introduction-to-gooddata/feed/ 12 http://www.dbms2.com/2009/12/11/ray-wang-on-sap/ http://www.dbms2.com/2009/12/11/ray-wang-on-sap/#comments Fri, 11 Dec 2009 23:16:54 +0000 Curt Monash http://www.dbms2.com/?p=1286 Ray Wang made a terrific post based on SAP’s annual influencer love-in, an event which I no longer attend. Ray believes SAP has been in a “crisis”, and sums up his views as

The Bottom Line  – SAP’s Turning The Corner

Credit must be given to SAP for charting a new course.  A shift in the management philosophy and product direction will take years to realize, however, its not too late for change.  SAP must remember its roots and become more German and less American.  The renewed focus must put customer requests and priorities ahead of SAP’s bureaucracy.  The emphasis must focus on the relationship.  When that reemerges in how SAP works with customers, partners, influencers, and its own employees, SAP will be back in good graces. In the meantime, its  time to get to work and deliver.  Oracle’s Fusions Apps are coming soon and competitors such as IBM, Microsoft, Epicor, IFS, and SalesForce.com will not relent.

I recall the 1980s, when SAP’s main differentiator, at least in the English-speaking US, was a total commitment to customer success, and when it could be taken for granted that SAP would do business ethically. Things change, and not always for the better.

Anyhow, the reason I’m highlighting Ray’s post is that he makes reference to a number of interesting SAP-cetric technology trends or initiatives. In no particular order, Ray suggests:

• SAP’s and Oracle’s (Fusion) efforts to meld memory-centric analytics with operational apps will be crucial for large enterprises — but perhaps only around the middle of the next decade. (I basically agree, although I’d note that:
  • Wisely, Ray suggested a very long time frame.
  • BI/operational app integration has been, on the whole, glacial.
  • The idea that you have to put pre-built aggregates into RAM to get performance is an indictment of market-leading RDBMS — but it’s a fair indictment.
  • I’m not sure whether memory-centric OLAP will wind up in RAM or Flash. If the data stores are updated at near-transactional speeds, RAM may make more sense. Otherwise, Flash should have major advantages.)
• SAP’s long-standing attempts to support third-party development of SAP add-ons are a technological mess, in line with my fears a couple of years ago. However, the business-relationship part of the effort is vastly stronger.
• As SAP focused more on the mid-market, it is partnering closely with Microsoft. (If you think about it, that makes all kinds of sense.)
• Energy/environmental/safety tracking — i.e., sustainability — tools are a big deal. (See also The Economist on that point.)

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

• Teradata is productizing “private cloud,” under names including “Teradata Enterprise Analytics Cloud,” “Teradata Agile Analytics Cloud,” and “Teradata Elastic Mart Builder.” I.e., Teradata hopes to leapfrog Greenplum in its “Enterprise Data Cloud” strategy. This is only fair, in that Greenplum lifted the idea from Teradata and eBay in the first place. It also provides major support for what I think is an extremely sensible trend. Give or take issues of who announces and ships what a couple months before or after a competitor, my early thinking is that the main differences between Greenplum and Teradata in this regard will be:
  • Virtual as opposed to just physical data marts, based on robust workload management software. (Advantage: Teradata)
  • Pricing, deployment options. (Advantage: Greenplum)
  • Features that don’t directly relate to enterprise/private cloud. (Advantage: Either, often Teradata.)
• Teradata is generally strengthening its data movement technology, e.g. for making various appliances work in sync. I’m not too clear yet on the details of that. I think this is what Teradata’s phrase “ecosystem management” refers to.
• Teradata is (pre-)announcing – at least as a statement of direction — an appliance based on solid-state drives (SSDs). I’ve thought for a while that Teradata was a leader in thinking through the issues around solid-state memory in data warehousing, so it makes sense that they’re among the leaders in actually coming to market as well. I plan to say more after meeting with, e.g., Carson Schmidt.
• Teradata has achieved a 300%ish speed-up in geospatial processing. I gather this is largely a byproduct of the parallel analytics work Teradata did around strengthening its SAS integration. However, there don’t seem to be a lot of Teradata geospatial users yet.
• Teradata Express, Teradata’s free Windows-based crippleware, is being ported to Amazon EC2 and VMware as well. Presumably to avoid cannibalizing Teradata product sales, there are quite a few limitations on Teradata Express, including system capacity, database size, and “no production use.”
• Teradata continues to extend its optimizations to handle queries issued by business intelligence tools. Previously, the focus of what Teradata discussed in this regard was query rewrite. But soon automatic recommendation and creation of Aggregate Join Indexes – i.e.., materialized views – will be included as well.

I’m going to start with analytic speed or, equivalently, analytic latency. There is, obviously, a huge industry emphasis on speed. Indeed, there’s so much emphasis that confusion often ensues. My goal in this post is not really to resolve the confusion; that would be ambitious to the max. But I’m at least trying to call attention to it, so that we can all be more careful in our discussions going forward, and perhaps contribute to a framework for those discussions as well.

Key points include:

1. There are two important senses of “latency” in analytics. One is just query response time. The other is the length of the interval between when data is captured and when it is available for analytic purposes. They’re often conflated — and indeed I shall do so for the remainder of this post.

2. There are many different kinds of analytic speed, which to a large extent can be viewed separately. Major areas include:

• Data exploration. In-memory OLAP is a huge trend, and QlikView is a hot BI product line.
• Budgeting/planning. In an unprecedentedly frightening economy, annual planning/forecasting cycles may well be too slow.
• Operational integration. This is probably the biggest current area of mission-critical IT advancement. Not coincidentally, it is also the mainstay of the most expensive and complex data warehousing technologies. It’s also an ongoing area of application for event/stream processing, aka CEP.
• General or deep analytics. This is what I seem to spend much of my time writing about — data warehousing price/performance, parallelized data mining, and much more.
• Data administration. Ease of data mart spin-out and administration is becoming a major concern. And of course analytic appliance and DBMS vendors have been telling ease-of-deployment, low-DBA-involvement kinds of stories at least since Netezza first came to market.

There certainly are relationships among those; e.g., a really great analytic DBMS could help speed up any and all of the last three categories. But when assessing your needs, you can go quite far viewing each of those areas separately.

3. It is indeed important to carefully assess your need-for-speed. Acceptable levels of analytic latency vary widely, ranging from sub-millisecond to multi-month. For example, I’ve put together a list:

• Algorithmic trading – Sub-millisecond. Increasingly, that’s what’s needed, at least for query response.
• Web page – Tenths of seconds. If you want to get up a complex web page in 2 seconds or less, you may require sub-second response time for your queries. (E.g., this is a key message from Teradata’s customer success story at Travelocity.)
• Call center – Seconds. If two humans are talking to each other on the phone, a couple-second delay in response is probably acceptable.
• Transportation – Tens of minutes. If a commercial flight is delayed, reaction to minimize the consequences often needs to be sub-hour. The same can be true for cargo transportation (truck, rail, or air). In other cases, a couple of hours may be fast enough.
• Inventory – Hours. In the 1980s, the retailers that won were the ones who reordered hot seasonal merchandise a couple of days before their competitors. Even then, 7-11 Japan was making restocking decisions several times a day. Things have only gotten faster since.
• Planning – Weeks or more. Planning is often done on an annual or even multi-year cycle. That may be excessively slow. But weeks or months? In many cases, that’s both the best achievable and plenty good enough.

That’s a range of at least 9 orders of magnitude, which is a lot like the difference between the speed of a turtle and the speed of light.

]]> http://www.dbms2.com/2009/09/10/analytic-speed-latency/feed/ 0