The Sense & Sensibility of a Data Scientist DevOps


The other day I was pondering the subject of a Data Scientist & model deployment at scale as we are developing our data science layers consisting of Hadoop, HBase & Apache Spark. Interestingly earlier today I came across two artifacts – a talk by Cloudera’s @josh_wills and a presentation by (again) Cloudera’s Ian Buss.

The talks made a lot of sense independently, but add a lot more insight – collectively !  The context, of course, is the exposition of the curious case of data scientists as devops. The data products need an evolving data science layer …

It is well worth your time to follow the links above and listen to Josh as well as go thru Ian’s slides. Let me highlight some of the points that I was able to internalize …

Let me start with one picture that “rules them all” & summarizes the  synergy. The “Shift In Perspective” from Josh & the Spark slide from Ian

JW-01

The concept of Data Scientist devops is very relevant. It extends the curious case of the Data Scientist profession to the next level.

Data products live & breath in the wild, they cannot be developed and maintained with a static set of the data. Developing an R model and then throwing it over the wall for a developer to translate won’t work.  Secondly, we need models that can learn & evolve in their parameter space.

 

JW-02

 I agree with the current wisdom that Apache Spark is a good framework that spans the reason,model & deploy stages of data. 

Other interesting insights from Josh’s talk.

Finally,

The virtues of being really smart is massively overrated; the virtues of being able to learn faster is massively underrated

Well said Josh.
P.S: Couldn’t find the video of Ian’s talk at the Data Science London meetup. Should be an interesting talk to watch …

AWS EC2 Price worksheet


It all started with a tweet Image

  • It so happens that I have been working on a similar worksheet for pricing & configuring our analytics infrastructure;
  • I modified the one I am working on (inspired by the original at ec2 pricing_and_capacity) & morphed into the one Otis wanted
  • The Excel worksheet is hosted it in github. Feel free to modify it to fit your needs. Let me know as well …
  • I have four sets of prices viz. on-demand, reserved-light,reserved-medium usage and reserved- heavy usage. The prices are calculated for one year (8640 hrs) off of the cell M1 – one has to prorate the upfront fees to get the effective $/hr rate
  • The worksheet has multiple uses – I use it to compute the price difference for different usage patterns-high memory for Spark, different sizes for HBase cluster et al. As it is a spreadsheet one could sort it on varying criteria; one could change the numbers (say 6 months) and see what model makes sense.
  • BTW, it is interesting to see that the Light -Reserved costs more in all cases except for the storage models.
  • Long time ago, I had a graphical representation, which has become very dated. I might resurrect it with the new prices …

The Spreadsheet :

The left columns have the attributes of the various EC2 models.

Image

 

The 8640 (hrs/year) is in M1. All the calculations are based on this cell. The reserved light is interesting … it costs more !

Image

The reserved medium does save $. Moreover, one can stop the instances when not needed.

Image

I have calculated the yearly price prorating the upfront fees et al. But for Heavy Reserved, it is somewhat meaningless as they will charge for the whole year even if the instances are stopped. But changing the value in M1 gives a feel for the different tiers …

Image

I would be happy to hear other inferences we can make and add columns to the worksheet …

Cheers

 

The Chronicles of Robotics at First Lego League – Day 1


This week am at St.Louis, volunteering at the First lego league World Robotics Competition. Have been involved with First Robotics since 2004. Usually my position is Robotic Design Judge – a front seat view to interesting & innovative ideas on Robots.

For 3 days we have the Edwards Jones Dome & the America Center in St.Louis, MO.

Day 1 : Stardate : 91913.81

Judges’ on-site meeting & briefing, allocations & FLL opening ceremonies.

Some quick pictures … Full day of judging starts tomorrow early morning  … looking forward to it ….

  • View From my Hotel

  • FLL-01 FLL-02 RoomView-01RoomView-02
  • The Trophies

  • awards-01 awards-02
  • The Field 

  • The field occupies the stadium. It consists of six areas – Einstein(FLL), Geleleo, Franklin, Newton, Edison & Curie. I have tried to capture the view of the fields from the ground and from the bleachers.
  • Galeleo

  • Field-01-01 Field-01-02 Field-03 Field-04-01Field-04Field-01 Field-05
  • NASA Truck to beam the competitions live via satellite

  • Field-06 Field-07
  • Franklin & Newton

  • Field-02-01 Field-02 Fig-05-01 Field-08 Field-09
  • Einstein (FLL and the venue of opening ceremonies – below)

  • Field-10 Field-11
  • FLL Opening Ceremonies

  • Open-01 Open-02 Open-03-01 Open-03 Open-04
  • Tomorrow is a busy day – robot judging whole day. Might not get time to take pictures
  • Still have to cover the pits, convention center hall filled with team stalls et al. One has to be there to understand the scale and the energy !

