WHY IN-MEMORY TECHNOLOGY WILL DOMINATE BIG DATA

Transcription

1 WHY IN-MEMORY TECHNOLOGY WILL DOMINATE BIG DATA In-Memory and the New BI Robin Bloor, Ph.D. WHITE PAPER

2 A Tale of Two Markets Big data is primarily about business intelligence (BI). There are a few areas of big data activity that are not focused on the opportunity to gather data from new sources, possibly combine it with data from established sources and then analyze it; however, the goal of data analysis is, as always, to discover new knowledge about some area of an organization s activity and exploit it. Big data itself may be gathered from a variety of sources: agents and partners up and down a supply chain; RFID data and data from embedded systems and sensors; mobile applications data; data from public data providers of many kinds, including the plethora of real-time data streams; social media data; data from the large number of log files (web site logs, computer logs, network logs, application logs, etc.); and more. Some of these data sources are new, but others were simply too voluminous to use until recently. In some ways it is the forward march of Moore s Law delivering ever more powerful technology at every level that is responsible for the dawn of the Big Era. However, the computer power has been usefully complemented by the emergence of open source Hadoop and the rapid deployment capabilities of cloud computing. The fact is that organizations are investing in big data projects because they can afford to and because they expect to reap significant benefits. Old BI and New BI BI applications have evolved considerably since the 1990s when business intelligence first began to flower. Nowadays, we can reduce BI into two distinct areas of activity: old BI and new BI. The old BI applications include the traditional areas of business monitoring such as reporting, data visualizations, analytical processing, dashboards and KPIs. What we regard as new BI has developed out of the area of data analytics which had, to some extent, been a cloistered activity, usually fed from a data warehouse and focused mainly on company data. This is now spoken of as the domain of the data scientist. It includes: exploration by data analysts/data scientists to reveal new insights that can be applied to the business. Advanced predictive analytics which reveals knowledge that can be acted on swiftly, often to preemptively manage business situations, i.e., to take advantage of a trend as it develops. These activities have been enlivened by the availability of new (big) data that was previously not subjected to analysis of any kind. Without wishing to disparage the useful contribution of old BI applications, it is clearly with the new BI applications that companies look for and find valuable insights into their business activities. The Value of Information From an IT perspective the new BI applications can be problematic to support. The need is for a highly productive environment which enables the data analyst to carry out analysis swiftly and implement the knowledge that has been discovered quickly so that it is delivered to the individual or software application that can use it just-in-time or sooner. 1

3 Even so, there are three different latencies that an organization will experience with the new BI. 1. The Time to Discovery: The time it takes for a data scientist to explore a collection of data and discover useful knowledge in it. 2. The Time to Deployment: The time it takes to implement the discovered knowledge within the business processes that it can enrich. 3. Knowledge Delivery Time: The time it takes for the BI application to deliver its knowledge in real time. New BI is distinctive in requiring very fast processing on large or even very large volumes of data tens to hundreds of terabytes and beyond. And there is a simple economic imperative for carrying out new BI as swiftly as possible. Consider, hypothetically, an analytical project where a data scientist discovers a data pattern that can save a business one million dollars per week when implemented. Now assume it takes the data scientist six months of analytical activity to make the discovery and prove the soundness of it: time to discovery is six months. Imagine, as is likely, that to utilize that discovery an analytical engine needs to be permanently analyzing streams of data not only identifying the patterns, but following any trends it exhibits. It may take significant time, maybe three months, to implement this. Time to deployment is three months. When implemented there will inevitably be a time lag before the analytical engine can feed usable knowledge to BI users let s say five minutes. Knowledge delivery time is five minutes. If it were possible to cut the discovery time and the deployment time to one month, then this would reduce the time to value by seven months. It would be worth an extra $28 million to the business, and that value would begin to be realized seven months earlier. In some situations the knowledge delivery time will be an important factor. This is contextual and it is easiest to see in competitive situations. Consider the stock market. Stock prices change in fractions of a second. If data analysis shows that a specific trigger will move a stock price, then you will make the most profit in the sale or purchase of that stock at the moment the trigger occurs. If you take action five minutes later, you may make less profit or miss the opportunity completely. Today, of course, automated trading happens in fractions of a second for very small stock price movements that obey known statistical patterns. However, there are many business situations where the delivery of knowledge needs to be very fast. There are many in web businesses: ad placement on web sites, web site behavior, computer gaming, the identification of trends on Twitter and so on. There also many transportation, telecoms, retail and media applications. The Strategic Deployment of In-Memory Technology As a rough rule of thumb, reading from memory is more than 3,300 times faster than reading from disk. A simple calculation would suggest that if it takes an hour to read a set of information from disk, it would take just over a second to read it from memory. The difference is dramatic, but of course memory is more expensive than disk. The relative cost, at 2

