Avro schema
byte array
LocalDateTime
Data Serialization
Programming

How to define byte[] and LocalDateTime in avro schema?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Apache Avro is a data serialization system that relies on schemas for data structure definition. These schemas are defined in JSON, making Avro language-independent. Defining non-primitive data types such as byte arrays and date/time objects in Avro can be slightly complex given that Avro has a limited set of primitive type definitions.

Defining byte[] in Avro Schema

In Avro, a byte[] (byte array) is typically represented using the type bytes. This type is intended for storing sequences of 8-bit unsigned bytes. Here’s how you can define a byte array in an Avro schema:

json
1{
2  "name": "data",
3  "type": "bytes"
4}

This definition is straightforward as bytes is a primitive type in Avro's type system. These byte arrays are often used for encoding binary data such as file contents, encryption keys, or similar data types that require efficient size storage.

Handling LocalDateTime in Avro Schema

LocalDateTime from Java 8’s date-time API (java.time.LocalDateTime) isn't natively supported by Avro's built-in types. However, it's common to handle such types by converting them into a string or long integers, depending upon the precision required.

Representing LocalDateTime as String

Storing LocalDateTime as a string involves converting the date-time object into an ISO-8601 formatted string. Here's an example schema definition:

json
1{
2  "name": "timestamp",
3  "type": "string",
4  "logicalType": "timestamp-millis"
5}

In this definition, although the data type is string, the logical type timestamp-millis can be used informatively (though it's not an official Avro logical type for strings) to indicate that the string contains timestamp data. Conversion back and forth from the LocalDateTime to the formatted string is necessary when serializing and deserializing.

Representing LocalDateTime as Long

Alternatively, you might choose to store LocalDateTime as the number of milliseconds since the Unix epoch (00:00:00 UTC, 1 January 1970). This representation is efficient for storage and comparison:

json
1{
2  "name": "timestamp",
3  "type": "long",
4  "logicalType": "timestamp-millis"
5}

In this schema, timestamp-millis as a logical type rightfully applies to long, indicating the interpretation of the numeric value as a timestamp.

Summary Table

FeatureAvro TypeLogical TypeDescription
Byte ArraybytesNoneUsed for binary data like images or files.
LocalDateTimestringtimestamp-millis (custom)ISO-8601 string representation of date and time.
LocalDateTimelongtimestamp-millisMilliseconds since Unix epoch. Efficient for storage and operations.

Additional Details

When implementing serialization or deserialization for LocalDateTime in either string or long format, consider:

  • Time zone: LocalDateTime does not store any time zone information. When converting from a timestamp (in milliseconds), ensure consistency regarding the time zone.
  • Precision: When using the long format, determine whether milliseconds are sufficient or if more precision (such as microseconds) is needed.

In scenarios where direct Avro support for advanced data types is necessary, exploring extensions such as custom logical types or using complex types (like records for individual components of LocalDateTime) can be effective.

In conclusion, although Avro schema might not directly support some complex data types, the flexible nature of JSON combined with logical types and custom extensions allows for effective methods to define almost any data type, including byte arrays and date/time information.


Course illustration
Course illustration

All Rights Reserved.