AVRO-4249: [java] provide a cache of schema to avoid building#3746
AVRO-4249: [java] provide a cache of schema to avoid building#3746mkeskells wants to merge 9 commits into
Conversation
mkeskells
force-pushed
the
AVRO-4249-schema-cache
branch
from
65f4513 to
34e6910
Compare
add tests and a benchmark
|
Could a maintainer please add the performance label to this PR? |
|
I have fixed the licence issues reported in the build (missing licence header). |
|
I finally got o the bottom of the memmory leak I was chasing when I observed the problem that this fixes- its https://issues.apache.org/jira/browse/AVRO-4253, a memory leak, which in my environment was holding only 200Gb of Schemas due to the leak. Mostly fixed by this PR |
|
Hey, pardon me! I appreciate the work, and I'll take a closer look soon -- we're going to do a 1.13.0 release just after the next one 1.12.2, and this should be in it! |
Hi @RyanSkraba I have fixed the checkstyle error I hope (unfortunately checkstyle doesnt run on this project fo me so I couldn't check before) A bit off topic, but Iwould have thought that https://issues.apache.org/jira/browse/AVRO-4253 would need to be fixed for any future release. Happy to assist (or get more involved in avro), but I dont have the context to propose anything other than the trivial/expensive fix in the comments |
|
@RyanSkraba I have added a soft cache as well. QQ - what should the default cache behaviour be? I don't know the avro policy on changes like this so looking for steer |
|
I do think that there is an oppertunity to use the same logic on a broader level, a soft cache of a String + parse options -> schema, but don't know the innards of the parsing expectations to know if a new Schema is guaranteed handling duplicate schemas seems to have secondary costs, like duplicate data in Anyway - its outside of the scope of this PR, and outside my knowledge, but maybe a manttainer can have an opinion |
mkeskells
force-pushed
the
AVRO-4249-schema-cache
branch
from
5638a0a to
b02221d
Compare
| do { | ||
| for (long i = 0; i < l; i++) { | ||
| String key = vin.readString(null).toString(); | ||
| String key = vin.readString(); |
There was a problem hiding this comment.
not related to the schema cache, but removes the allocation of the ByteBuffer, which is disguarded immediately. This was done after the benchmark results were published and will reduce allocations by the size of the schema for each file parsed, for all scenarios
| for (long i = 0; i < l; i++) { | ||
| String key = vin.readString(null).toString(); | ||
| String key = vin.readString(); | ||
| ByteBuffer value = vin.readBytes(null); |
There was a problem hiding this comment.
We could reuse the byte buffer, but an impovement in #3776 removes it anyway
mkeskells
force-pushed
the
AVRO-4249-schema-cache
branch
from
a66abf0 to
6e14feb
Compare
# Conflicts: # lang/java/avro/src/main/java/org/apache/avro/file/DataFileStream.java
mkeskells
force-pushed
the
AVRO-4249-schema-cache
branch
from
0dab957 to
b26ec41
Compare
2 participants
What is the purpose of the change
To improve the performance of parsing files.
In an environment where we parse 10k to 100K (generally very small) files that are small, and use the same schema, or a handful of schemas we see many Tb of garbage generation with duplicate schemas being parsed
this PR is a simple fix to enable a cache to be inserted in the reader, so that the cache lookup can replace the parse where there is an exact match already
The shape of the API changes - I leave this to the reviewers to comment, and I am happy to work to their steer, and will generate tests when I have agreement of the approach to this
Verifying this change
(Please pick one of the following options)
I will add tests once the chnages to the API have been agreed. There are many ways that this chnage could be implemented so I dont want to spend th time until the shape can be agreed
Documentation