In and of itself, your StatisticManager class, sounds like a good idea to encapsulate this sort of logic. However let's address the hurdles you mention.
Backlog size is not what I would call a problem. The reason is that every application that has ever kept a backlog has had to draw the line somewhere, to limit the amount of history it retains. You have to cut off somewhere. You need to decide on a backlog size (something, anything!) and work with that constraint in mind, in regards to your game logic. You can adapt it as you move forward in your development processes; other factors will either support or work against your existing choice.
I am not sure I would want to keep data outside of game sessions without there being a very good reason for that. I would keep just the results of earlier analyses. It's true that you wont have anything but the results, so you won't, at a later time, know how those results were derived. But primary and secondary storage space aren't infinite either (no matter how big it is). Again, you have to sacrifice somewhere. If you absolutely had to keep at least certain prior-session data, without losing anything from those sessions, well then that's what file compression is for. Some games do this, and keep a data set that continually grows, eg. save games in some RPGs. But it needs to be darned reasonable if you're going to do that. 1mb per hour is rough. 1kb per hour probably isn't. Even so, it's not an advisable practice.
As you already know, this all depends on the size of the data set. The less data you include in the calculation, the less concern you have. In many cases, the criterion for selection for processing will be time-proximity, i.e. how recent the data is. Which comes down to the same as the above -- just keep the most recent data, up to some predefined limit of storage space or elapsed time. You could store only as much as you'll ever be able to process at once, if processing cost were a bigger issue than storage cost.
You could parallelise this (CPU/GPU). But it sounds like overkill to me, a brute force approach that doesn't really deal with the core of the problem which is, "How do I restrict my data set and still get good results?" Some of the most expansive games ever made were created on a single-CPU, single-core machine with very limited memory. XCOM/UFO and Elite are two such examples. Dwarf fortress is another. That's because those developers knew where to draw the line.
Another way to look at this is that you are creating a game with a set of unique servers that host the game, much like an MMO. This being precisely because you have this unusual technical constraint (of storage requirements) that simply makes it unfeasible to do on client systems where you have no say over available storage. If this is the conclusion you come to, it means that you're probably not looking at your problem correctly, and even if you are, you'd need to be in the position to host servers, buy more storage when needed etc. I am guessing you're not in that position right now, because that usually requires solid backing for funding. Any engineering problem is about working to your existing practical constraints, so that solution immediately looks unreasonable.
First and foremost, you need to decide what the hard upper limit to your storage requirements are. From there you can prototype the processing, and see what is or isn't too demanding, set yourself another reasonable limit on processing cost, and move forward with your game from there.