Showing posts with label research-paper. Show all posts
Showing posts with label research-paper. Show all posts

Thursday, May 29, 2014

Feature Selection - methods and algorithms

"Feature selection is often an important step in applications of machine learning methods and there are good reasons for this. Modern data sets are often described with far too many variables for practical model building. Usually most of these variables are irrelevant to the classification, and obviously their relevance is not known in advance. There are several disadvantages of dealing with overlarge feature sets. One is purely technical — dealing with large feature sets slows down algorithms, takes too many resources and is simply inconvenient. Another is even more important — many machine learning algorithms exhibit a decrease of accuracy when the number of variables is significantly higher than optimal. Therefore selection of the small (possibly minimal) feature set giving best possible classification results is desirable for practical reasons. This problem, known as minimal-optimal problem, has been intensively studied and there are plenty of algorithms which were developed to reduce feature set to a manageable size."

I list three interesting articles related to feature selection:





All of these algorithms can be implemented using map-reduce paradigm in tools like hadoop or spark and they can provide high scalability on large scale datasets.

sources:
http://www.cs.cmu.edu/~daria/papers/fslr.pdf
http://penglab.janelia.org/proj/mRMR/FAQ_mrmr.htm
http://www.jstatsoft.org/v36/i11/paper

Friday, May 23, 2014

Google Papers and open source projects - where it all started

Most (if not all) open-source big data projects were inspired on Google's technologies after Google publishing papers describing how they solved distributed systems and parallel computing problems.

Here are the list of the most impotant original google's papers and related open-source projects:

