impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Kornacker (Code Review)" <>
Subject [Impala-ASF-CR] IMPALA-4029: Reduce memory requirements for storing file metadata
Date Thu, 04 May 2017 04:58:20 GMT
Marcel Kornacker has posted comments on this change.

Change subject: IMPALA-4029: Reduce memory requirements for storing file metadata

Patch Set 5:


when staffan did the origin analysis, he found problems with both the total amount of memory
needed as well as the rate of object creation. it would be good to try to reduce the latter
in your current code even more, by accessing the fb structures directly instead of wrapping
them with objects.
File common/fbs/CatalogObjects.fbs:

Line 31:   LZ4

Line 38:   offset: long (id: 0);
why not specify a default, given that most will be 0?

Line 51:   disk_ids: [ushort] (id: 3);
File common/thrift/CatalogObjects.thrift:

Line 217:   // File descriptor metadata serialized into a FlatBuffer.
reference which one exactly
File common/thrift/CatalogObjects.thrift:

Line 217:   // File descriptor metadata serialized into a FlatBuffer.
mention where to find the fb definition
File fe/src/main/java/org/apache/impala/catalog/

Line 46:     private ConcurrentHashMap<String, Short> storageUuidToDiskId =
add trailing _ to member vars

Line 78:           diskId = (short) (storageIdGenerator.get(host) + 1);
at least assert that you don't get an overflow here
File fe/src/main/java/org/apache/impala/catalog/

Line 78:   public byte toFlatBuffer() {
should we generally settle on toFb for functions like these? brevity is a virtue...
File fe/src/main/java/org/apache/impala/catalog/

Line 115:       int[] blockOffsets = createBlockMetadata(fbb, blockLocations, hostIndex, stats);
i couldn't tell from the name that this creates an array of fbs. call it something like createFbFileBlocks
or createFbFileBlockVector to indicate how this relates to the fb structures (and the fact
that it outputs fbs)?

Line 126:     public static FileDescriptor createWithSynthesizedBlockMetadata(FileStatus fileStatus,
feel free to generally abbreviate metadata as md, to make this very long name a bit shorter.

PS5, Line 141: blockOffsets
would also be good to name this so it's immediately clear what it is (ie, embed the fb struct

you can also apply that to other variable names, ie, use a deterministic naming algorithm
to make it immediately clear what the things are. i used that approach in my proof-of-concept
test code, i think it made the code reasonably easy to follow.

Line 161:      * Synthesizes the block metadata of a file represented by 'fileStatus' that
you don't say what that block metadata contains.

Line 182:         List<BlockReplica> replicas = Lists.newArrayList(
same comment about intermediate objects as below

Line 208:         List<BlockReplica> replicas = Lists.newArrayListWithExpectedSize(
hm, it would be nice not to have to construct these intermediate objects. pass all the params
that you need for construction into fileblock.createfbfileblock and then populate the fbfileblock

Line 224:     public THdfsCompression getFileCompression() {
does this need to return a thrift struct?

Line 231:     public FileBlock getFileBlock(int idx) {
why not just return the fbfileblock and save yourself the object construction?

Line 329:      * Loads the metadata of a file block from its block location metadata 'location'
what do you mean by 'load'? 'construct an FbFileBlock with the provided fbb'?

Line 346:         replicaIdx = replica.isCached() ?
please describe this encoding in the .fb file.

Line 360:       FbFileBlock.addOffset(fbb, location.getOffset());
why not just pass in the offset/length directly and avoid constructing a BlockLocation?

Line 402:     public boolean hasCachedReplica() { return hasCachedReplica_; }
instead of adding member vars, why not make all functions be static and take an FbFileBlock
parameter. that way, you save yourself more object construction.

Line 449:   public static class FileDescStats {
since this only keeps track of a single number, consider using a Long instead, that's less
File fe/src/main/java/org/apache/impala/catalog/

Line 134:   // if the table is stored in the catalog server.
what does that mean? i thought all tables are stored in the catalog server.
File fe/src/main/java/org/apache/impala/catalog/

Line 93:   protected boolean storedInImpaladCatalogCache_ = false;
is this part of your changes?

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I483d3cadc9d459f71a310c35a130d073597b0983
Gerrit-PatchSet: 5
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Dimitris Tsirogiannis <>
Gerrit-Reviewer: Alex Behm <>
Gerrit-Reviewer: Bharath Vissapragada <>
Gerrit-Reviewer: Dimitris Tsirogiannis <>
Gerrit-Reviewer: Henry Robinson <>
Gerrit-Reviewer: Marcel Kornacker <>
Gerrit-Reviewer: Tim Armstrong <>
Gerrit-HasComments: Yes

View raw message