T+1，也就是数据进去24小时后才能拿到计算结果，这是很多大数据平台宣称的规范。显然，太慢了，是不能满足业务需求的。 何况才百亿级的数据量。这种情况下的 T+1 延时，属于严重的性能浪费和架构设计缺陷。
在这个时代，数据的价值是随着时间指数级衰减的。对于反欺诈、应急调度、供应链风控等核心业务，昨天的满分答案，可能是今天的废纸。如果我们只有几万张表、百亿级数据总量，我们完全有能力做到分钟级响应，让业务部门拿着‘瞄准镜’打仗，而不是看着‘后视镜’开车。
引起T+1延迟的原因是可以归纳出来的，比如，没有并行计算和分布式调度引擎，数据处理软件版本落后，硬件资源不足，其中有一个很多项目都在采用的错误方法，那就是使用Hive作为数据湖以及数仓，然后，为了方便计算，将BI需要的数据再导入到Mysql，从Mysql中计算BI需要的指标。
这个方法，来自于早几年一个广泛的名词认知，那就是 “大数据=Hadoop”，很多项目为了大数据而大数据，其实，对于百亿级以下结构化数据量的大数据平台，选用Hive或者基于Hive改造的数据库作为底座，只会导致数据运行更慢，数据处理更复杂。
使用 Hive 作为结构化数据湖的底座是否合理，还要根据具体的需求和背景来分析。我们可以从多个角度分析这个问题，看看在什么情况下使用** Hive 做结构化数据湖**合适，哪些场景下可能不太合适。
1.Hive的优势
Hive 最初是基于 Hadoop 的一个数据仓库工具，而不是一个独立的数据库管理系统（DBMS），要用于大数据环境下的批处理查询。由于Hive是基于Hadoop HDFS存储，它可以轻松地扩展到成千上万的节点，并且能够处理PB级别的数据。假设单表数据量是百亿条，存储的总数据量是万亿级规模，Hive是非常不错的选择。HIve通过类似 SQL 的查询语言（HiveQL）使得开发者能够在 Hadoop 上运行复杂的查询，并且能够支持分布式存储。对于大规模数据处理和高并发查询，它的优势如下：
兼容性与SQL风格的查询：Hive 使用类似 SQL 的查询语言，使得开发人员能够快速上手，而不需要深入掌握 MapReduce 等底层技术。
分布式存储：基于 Hadoop HDFS，Hive 能够利用分布式存储系统处理大规模数据，对于存储上百亿条结构化数据非常有效。
扩展性：得益于 Hadoop 的分布式架构，Hive能够随着数据规模的增加而线性扩展，适合大规模数据的存储和处理。
支持多种数据格式：Hive 支持多种数据格式，包括文本、ORC、Parquet 等，这些格式适合进行高效存储与压缩，能够加速查询性能。
所以很多项目选择Hive作为数据湖的一部分，可以把结构化数据存储在 HDFS 上，同时通过 Hive 提供的 元数据管理，能够将数据进行组织、查询和分析。
2.Hive的局限性
尽管 Hive 在某些场景下能够作为结构化数据湖的基础，但也有一些局限性，特别是在实时性、性能和易用性方面。以下是一些常见的 局限性：
性能较差，尤其是实时查询：Hive 的设计初衷是批处理，因此它在处理实时数据时表现较差。虽然有一些优化方案（如使用 Hive on Tez、Hive on Spark 等），但相比于现代的数据库或者专门的实时计算框架，Hive 仍然不够高效。MapReduce 中的 shuffle 阶段（即从 Map 到 Reduce 阶段的数据传输和排序）是一个常见的性能瓶颈。大量的数据需要在不同节点之间传输，这个过程会非常缓慢，严重影响查询性能。另外，数据倾斜是一种常见的性能瓶颈，常见于 group by、join 等操作，尤其是当数据分布不均匀时，倾斜问题更为严重。
延迟较高;Hive 主要使用 MapReduce 或类似的批处理方式来执行查询，这种处理模式会带来较高的延迟，对于对实时性有较高要求的应用来说，可能不适合。
复杂性与维护成本：随着数据量的增长，Hadoop 集群的管理、监控、调度、数据清洗等工作会变得更加复杂。Hive 依赖的 Hadoop 环境需要较高的运维和管理成本，特别是在云环境或者容器化环境中，可能需要额外的配置和调整。
SQL支持的限制：虽然 Hive 支持 SQL 风格的查询，但其 SQL 功能不如传统的关系型数据库强大。特别是在复杂的查询优化和事务处理上，Hive 与现代数据库（如 Presto、BigQuery）存在差距。
不适合低延迟查询和快速反馈：如果你的数据湖需要支持实时、低延迟的查询和交互式分析，Hive 可能就不是一个理想的选择。特别是对于需要快速响应的业务场景，传统的数据库或者现代的数据仓库会更适合。
事务性不一致问题
● ACID 支持差：HIVE 自身是面向大数据的批处理框架，设计目标并非为了支持高并发、高一致性的事务处理。在实际应用中，尤其是在涉及到多个表的联动查询时，很容易出现事务不一致的情况。例如，在数据插入、更新时，由于缺乏原子性操作，可能会出现部分数据更新失败或者查询得到不一致的数据。传统的Hive表（如TextFile）不支持ACID事务。在数据库系统中，一个事务是指：由一系列数据库操作组成的一个完整的逻辑过程。例如银行转帐，从原账户扣除金额，以及向目标账户添加金额，这两个数据库操作的总和，构成一个完整的逻辑过程，不可拆分。这个过程被称为一个事务，具有ACID特性。
● 脏读与不一致性：当 HIVE 处理的数据量非常庞大时，查询时的“脏读”问题（读取未提交的数据）和数据一致性问题可能会加剧。这对于实时数据分析尤为致命，因为它会导致BI报表中的数据时常出现错乱，不符合实际业务状态。
字段类型转化问题
字段类型全部转化为字符串：HIVE 的设计原本是为了处理大量非结构化数据，很多数据存储在其表中的时候，字段类型往往会被自动转换为字符串类型。虽然这对某些类型的数据存储没有太大影响，但对于需要精确计算的数据（如数值类型、日期类型等），将字段统一转为字符串后，进行计算和数据聚合时，必须在编写程序或者人工处理强制进行类型转换，降低了查询性能。而如果目标端选择MPP结构化数据库，通过 JDBC 自动转换后，日期字段通常保持一致的日期格式（YYYY-MM-DD 或 YYYY-MM-DD HH:MI:SS），尽管不同数据库使用不同的类型（如 DATE、TIMESTAMP 或 DATETIME）。这些自动转换确保了跨数据库迁移时，日期数据的一致性和正确性，无需手动处理日期格式。
3.底座数据库选型方案
结构化数据：由于来自多个业务系统不同类型数据库，而且单表最大数据量也就是几亿条数据，总共数据量百亿级。建议将结构化数据存储在MPP数据库或者数据仓库中，支持高效的查询和分析。
传感器数据（时序数据）：传感器数据一般是时序数据，其处理和存储需要特别的设计。所以要选择一个高效的时序数据库，适合存储和查询传感器数据。 Apache Kafka + Apache Flink 或 Apache Spark Streaming：Kafka可以用作时序数据的流处理引擎，结合Flink或Spark Streaming做实时计算和分析。在这种情况下，由于数据已经实时处理，那么对底层数据库的选型选择范围就比较多。
视频帧数据：视频数据属于大规模的非结构化数据，并且一般需要处理高频的图像帧。因此，建议使用分布式文件系统如HDFS、MinIO或者对象存储（如Amazon S3，Azure Blob Storage）存储视频数据。视频数据的存储可以采用压缩格式，减少存储空间需求。
4.任务处理机制
除了底座选型导致数据加载和写入延迟比较大之外，还可以从以下几个方面进一步探讨：
（1） 批处理延迟和资源调度
原因：批处理通常集中在某个固定的时间窗口进行，这会导致任务的延迟。在数据量极大的情况下，计算资源的分配和调度变得复杂，可能导致资源的不充分利用或过度拥塞。
解决方案：优化作业调度器，合理分配资源，并且分批次逐步处理，以避免大规模作业造成过大的延时。
（2） 计算模型和任务依赖
原因：在T+1的处理模型中，通常需要依赖多个复杂任务的执行顺序，这使得处理过程变得线性化，任何一个步骤的延迟都会影响后续步骤的执行。因此，任务之间的依赖关系和计算模型可能是一个瓶颈。
解决方案：通过解耦任务、提高任务的并行度来减少延时，并使用分布式流式处理框架来代替传统的批处理模型。
（3）任务重试和容错机制的开销
原因：大规模的批处理任务通常会有较多的容错机制，例如任务失败后的重试，这可能会导致额外的延迟。如果系统设计过于保守，容错机制的开销可能会显著影响整体处理时间。
解决方案：优化容错机制，避免过多的任务重试，通过实时监控和及时恢复策略减少重试次数，避免大规模任务失败。
总结： 除了Hive和并行计算的限制，T+1延迟问题还与数据加载延迟、资源调度瓶颈、任务依赖关系、计算模型的选择、系统扩展性和容错机制等因素紧密相关。综合考虑这些问题，建议结合更高效的计算引擎、灵活的数据一致性处理方案以及优化资源调度策略，来提升大数据处理的实时性和效率。
手机端请关注公众号：数据集成服务
本文讲解视频请参见：
加入讨论群：
