[
https://issues.apache.org/jira/browse/HIVE-21218?focusedWorklogId=397939&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-397939
]
ASF GitHub Bot logged work on HIVE-21218:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 04/Mar/20 22:47
Start Date: 04/Mar/20 22:47
Worklog Time Spent: 10m
Work Description: davidov541 commented on pull request #933: HIVE-21218:
Adding support for Confluent Kafka Avro message format
URL: https://github.com/apache/hive/pull/933#discussion_r387980822
##########
File path: kafka-handler/README.md
##########
@@ -50,6 +50,9 @@ ALTER TABLE
SET TBLPROPERTIES (
"kafka.serde.class" = "org.apache.hadoop.hive.serde2.avro.AvroSerDe");
```
+
+If you use Confluent Avro serialzier/deserializer with Schema Registry you may
want to remove 5 bytes from beginning that represents magic byte + schema ID
from registry.
Review comment:
@b-slim You appear to be correct, based on the source code:
https://github.com/confluentinc/schema-registry/blob/master/avro-serializer/src/main/java/io/confluent/kafka/serializers/AbstractKafkaAvroSerializer.java.
Let's say we did implement as is, and later we implement the schema registry
lookup and use the same identifier? Who would that break? Serialized messages
that point to a bogus schema registry instance, or serialized messages that
happened to need 5 bytes at the front of the message, but aren't from
confluent, and some clever dev figured out he could use Confluent instead of
the right way?
The second case doesn't matter to me tbh.
The first case is concerning and should be handled. I would expect that we
would catch when we can't find a schema and print out a warning, but no error.
That would allow this case to continue working. But we would be making
assumptions on the implementation of a feature in the future, which is always a
crapshoot...
To be clear, if we make sure documentation is clear on this outside of just
these parameters, and @cricket007 agrees with it as a heavy Confluent user,
then I'm fine with it. It feels like we've covered this problem enough to be in
a good spot either way.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 397939)
Time Spent: 9.5h (was: 9h 20m)
> KafkaSerDe doesn't support topics created via Confluent Avro serializer
> -----------------------------------------------------------------------
>
> Key: HIVE-21218
> URL: https://issues.apache.org/jira/browse/HIVE-21218
> Project: Hive
> Issue Type: Bug
> Components: kafka integration, Serializers/Deserializers
> Affects Versions: 3.1.1
> Reporter: Milan Baran
> Assignee: David McGinnis
> Priority: Major
> Labels: pull-request-available
> Attachments: HIVE-21218.2.patch, HIVE-21218.3.patch,
> HIVE-21218.4.patch, HIVE-21218.5.patch, HIVE-21218.patch
>
> Time Spent: 9.5h
> Remaining Estimate: 0h
>
> According to [Google
> groups|https://groups.google.com/forum/#!topic/confluent-platform/JYhlXN0u9_A]
> the Confluent avro serialzier uses propertiary format for kafka value -
> <magic_byte 0x00><4 bytes of schema ID><regular avro bytes for object that
> conforms to schema>.
> This format does not cause any problem for Confluent kafka deserializer which
> respect the format however for hive kafka handler its bit a problem to
> correctly deserialize kafka value, because Hive uses custom deserializer from
> bytes to objects and ignores kafka consumer ser/deser classes provided via
> table property.
> It would be nice to support Confluent format with magic byte.
> Also it would be great to support Schema registry as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
