@Alan thanks for the quick response!
I have quite a bit of experience with processing large amounts of data, but form another domain. I was the chief architect of Mercury (HP) Topaz (Business Availability Manager) - a monitoring platform.
So I had the advantage of knowing this is something that requires some thinking and planning in advance. Specifically, I made a bunch of very useful decisions around what data to keep, how to aggregate it, and how to store it so that it will be easily accessible later. But this is of course, limited to a degree, by the types of reports I could think of at the time.
Long story short, the data used for the _current_ reports, is stored in a SQL DB, in specific tables, and very easy to access.
In the future, as we go forward, this may not be the case.
So I'm looking for a 'start small & grow' approach, where the cost of initial implementation will be limited, but I will be able to expand on the same infrastructure as we go forward