In a previous post, I outlined a design pattern that we call “The Automated Feedback Loop.” In this post, I want to outline a design pattern that we call “The (Iterative) Analytics Data Warehouse”.

The traditional well-understood design pattern of a data warehouse is a central (for Enterprise Data Warehouse) or departmental (for Data Marts) repository of data. Data is fed into the warehouse from ETL processes that pull data from a variety of sources. The data is organized in a data model that caters to 3 use-cases of the warehouse:

1. Reports - A set of BI queries are run with regular frequency to monitor the state of the business. The target of the reports are business users who want to understand what happened. The goal is to keep them in touch with the pulse of the business.
2. Exports - A set of export jobs are run with adhoc frequency to provide data sets for further analysis. The target of the exports are business analysts who want to optimize business practices. The goal is to provide them with true, quality-stamped data so that they can make confident optimization recommendations.
3. Adhoc - A set of queries are run with adhoc frequency to detect or verify patterns that influence business events. The source of the queries are data scientists who want to understand and optimize business practices. The goal is to provide them with computation capabilities (good query interfaces, enough processing, memory and storage resources) to allow them to interact with the data.

The exports and adhoc tasks are transient tasks. Once the data analysts or data scientists find a pattern valuable to the business, that pattern is incorporated into a report so that business users can monitor that pattern on a frequent repeatable practice.

In a typical data warehouse, the bulk of tasks (~80%) are from [1] Reports. The remainder of 20% is from [2] Exports and [3] Adhoc.

Since Reports are frequent and generate known queries, the design of the data warehouse is done to cater to reporting. This includes data models, indexes, materialized views or derived tables – and other optimizations – to make the known Reporting queries go fast.

Since exports and adhoc tasks are infrequent and generate unknown queries, the design of the data warehouse is unable to cater to them upfront. This means that exports and adhoc tasks generate queries that are harder to satisfy (since they have to fight the data modeling decisions made for reporting) and therefore impose more load on the data warehouse.

The net result is that reports run fast while exports and adhocs are slow. In fact, exports and adhocs consume so much resources, that reporting starts running slower. And that is not good – reports are distributed widely and reach a wide variety of business users. They are unhappy and put pressure on the data warehousing team to “get the reports in time.” At the same time, the export and adhoc users are unhappy because they can’t get to the data fast enough to benefit the business.

The poor data warehouse team now looks for solutions invariably prioritizing reports. Historically, the answer was to prioritize via workload management – constrain adhoc & export usage to devote resources to reporting. If workload management didn’t work, the answer was to create walled gardens by enforcing rules -

“thou shalt not report when data is loading; thou shalt not adhoc query when reports are being generated; thou shalt not export except in the evening”.

Let’s call this design pattern of data warehouse to be a “Reporting Data Warehouse”.

The first-class citizen of a “Reporting Data Warehouse” is reports. The exports and adhoc are second-class citizens – they do not get dedicated data models, they do not get large chunks of resources, and their protests are answered by asking them to constrain their requirements (use samples, use rolled up aggregates that were built to make reports faster, use smaller timeframes of history that were retained to just satisfy reporting requirements, phrase queries that are simpler even though they may be compromises on the pattern sought, …).

This motivates the definition of a different design pattern of a data warehouse whose use is to be an “Analytical (Iterative) Data Warehouse“.

The first-class citizens of an “Analytical Data Warehouse” are exports and adhoc analytics, and the primary users of the Analytical Data Warehouse are business analysts and data scientists. The data models are built to support their adhoc usage – fine-granularity data is retained, rich dimension tables are frequently imported, derived views and tables are created promptly, interfaces are opened up to express their patterns in a computationally simple and natural manner, scale-out is used to create resources for the tasks to finish interactively, enough storage is allocated for several exports to proceed simultaneously.

In other words, the infrastructure and the team exist to support export and adhoc usage as their primary customers.

Once an insight is confirmed, it can be added with careful design to the Reporting Data Warehouse – with carefully defined data models, indexes and materialized views and support to maintain it during the ETL process.

The infrastructure can play a significant role in enabling Analytical Data Warehouses.

