Gábor Horváth - Code Generation in Serializers and Comparators of Apache Flink
2 likes1,329 views
This document discusses code generation for serializers and comparators in Apache Flink. Currently, Flink serializers use reflection which reduces performance. The document proposes generating serialization code at runtime to eliminate reflection and improve efficiency. It shows benchmark results demonstrating a 6x speedup from generated serializers and comparators compared to Flink's current approach. Future work is discussed to further optimize serialization performance and address challenges of dynamically generated code.
![INEFFICIENCIES OF CURRENT FLINK
SERIALIZERS
• Fields accessed using reflection
• Each iteration might dispatch to a different method, inhibits
inlining
• Null checks and null and subclass flags
• Extra code to deal with subclasses
• Hard to unroll the loop, upper bound is not a compile time
for (int i = 0; i < numFields; i++) {
Object o = fields[i].get(value);
if (o == null) {
target.writeBoolean(true);
} else {
target.writeBoolean(false);
fieldSerializers[i].serialize(o, target);
}
}](https://image.slidesharecdn.com/gaborhorvath-codegenerationinserializersandcomparatorsofapacheflink-160927085856/85/Gabor-Horvath-Code-Generation-in-Serializers-and-Comparators-of-Apache-Flink-5-320.jpg)
Gábor Horváth - Code Generation in Serializers and Comparators of Apache Flink
- 1. CODE GENERATION IN SERIALIZERS AND COMPARATORS OF APACHE FLINK GÁBOR HORVÁTH
- 2. PARADIGM SHIFT IN BIG DATA PLATFORMS •Applications used to be I/O bound (Network, Disk) •InfiniBand, SSDs reduced I/O overhead significantly •CPU increasingly became a bottleneck •Even in I/O bound applications, reduced CPU usage might mean reduced electricity costs
- 3. SERIALIZATION IN FLINK •Several methods: Avro, Kryo, Flink •Flink serialization is more efficient than Kryo • Not to mention the default Java serialization •Crucial, not just for I/O, operating on serialized data •Still some room for improvements
- 5. INEFFICIENCIES OF CURRENT FLINK SERIALIZERS • Fields accessed using reflection • Each iteration might dispatch to a different method, inhibits inlining • Null checks and null and subclass flags • Extra code to deal with subclasses • Hard to unroll the loop, upper bound is not a compile time for (int i = 0; i < numFields; i++) { Object o = fields[i].get(value); if (o == null) { target.writeBoolean(true); } else { target.writeBoolean(false); fieldSerializers[i].serialize(o, target); } }
- 6. SEVERAL SERIALIZER RELATED INNOVATIONS IN APACHE FLINK •Object reusing overloads •Delicate type system •Code generation (not mainline yet, this talk’s topic) • Fix the inefficiencies of Flink serializers
- 7. RUNTIME CODE GENERATION • Focus on POJOs (Plain Old Java Objects) • Best ROI due to eliminating reflection • Specialization • No reflection for serialization (direct field access code generated) • No null checks, subclass handling for primitive types • No subclass handling for final types • Unrolled loops, better for inlining
- 8. QUESTIONNAIRE • Who has written a custom serializer to improve performance? • Who has written a custom comparator to improve performance? • Who used Tuples instead of POJOs only to improve performance? Who wants performance close to Tuples with null value support?
- 9. LET’S SEE THE NUMBERS! 6X PERFORMANCE IMPROVEMENT Rest of Flink Job Serializers/Compara tors
- 10. NINE MEN’S MORRIS BENCHMARK •Calculates game-theoretical values of game states •Iterative job •Group by, reduce, outer joins, flat maps, and filter •Heavy use of POJOs •Real world complexity
- 11. LET’S SEE THE NUMBERS! •Measured on ReducePerformance, WordCountPojo and Nine Men’s Morris on local machine •Measured ReducePerformance and Nine Men’s Morris on a cluster •The results were consistent
- 12. LET’S SEE THE NUMBERS! (LOCAL MACHINE) 0 10 20 30 40 50 60 Serializer: Flink Handwritten Generated Handwritten Comparator: Flink Flink Generated Generated
- 13. CLOSE TO HAND WRITTEN SERIALIZERS •About 20% speedup compared to Flink serializers •Some gap left to handwritten • Smarter getLength • Flattening • Null and subclass flags • Better handling of primitives (less boxing/unboxing, inlining)
- 14. HOW DOES THIS WORK?
- 15. HIGH LEVEL OVERVIEW: THE TRADITIONAL WAY POJO Object Serialize d POJO TypeInfo Serialize rPOJO Class Instantiate
- 16. HIGH LEVEL OVERVIEW: THE NEW WAY POJO Object Generate d Serialize r Serialize d POJO TypeInfo FreeMark er Template Janino Serialize r Generato r POJO Class ClassLoad er
- 18. HOW TO LOAD GENERATED CODE? •We need to serialize serializers •First step of deserialization: load the class •Which ClassLoader to use? •Custom ClassLoader to the rescue! Sourc e Code Class Loader
- 21. LET’S TRY IT OUT! Class cast exception: SerializerA cannot be cast to SerializerA.
- 24. LETS CACHE AND TRY IT OUT! Class cast exception: UserObjectA cannot be cast to UserObjcetA.
- 26. LETS CACHE AND INVALIDATE AND TRY IT OUT!
- 27. ACTUALLY... THERE ARE COUPLE OF MORE •Janino bugs •Compatibility with Scala POJO like classes •Generated code harder to debug •…
- 28. WHAT’S NEXT? • Versioning serialization format • Replace reflection where performance matters • d.sortPartition("f0.author", Order.DESCENDING); • Better utilization of getLength information • Eliminate redundant null/subclass flags • Beating Tuples!
- 29. DISTANT FUTURE •Vision: more JVM independent optimizations! •Columnar serialization format (end to end optimization) • Final goal: Faster than naive handwritten serializers! •Customized NormalizedKeySorter •Lots of opportunities due to the delicate type system
- 30. CONCLUSION •Significant performance improvement •Ground work for lots of possible performance improvements •ClassLoader issues are not newcommer friendly •Not part of mainline Flink yet, happy to receive reviews
- 31. ACKNOWLEDGEMENT •Huge thanks to GSoC: •Márton Balassi •Gábor Gévay •Thanks to data Artisans for brainstorming •Thanks for your