Google File System - 2003 (http://research.google.com/archive/gfs.html)
Short description: distributed file system using commodity machines.
Related Open Source Projects:

MapReduce - 2004 (http://research.google.com/archive/mapreduce.html)
Short description: programming model for distributed processing.
Related Open Source Projects:
Short description: distributed storage system for managing structured data, inspiration for NoSQL databases.
Related Open Source Projects:

Percolator - 2010 (http://research.google.com/pubs/pub36726.html)
Short description: a system for incrementally processing updates to a large data set.
Related Open Source Projects:

Dremel - 2010 (http://research.google.com/pubs/pub36632.html)
Short description: a scalable, interactive ad-hoc query system for analysis of read-only nested data.
Related Open Source Projects:

Pregel - 2010 (http://kowshik.github.com/JPregel/pregel_paper.pdf)
Short description: a system for large-scale graph processing and graph data analysis..
Related Open Source Projects:

FlumeJava - 2010 (http://pages.cs.wisc.edu/~akella/CS838/F12/838-CloudPapers/FlumeJava.pdf)
Short description: a library that makes it easy to develop, test, and run efficient data- parallel pipelines.
Related Open Source Projects:

Tenzing - 2011 (http://research.google.com/pubs/pub37200.html)
Short description: query engine built on top of MapReduce for ad hoc analysis of Google data.
Related Open Source Projects:
Short description: BigTable + transactions + schema.

Spanner - 2012 (http://research.google.com/archive/spanner.html) and
F1 - 2013 (http://research.google.com/pubs/pub41344.html)
Short description: hybrid database that combines high availability, the scalability of NoSQL systems like Bigtable, and the consistency and usability of traditional SQL databases.

PowerDrill - 2012 (http://research.google.com/pubs/pub40465.html)
Short description: answering ad hoc queries over large datasets in an interactive manner.

Sampling-based Database

Everyone knows that the amount of data exploded, although technology also advanced, tasks involving exploration of petabyte datasets are not as fast as you may need for your data explorations interactive work.

Solution? What about start analysing sample results of your queries?

Look at this AMPLab project and these two AMPLab papers:

BlinkDB
is a large-scale data warehouse system built on Shark and Spark that aims to achieve real-time (i.e., sub-second) query response times for a variety of SQL-based aggregation queries (augmented by a time and/or error bound) on massive amounts of data. This is enabled by not looking at all the data, but rather operating on statistical samples of the underlying datasets. More precisely, BlinkDB gives the user the ability to trade between the accuracy of the results and the time it takes to compute queries. The challenge is to ensure that query results are still meaningful, even though only a subset of the data has been processed. Here we leverage recent advances in statistical machine learning and query processing. Using statistical bootstrapping, we can resample the data in parallel to compute confidence intervals that tell the quality of the sampled results.

SampleClean: Fast and Accurate Query Processing on Dirty Data
In emerging Big Data scenarios, obtaining timely, high-quality answers to aggregate queries is difficult due to the challenges of processing and cleaning large, dirty data sets. To increase the speed of query processing, there has been a resurgence of interest in sampling-based approximate query processing (SAQP). In its usual formulation, however, SAQP does not address data cleaning at all, and in fact, exacerbates answer quality problems by introducing by sampling error. We explore the use of sampling to actually improve answer quality. We introduce the Sample-and-Clean framework, which applies data cleaning to a relatively small subset of the data and uses the results of the cleaning process to lessen the impact of dirty data on aggregate query answers.


Knowing When You’re Wrong: Building Fast and Reliable Approximate Query Processing Systems
Modern data analytics applications typically process massive amounts of data on clusters of tens, hundreds, or thousands of machines to support near-real-time decisions.The quantity of data and limitations of disk and memory bandwidth often make it infeasible to deliver answers at interactive speeds. However, it has been widely observed that many applications can tolerate some degree of inaccuracy. This is especially true for exploratory queries on data, where users are satisfied with “close-enough” answers if they can come quickly. A popular technique for speeding up queries at the cost of accuracy is to execute each query on a sample of data, rather than the whole dataset. To ensure that the returned result is not too inaccurate, past work on approximate query processing has used statistical techniques to estimate “error bars” on returned results. However, existing work in the sampling-based approximate query processing (S-AQP) community has not validated whether these techniques actually generate accurate error bars for real query workloads. In fact, we find that error bar estimation often fails on real world production workloads. Fortunately, it is possible to quickly and accurately diagnose the failure of error estimation for a query. In this paper, we show that it is possible to implement a query approximation pipeline that produces approximate answers and reliable error bars at interactive speeds.

A Sample-and-Clean Framework for Fast and Accurate Query Processing on Dirty Data
In emerging Big Data scenarios, obtaining timely, high-quality answers to aggregate queries is difficult due to the challenges of processing and cleaning large, dirty data sets. To increase the speed of query processing, there has been a resurgence of interest in sampling-based approximate query processing (SAQP). In its usual formulation, however, SAQP does not address data cleaning at all, and in fact, exacerbates answer quality problems by introducing sampling error. In this paper, we explore an intriguing opportunity. That is, we explore the use of sampling to actually improve answer quality. We introduce the Sample-and-Clean framework, which applies data cleaning to a relatively small subset of the data and uses the results of the cleaning process to lessen the impact of dirty data on aggregate query answers. We derive confidence intervals as a function of sample size and show how our approach addresses error bias. We evaluate the Sample-and-Clean framework using data from three sources: the TPC-H benchmark with synthetic noise, a subset of the Microsoft academic citation index and a sensor data set. Our results are consistent with the theoretical confidence intervals and suggest that the Sample-and-Clean framework can produce significant improvements in accuracy compared to query processing without data cleaning and speed compared to data cleaning without sampling.


souces:
http://blinkdb.org/
http://sampleclean.org/
https://amplab.cs.berkeley.edu/projects/sampleclean-fast-and-accurate-query-processing-on-dirty-data/
https://amplab.cs.berkeley.edu/publication/knowing-when-youre-wrong-building-fast-and-reliable-approximate-query-processing-systems/

research papers:
http://www.cs.berkeley.edu/~sameerag/blinkdb_eurosys13.pdf
https://amplab.cs.berkeley.edu/wp-content/uploads/2014/05/mod282-agarwal.pdf
https://amplab.cs.berkeley.edu/wp-content/uploads/2014/05/sampleclean-sigmod14.pdf

Large-scale Video Classification with Convolutional Neural Networks

Google paper about Video Classification using Neural Networks.

paper: https://plus.google.com/+ResearchatGoogle/posts/eqSPSviY2CH

Look at the video below, showing which sport the algorithm predicted frame-by-frame.

I'm wondering how long did it take to classify all the frames. Imagine if it was possible to do in real-time...
PS: I got an answer from Andrej Karpathy (thanks Andrej):
"inference is embarrassingly parallel process so this video could be done almost instantly given enough CPUs on cluster as done in this work. On modern GPUs, CNNs like this run at about 2ms/frame, and since 72 seconds = ~2160 frames you'd expect somewhere around 5 seconds for this video."



source: https://plus.google.com/+ResearchatGoogle/posts/eqSPSviY2CH