I work in the beg data realm of healthcare. We're looking at potential architectures for our next wave of development and OSGI is on the list of potential technologies to solve one of our biggest problems: sharing and analysis of large data. PLease let me know if I'm totally off the wall here...
It would seem possible to build a Java application that could use OSGI to integrate externally developed and shared analysis "plugins". This could get us beyond sending boxes full of hard drives of genomic data between researchers. Instead, these (trusted) researchers implement their analysis tools and share them over the network. This also allows us to maintain full control over our data.
So it's not so much OSGi for big data, but OSGi for plugin code separation. That's a perfect application for OSGi, but OSGi is a big hammer whichever way you look at it. A few years ago I had written about something on a smaller level that may give you some ideas: http://www.javaranch.com/journal/200607/Plugins.html
Ulf is spot on. The benefit of OSGi, as you describe the requirements, is to help you develop a plug-in architecture. That's definitely a sweet spot for OSGi. Other benefits you'll get out of OSGi include dependency management, hot deploys, versioning, etc. See my other reply for more details on the benefits.
For the sack of POC I have used JBoss 7.x(which has OSGI container) and HBase and integrated them. Though for the web application I have not used OSGI, the concept is very valid. You can deploy OSGI in the container and connect with Big Data(I don't know which DB you planning to choose). I choose JBoss as I plan to use it as more of an ESB then just a container. In normal situation Felix will work too.