Data Science Folk Knowledge & Words of Wisdom


I have collected some words of wisdom on Data Science & Machine Learning for my pycon 2014 Tutorial “Data Wrangling”.
Posting as a blog. The pdf is at Slideshare. Would appreciate comments, insights & corrections.

Slide01

Slide02

  • Slide11
  • Slide12
  • Slide13
  • Slide14
  • Slide15
  • Slide16
  • Slide17
  • Slide18
  • Slide19
  • Slide20
  • Slide21
  • Relevant Papers To Read

  • Slide22
  • An ordered list of mooc links & books. This was my answer in Quora

  • Slide23

A Glimpse of Google, NASA & Peter Norvig + The Restaurant at the End of the Universe


I came across an interesting talk by Google’s Peter Norvig at NASA.

Of course, you should listen to the talk – let me blog about a couple of points that are of interest to me:

Algorithms that get better with Data

Peter had two good points:

Norvig-01

  • Algorithms behave differently as they churn thru more data. For example in the figure, the Blue algorithm was better with a million training dataset. If one had stopped at that scale, one would be tempted to optimize that algorithm for better performance
  • But as the scale increased, the purple algorithm started showing promise – in fact the blue one starts deteriorating at larger scale. The old adage “don’t do premature optimization” is true here as well. 
  • Norvig-02In general, Google prefers algorithms that get better with data. Not all algorithms are like that, but Google likes to go after the ones with this type of performance characteristic. 

There is no serendipity in Google Search or Google Translate

  • There is no serendipity in search – it is just rehashing. It is good for finding things, but not at all useful for understanding, interpolation & ultimately inference. I think Intelligent Search is an oxymoron ;o)
  • Same with Google Translate. Google Translate takes all it’s cue from the web – it wouldn’t help us communicate with either the non-human inhabitants of this planet or any life form from other planets/milky ways.
    • In that sense, I am a little disappointed with Google’s Translation Engines.  OTOH, I have only a minuscule view of the work at Google.

The future of human-machine & Augmented Cognition

And, don’t belong to the B-Ark !

The Curious Case of the Data Scientist Profession


Data Science & the profession of a Data Scientist is being debated, rationalized, defined and refactored … I think the domain & the profession is maturing and our understanding of the Mythical Data Scientist is getting more pragmatic.

Now to the highlights:

1. Data Scientist is multi-faceted & contextual

  • Two points – It requires a multitude of skills & different skill sets at different situations; and definitely is a team effort.
  • This tweet sums it all
  • DataScienceTeam
  • Sometimes a Data Scientist has to tell a good business story to make an impact; other times the algorithm wins the day
    • Harlan in his blog identifies four combinations – Data Business Person, Data Creative, Data Engineer & Data Researcher
      • I don’t fully agree with the diagram – it has lot less programming & little more math; math is usually built-in the ML algorithms and the implementation is embedded in math libraries developed by the optimization specialists. A Data Scientist should n’t be twiddling with the math libraries
    • I had proposed the idea of a Data Science Engineer last year with similar thoughts; and elaborated more at “Who or what is a Data Scientist?
    • The BAH Field Guide suggests the following mix:
    • Data Scienc 03
    • I would prefer to see more ML than M. ML is the higher from of applied M and also includes Statistics
  • Domain Expertise and the ability to identify the correct problems are very important skills of a Data Scientist, says John Forman.
  • Or as Rachel Schutt at Columbia quotes:
    • Josh Wills (Cloudera)
      • Data Scientist (noun): Person who is better at statistics than any software engineer & better at software engineering than any statistician

    • Will Cukierski (Kaggle) retorts
      • Data Scientist (noun): Person who is worse at statistics than any statistician & worse at software engineering than any software engineer

2. The Data Scientist team should be building data products

3.  To tell the data story effectively, the supporting cast is essential

  • As Vishal puts it in his blog,
    • Data must be there & processable – the story definitely depends on the data
    • Processes & buy-in from management – many times, it is not the inference that is the bottle neck but the business processes that needs to be changed to implement the inferences & insights
    • As the BAH Field Guide says it:
    • Data Scienc 04
    • DS01

 4.  Pay attention to how the Data Science team is organized

5. Data Science is a continuum of Sophistication & Maturity – a marathon than a spirint

Let me stop here, I think the blog is getting long already …