Live data from Hacker News

Scribe: Transporting petabytes per hour via a distributed, buffered queueing

engineering.fb.com

21–30 of 44 posts

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#21
post #4

Earlier quoted context omitted.

Never underestimate the bandwidth of a cargo ship full of SSDs. (I'm paraphrasing an old, old joke.)

Fairly high latency though I guess.

using jet for trans ocean data delivery gives you several hours latency - acceptable for the logs - at the cost on the scale like $0.1-0.3/TB (really depends on the napkin used for the estimations)

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#22
So, if I'm reading this correctly, 2.5GB/s of log data being generated? If we assume (aggressively) that they have 5mil machines in their infrastructure, doesn't that mean that each machine would have to be generating 500kB/s of log data?

Despite that, I find the claims to be underwhelming. So your system can process massive amounts of data by scaling massively horizontally...neat.

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#23

Is it normal for these internal system to not implement any kind of access control? From the post it seems every reader can access every stream?

That's actually not the case, there's access control :)

The article just focuses on certain areas of the system and doesn't go into the security and privacy parts, that's all.

(I work in Scribe)

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#24

Earlier quoted context omitted.

This is the same scribe. Facebook closed-sourced it because it was too hard to maintain an open version and a version that addresses Facebook's needs.

I wonder why couldn't they just make the open source version address their needs...

The version that was open-sourced kept evolving and integrating with other internal systems at Facebook. That's what made it hard to continue open-sourcing it (why the open-sourced version was discontinued) and why the current version is also hard to open-source.

Maybe one day we'll have a version available. In any case, one of the larger parts of the system (LogDevice) is open source :)

(disclaimer: I work in Scribe)

LogDevice: https://engineering.fb.com/core-data/open-sourcing-logdevice...

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#25
post #11
post #5

Naming is hard! Facebook used to have a _different_ Scribe ( https://en.wikipedia.org/wiki/Scribe_(log_server) ). We used it at a company I worked for, but it had long-since been deprecated, so I was confused when I saw this Scribe.

Scribe is also an enterprise integration/ETL tool. For _many_ years before FB existed.

Interesting! Just found out about this, and I googled it out. TIBCO acquired Scribe Software, and Scribe Software was running as early as 1998-1999! :D

https://web.archive.org/web/20120301000000*/http://www.scrib...

The initial stuff seems to not be so related, but the current description of what they do seems much much closer to what Facebook's Scribe does today :)

Naming is hard! :D

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#26
post #22

So, if I'm reading this correctly, 2.5GB/s of log data being generated? If we assume (aggressively) that they have 5mil machines in their infrastructure, doesn't that mean that each machine would have to be generating 500kB/s of log data? Despite that, I find the claims to be underwhelming. So your system can process massive amounts of data by scaling massively horizontally...neat.

The number in the article is 2.5 TB/s, not GB/s :)

(disclaimer: I work in Scribe)

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#27
post #9

braggy PR is misleading: the 25GB/s coming from CERN is after they filter the data down from 600TB/s because there are no commercial systems that can capture data at higher rates.

it's adorable how you call it "braggy PR" when almost every major technology company these days (FB, Google, Amazon, Uber, Pinterest, etc., pretty much everybody except Apple) has an engineering blog where they share possibly-interesting work they've done.

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#28
post #19
post #9

braggy PR is misleading: the 25GB/s coming from CERN is after they filter the data down from 600TB/s because there are no commercial systems that can capture data at higher rates.

This is a good point! Just for fun, for more perspective on big data, a human body generates around 1-10M new cells per second, and a cell contains about 10-100GB of information. So a single human is generating 1-100PB/s of data just in the new cells! (Give or take a few OOM)

Are you trying to quantify the "information" by the size of the DNA? I think this is a pretty meaningless number to multiply since most of the DNA will be exact copies and DNA alone doesn't capture all the information about a cell.

OTOH the amount of "information" needed to perfectly simulate a cell is probably unbounded. Just a corollary of the fact that we currently don't know how to perfectly simulate reality. Even a single "real" number can take up infinite space.

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#29
post #19

Earlier quoted context omitted.

This is a good point! Just for fun, for more perspective on big data, a human body generates around 1-10M new cells per second, and a cell contains about 10-100GB of information. So a single human is generating 1-100PB/s of data just in the new cells! (Give or take a few OOM)

Are you trying to quantify the "information" by the size of the DNA? I think this is a pretty meaningless number to multiply since most of the DNA will be exact copies and DNA alone doesn't capture all the information about a cell. OTOH the amount of "information" needed to perfectly simulate a cell is probably unbounded. Just a corollary of the fact that we currently don't know how to perfectly simulate reality. Eve…

> OTOH the amount of "information" needed to perfectly simulate a cell is probably unbounded. Just a corollary of the fact that we currently don't know how to perfectly simulate reality.

This is a very good point. The 'information' in a cell isn't the base pairs in its DNA, but all the atoms that make up the whole cell. And then each atom encapsulates properties such as position, velocity, charge, van der Waals radius etc.

However this considers atoms with classical mechanics. In a quantum mechanical representation it would be very different again and you can start asking really hairy questions about whether information can be created or destroyed.

Re: Scribe: Transporting petabytes per hour via a distributed, buffered queueing

#30
post #19

Earlier quoted context omitted.

This is a good point! Just for fun, for more perspective on big data, a human body generates around 1-10M new cells per second, and a cell contains about 10-100GB of information. So a single human is generating 1-100PB/s of data just in the new cells! (Give or take a few OOM)

Are you trying to quantify the "information" by the size of the DNA? I think this is a pretty meaningless number to multiply since most of the DNA will be exact copies and DNA alone doesn't capture all the information about a cell. OTOH the amount of "information" needed to perfectly simulate a cell is probably unbounded. Just a corollary of the fact that we currently don't know how to perfectly simulate reality. Eve…

Just back of the envelope estimates if you were to do things like scRNAseq, metabolomics, genomics, etc, on every cell. Infeasible but just as a thought experiment. Most DNA is the same, but not exact, and therein lies the rub (cancer). The point on unbounded though is a good one.
Post reply on HN