In 2014, infrastructure components such as Hadoop, Berkeley Data Stack and other commercial tools have stabilized and are thriving. The challenges have moved higher up the stack from data collection and storage to data analysis and its presentation to users. The focus for this year’s conference on analytics – the infrastructure that powers analytics and how analytics is done.
Talks will cover various forms of analytics including real-time and opportunity analytics, and technologies and models used for analyzing data.
Proposals will be reviewed using 5 criteria:
Domain diversity – proposals will be selected from different domains – medical, insurance, banking, online transactions, retail. If there is more than one proposal from a domain, the one which meets the editorial criteria will be chosen.
Novelty – what has been done beyond the obvious.
Insights – what insights does the proposal share with the audience that they did not know earlier.
Practical versus theoretical – we are looking for applied knowledge. If the proposal covers material that can be looked up online, it will not be considered.
Conceptual versus tools-centric – tell us why, not how. Tell the audience what was the philosophy underlying your use of an application, not how an application was used.
Presentation skills – proposer’s presentation skills will be reviewed carefully and assistance provided to ensure that the material is communicated in the most precise and effective manner to the audience.
For queries about proposals / submissions, write to firstname.lastname@example.org
Data Collection and Transport – for e.g, Opendatatoolkit, Scribe, Kafka, RabbitMQ, etc.
Data Storage, Caching and Management – Distributed storage (such as Gluster, HDFS) or hardware-specific (such as SSD or memory) or databases (Postgresql, MySQL, Infobright) or caching/storage (Memcache, Cassandra, Redis, etc).
Data Processing, Querying and Analysis – Oozie, Azkaban, scikit-learn, Mahout, Impala, Hive, Tez, etc.
Big data and security
Big data and internet of things
Data Usage and BI (Business Intelligence) in different sectors.
Please note: the technology stacks mentioned above indicate latest technologies that will be of interest to the community. Talks should not be on the technologies per se, but how these have been used and implemented in various sectors, enterprises and contexts.
Storing relationships in large data-sets using Graphs
Problem Statement - Fast Programmatic/self-serve analytics on linked data in an ad system by indexing it across all cuts, especially for traversals like -
- Find all users who came from ‘iphone’ and ‘SFO’ with 10k or more clicks within the last two days.
- Find all users who played ‘Subway sufers’ from U.S. more than 10 times in the last week.
As it’s evident from the above examples these class of queries are different from a typical pointed query like - “find my friends who have been to golden gate birdge in the last year and have liked hiking articles”. This class of query start with a point lookup and then a BFS traversal with appropiate filtering criteria which are addressed by db’s like neo4j, titan in a generic fashion.
Scope of the talk -
- highlight the internals of what it takes to solve for non-pointed queries in a generic fashion.
- extend it to support the tinker pop api specification from neo4j, titan so that users can easily flip from one backend to another.
This work was motivated to store large amounts of linkeddata in an ad system and make it available for programmatic/analytics consumption.
This talk outlines our journey which started from researching existing graphdb’s/processing frameworks, why they didn’t work for us at our scale and then moving on to build something.
We will go in depth to explain the data-structures used and how we supported the tinker-pop graph API specification( used by all graph databases). We will also touch upon how our ad-system unique data model allowed us to come up with a fairly simplistic technique to shard the entire thing and query over it.
Takeaways from this talk -
- what are graphdb’s, when should you choose one.
- different use-cases require different stores.
- what it takes to build a graph store for allo-centric(alike OLAP) graph traversals.
- inclination towards linked-data, everything else will be covered.
Inder Singh - have been working on solving data related problems at Inmobi(World’s largest independent ad-network) for the past ~3 years.
- LinkedIn - http://www.linkedin.com/in/indspall
- Speaker at hadoop meetups at informatica, Yahoo - http://www.slideshare.net/InderSingh10/meetup-realtime-datacollection