4 the time of writing, is about 100:1; a terabyte of disk costs about $50 and a terabyte of memory about $4,500. Clearly it makes no economic sense to hold all corporate data in memory, even given an unlimited budget, as most data is rarely accessed. There are also other factors to consider. solid state disk (SSD) has become an important data storage option. In practice SSDs speed up data access by a factor of between three and ten (it depends on workload), so they do not come close to in-memory speeds. They are about ten times the cost per byte of HDD (normal disk) at the moment. The picture is further complicated by the fact that data volumes grow fairly rapidly for many businesses, and workloads can vary significantly from one BI project to another. If the goal is to accelerate BI activities dramatically, the natural approach is to have an inmemory processing resource that can be used where it makes a difference, flowing the data from disk through SSD to memory in order to support those BI workloads. In other words, data is kept in memory when the value obtained from processing it is high, and data stays on disk when it is inactive or the value from processing it is low. The Morphing of the base We have entered a stimulating era of database innovation. It began when the scalability of the traditional relational databases tailed off, leading to a focus on column-store and NoSQL databases with scale-out architectures that were better suited to processing very large amounts of data. At almost the same time, the inexpensive and highly scalable Hadoop appeared not a database per se, but a very useful data store and platform. It can be, and is, used effectively as a data reservoir and as a staging area for flowing data to analytical databases. Although Hadoop was not engineered for performance in the way that many databases are, it enabled businesses to inexpensively collect much larger volumes of data than before. This was not just archived and log file data, but also external data from social media, public data sources, partners and suppliers. This capability was a blessing in giving companies more valuable data to mine, but it also increased the computer workload of data analyst activities significantly. As a consequence, for many businesses Hadoop has become an integral component of data exploration and data analysis activity. But, if performance is important, and in this area it nearly always is, its use needs to be considered. In simple architectural terms, you can either move the processing to where the data is or you can move the data to where the processing is. When you have very large amounts of data, it will obviously be better to move the processing to the data. But Hadoop is not lightning fast, nor is it easy to program. This creates a definite challenge, especially if one needs the muscle that in-memory processing provides, because neither Hadoop nor any of its components have in-memory capabilities. The nature of data analysis further complicates the situation. With analytics, the data analyst conducts a fairly extensive dialogue with the data that may involve many steps. In modeling a problem the analyst may read just a small sample of the data and interact with it using various statistical techniques. So the first query might hit all the data, perhaps even hundreds of terabytes or even petabytes of data, to extract the required sample. Hadoop might process that query reasonably swiftly. But then the rest of the data analyst interactions including data preparation and cleansing might involve a relatively small amount of data which could 3

5 be held in memory and against which various mathematical routines execute. This is not going to work well with Hadoop. Once the data analyst is finished with modeling, he or she may wish to query a much larger volume of data, but again this might fit into memory if a sufficiently large memory configuration were available. And if not, then it might be best to flow the data to memory anyway to take maximum advantage of in-memory speed. The important point is that the data analyst activity is an iterative conversation with the data, and for maximum speed, the in-memory resource needs to be used optimally, not just for querying, transforming and cleansing data, but also for applying mathematical functions to it. It demands more than an in-memory database, it requires an in-memory analytical database which can apply parallel processing to both data queries and to mathematical calculations. Such an architecture will produce two useful and profitable outcomes: 1. The data analyst achieves greater productivity 2. The knowledge gained by the data analyst can be acted on more swiftly In-Memory Analytical Platforms There are currently just a few software platforms that can work in the manner we have described. Here we describe one that is offered by Kognitio, illustrated in Figure 1. Analyst Tools BI Tools MS Excel OLAP Clients Application Layer Queries Results Kognitio SSD Near Line/ SSD Analytical Platform Feeds Storage Hadoop Hadoop Hadoop EDW Cloud Storage Other Other Stores Stores Reporting Persistence Layer Figure 1. Kognitio Overview Kognitio is both an in-memory database and an analytical engine that can execute analytical functions. As such it naturally fits in between a persistence layer which stores persistent data and a layer of applications that can exploit its capabilities. It can gather and/or store data from other data sources, including many databases, Hadoop and cloud storage services, 4

