use*_*246 23 java apache solr hadoop avro
我们需要序列化一些数据以放入solr和hadoop.
我正在评估序列化工具.
我名单中的前两位是Gson和Avro.
据我所知,Avro = Gson + Schema-In-JSON
如果这是正确的,我不明白为什么Avro如此受Solr/Hadoop的欢迎?
我在互联网上搜索了很多,但找不到一个正确的答案.
它所说的任何地方,Avro都很好,因为它存储架构.我的问题是如何处理该架构?
对于Hadoop中的非常大的对象可能是好的,其中单个对象存储在多个文件块中,使得存储每个部分的模式有助于更好地分析它.但即使在这种情况下,模式也可以单独存储,只需对其进行引用就足以描述模式.我认为没有理由为什么架构应该成为每一件作品的一部分.
如果有人可以给我一些好的用例,Avro如何帮助他们,而Gson/Jackson不能达到此目的,那将非常有帮助.
此外,Avro网站上的官方文档说我们需要为Avro提供一个架构,以帮助它生成Schema + Data.我的问题是,如果输入架构并将相同的数据发送到输出以及数据的JSON表示,那么Avro正在实现什么额外的?我可以不通过使用JSON序列化对象,添加我的输入模式并将其称为Avro来自己做吗?
我真的很困惑!
假设你为Employee类设计了一个这样的模式
{
{"name": "emp_name", "type":"string"},
{"name":"dob", "type":"string"},
{"name":"age", "type":"int"}
}
Run Code Online (Sandbox Code Playgroud)
后来你意识到年龄是多余的,并将其从模式中删除.
{
{"name": "emp_name", "type":"string"},
{"name":"dob", "type":"string"}
}
Run Code Online (Sandbox Code Playgroud)
在此架构更改之前序列化和存储的记录如何?你将如何回读这些记录?
这就是avro阅读器/反序列化器要求读写器架构的原因.在内部,它执行模式解析,即.它试图使旧模式适应新模式.
进入该链接- http://avro.apache.org/docs/1.7.2/api/java/org/apache/avro/io/parsing/doc-files/parsing.html -部分"用动作符号解析"
在这种情况下,它确实跳过动作,即它省略了阅读"年龄".它还可以处理从int到long等字段更改的情况.
这是一篇非常好的解释模式演变的文章 - http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html
对于单个文件中的多个记录,模式仅存储一次.
大小,以极少的字节编码.
我认为,架构演化解决的关键问题之一没有在任何地方明确提及,这就是为什么它为新来者带来了太多困惑。
一个例子将阐明这一点:
假设一家银行存储了所有交易的审核日志。日志具有特定的格式,需要保存至少10年。还非常需要保存这些日志的系统适应所有这十年来不断发展的格式。
这些条目的架构不会经常更改,我们平均每年要说两次,但是每个架构都会有大量的条目。如果我们不跟踪模式,则过一会儿,我们将需要参考非常旧的代码来找出当时存在的字段,并继续添加if-else语句以处理不同格式。使用所有这些格式的模式存储,我们可以使用模式演化功能将一种格式自动转换为另一种格式(如果您提供较旧和较新的模式,则Avro会自动执行此操作)。
模式演变的另一个优点是,新格式的生产者可以安全地生产具有新模式的对象,而无需等待下游使用者先进行更改。下游使用者可以具有内置的逻辑来简单地暂停处理,除非他们对与新格式关联的新架构具有可见性。这种自动挂起功能非常适合使系统保持联机状态,并使处理逻辑适应新的架构。
因此,总而言之,模式演变可通过使用自动格式转换来帮助较新的客户端读取较旧的格式,还有助于较旧的客户端以优美的方式暂停处理,直到使它们能够理解较新的格式为止。
| 归档时间: |
|
| 查看次数: |
14680 次 |
| 最近记录: |