The Need to Consider Hardware Selection when Designing Big Data Applications Supported by Metadata

The selection of hardware to support big data systems is complex. Even defining the term “big data” is difficult. “Big data” can mean a large volume of data in a database, a MapReduce cluster that processes data, analytics and reporting applications that must access large datasets to operate, algorithms that can effectively operate on large datasets, or even basic scripts that produce a needed resulted by leveraging data. Big data systems can be composed of many component systems. For these reasons, it appears difficult to create a universal, representative benchmark that approximates a “big data” workload. Along with the trend to utilize large datasets and sophisticated tools to analyze data, the trend of cloud computing has emerged as an effective method of leasing compute time. This chapter explores some of the issues at the intersection of virtualized computing (since cloud computing often uses virtual machines), metadata stores and big data. Metadata is important because it enables many applications and users to access datasets and effectively use them without relying on extensive knowledge from humans about the data. INTRODUCTION Big data systems have emerged as a set of hardware and software solutions to allow organizations to obtain value from the increasing volume and complexity of data that is captured. Web sites are one example of leveraging big data systems and data to improve key business metrics. For example, large organizations often have a portal site that is a vital part of their business operations, whether it a private extranet, a public site for news, or an e-commerce site. While major public portal sites often appear that they are one seamless site, they are often built from many separate applications. For example, a news site may have an application that lists the top ten most popular news articles or an ecommerce site may recommend products for a user. Increasingly, these applications or components are driven by big data systems. Major portal sites are essentially large distributed systems that appear as a seamless site. This approach allows the operators of the site to experiment with new applications and deploy new applications without impacting existing functionality. It also importantly enables the workflow of each application to be distinct and supported by the necessary hardware and application level redundancy that is appropriate for that specific application. An ecommerce site would likely invest substantial resources to ensure that the “shopping cart” application was available with an uptime of 100%, while the “recommended products” application may have a target uptime of 99.9%. Likewise, a news site may decide that the front page should be accessible with a target uptime of 100%, even during periods of extreme load such as on a national election day. The news site may decide that the “most popular articles” application should have a target uptime of 99.99%. For example, a small pool of servers may present the content for display that is produced by each application, but each application may have its own internal database servers, Hadoop cluster, or caching layer. News Site Use Case Assume that a news site began their “most popular articles application” by ranking the frequency of news article displays. The intent of the “most popular articles application” on a news site is often to increase the length of a site visit and this is naturally linked to the business objectives of an organization. If the news site is revenue driven then increasing the length of a site visit increases the likelihood that the user will click on advertisements that generate revenue for the owner. Given this background, assume that in the initial version of the “most popular articles” application, users in the southern United States caused the most popular article to be an article that discussed an impending hurricane that might hit the southern United States. Users in the central United States may only rarely read this “most popular article” since it is not relevant to users in the central United States. Calculating the most popular articles on a news site is relatively easy, assuming that a well designed database of activity exists. However, this simple calculation isn’t necessarily optimal from a business metric standpoint. The user should be presented the “most popular articles” that are actually relevant or are likely to be clicked on, since the goal is to increase traffic, not just present a ranking of the most read articles to the user. Perhaps the data scientist discovers that weather articles are generally sought out by users that are aware of impending weather events or are rarely read outside of the immediate geographic area of the weather event. The data scientist may decide to utilize information concerning the type of the article and the geographic area discussed by an article to determine whether it should be present in a “most popular articles list. ” Both enhancements require more complex data and a more complex query. For example, in the simplest revision of the “most popular articles” application, articles must be tagged with the type of article: “weather” or “non-weather” and the geographic area discussed in the article. These tags can likely be created by the article author. When a user visits the site, each user’s geographic location must be approximated so that they can be mapped to a “geographic area” that the news site recognizes. The type of article and the geographic area discussed in the article also need to be retrieved, and the algorithm can determine which articles will be the “most popular articles” for that user, considering the type of each article and the geographic area of the user and article. The article’s tags (metadata) and any information that is utilized to approximate the location should be available for rapid retrieval. This requirement is often imposed because the “most popular articles” application will need to calculate the result quickly so that the web page can be generated and displayed within a fraction of a second. An operational data store may be utilized to store and recall the data that is needed for the application. An operational data store could be implemented as an in-memory database to provide low latency responses to the “top articles” application. The hardware to support the in-memory database may be a machine with a high speed bus connecting the CPU, memory, and network card. The results of user behavior (e.g. user X read article Y or user X viewed advertisement Z) may be captured in the data warehouse for longer term analysis to develop improved algorithms, measure advertisement revenue, and monitor site traffic over time. The hardware to support a data warehouse is often a large volume of storage and compute capacity. Storage can be implemented as a storage area network, Hadoop file system, or directly attached local storage. The site and its applications will likely change over time. For example, the “top articles application” may have begun with five articles for all users but is later changed to display ten articles to all users. A metadata store could track the number of articles that the top articles application displayed during a given date range. Analytics and reporting applications would utilize the metadata store and the data warehouse to explore the relationship between the number of articles displayed through the “top articles application” and the number of articles that users read, including information about their geographic area. BACKGROUND The performance of the application is often the ultimate concern of the big data system designer. Business managers are not concerned with which components are utilized, but merely that the system will achieve its performance targets such as precision, recall, and “response to application within . 1 seconds. ” Therefore, the system designer’s job is to determine which components and hardware can reach the desired performance targets when coupled with an appropriate algorithm. Obviously, the capabilities of current hardware technologies are useful in order to determine the latency and throughput that is achievable for a given budget. For example, system designers could implement an operational data store to create near real-time response rates. However, an operational data store would be cost prohibitive for an archived dataset where all of the data did not have to be close to the applications as memory and solid state (or flash) storage has traditionally been more costly per gigabyte than a magnetic disk. Ultimately, the applications that will execute on the hardware need to be considered as part of the decision to ensure that the application will be able to meet its performance targets when implementation is complete as various implementations of algorithms will result in differing performance results. Background in Virtualization The use of a virtualized environment (such as most cloud providers) presents additional complexity to the big data system architect, due to the fact that virtualization adds an additional source of overhead to the system that must be factored into the hardware and software selection process. Virtualization also enables fault tolerance when the hardware is experiencing a failure (such as degraded network connectivity because one network card in a team has failed or a disk has failed in a RAID array) and the operator wishes to move the workload to another piece of hardware while the repairs are occurring. Obviously, many modern applications that are intended to execute in distributed environments have some support for fault-tolerance, but some applications are not designed to handle hardware failures. Alternatively, it may be more efficient to relocate a workload rather than restart the execution of the workload (MPI jobs without check-pointing are one situation where the ability to migrate a workload from one failing node to a new node may save significant computati