hive-varchar vs string,如果存储格式是parquet文件格式,有什么优势吗

rjjhvcjd  于 2021-06-26  发布在  Hive
关注(0)|答案(3)|浏览(660)

我有一个配置单元表,它将容纳数十亿条记录,它是一个时间序列数据,因此分区是每分钟。每分钟我们将有大约一百万条记录。
我的表中有几个字段,vin编号(17个字符),状态(2个字符)。。。等
所以我的问题是,在创建表的过程中,如果我选择使用varchar(x)vs string,是否存在存储或性能问题,
varchar的一些限制是https://cwiki.apache.org/confluence/display/hive/languagemanual+types#languagemanualtypes-字符串
如果我们提供超过“x”个字符,它将自动截断,因此保留字符串将是未来的证明。
非泛型UDF不能直接使用varchar类型作为输入参数或返回值。可以改为创建字符串udf,varchar值将转换为字符串并传递给udf。要直接使用varchar参数或返回varchar值,请创建genericudf。
如果其他上下文依赖于基于反射的方法来检索类型信息,那么它们可能不支持varchar。这包括一些serde实现。
在存储和性能方面,使用string而不是varchar需要支付多少成本

s4chpxco

s4chpxco1#

最好的办法就是跟着绳子走。varchar也在内部存储为字符串。如果您想确定数据类型,请根据需要在相同的数据上创建一个视图。
t我看到的唯一区别是字符串是无界的,最大值为32767字节,varchar是有界的。字符串有效地限制了不使用它的数据。
矢量化支持也可用于字符串。

qco9c6ql

qco9c6ql2#

让我们试着从中了解它是如何实现的api:-

org.apache.hadoop.hive.ql.io.parquet.write.DataWritableWriter

魔术开始了-->

private DataWriter createWriter(ObjectInspector inspector, Type type) {
case stmt.....
........
case STRING:
        return new StringDataWriter((StringObjectInspector)inspector);
    case VARCHAR:
        return new VarcharDataWriter((HiveVarcharObjectInspector)inspector);

}

datawritablewriter类的createwriter方法检查列的数据类型。i、 e.要么 varchar 或者 string ,因此它为这些类型创建writer类。
现在让我们继续讨论 VarcharDataWriter 班级。

private class VarcharDataWriter implements DataWriter {
    private HiveVarcharObjectInspector inspector;

    public VarcharDataWriter(HiveVarcharObjectInspector inspector) {
      this.inspector = inspector;
    }

    @Override
    public void write(Object value) {
      String v = inspector.getPrimitiveJavaObject(value).getValue();
      recordConsumer.addBinary(Binary.fromString(v));
    }
  }


StringDataWriter

private class StringDataWriter implements DataWriter {
    private StringObjectInspector inspector;

    public StringDataWriter(StringObjectInspector inspector) {
      this.inspector = inspector;
    }

    @Override
    public void write(Object value) {
      String v = inspector.getPrimitiveJavaObject(value);
      recordConsumer.addBinary(Binary.fromString(v));
    }
  }

两个类中的addbinary方法实际上都添加了编码数据类型的二进制值(encodeutf8编码)。字符串编码和varchar编码不同。
对…的简短回答question:- unicode 字符串和varchar的编码不同。在存储方面,它可能根据存储的字节数变化不大。但根据我的理解,Hive是 schema on read 工具。 ParquetRecordReader 知道如何读取记录。它只读取字节,所以不会因为varchar或string数据类型而有任何性能差异。

pb3skfrl

pb3skfrl3#

鉴于orc格式已成为配置单元存储的默认标准,我的案例将限制并集中讨论orc格式,我不认为性能是配置单元中varchar和string之间的真正问题。对于orc格式,两种情况下的数据编码(参见下面的链接)是相同的。即使在使用自定义serde时,这也适用,它都被视为字符串,然后应用编码。
对我来说,真正的问题是其他第三方工具和编程语言如何使用字符串。如果最终使用的字符串没有文档化的问题,那么使用string作为类型而不是varchar(n)类型是很容易的。这在使用etl时尤其有用,因为etl需要通过管道Map元素,并且您不想冒忽略大小错误的风险。回到第三方工具,例如,sas在连接到hive时有很多关于读取字符串类型的问题。它将成为一些人的痛苦区域,对一些人来说,它将成为他们各自架构中的一个意识点。例如,当数据库通过jdbc或odbc连接到配置单元时,可能会将数据读取为varchar(max),这可能意味着需要考虑的挑战数量。
我建议将此作为一个主要因素,而不是Hive本身的性能。到目前为止,我还没有发现任何东西表明varchar在决定要使用的类型方面比string性能更好。
https://cwiki.apache.org/confluence/display/hive/languagemanual+orc#languagemanualorc-字符串列序列化
另一点是varchar现在支持向量化。在任何情况下,接收varchar的udf都将被视为字符串,因此点取反。
谢谢你纠正我,以防你发现理解不同。另外,可以提供一个参考链接,可能会有所帮助。

相关问题