Choices in analytic computing system design
When I posted a long list of architectural options for analytic DBMS, I left a couple of IOUs in for missing parts. One was in the area of what is sometimes called advanced-analytics functionality, which roughly speaking means aspects of analytic database management systems that are not directly related to conventional* SQL queries.
*Main examples of “conventional” = filtering, simple aggregrations.
The point of such functionality is generally twofold. First, it helps you execute analytic algorithms with high performance, due to reducing data movement and/or executing the analytics in parallel. Second, it helps you create and execute sophisticated analytic processes with (relatively) little effort.
For now, I’m going to refer to an analytic RDBMS that has been extended by advanced-analytics functionality as an analytic computing system, rather than as some kind of “platform,” although I suspect the latter term is more likely to wind up winning. So far, there have been five major categories of subsystem or add-on module that contribute to making an analytic DBMS a more fully-fledged analytic computing system:
- SQL extensions. Examples include SQL-2003 analytics (notably windowing), or vendor-specific temporal functionality.
- A framework for UDFs (User-Defined Functions) to further extend SQL. At its core, a relational DBMS is a big SQL interpreter. SQL, while powerful, only does a limited number of things. User-Defined Functions are new predicates in the SQL language that do additional things.
- An execution engine for analytic processes that is less coupled to the SQL engine than a pure UDF framework might be. The two main approaches are MapReduce (e.g. Aster Data) and general C++ libraries (Netezza, ParAccel).
- Libraries of pre-built analytic processes. Commonly included are statistics, (other machine learning), general linear algebra, and Monte Carlo analysis. Some of these functions are fully parallelized (perhaps tens per vendor). Others just play nicely with the vendor’s execution framework, in that a separate copy can be run on each node (up to thousands per vendor, for those who bring in open source statistics libraries).
- Development tools such as integrated development environments (IDEs). Aster keeps trying to convince me that having built a nice Eclipse IDE is a major competitive differentiation.
The most structural or architectural are the UDF framework and the non-UDF analytic execution engine. But even those are in essence add-on modules, which means that pretty much any vendor can do any part of them if they invest enough resources in the effort. So I expect considerable convergence over time as the industry and market discover which capabilities are or aren’t particularly useful.
When I’m being told about an analytic DBMS that supposedly has evolved into an analytic computing system, some of my top-of-mind questions are:
- How does the execution work? UDFs? MapReduce? Something else? What forms can the inputs and outputs of a UDF take? And by the way, what’s your complete list of MapReduce integration possibilities?
- What languages are currently supported? The obvious choices are C++ (if that’s the style of execution engine); SAS, R, or other statistical languages; and anything that is commonly associated with MapReduce (Java, Python, et al.).
- In-process, out-of-process, or both? In-process runs faster; out-of-process is more stable, in that the advanced-analytics part can crash without bringing down the whole DBMS. Even if other languages are available out-of-process, C++ might be the only in-process choice. If you don’t have out-of-process execution, you may not be serious about offering really broad analytic capabilities.
- Is there anything special about your library of pre-built, fully parallel processes? For example, I like Netezza’s broad approach to linear algebra, Greenplum’s sparse vector manipulation, and a number of Aster Data’s packages. ParAccel’s list looks interesting too, although I haven’t grilled them about what is or isn’t fully parallel.
- How does the associated memory management work? Can you create temporary data structures that survive longer than the process that spawned them? (Those can be useful for various kinds of lookup table.) Do they have to be tabular? (Graphs and other alternatives can be useful.) And by the way, do UDFs or other processes have enough RAM under their control to run efficiently?
- How is workload management handled? Hopefully, everything that runs on the same cluster is handled by one integrated workload management system. Vendors for whom that isn’t true today should have a clear road map for getting there, because the alternative is something of a mess.
Please note what I’m not including in this discussion — the integration of DBMS and fairly ordinary business intelligence. That may have virtues, for reasons of price or performance, and the virtues may grow as in-memory BI and/or data management capabilities evolve. But for the foreseeable future, BI/DBMS integration is a fairly separate matter from the integration of analytic DBMS with sophisticated investigative analytics.
Comments
8 Responses to “Choices in analytic computing system design”
Leave a Reply
[…] This post was mentioned on Twitter by Curt Monash and Oracle FAQ, Design4people (rss). Design4people (rss) said: Choices in analytic computing system design: http://bit.ly/hkg0VO […]
UDF is not enough. Users need UDAF and UDTF as well.
UDF – user defined functions (scalar to scalar mapping)
UDAF – user defined aggregate functions(rows to scalar mapping)
UDTF – user defined table functions (row to rows mapping)
Then, all of these functions must be easily incorporated (installed) into analytical DBMS, hence C++ is not the best option here. We need Java, Scala, Python etc support to make things more interactive (on the fly).
MapReduce is nice to have but its programming model is too rigid and limited to support effectively many useful distributed algorithms (any iterative algorithm, PageRank, for example :)).
Vlad,
“What forms can the inputs and outputs of a UDF take?” was meant to address your UDAF/UDTF point, but thank you for spelling it out more clearly!
Vlad,
You make a great point that an analytic computing system needs to support a wide range of programming languages. Multiple programming language support is something that we considered from day one when we built SQL-MapReduce at Aster Data (http://www.asterdata.com/resources/mapreduce.php). SQL-MapReduce provides rich java support complete with an Eclipse development plugin for interactive development. SQL-MapReduce also supports C, C++, Python, SAS, R, and a whole host of languages that can run on Linux.
We feel that these options make deep analytics more user friendly and open to a wider development community. It allows enterprises to take advantage of more of the skill sets they have in-house rather than forcing analytics development to one particular language. That’s why SQL-MapReduce functions (UDFs, UDAs,and UDTs!) are first class citizens in nCluster along with — and within — any SQL query.
To your point about MapReduce being too limited for some computations like PageRank, we designed SQL-MapReduce to allow pipelining of arbitrary Map and Reduce functions, or as we call them, Row and Partition functions. This means that unlike traditional MapReduce, which runs one map step and then one reduce step, in nCluster you can pipeline multiple map and reduce steps in any order and also mix these steps with SQL.
[…] By late 2010, the term “analytic platform” started to take shape. The definition of it fit exactly with what Aster Data has built. And now, traditional DW appliances are claiming to be analytic platforms. Even Netezza is taking the same box they had before and calling it “An Appliance for Deep Business Analytics,” and pure columnar MPP DBMS’s like Vertica and ParAccel overnight went from being ‘the world’s fastest database’ to ALL claiming to be an analytic(s) platform. This is a typical marketing trajectory if you now see where the future lies in big data management. The market as a whole is gravitating to accept that if you truly want to manage big, diverse data, you ultimately want to analyze all of it, and for that you’re really in need of a big data analytic platform – not just a big data store. Recently, Curt Monash supports a similar notion when describing choices in analytic computing system design. […]
“MapReduce is nice to have but its programming model is too rigid and limited to support effectively many useful distributed algorithms (any iterative algorithm, PageRank, for example )”
This is beyond silly. The first major application for MapReduce at google was PageRank.
[…] has positioned itself as an analytic platform company despite not obviously having the technology to back that […]
[…] original feature list for analytic platforms (January, 2011) Categories: Analytic glossary, Aster Data, Data warehouse appliances, Data […]