6 and has the option to read from and write to available local storage from memory, if memory resources become exhausted. This analytical platform can be added incrementally into almost any computing environment. As the diagram indicates, while data feeds of any type might flow into the persistence layer, many reporting and BI functions can carry on as they did before. The customer is only likely to deploy this product for those BI tasks that will benefit from a big acceleration in execution time. The database runs on commodity servers, usually with large amounts of configured memory on each and, possibly, extended by the addition of SSD or near-line storage. It employs a massively parallel processing (MPP) engine that scales linearly. It can be upgraded simply by adding more servers (i.e., more CPUs and memory) as needed. It loads data in parallel at the persistence layer, distributing it across the grid to create its in-memory data store and balancing the resources available to it. It can continue to ingest data in real time, without disturbing any of the queries it is executing. It serves a BI applications layer which can include data analyst tools and more conventional BI tools, including Microsoft Excel and OLAP clients. Analytical Tasks Kognitio supports the industry-standard interface SQL (ODBC and JDBC) as well as MDX for OLAP queries. To satisfy MDX queries, it builds virtual in-memory cubes. However, it is not just a query engine. It can also execute analytical processing, running third-party binaries embedded directly within SQL commands. In this way, it delivers full MPP execution of WPS libraries, R, Python, Java and other languages, so that the whole workload is executed in parallel. It can, by wrapping it in SQL, include any script or binary that will run under Linux. It can also be configured to isolate workloads. It achieves this by treating part of the MPP configuration as a hub, automatically building external table instances on other nodes of the grid for each isolated workload. In this way, for example, data analyst workloads can be given a greater share of the available resources than other BI workloads and OLAP workloads. Overall, the engine works in a distinctly different manner than, for example, a scalable column store database. As it has a full in-memory architecture, it does not locate data on disk. Thus there is no disk I/O when a query executes, only direct memory access. When analytical routines execute they run in parallel with the query, operating on the results of the query as data becomes available. With a column store database an analytical task can be thought of as a three-step process involving reading data from disk into cache, answering the query and then applying the analytical routine to get a result. With an in-memory architecture, it is a one-step process that runs the query and the analytical calculation in parallel at a much greater speed. Hadoop Integration Naturally, situations will arise where the data is too large to fit into memory and disk I/O is necessary. Enter Hadoop. Nearly every vendor out there offers some sort of Hadoop integration, and for good reason: it can process very, very large volumes of data. Its interface, however, requires a certain level of expertise that many companies simply cannot cater for. As 5

7 a result, vendors have either developed native connectors to Hadoop or, more recently, put SQL right on top of Hadoop, both of which mitigate the skill set gap. Kognitio has an interesting solution: it integrates directly with the Hadoop environment, both at the MapReduce level and the Hadoop Distributed File System (HDFS) level, and it offers a SQL interface. By placing an agent on every node within the Hadoop cluster, it can filter data from very large files after the manner of MapReduce, but at higher speeds. A SQL query, for example, will pass selections and relevant predicates to the agents. filtering and projection is performed locally on each node, and only the data required to satisfy the query is transferred and loaded into memory, in parallel. Resolving a query to a large Hadoop cluster at the node level thus greatly reduces processing time. Similarly, connecting directly to Hadoop s file system produces faster loads of complete files. For example, when a connector defines access to HDFS, it allows an external table to grab the row-based data that is stored within it. That data can then be pinned into memory to return the query results. As mentioned, many vendors are and have been offering Hadoop connectors. It makes sense. It also makes sense to allow users to query data that is stored in Hadoop by using standard SQL. Hive is Hadoop s answer to SQL, but it must be configured. Using a SQL wrapper for Hadoop eliminates the need to learn and deploy yet another interface. The end user can continue to use SQL as a data management language and can query from Hadoop directly. A tight integration with Hadoop essentially creates a separation of concerns. In other words, Hadoop is left to store and filter data, and the analytical engine can focus on complex analytics. The Business Benefits of New BI In-memory analytics is not just about time to value, it is also about volume processing. While this may seem counter-intuitive, there are good reasons why this is so. The fact is that without an analytical engine of the kind we have described, some analytical activity will not even be attempted because the results will arrive far too late. Part of this relates to data analyst productivity. If data analysts can get results in seconds or minutes instead of hours, then they can test many more hypotheses than before and they will. They are also more likely to consider engaging in activities they previously thought impractical, such as adding to their data sources and pursuing new analytical projects. The point is that memory is three orders of magnitude (more than 1,000 times) faster than disk, and an increase in speed of that magnitude does not just open up possibilities for the data analyst, it completely changes the approach to analysis projects. The same applies to other areas of BI. If BI dashboards can be accurate up-to-the-second then it may be possible to support individual decision making in the moment, rather than report after the fact what the optimum way to handle a specific opportunity or business problem might have been. 6

8 About The Bloor Group The Bloor Group is a consulting, research and technology analysis firm that focuses on open research and the use of modern media to gather knowledge and disseminate it to IT users. Visit both and for more information. The Bloor Group is the sole copyright holder of this publication. PO Box Austin TX Tel: w w w. B l o o r G r o u p. c o m 7