Investment banks rely extensively on grids to dramatically increase throughput for their calculations for analytics (especially risk). The traditional design pattern involves executing compute intensive workflows where jobs require movement of large data files to the compute nodes, calculation results creating files which then are again consumed by the next job in the flow. Increasingly, the pattern is shifting to running short lived tasks where the bottleneck is data i.e. the time spent to move data back and forth between compute nodes can be overwhelming - turning a compute bound job to be a IO bound one. For instance, real time pricing for financial derivative instruments could just take a few milliseconds, but, the time required for the data transfer could be hundreds of milliseconds. The talk focuses on one architectural pattern gaining popularity - move the compute to the data. The data is partitioned in grid memory across many nodes and the compute task is routed to the node with the right data set provisioned based on the data hints it provides during launch. We discuss the features of the main-memory based data grid solution that uses different data partitioning policies such as hashing or data relationship based to manage data across a large cluster of nodes. We also discuss techniques for rebalancing data and behavior across the Grid nodes to achieve the best throughput and lowest latency.

1. Low Latency Data Grids in Finance Jags Ramnarayan Chief Architect GemStone Systems [email_address]

7. Data Fabric for Risk Analytics When data is stored, it is transparently replicated and/or partitioned; Redundant storage can be in memory and/or on disk— ensures continuous availability Keep reference data replicated on many; partition trade data Machine nodes can be added dynamically to expand storage capacity or to handle increased client load Pool memory (and disk) across cluster ; parallelize data access and computation to achieve very high aggregate throughput

8. Data Fabric for Risk Analytics TaskFlow - As results are generated push events to compute nodes to initiate subsequent computation Avoid bulk data transfer across tasks or Jobs Thousands of compute nodes can maintain local cache of most frequently used data; Optionally use local disk for overflow Move reference data to local cache Synchronous read through, write through or Asynchronous write-behind to other data sources and sinks