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
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.
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.
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 …
It all started with a tweet
- 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.
The 8640 (hrs/year) is in M1. All the calculations are based on this cell. The reserved light is interesting … it costs more !
The reserved medium does save $. Moreover, one can stop the instances when not needed.
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 …
I would be happy to hear other inferences we can make and add columns to the worksheet …
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:
- 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.
- In 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 !
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
- 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:
- 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:
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
- I am sure organizations understand this intuitively, but many times the understanding is not reflected in their actions.
- Simply Put:
- Descriptive = What Happened
- Reactive = Take corrective Actions for what happened
- Proactive = Take actions based on fixed predictions
- Adaptive = Dynamic actions based on learning Predictive Models, embedded business rules and augmented cognition
- Prescriptive = Actionable inferences based on Data Science Models
- Jeff Bertolucci has a quick blog on the Descriptive, Predictive & Prescriptive Analytics.
- Michael Wu, Chief Scientist at Lithium has a series of blogs on this topic
Both Jeff & Michael haven’t talked about the Adaptiveness. For example, recommendation systems (like collaborative filtering) constantly incorporate new data and “tweak” the running models
Let me stop here, I think the blog is getting long already …