Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reducing logging cost by two orders of magnitude using CLP

uber.com

Post reply on HN
Print view View original

81–90 of 107 posts

Re: Reducing logging cost by two orders of magnitude using CLP

#81

Post by lenkite »

npalli wrote: post #56
taftster wrote: post #53

I'm not trying to flame bait here, but this whole article refutes the "Java is Dead" sentiment that seems to float around regularly among developers. This is a very complicated and sophisticated architecture that leverages the JVM to the hilt. The "big data" architecture that Java and the JVM ecosystem present is really something to be admired, and it can definitely move big data. I know that competition to this arch…

I didn't read the article that way. FTA, the sense is Java is not dead in the same sense COBOL is not dead, that is "legacy" technology that you have now work around because it is too costly to operate and maintain. Ironically, from this article the two main technical solves for the issues with their whole JVM setup are CLP (which is the main article) and moving to Clickhouse for non-Spark logs both of which are writ…

Java supports AOT via Graal so you can have non JVM setups already.

Re: Reducing logging cost by two orders of magnitude using CLP

#82

Post by tkhattra »

gcr wrote: post #72
pmarreck wrote: post #54

Earlier quoted context omitted.

1) Use Zstandard with a generated dictionary kept separate from the data, but moreover: 2) Organize the log data into tables with columns, and then compress by column (so, each column has its own dictionary). This lets the compression algorithm perform optimally, since now all the similar data is right next to itself. (This reminds me of the Burrows-Wheeler transform, except much more straightforward, thanks to how s…

Does the user have to specify the "schema" (each unique log message type) manually? or is it learned automatically (a la gzip and friends)? I wasn't able to discover this from a cursory readthrough of the paper...

the paper mentions that CLP comes with a default set of schemas, but you can also provide your own rules for better compression and faster search

Re: Reducing logging cost by two orders of magnitude using CLP

#83

Post by emj »

SkeuomorphicBee wrote: post #12

"Page not found" Apparently the Uber site noticed I'm not in the USA and automatically redirects to a localized version, which doesn't exist. If their web-development capabilities are any indication I'll skip their development tips.

https://www.uber.com/en-US/blog/reducing-logging-cost-by-two...

Re: Reducing logging cost by two orders of magnitude using CLP

#84

Post by taftster »

foobarian wrote: post #67
taftster wrote: post #53

I'm not trying to flame bait here, but this whole article refutes the "Java is Dead" sentiment that seems to float around regularly among developers. This is a very complicated and sophisticated architecture that leverages the JVM to the hilt. The "big data" architecture that Java and the JVM ecosystem present is really something to be admired, and it can definitely move big data. I know that competition to this arch…

Not answering your primary question, I know. But I wonder where you are getting the "Java is Dead" sentiment - I am not getting it at all in my (web/enterprisey) circle, if anything there is a lot of excitement due to new LTS versions and other JVM languages like Kotlin. And I am also finding a lot of gratitude for the language not changing in drastic ways (can you imagine a Python 2->3 like transition?) despite the…

Maybe it's just a little cliche and maybe the phrase "XXX is Dying" is too easily thrown around for click-bait and hyperbole. It can probably be applied to any language that isn't garnering recent fandom. You could probably just as easily say, "Is C# dead?" or "Is Ruby on Rails dead?" or "Is Python dead?" or "Is Rust dead?" (kidding on those last ones).

And yes, I'm with you. I'm super excited about the changes to the Java language, and the JVM continues to be superior for many workloads. Hotspot is arguably one of the best virtual machines that exists today.

But there are plenty of "Java is dead" blog posts and comments here on HN to substantiate my original viewpoint. Maybe because I make a living with Java, I have a bias towards those articles but filter out others, so I don't have a clean picture of this sentiment and it's more in my head.

Re: Reducing logging cost by two orders of magnitude using CLP

#85

Post by SergeAx »

twunde wrote: post #13

Original CLP Paper: https://www.usenix.org/system/files/osdi21-rodrigues.pdf Github project for CLP: https://github.com/y-scope/clp The interesting part about the article isn't that structured data is easier to compress and store, its that there's a relatively new way to efficiently transform unstructured logs to structured data. For those shipping unstructured logs to an observability backend this could be a way to…

Wow, that's awesome! What are the chances to see it integrated into Loki stack?

Re: Reducing logging cost by two orders of magnitude using CLP

#86

Post by otikik »

eterm wrote: post #50
otikik wrote: post #42

I really didn't know whether this was going to be an article about structuring sequential information or about a more efficient way to produce wood. Hacker news! I clicked, found out, and was dissapointed that this wasn't about wood. Maybe I should start that woodworking career change already.

Given that uber.com is prominently displayed in the title, I don't believe this charming and relatable little anecdote about title confusion.

You overestimate my reading speed and underestimate my clicking speed, good sir

Re: Reducing logging cost by two orders of magnitude using CLP

#87

Post by Veserv »

gdcohen wrote: post #14
twunde wrote: post #13

Original CLP Paper: https://www.usenix.org/system/files/osdi21-rodrigues.pdf Github project for CLP: https://github.com/y-scope/clp The interesting part about the article isn't that structured data is easier to compress and store, its that there's a relatively new way to efficiently transform unstructured logs to structured data. For those shipping unstructured logs to an observability backend this could be a way to…

Does anyone have a simple explanation of how it structures the log data?

If you have exactly two logging operations in your entire program:

log(“Began {x} connected to {y}”)

log(“Ended {x} connected to {y}”)

We can label the first one logging operation 1 and the second one logging operation 2.

Then, if logging operation 1 occurs we can write out:

1, {x}, {y} instead of “Began {x} connected to {y}” because we can reconstruct the message as long as we know what operation occurred, 1, and the value of all the variables in the message. This general strategy can be extended to any number of logging operations by just giving them all a unique ID.

That is basically the source of their entire improvement. The only other thing that may cause a non-trivial improvement is that they delta encode their timestamps instead of writing out what looks to be a 23 character timestamp string.

The columnar storage of data and dictionary deduplication, what is called Phase 2 in the article, is still not fully implemented according to the article authors and is only expected to result in a 2x improvement. In contrast, the elements I mentioned previously, Phase 1, were responsible for a 169x(!) improvement in storage density.

Re: Reducing logging cost by two orders of magnitude using CLP

#88

Post by [deleted] »

gdcohen wrote: post #14
twunde wrote: post #13

Original CLP Paper: https://www.usenix.org/system/files/osdi21-rodrigues.pdf Github project for CLP: https://github.com/y-scope/clp The interesting part about the article isn't that structured data is easier to compress and store, its that there's a relatively new way to efficiently transform unstructured logs to structured data. For those shipping unstructured logs to an observability backend this could be a way to…

Does anyone have a simple explanation of how it structures the log data?

[deleted]
Post reply on HN