Stephen Brobst, Teradata’s CTO, took open Q&A.
- What’s the business and architectural impact of the temporal (and spatial) extensions in 13.10?
Most Teradata customers are doing temporal things but implementing manually today using things like effective date columns. This is hard work and the new feature makes it easier to manage, more accessible to customers (some of whom have given up on keeping history due to cost/complexity) and slightly more efficient. As more customers adopt data mining temporal is becoming more important because it is important to be able to get data as of the day a customer signed up or as of 30 days after they became a customer. In addition, changing product hierarchies/territories etc can create complexity in reporting and this feature will make this easier also (at least once the BI tool generates the new SQL).
- What about the challenges of working with BI vendors who have competitive data warehouse products?
IBM has a long history of working well with Teradata despite the competition of DB2 and is set up to make it possible for some groups to partner while others compete. Oracle has acquired a bunch of good Teradata partners over the years (Synopsis, Hyperion, Siebel Analytics) and has less of a history of partnering. Nevertheless, Teradata feels that this has gone well and Oracle has become a really strong partner also. In fact the additional resources Oracle invests in these products has helped with some strong Teradata specific enhancements.
- What about complex event processing? Can Teradata handle streaming data?
Teradata does not have a CEP engine today, though it works with CEP engines to allow them to access historical data alongside the streaming data/events. Plan is to enable CEP engines but Teradata has no plans for a CEP engine of their own. They can ingest and manipulate data in a very low latency environment but don’t plan to have the rest of what a CEP engine needs (rules, streaming analytics etc).
- How does Teradata enable low latency access to date outside the warehouse for embedded analytics like the SAS in-warehouse analytic tools?
External table functions allow SAS to access data from outside the warehouse in the same way as data that is inside the warehouse (though this may or may not be low latency access).
- What about in-memory databases?
In-memory processing is an important performance tool but Teradata sees the growth in data outpacing the ability to put all the data in memory. So it will be important to keep the right data in-memory (to support the workloads where this makes sense) and integrate this with data in other storage (by partitioning by row or by column for instance). Storage hierarchies are going to become more complex and more dynamic to take advantage of new technologies and approaches like solid-state disks, in-memory etc. What will make the difference in the future is more effective use of the various storage technologies by better understanding the data, its usage and its temperature.
- Is Teradata going to support native XML storage and access?
More and more data is available XML but Teradata is “moving with caution” to support XML objects that are natively supported with XQuery etc. See more interest in working with files systems, MapReduce or Hadoop, for instance. Text partners are becoming more important.
- What about in-warehouse decisioning?
Some customers pushing the logic into the warehouse as well as the analytics, but mostly as SQL. No plans today to push rules management / rule execution capabilities into the warehouse to enable in-warehouse decisioning.
Stephen wrapped up with some thoughts on extreme warehousing and noted that sensor data will turn out to be more “extreme” than text data because there is so much potential information about location and movement. Large warehouses are now >1PB with largest customers becoming multi-Petabyte installs with millions of users (albeit casual and low impact users). A brave man to take open Q&A from this audience!