1. Query interface to support in-database computations: The export and adhoc queries want to manipulate data in rich ways, and often SQL is not enough. The infrastructure should support an easy-to-express interface for rich computations (e.g., SQL/MapReduce). This is important because the correct perspective of data, amenable to downstream manipulation, cannot be defined upfront in the ETL process.
2. Incremental scale-out MPP capabilities: The infrastructure should allow for an ability to scale out both storage and computing resources incrementally and easily (i.e., without months of planning). This is important because temporary storage requirements (as data is transformed for analysis) or temporary processing requirements (as several models are generated to validate insights) at the peak of the analysis can be much higher than normal use.
3. Cheap hardware: The size of data demanded by exports and adhoc users may be large and the computations may be rich. The infrastructure must enable analysis of data at a cheap operating point.
4. Workload manage both export and analysis: Some data analysts are comfortable in manipulating data in their preferred tools (e.g., Excel, SAS, Matlab) – others are comfortable writing in-database queries (SQL, Java, C++, Perl, Python). The infrastructure should elegantly manage all tasks, and not require a “walled garden” to favor queries over export, or vice-versa.

My observation has been that the design methodology of an Analytical Data Warehouse is substantially different from a Reporting Data Warehouse. Understanding the primary customer of a data warehouse can often help simplify operations of the data warehouse and help lower the operating point costs substantially by making priorities clearer.

Both Aster Data and Greenplum made announcements this week that illustrated different approaches. At the same time that Aster Data announced the Aster Analytics Center, Greenplum announced an upcoming product named Chorus. I wanted to take a moment to compare and contrast what these announcements say about the direction of the two companies.

Greenplum’s approach speaks to two traditional problem areas i) access to data, from provisioning of data marts to connectivity to data across marts, and ii) some level of collaboration among certain developers and analysts. Their approach is to create a tool for provisioning, unified data access, and sharing of annotations and data among different developers and analysts. Interestingly, this is not an entirely new concept; these are well-known problems for which a number of companies and tools have already developed best-of-breed solutions over the last 15 years. For example, the capabilities for data access are another version of Export/Copy primitives that already exist in all databases and that have been built upon by common ETL and EII tools for cases in which richer support than Export & Copy are needed – for instance, when data has to be transformed, correlated or cleaned while being moved from one context (mart) to another (mart).

This approach is indicative of a product direction in which the primary focus is on adding another option to the list of tools available to customers to address these problems. It’s really not a ground-breaking innovation that evolves the world of analytics. New types of analytics, or ‘data-driven applications,’ is where the enormous opportunity lies. The Greenplum approach of data collaboration is interesting in a test environment or sandbox. When it comes to real production value however, it effectively increases the functions available to the end user, but at a big cost due to significant increases in complexity, security issues and extra administrative overhead. What does this mean exactly?

• The spin-up of marts and moving data around can result in “data sprawl” which ultimately increases administrative overhead and is dangerous in these days of compliance and sensitivity to privacy and data leaks.
• Adding a new toolset into the data processing stack creates difficult and painful work to either manage and administer multiple tool sets for similar purposes or to eliminate and transition away from investments in existing toolsets.
• To enable effective communication and sharing, users need strong processes and features for source identification of data, data collection, data transformation, rule administration, error detection & correction, data governance and security. The quality and security policies around meta-data are especially important as free-form annotations can lead to propagation of errors or leaks in the absence of strong oversight.

In contrast, Aster Data’s recent announcements support our long-standing investments in our unique advanced in-database architecture where applications run fully inside Aster Data’s platform with complete application services essential for complex analytic applications. The announcements highlight that our vision is not to create a new set of tools and layers in the data stack that recreate capabilities currently available from a number of leading vendors, but rather to deliver a new Analytics Platform, a Data-Application Server, to uniquely enable analytics professionals to create data-rich applications that were impossible or impractical before – namely, to create and use advanced analytics for rich, rapid, and scalable insights into their data. This focus is complemented by our partners, who offer proven best-of-breed solutions for collaboration and data transformation.

A key illustration of the investments that Aster is making in this vision is the formation of the new Aster Analytics Center: a center of excellence; ready-to-use analytics solutions that leverage MapReduce; and best practices for advanced analytics on big data. The Center’s charter is to develop products and provide insights that help organizations use data in clever ways to enable data-driven decisions. The Center is headed by Dr. Jonathan Goldman, our Director of Analytics and Applications, and a team of analytics experts. Jonathan joined us from LinkedIn, where as their Principal Scientist he led a team of analytics researchers to build cutting-edge products with the rich data sets LinkedIn has amassed. His team’s focus was on driving growth and user engagement for the LinkedIn social network. His team developed a successful model to build, ship, and iterate – to deliver value to LinkedIn effectively and sustainably. Across 3 years, he and his team delivered several industry-first features that surprised and delighted LinkedIn’s users – “People You May Know,” “Who Viewed My Profile?” “Jobs that are Similar to Mine,” and several others.

