brain of mat kelcey

e10.0 introducing tgraph

so e9 sip is on hold for a bit while i kick off e10 tgraph. was looking for another problem to try hadoop with and came across a classic graph one, pagerank. a well understood algorithm like page rank will be a great chance to try pig, the query language that sits on top of hadoop mapreduce.

so we need a graph to work on. my first thoughts were using one of the wikipedia linkage dumps but it feels a bit sterile. instead it's a good excuse to do a little crawl of the following graph of twitter.

this will also be a chance to try to document a project via a blog. skorks' incessant blog rambling has convinced me to give it a go.

first hadoop experiment

just finished my first hadoop experiment.

matpalm.com/sip

not fantastic results but heaps of of feedback from hadoop mailing group

more results coming soon

how using compressed data can make you app faster

when working with larger data sets (ie more than can fit in memory) there are two important resources to juggle…

cpu. how quickly can you process the data.
disk io. how quickly can you get data to the cpu.

i remember reading once that depending on your situation you might be better off using data compressed on disk. why? because the extra cpu time used decompressing it is worth it for the time saved getting it off disk.

i’ve recently been working with a number crunching app (burns 100% cpu of a quadcore machine for an hour over a 7gb working dataset) and thought it’d be a good chance to try this theory.

quite surprisingly it actually worked; the 7.2gb dataset came down to 1.3gb and the runtime was reduced from 1hr 5m to 56m. cool.