I think you miscalculated. I get 10MB per trip on average, assuming 10bn total trips. Maybe deduct something for maps and inefficient file formats & data structures?

1 billion bytes = 1GB,

1 billion KB = 1TB,

1 billion MB = 1PB,

10 billion * 10MB = 100PB.

Yes, you're right. My calculation was 2^50 bytes in a PB / 10^10 trips, which should have been multiplied by 100 to get 100PB.

Which again leaves me wondering why Uber needs 100PB.

They collect user location during the trip, app launches and every possible user action that may be useful for them while you're using the app.

Tinfoil hat: data that they slurp outside trips, like tracking user locations, etc

I do forecasting at Uber, we don’t collect data outside of trips.

Has this kind of thing stopped, then? https://techcrunch.com/2016/11/28/uber-background-location-d...

What kind of problems do you work on?

>we don’t collect data outside of trips.

And it's not like Big Tech has ever misled people on this subject.

The data sizing heuristic for basic vehicle positioning telemetry is a GB per vehicle per year assuming a professional driver (e.g. taxi, trucking, etc). A petabyte is about a million vehicle-years of positioning data, which isn't that much.

Remember, Uber also stores application positioning telemetry as well, so it isn't just the number of vehicles.

It makes me wonder if those yellow cabs are just stuffed full of hard drives to store all their historic data too. None of that data is useful or necessary. I would love to see any “insight” that would beat the knowledge of a basically competent cabbie on where and when people need rides. Uber just has lots of investor funny money that they want to spend to make it look like technology has something to do with their business when they are actually just a marketing and booking engine for independent taxi operators. Investors just get more excited and start throwing “internet money” your way if you brag about things like amount of data and engineers.

Well, I’d expect there to be aggregate result stores as well for other dashboards that may store the same data sorted and aggregated a different way.

Which is about 99.7kb more than I would hope and expect as a customer.

That's a fairly naive expectation.

I had a friend head off in 2011 to work with Hailo in London, and designed much of the data ingest & storage architecture there. That was built on Cassandra, and some of the numbers were staggering, even for a (initially) single-city, < 2,000 driver system.

You're not just tracking start and end point of successful rides -- you're tracking users when their app is open (both drivers and users move around before and after initiating a ride, and you need to share that data between parties), you're also tracking empty vehicles so you can identify over / under serviced areas ... doubtless lots of other real time stuff you want to know. But the big thing is you want to then have that data available for mining, improving your service, regulatory obligations, and so on.

Only if you believe in retaining all data in perpetuity. I suppose it demonstrates the difference in US and European perspectives on data.

Most of what you describe has little meaning or use at a few months old. Sure you might want to collect detailed awareness of individual drivers over say a month, generic traffic patterns over six months, and little or nothing beyond.

Once the data has outlived that direct, primary, purpose you dispose of it or it's a famous, excessive, data breach waiting to happen. There is absolutely nothing wrong with only keeping billing data beyond say six months max.

In California, you soon won’t be able to keep 6 months max. You have to hold a year.

> Most of what you describe has little meaning or use at a few months old. Sure you might want to collect detailed awareness of individual drivers over say a month, generic traffic patterns over six months, and little or nothing beyond.

The really invasive pattern-matches happen best retroactively at that scale.

Age of the data does not typically impact many such analyses.

> Only if you believe in retaining all data in perpetuity.

There's a huge spectrum between your 'at most 30d' claim in another reply, and 'all data in perpetuity'.

30d is way too short. Perpetuity is probably the idealistic intent, and depending on storage costs over time this may be achievable.

> I suppose it demonstrates the difference in US and European perspectives on data.

How so? I described a the case of one UK-based company, and TFA is about one US-based company, both doing similar things.

> Most of what you describe has little meaning or use at a few months old.

Clearly this is not the case, as evinced by the actions of the people designing, building, operating, and maintaining these types of systems.

I think there are tradeoffs, for example, they probably store the route, which is good (refunds for really terrible routes) but bad (tracking). That's quite a bit of space, probably the big one. Rating and possibly comments, again could be pretty big. Multiple UUIDs or whatever (cust/driver IDs, CC txn IDs) will take up some space as well. 300B is probably a fair bit too low.

That said, 100kB does seem high. 10kB or so would seem more appropriate, as a very rough ballpark.

Beyond the route itself, consider also: time spent in traffic (speed per geo-coordinate) for use in predicting surges, deviations between planned and taken routes, etc. The degree to which Uber has a pulse on urban traffic is fascinating and probably exceeds even city planners with access to ubiquitous traffic cameras.

They probably need to store a ton of things (like maps) that aren't data though, so probably not fair to say each ride is 100kb.

Even if they have 20PB of maps, which is probably way too high, it's still 80kb.

Almost none of which they need to keep. Route for 30 days perhaps, start and end point for longer. I imagine most ratings are just that with no comments.

Routes determine pay to drivers, so they probably have to keep it much longer in case of a pay dispute.

They could just give a digitally signed copy to the drivers and have the onus be on them to keep it.