One of the first product solutions from the Aster Analytics Center is a suite of advanced analytics modules built on SQL and MapReduce called ‘Aster Data Analytic Foundation.’ The suite makes it easy for data analysts to leverage large volumes of diverse data effectively. This package, which made its debut with our nCluster 4.5 release, announced in February, provides a suite of rich analytic functions that enable data scientists and users to manipulate data easily rather than building primitives from scratch.

The second aspect of the Analytics Center’s charter, the methodology of using data, is being addressed by their work to create analytics best practices that provide blueprints for data analysts to develop their insights into an operational data product that can be delivered repeatably.

From what we see already with customers, the Aster Analytics Center – the Aster Analytics Foundation solution, big data analytics best practices, and deep analytics expertise – will be a catalyst accelerating a chain reaction that will revolutionize data usage across industries.

The key observation was that individuals, groups and organizations are struggling to discover, assemble, organize, act on, and gather feedback from data. Data itself is growing and fragmenting at an exponential pace. We as individuals feel overwhelmed by the slew of data (messages, emails, news, posts) in the microcosm, and we as organizations feel overwhelmed in the macrocosm.

The very real danger is that an individual or organization’s feeling of being constantly overwhelmed could result in the reduction of their “Aha!” moments – our resources will be so focused on merely keeping pace with new information that we won’t have the time or energy to connect the dots.

The goal then is to find tools and best practices to enable the “Aha!” moments – to connect the dots even as information piles up on our fingertips.

My thought going into the conference was that we need to understand what causes these “Aha!” moments. If we understand the cause, we can accelerate the “Aha!” even at scale.

Earlier this year, Janet Rae-Dupree published an insightful piece in the International Herald Tribune on Reassessing the Aha! Moment. Her thesis is that creativity and innovation – “Aha! Moments” – do not come in flashes of pure brilliance. Rather, innovation is a slow process of accretion, building small insight upon interesting fact upon tried-and-true process.

Building on this thesis, I focused my talk on using frontline data warehousing as an infrastructure piece that allows organizations to collect, store, analyze and act on market events. The incremental fresh data loads in a frontline data warehouse add up over time to build a stable historical context. At the same time, applications can contrast fresh data with historical data to build the small contrasts gradually until the contrasts become meaningful to act upon.

I’d love to hear back from you on how massive data can accelerate, rather than impede, the “Aha!” moment.

Aggregate Knowledge powers a discovery network (The Pique Discoveryâ„¢ Network) that delivers recommendations of products and content based on what was previously purchased and viewed by an individual using the collective behavior of the crowds that had behaved similarly in the past. Again, each 1% increase of engagement is a significant revenue stream for them and their customers.

ShareThis provides a sharing network via a widget that makes it simple for people to share things they find online with their friends. In a short period of time since their launch, ShareThis has reached over 150M unique monthly users. The amazing insight is that ShareThis knows which content users actually engage with, and want to tell their friends about! And in its sheer genius, ShareThis gives away its service to publishers and consumers free; relying on delivering targeted advertising for its revenue: by delivering relevant ad messages while knowing the characteristics of that thing being shared. Again, the better their analytics, the better their revenue.

Which brings me to my point: data analytics is a direct contributor of revenue gains in these companies.Traditionally, we think of data warehousing as a back-office task. The data warehouse can be loaded in separate load windows; loads can run late (the net effect is that business users will get their reports late); loads, backups, and scale-up can take data warehouses offline –which is OK since these tasks can be done on non-business hours (nights/weekends).But these companies rely on data analytics for their revenue.· A separate exclusive load window implies that their service is not leveraging analytics during that window;· A late-running load implies that the service is getting stale data;· An offline warehouse implies that the service is missing fresh trendsAny such planned or unplanned outage results in lower revenues.On the flip side, a faster load/query provides the service a competitive edge – a chance to do more with their data than anyone else in the market. A nimbler data model, a faster scale-out, or a more agile ETL process helps them implement their “Aha!” insights faster and gain revenue from a reduced time-to-market advantage.These companies have moved data warehousing from the back-office to the frontlines of business: a competitive weapon to increase their revenues or to reduce their risks.In response, the requirements of a data warehouse that supports these frontline applications go up a few notches: the warehouse has to be available for querying and loading 365×24x7; the warehouse has to be fast and nimble; the warehouse has to allow “Aha!” queries to be phrased.We call these use cases “frontline data warehousing“. And today we released a new version of Aster nCluster that rises up those few notches to meet the demands of the frontline applications.

We’re happy to see a similar anticipation and word-of-mouth about some new ideas Aster is bringing to the data analytics market. Seems that good news is just too hard to keep to yourself.

We’re serving up something unique that we’ve been preparing for several years now. We’re just as excited to be bringing you this fresh approach.