如何设计真正的实时数据湖？
汽车制造行业在企业数据管理方案上的探索已有数十年之久，本文以辩证的视角回顾了这段发展史，先后分析了专用数据仓库时期、以湖代仓时期，以及湖仓一体时期的业界普遍共识。本文作者结合自己在不同时期基于对数据技术的挖掘，分享了对这些“流行观点”的理解、反思、消化与再造。
通过剖析“以湖代仓”观点的认知误区，作者提出了数据的流表二象性理论，并基于“流驱表”理念指出了湖仓融合的正确发展方向——利用流式计算加速湖内仓的数据流转，落地真正的实时数据湖。
作者 | 徐智出品 | CSDN（ID：CSDNnews）
在数据技术理论的探索上，我们走了很久的弯路。
01
以湖代仓悖论：数据湖与数仓从来不是可替代关系
实践中，数据仓库和数据湖都是企业数据管理的两种主要范式。单就汽车行业而言，在数据湖、仓上的“折腾”由来已久。世纪初，基于 IBM DB2 MPP 和 Oracle RAC 两大技术方案的“汽车行业专用数据仓库”概念出现，数据仓库的业务核心价值是对齐业务视角的操作，即不同部门在同一时间点上以相同的统计维度对自身所掌握的数据进行统计时，得到的结果应该是能够互相印证的。但是，美好的理想在骨感的现实面前，被数据的时效性与一致性问题冲击的痛苦不堪：
① 时效性挑战
数仓总是 T+1 的，几乎成了亘古不变的规律，即便使用了强如阿里的套装方案，也就是做到 T+1 小时，当前业务数据也是不能立等可取的。
具体表现为，企业大则报表慢。企业越大，分支机构多且杂，造成口径对齐的难度更大，最终引起统计耗时延长。总结出来的规律就是：数据的统计范围与数据的时效性呈负相关关系，即当所需要统计的数据范围越大，数据统计的周期就会越长。因为在统计数据时，需要等待所有参与者的数据都到达才能进行统计。而范围越大，统计的机构和参与者就越多，因此最后一个数据到达的时间将直接决定整个统计过程的结束时间。简言之，数据的时效性和数据统计范围的冲突是客观存在的，也是康威定律在数据领域的表现。
举例来说，假设我们需要统计当日早 9:00 的员工到岗率。由于需要等待各部门报告数据，直至最后一个部门上报完成，整体的口径才算完整，有可能计算完成时已经是中午了。
② 一致性挑战
月度的经营会议上，各个业务负责人对不齐数字，是每个月都要有的痛苦时刻，背后的一致性问题也是数仓的天生缺陷之一，源自于不同业务部门数据处理时间周期的差异。
具体表现为，总也对不上的销售与财务。营销或者销售部门受迫于业绩压力，会把销售的付款分层次展开，全款买断、授信付款、融资租赁、合同融资、合格证抵押等多种多样，总体上表现为不同层次的赊销现象，甚至于体现在经销商与代理商的渠道主体区别定义上。赊销分层造成直接后果就是，从销售视角的某个时间点的销售额的计算，按照个数、按照付款进度、按照风险程度，会出现多个统计数字。另一头的财务体系，基于明确的财务税务原则，把繁杂的业务动作拍扁成精确的数字，与含着各种风险因素的销售业绩进行核对，再杂糅着业务 KPI 导向的认为操作，自然是明白中带着糊涂。
以上便是数仓常要面对的业务需求自身的矛盾冲突。直到 Hadoop 兴起，Pentaho 公司（一家开源 BI 公司）首次提出“数据湖”理论，大家开始尝试用大数据技术来解决这一数仓困境，汽车行业的数据湖时代由此开启。在这一时期，业界的主论调更倾向于“数据湖是数据仓库的替代品”。基于这一观点，彻底推掉数仓，改建数据湖也成了当时的主流思路。
但很显然，数据湖与数据仓库之间并不是简单的可替代关系。这条路线是片面，甚至可以说是理论上完全错误的。
首先，技术上看，数据湖通常是基于大数据引擎构建的。依据 Hadoop 之父 Doug Cutting 的数据本地化（Data Locality）理论，大数据引擎本质上是计算引擎（Computing Engine）。而传统数仓的技术定位，则是基于数据库技术的读取性能演进，本质是存储引擎（Storage Engine）。最终，由于两种引擎的设计出发点不同，一旦与应用场景错配就会引起使用上的困难，要么数据时效跟不上，要么数据内容不一致。术语化的表达就是 CAP 理论的不可能三角，即无法同时保证方案的一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。
其次，业务上看，时效性和一致性的冲突，细究根源，是有着层次结构的多方业务数据，按照各自规则拍扁之后，再互相核对引起的偏差。由此，在保留业务数据层次结构的基础上，多方业务细节进行直接匹配，就可以完成时效性和一致性的宇宙和谐。基于此，技术能力反向牵引技术需求，支撑业务数据结构展开的，恰恰是 Hadoop 的快速计算能力，与数据库的精准存储能力，两者的密切且严谨的组合，才是解决问题的方案。
02
改道易行：从「以湖代仓」转至「湖仓融合」
由此，我们开始尝试将湖仓两者结合，并思考突破的路径。于是在 2018 年，提出了双引擎数据库的概念，也即在湖内包含一个仓，类似于今天常说的“湖上建仓”思路。而在此前，阿里云 MaxCompute 团队也提出了“仓外挂湖”的设想，也就是在分布式算力的数据仓库旁路一个数据湖。回头再看这一时期，湖仓一体的两大路线已初具端倪。
此后，我们的实践方向也就开始围绕湖上建仓展开——以分布式的大数据技术为基础，在其上构建具有数据仓库理论特征的数据管理层来解决时效问题。历史的机缘，又将车联网的海量数据抛给我们，从而加速了湖仓融合的进度。
当时所面临的的数据技术困境如下：
数据量大：车联网中多用 Kafka 来实现实时数据流处理和消息传递，每秒数据量可达数十万行，单条信息长且层次复杂，结构不可预知，传统数据库技术和数仓技术都难以负荷；
传统数仓数据融合难：通常情况下，车联网数据是指由车上传感器产生的实时数据，如位置信息、车辆状态等，而传统的 OLAP 数据仓库主要用于存储和管理业务数据库的 OLTP 数据结果。但在物联网，特别是车联网行业要求这两种不同类型的数据能够结合，以实现人找车、车找人、车在哪里运行、指定区域有哪些车、描述用车行为等场景。例如，需要将车辆的实时位置数据与业务数据库中的车辆信息进行关联，以确定每辆车的所有权、行驶范围、潜在故障等。
在业务的逼迫下，首先解决的是车联网（IoV）场景。
真实案例：网约车的实时定位需求
以 T3 为例的移动出行业务，对于实时定位的需求非常明确，其一是车辆的最新位置，其二是车的历史轨迹，且都要求支持近实时查询。通过车联网平台，车辆与乘客通过互联网连接，实现了实时的位置追踪和调度。这种实时定位和调度功能是车联网技术的一种应用，它利用了车辆上的传感器和通信技术，将车辆的位置信息传输到云端，然后通过 T3 的平台实现了车辆调度、路线规划等功能。
在此场景中，由于制造业的技术积累，无法像原生互联网企业全面使用分布式算力，或者全面流式计算，而是要面对大量关系型数据库与 Hadoop 生态组件的互通。以此为驱动力，湖上建仓方法论不断延展，IoV 需求也被视作湖上建仓发展的关键拉动点。
由于查询涉及的车辆不确定，纯粹依赖标准的流式处理的结果推送或传统的数仓预计算方案，来处理每辆车的随机查询都过于复杂，无法完全解决需求。这里考虑引入一种时效性更强的数据湖概念，“实时数据湖”开始被提及。
03
实时数据湖：更具时效性优势的湖仓融合方案
实时数据湖的核心原理：数据的流表二象性
在湖上建仓的过程中，我们提出了“数据的流表二象性”这一概念。灵感源自《流系统设计》（Streaming Systems）这本书，其中有一个章节叫作“流表相对论（Theory of Stream and Table Relativity）”，此书目标是设计一种同时处理流表两种形态的组件，也是当下阿里 Flink 的思想，但是，这种思想应该是错误的，因为具有流表二象性的是数据本身，而不是处理数据的组件，数据处理组件可以进出流数据或者表数据，但是其计算引擎的范式是一定受限于存储机制的，存储里面是表还是消息，这种选择是唯一的，否则也会有 CAP 冲突。在试图将这一理论运用到数据湖设计实践中时，我们发现流和表作为数据的两种形态，之间互相转换的方法和时空特性，是研究的重点。
分析过程大致如下，剖析 Oracle、MySQL 等经典数据库设计，不难发现传统数据库的构成都是 data+log，即数据文件与日志文件。其中，log 本身就属于流的范畴。换句话说，在传统数据库中，实际上存在着“流”的概念。反观 Hadoop 结构后发现，MapReduce 和 Kafka 的结构，是流优先的，持久化后流数据会以 Hive 方式被访问，这是一种“表”的形式。
另外，从 Oracle 的 Exadata 架构中也间接验证了这种思路，Exadata 的软硬一体设计带来超高性能，表现出了超乎传统数据库能力的表现。其中，基于 RDMA 等技术的 Exafusion 等独有的内部结构，必然是同时面对 data+log 处理的，表现出超高的 Data 块数据存取能力同时，也是高效能的 Log 流引擎。
Exadata 具体的产品功能与 Hadoop 对比，能够得到一种映射关系，Iog 高速落盘、高性能 JSON 存储、Database In-Memory，都可以映射到 Hadoop 生态的 Kafka、HBase、Redis 等组件。由此，从计算系统角度观察，有一种打碎 Exadata 体系为 Hadoop 生态组件单独发展的感受，即 Hadoop 生态是为了计算效率，而拼凑出来的可以存储的引擎。而对 Oracle 的工程成就的概括是，Exadata 是源自存储引擎的高性能计算设备，其计算能力恰恰是领先其他数据库产品的最大优势。
综上所述，Exadata 是解决结算效率问题的强一致的数据库，由此设计了软硬一体的架构，Hadoop 是有存储能力的可线性扩展的计算引擎，可以 SQL 驱动计算过程。即数据库中存在流，大数据平台中亦有表，这就意味着在《流系统设计》的流表相对论之前，远在 SAGE 时代就已经存在两者的调和方式，由此，理应有一层更深刻的关系在流和表这两种形态中存在。于是，我们提出了“数据的流表二象性”，并由此最终解释实时数据湖的核心原理。
流驱表：数据湖的“时效性”法门
用今天仍是主流的大数据架构 Lambda 来搭建实时数据湖是完全错误的。
基于数据的流表二象性，如果我们希望最终设计出真正实时的数据湖，需要思考的新问题是：同一份数据在流、表两种形态下来回转换的过程中，如何保障其时效性与一致性。
从以湖代仓到湖仓融合的这段时期，国际主流的融合方案是 Lambda 架构。该方案主要表现为同时执行表和流，并在某种程度上互相替代 —— 回到数据的流表二象性来看，这个架构明显存在问题。
正确的方案应该是流驱表或是表内流，也就是 Stream Driving Table 或 Stream in Table，也可以理解为表中有流。
换句话描述就是：最终表现形态是表，输入输出都是表，但进出表之间的转换（Transformation）过程是靠流引擎（Flow Engine）来驱动完成的。
因为对于表而言，最小的处理单位是表，处理一张表意味着需要操作表锁，要保证表的整体形态；而若是流，则最小的处理单位将会是一条消息，支持每条消息并行处理。也就是数据处于流形态时，并发度更高，效率也就更高，性能也会更好。即，对齐即延迟（Alignment is Delay），而表（Table）是对齐的结果。
回到开头提到的数仓一致性与时效性冲突问题，如果基于数据的流表二象性来思考，那么，作为出入形式的表，需要与流计算引擎，进行分别的讨论。
入口的表，可以检查完整性；出口的表，也可以检查完整性；入口的表与出口的表，可以按照逻辑进行一致性检查；各类检查都合格了，才把数据放出去。这样的功能，几乎就是梦想中的数据连接器的设计。
而如何设计驱动各类检查的引擎，流式引擎几乎就是这个问题的唯一答案，因为它真的在“实时计算”。首先，面向单条消息的处理机制体现为“不对齐则不等待”（No Alignment No Delay），而不必进行为了凑表的对齐。其次，各条消息之间的计算独立性，保证了并发性，实现了每一条的按需处理（Process on Demand）。
由此，通过在流中同时监控不同来源的数据并动态观察，便能够在某一时间点上实现真正的对齐，这便是流式技术解决一致性和时效性之间的冲突问题的基本逻辑。基于这样的流驱表思想，真正的实时数据湖结构诞生了。
流内表：吸引人的大数据副产品
有了表内流，也会有流内表，例如在 Kafka 的 Topic 中设计维度表的结构，然后在 Spark 等引擎中进行 Join，甚至于在 Flink 的生态中诞生了 Paimon 存储引擎，尝试解决流态数据的持久化问题，从而诞生了 Kappa、Flink 等著名的批流一体的架构。
但是，从架构成熟度角度观察，流内表方案始终停留在 ZooKeeper、Kafka、Spark/Flink 的组件组合状态中，即结构功能外部化的组合形态，直接表现在架构的复杂性和脆弱性上。实践当中，流处理引擎的角色，更多的是解决存储组件之间的数据流动问题，更类似 ETL 的定位，而不是作为 Cube 驱动引擎来使用。
另外，人类商业动作中对表格的偏爱，对流的冷落，是否体现为某种观念落后？流内表是否为更先进或优良的技术选择？可以参见传播学名著《字母表效应》中对表格产生过程的阐述，我将其解读为表的出现与文字，可能是平行的，即，流化的文字语言的出现，并不能替代表的形式，表的形式也是内容的一部分（麦克卢汉媒介即讯息）。
小结
通过对数据的两种基本形态的探索，我们最终得出数据可以在流与表两种形态下相互转换的规律。鉴于流在数据处理并发度上的先天性优势，我们在湖仓一体的研究方向上，破译了加速仓内数据流转的密码——流驱表，即在不影响输入输出数据的表形态的前提下，依靠流引擎驱动完成数据处理。
对于实时数据湖而言，最核心可用的部分是数据，是企业行为在数字化世界的痕迹或者映射。那么如何让仓内表的流转变得更快？这就需要寻找一种用流引擎驱动的表形态的转换器，其主要任务是高效地管理数据在流和表之间的转换，确保数据的时效性和一致性。
该转换器将通过流处理引擎实时采集并预处理数据，然后进行必要的转换操作，如数据清洗、格式转换、聚合和过滤。转换后的数据将被动态存储到仓库表中，保持数据的实时性和一致性。通过分区和索引技术优化存储效率，并实时监控数据源的变化，确保数据更新及时同步。此外，还需要合理分配计算资源，优化性能，建立全面的监控系统，确保系统高效稳定运行。上述步骤是提高数据处理速度和可靠性的关键，最终目的仍然是帮助企业更快地获取有价值的数据。
04
理论到实践：如何设计实时数据湖技术架构
既然有了脱离数据困境的思路，也整理了流表关系的方法论，我们需要考虑如何在当前的技术条件下，把这些方法论在物理上实现出来。
企业级实时数据湖的技术约束
技术约束是指当前能够找到的，且可行成本条件下可用的组件，尊重技术的客观规律，是“让可能变得可行”的根本原则。并且，为了保证设计出来的数据湖，能够在企业的发展历程中生存下去，需要兼顾稳定性、可扩展性和运维经济性，在设计架构时需要考虑如下一些基本原则或前提条件：
算量守恒规律：确定问题的计算时长受到软件、硬件、算法的共同制约，各成熟的编程语言差异低于 2 个数量级。即，如果要缩短计算时长，最有效的方法是提前计算。
技术独立性：尊重技术发展的客观规律，以历史的视角来选择和使用，可靠、成熟的第三方技术和框架，而不是自行开发所有组件，顺应技术发展趋势，而不是逆流而上强行自研。
系统可维护性：具备良好的可维护性的架构，体现在系统运行过程中的可观察性和可控制性，能够地满足系统的增长需求，应对业务增长带来的不确定性和风险。
硬件廉价性：计算机硬件廉价化的趋势，在架构上体现为系统性能的线性扩展力，即增加节点就可以提高性能、性能天花板很高、且架构没有单点故障。
接存算用：为了便于理解和掌握，我们将数据架构总结成四个字“接存算用”，即数据的接收、存储、计算和应用的四层功能，也迎合着企业内操作数据的四类工作内容。其中，存算的概念分离，既是双引擎的对立统一，也是对冯诺依曼架构的致敬。接存算用的描述方法，为数据团队提供了共同的术语体系，便于话题的定位和描述的聚焦。
05
实时数据湖架构设计的思路
从技术视角出发，在设计实时数据湖时，关键是设计出流表关系的结构。这个结构强调在数据湖中实现流与表的有机结合，通过流的处理能力来驱动表的转换和操作，从而提升数据处理的效率和实时性。Lambda 被业界实践，又被反复打补丁，就是因为流表互替的出发点存在缺陷，即便是投入海量人力物力，把技术手段深入到业务逻辑，搞得定一时一刻，却又违反了分层独立与低耦高聚的根本原理，终究是顾头不顾尾。那么在流表互替之外，我们提出了流内表（Table in Stream）或表内流（Stream in Table）的设计，其中表内流方案最为成熟，也被称为流驱表。
从业务视角看，实时数据湖需要兼顾数据的实时性、一致性、可靠性和扩展性，这些实际的业务需求，需要考虑以下关键要素：
隔离业务数据库的性能波动
数据仓库的延迟，最根本的问题是出在业务闲忙周期引起的业务数据库性能波动，对数据仓库抽取数据操作的时间限制。那么，如果要实现业务数据的实时汇聚，在业务数据库上建立“数据库性能防火墙”，就是非常有效的设计。
应用业务库的经典架构。读写分离、主从架构等经典的业务数据库高可用方案，要充分应用，除了 Oracle 的 RAC 使用昂贵的直接内存访问 (DMA)技术打破节点关系的方案，其他廉价策略的数据库系统，都要具备完整的高可用数据库架构。
稳定的数据同步负载。ETL 与二进制 Log 同步器的选型争议由来已久，在数据源负载的角度看，二进制 Log 同步器（Otto/Canal/OGG）是最佳选择，再以 ETL 方案进行补充。其中二进制 Log 同步器以 1%以下的源端性能负载，且主要负载在存储 IO 的特点，决定了其核心技术地位。
自动化检查数据一致性。源端与目标端数据库的兼容层次，决定了检查数据一致性的技术难度。两侧数据库在物理层、协议层、逻辑层的不同兼容水平，决定了两侧数据一致性检查的算法复杂度，兼容越浅验证逻辑越复杂，对同步器的可编程性要求越高。
自动化数据库与链路监控。面对一个数据库，可靠性可以 99.9999%，即每年停机 5 分钟，但是，如果湖仓连接 50 个数据库，就是 50 个每年停机 5 分钟，几乎是每周都有链路不好使。那么，湖仓数据链路的启停、初始化、恢复、碎片补偿，就是必要准备的技术方案。对于源端库宕机、链路中断、目标库空间不足，就变成了常规事项，比传统业务数据库管理，差异蛮大。
构建高效元数据管理功能
实时数据湖是直接对接到业务动作的，而不是传统的报表平台，所以，接存算用各环节的语义变化过程，是要透明清晰的，那么，记录数据链路内容，并伴随业务变化而动的元数据管理功能，重点关注数据完整性和准确性。需要重点考虑以下几个方面：
多源数据接入：实时数据湖通常需要处理来自各种不同数据源的数据流，这些数据源可能包括数据库、日志系统、传感器数据、API 数据等。每种数据源的数据格式和数据传输方式可能都不同，因此，需要设计一个灵活且兼容性强的数据流接入模块。
数据流监控：实时数据湖需要具备强大的数据流监控能力，以确保数据流的稳定性和可靠性。监控系统应能够实时跟踪数据流的状态，并在出现异常时及时发出警报。关键监控指标包括：延迟、数据完整性、数据流量等。
数据流管理：为了确保数据的完整性和准确性，数据流管理系统需要具备数据清洗、数据转换、数据验证等功能，对于已经接入的数据流，查看其接入方式、监控记录、转换逻辑、验证方式等。
安全性和隐私保护：依靠访问控制、数据脱敏、传输加密等手段，加强数据的安全性和隐私保护：
选择合适的数据处理引擎
数据处理引擎是承接算力的核心，其分布式架构是流驱表的原理性表达，其需要具备高并发处理能力、低延迟、高可靠性、有效的容错机制、尽可能多样化的数据处理模式、完善的生态系统支持，以及良好的扩展性和灵活性。以下是选择流处理引擎时需要考虑的关键因素：
流处理框架选择：需要评估各种流处理框架的特性和适用场景，如 Apache Flink、Apache Kafka Streams、Apache Spark Streaming 等。每种框架都有其独特的优势和适用范围，需要根据实际需求进行选择。
性能和扩展性：考虑流处理引擎的性能、扩展性和容错能力。性能和扩展性直接影响系统的吞吐量和处理能力，而容错能力则决定了系统的稳定性和可靠性。
此外，在流处理引擎上实现实时数据湖的流处理逻辑时，还需关注以下步骤：
数据清洗和转换：在数据流入实时数据湖之前，通常需要进行数据清洗和格式转换。这包括去除重复数据、处理异常值、统一数据格式等操作，以确保数据质量和一致性。
实时计算：实时数据湖需要支持各种实时计算操作，如实时聚合、过滤、联结等。通过流处理引擎实现这些实时计算操作，可以及时地处理数据并生成所需的结果。这些计算操作可以根据业务需求进行定制，以满足不同的实时分析和查询需求。
支持高并发操作的存储引擎
数据持久化是数据湖的基础能力，能否接住汹涌的数据流是至关重要的，它需要满足高效的读写操作，并与流处理引擎无缝集成。以下是设计数据存储时需要考虑的要点：
存储系统选择：常用的分布式存储系统包括 Apache Hive、Apache HBase 以及现代化的分布式文件系统如 Apache HDFS。每种存储系统都有其独特的特性和适用场景，需要根据实际需求进行选择。
高效读写操作：数据存储系统需要支持高效的读写操作，以满足实时数据处理的需求。高效的读取操作可以确保实时查询和分析的性能，而高效的写入操作可以保证数据的及时更新和同步。
与流处理引擎集成：数据存储系统需要与流处理引擎无缝集成，以便实时数据的流入和流出。通过与流处理引擎的集成，可以实现数据的实时写入和查询，从而满足实时数据湖的需求。
数据转换和操作的可编程空间
在实时数据湖的设计中，定义并执行转换和操作逻辑同样是关乎其基础的一环。这些逻辑操作包括数据清洗、格式转换、聚合计算等，它们确保了数据在流和表之间的高效转换和处理。这一层的考虑要点如下：
数据清洗：在数据流入实时数据湖之前，通常需要对数据进行清洗，去除无效数据、填充缺失值等。数据清洗操作可以确保数据的质量和完整性，为后续的分析和处理提供可靠的数据基础。
格式转换：不同数据源可能采用不同的数据格式和结构，因此在流和表之间进行转换时，可能需要进行格式转换。这包括数据的编码、解码、序列化、反序列化等操作，以确保数据在不同环节之间的兼容性和一致性。
聚合计算：实时数据湖通常需要支持实时的聚合计算，包括求和、平均值、计数等操作。这些聚合计算可以在流中进行，也可以在表中进行，取决于具体的业务需求和数据处理流程。
高效性和一致性：转换和操作逻辑需要保证高效性和一致性。高效性可以通过优化算法和数据结构来实现，确保操作的快速执行；而一致性则需要考虑数据的同步和更新机制，确保在数据流和表之间的转换过程中数据的一致性和准确性。
完备的监控和管理组件
为了确保实时数据湖的稳定运行，需要一套完善的监控和管理工具。这些工具应提供实时的性能监控、错误检测和告警功能，帮助运维人员及时发现和解决问题。以监控和管理工具的重点智能：
性能监控：监控工具应能够实时监测实时数据湖的性能指标，包括数据流处理速度、数据存储容量、系统负载等。通过监控这些指标，可以及时发现性能问题并采取相应的措施进行优化。
错误检测：监控工具应能够检测并记录实时数据湖中出现的错误和异常情况，包括数据丢失、数据延迟、系统崩溃等。及时发现错误并进行处理可以有效地减少数据损失和系统 downtime。
告警功能：监控工具应能够设置告警规则，并在发生异常情况时发送告警通知，以便运维人员及时采取行动。告警通知可以通过邮件、短信、即时通讯工具等方式进行发送，确保问题能够被及时解决。
可视化界面：监控工具通常提供可视化界面，以直观地展示实时数据湖的运行状态和性能指标。通过图表、曲线等形式的展示，可以帮助运维人员快速了解系统的运行情况，并进行必要的调整和优化。
自动化操作：监控工具还可以提供自动化操作功能，例如自动重启服务、自动扩展资源等，以减少人工干预和提高系统的可用性和稳定性。
设计案例
挑战 1：获取数据遗产的实时数据
常规思路，在数据接入阶段模仿互联网方案，使用 Kafka 这种流式处理的接入。第一，很多业务系统是在 Kafka 得到广泛使用之前存在的，改造系统直接发送数据到 Kafka 的代价是巨大且不可行的。另一个，常见方法是使用 Flink-CDC 技术和 Kafka 对接， 把数据库中的数据以日志形式转为流后传输到 Kafka 中，也就是 Lambda 架构为主的策略。在忽略运维成本的问题下，由于 Kafka 非唯一化问题，通常架构师会在 Kafka 出口处，编写业务逻辑来检查其唯一性，这种设计会挑战业务逻辑的完备性，随着业务的变化会产生新的问题，即业务逻辑是不完备的，无法覆盖所有情况，这就意味着系统运行时长，会破坏数据的准确性，即短期靠谱，长期一团乱的局面。
因此，我们尝试应用流驱表的理论来解决，由此产生了两个应用分支：
使用经典数据库组件：借助经典数据库组件，其中最典型的代表就包括同步器 Golden Gate 和校验器 Veridata，二者连用就会是一个兼具实时传输能力和准确性保证的方案，另外，华为的 DRS（Data Replication Service）也是类似的解决思路，通过强化数据库自身组件能力，实时同步且校验数据一致性。优点是经典方案，缺点是架构古老可扩展性差。
使用新一代实时数据工具：基于大数据时代的数据库技术成果，在 MongoDB 等新一代数据库经验基础上, 国内 TapData 完整实践了流驱表架构，在实时性、一致性、可扩展方面达成均衡，能够支持在实时同步的同时进行一致性检查。
挑战 2：建立性能防火墙实现性能隔离
实时数据湖的上游脆弱性，是非常大的设计挑战，大量数据的抽取操作，当取数周期与业务高峰相撞时，会对业务库造成很大的压力，甚至宕机。这也是所有涉及抽取数据的场景所面临的共性困境，解题思路如下：
避免批量抽取数据：批量抽取数据会导致高强度的压力，因此建议尽可能采用 Log(日志流)形式来获取数据。流的形式支持稳定而持续地从源端库中获取数据，从而使得对源库的压力得以稳定保持在一个较低的水平，通常低于 1%。
建立源端库的镜像：在数据湖内部建立源端库的镜像，而且要尽可能地与源端库技术门类相同，即源端库与湖内镜像库同构，两端兼容层次越深越好（兼容性有物理、协议、逻辑的三层），例如源端和目标端都为 MySQL。此设计源自 CQRS（Command Query Responsibility Segregation，命令查询职责分离）思想，本质上是在湖内创建一个只读镜像，作为性能防火墙——无论对这个镜像施加多大的计算压力或抽取压力，都不会影响到源端的业务库，保护源端数据库免受实时数据湖的操作影响。
挑战 3：流式数据的导流问题
常见的数据流总线 Kafka 的设计都是集中式的，一组 Kafka 集群负担几乎所有的数据流。但是，在车联网领域，数据流来源和去向是由众多团队共同完成的，长期的交叉变更让 Kafka 上的数据流变得脆弱。由此，设计了多级瀑布式的 Kafka 架构，其核心思想是让 Kafka 的入口与出口独立出来，成为独立的小型 Kafka 集群，然后 Kafka 集群之间通过 Flume 或其他转发程序连接，实现了 Kafka 的“读写分离”，也是 CQRS 理念的变通实现。
在特定的 Kafka 出口集群上进行数据落盘操作，在物理结构上独立了数据流的导流槽，隔离了纯流式数据开发环境，与流表混合应用环境。为后续的基于 Kafka 的 Topic 进行维度建模，流内建仓（流态 Cube）的实践，创造了技术基础。由此，对于不同规模的实时数据，分别可以进行流内 Join、表内 Join，甚至流表混合 Join，都有了物理结构基础。
设计成果
此时，实时数据湖中已包含所有企业需要的数据，其中，来自关系型业务数据库的业务明细数据已经被成功地实时汇总、隔离，并且通过了一致性校验，已经准备好与其他数据相结合。进入传统的“大宽表”的蛮力计算阶段，利用 Hadoop 这样拥有线性性能扩展能力的开源分布式计算框架，即可将从各个源镜像层获取的数据在充足的算力下 Join 和 Union，整合为需要的大小，所消耗的时间仅仅取决于 Hadoop 的规模大小。
对于汽车制造业而言，建立实时数据湖，可以同时解决三个问题：
第一个是解决了传统数据仓库的时效缺陷；
第二个是解决超大表的 Join 的效率问题；
第三个是将实时产生的流式数据（例如车上传感器数据、设备数据等 IoT 数据）与传统的关系型数据（例如数据库中的记录、业务数据等）相结合，创造了大量的新场景。
至此，汽车制造业的流式数据与关系型数据混合的实时数据湖方案设计完成。
06
落地：实时数据湖架构的技术选型
设计完成的下一步来到了选型，这不是简单的技术好恶问题，更多是一个人力资源问题，需要充分权衡技术需求与自身人才条件。对地处于一线城市企业，容易招聘到技术能力强的人才，甚至于能够雇佣在数据组件社区有贡献的人员，但是，对于三四线城市的企业，大多数时候只能找到使用技术组件的人员。这就决定了，是内化技术能力，还是外包技术组件，是经济和人才环境决定的客观选择。
选型与对比
（1） 流处理引擎选择
Apache Flink：是一个开源的流处理引擎，具有低延迟、高吞吐量和 Exactly-Once 语义等特点。它支持事件时间处理和状态管理，能够处理无界和有界数据流，并提供丰富的操作符和窗口函数。Flink 的扩展性和容错性也很强，在大规模数据处理和复杂流处理场景中表现优异。
优点：
低延迟、高吞吐量和 Exactly-Once 语义
支持事件时间处理和状态管理
处理无界和有界数据流
强大的操作符和窗口函数
扩展性和容错性强
缺点：
部署和维护成本相对较高
Apache Kafka Streams：是 Kafka 生态系统中的一部分，提供了简单而强大的流处理功能。它与 Kafka 消息队列无缝集成，能够直接从 Kafka 主题中消费数据，并支持状态管理和流-表转换。Kafka Streams 非常适合与 Kafka 一起构建端到端的实时数据处理流水线。
优点：
与 Kafka 无缝集成
直接从 Kafka 主题消费数据
支持状态管理和流-表转换
适合构建端到端的实时数据处理流水线
缺点：
对 Kafka 生态外的数据源集成不够友好
需要配合 CDC 组件
Materialize.io：是一个实时流处理和物化视图引擎，专注于提供低延迟、强一致性的流处理能力。它能够实时地将流数据转换为 SQL 查询的物化视图，支持复杂的 SQL 查询和聚合操作。Materialize 非常适合需要快速响应和复杂查询的场景。
优点：
实时流处理和物化视图引擎
支持复杂的 SQL 查询和聚合操作
低延迟和强一致性
缺点：
对于超大规模数据处理的扩展性有限
生态系统和社区支持相对较小
TapData：TapData 是一款集 CDC、流处理、数据集成于一体的新一代数据同步工具，以低延迟表现见长。自带较强的计算能力和强大的表流转换能力，TapData 可以通过数据库日志解析技术，无代码升级企业的数据架构，支持流式计算，完成表到流的自动转换；同时还能通过物化视图和中央化存储能力，将流式数据固化为可以高效查询的数据表，完成流到表的自动转换。支持快速在业务数仓和各业务系统之间建立弹性、高效且稳定的连接，能够快速适应不同的环境和需求，并保证数据传输的稳定性和可靠性，实现数据实时入湖入仓。
优点：
技术逻辑与“流驱表”理念较为吻合
高度优化的性能和突出的低延迟表现
自带监控模块，便于监测任务状况
原生支持 60+ 数据源
简化了数据流管理和操作逻辑
自带 CDC 采集，和数据转化，实时能力较为完整
缺点：
流式多表关联能力不足
开源社区不如其他 Apache 产品成熟
（2） 数据存储系统选择
存储系统的性能、扩展性和可靠性是选择合适数据存储系统时需要考虑的重要因素，下面就从这三个维度，来评估一些常见方案的表现。
Apache Hive
性能：Apache Hive 通常用于批量数据处理，对于大规模数据的分析查询具有较高的性能。但对于实时数据处理需求，其性能可能不如其他数据存储系统。
扩展性：Hive 可以通过添加更多的节点来实现水平扩展，但在大规模数据处理时，需要进行适当的优化和配置。
可靠性：Hive 在数据处理过程中提供了较好的容错机制，可以有效地处理节点故障或数据丢失等情况。
MongoDB
性能：MongoDB 采用灵活的动态 Schema 数据模型，允许多源数据的无需建模快速入湖，具备高并发和低延迟查询能力，接近内存数据库性能，毫秒级响应延迟，适合直接为 TP 型业务应用的查询场景直接供数。
扩展性：MongoDB 通过分片架构实现水平扩展，数据可以存放于数十到数百个分片服务器上，支持海量数据存储和处理。
可靠性：MongoDB 使用分片和复制集来确保数据的可靠性和持久性。分片在多个节点之间分布数据，而每个分片内的数据通过复制集进行复制和备份，从而提供良好的容错能力。
Apache Doris
性能：Apache Doris 是一款高性能、实时数据分析的 MPP 数据库，具有极高的查询性能，支持快速的数据导入和实时分析。
扩展性：Doris 采用 MPP 架构，通过添加更多的计算节点和存储节点，可以线性扩展处理能力和存储容量。
可靠性：Doris 支持多副本和故障恢复机制，确保数据的可靠性和可用性。
Apache Paimon
性能：Apache Paimon 专为实时数据湖和批处理优化，能够高效处理流数据和批数据，具有低延迟和高吞吐量的特性。
扩展性：Paimon 支持水平扩展，能够通过增加计算和存储节点来提升处理能力，适应不同规模的数据需求。
可靠性：Paimon 提供强大的容错机制和数据一致性保障，通过分布式架构确保数据安全和高可用性。
综合比较
性能比较：Apache Doris 在实时数据分析和查询方面表现优异，适合需要高性能查询的场景。Apache Paimon 能高效处理流数据和批数据，适用于数据湖和混合负载场景。Apache Hive 适用于大规模批量数据处理。Apache HBase 则适用于需要快速响应和低延迟的实时数据访问。
扩展性比较：Doris 采用 MPP 架构，扩展性强，适用于大规模数据处理和分析。Paimon 支持水平扩展，能够适应不同规模的数据需求。HBase 也支持水平扩展，可通过增加节点来提升存储和处理能力。Hive 通过优化和配置也能实现一定程度的扩展，但在大规模数据处理时可能需要更多的考虑。
可靠性比较：Doris 支持多副本和故障恢复机制，确保数据的可靠性和可用性。Paimon 提供强大的容错机制和数据一致性保障，通过分布式架构确保数据安全和高可用性。Hive 的可靠性主要取决于底层存储系统的支持和配置。HBase 在数据冗余和备份方面较为灵活，可以按需配置和调整。
（3） 转换和操作逻辑
在实时数据湖架构设计中，转换和操作逻辑起着至关重要的作用。这部分涉及到数据在流与表之间的转换过程，以及对数据进行清洗、格式转换、实时计算和聚合操作等。
数据清洗和格式转换
在数据流入实时数据湖之前，通常需要进行数据清洗和格式转换，以确保数据的质量和一致性。数据清洗可以包括去除重复记录、处理缺失值、修复错误数据等操作。同时，将数据转换为统一的格式和结构，有助于后续的数据处理和分析工作。
这里可以使用流处理引擎的数据转换功能或自定义代码来进行数据清洗和格式转换。流处理引擎提供了丰富的转换操作和 API，能够快速灵活地处理各种数据清洗和格式转换需求。
实时计算和聚合操作
实时数据湖需要支持实时的计算和聚合操作，以满足业务需求。通过流处理引擎实现实时计算，可以对数据进行即时的处理和分析，从而及时发现和响应数据变化。聚合操作可以对数据进行汇总统计，提取有用的信息和洞察，为业务决策提供支持。
根据实时计算和聚合操作的复杂度和性能要求，选择合适的流处理引擎和相应的操作方法。例如：以出色的实时计算能力为关键优势的 TapData；提供了丰富的流处理功能的 Apache Flink；以及更适合简单的流处理场景的 Apache Kafka Streams。
流与表之间的转换逻辑设计
流与表之间的转换逻辑设计是实时数据湖架构设计中的重要组成部分。在流处理过程中，数据需要被转换为表格式，以便进行存储和查询。同时，从表中读取的数据也可能需要被转换为流，以满足实时计算和分析的需求。设计有效的转换逻辑，能够确保数据在流与表之间的高效转换，并保持数据的一致性和准确性。
根据流处理引擎的特性和支持的功能，选择合适的转换逻辑设计方案。Apache Flink 提供了丰富的流-表转换操作和语义，能够灵活地实现流与表之间的转换逻辑。Apache Kafka Streams 则更适合简单的流-表转换场景，提供了简单易用的转换 API 和语义。TapData 更是以“流驱表”为理论底座，支持稳定高效的流表转换。
（4）人力资源平衡
在选型阶段，考虑到企业或组织所在的地理位置对人才水平的影响，我们提出了人力资源平衡问题。
首先，不可否认的是，不同地理位置的人才水平差异明显，城市人才水平等于企业或组织的自有人才水平，也就决定了其自身的运维水平，继而决定了其对开源技术的选择深度。
简单来说，如果企业自身拥有高水平的技术团队，可以选择更深度的开源方案，选取更多开源组件；而对于技术能力相对较弱的企业，则需要更多依赖更多厂商的力量，可能需要购买更多服务来弥补技术缺口。
数据相关的行业与工具不胜枚举，因此，选型考量时往往需要平衡企业的组织能力、技术能力以及开源水平，综合考虑当前地理位置，乃至工资水平等客观条件，进行合理、可持续的组件选择。
举个例子
以东北某大型汽车制造企业为例，其现状可大致总结为：一，属于相对偏远地区，气候条件不好，导致高端人才稀缺；二，所在地区自有高校资源，整体人才素质有基本保障；三，该企业战略要求培养自有能力。
基于这些背景，我们对该企业的选型建议是：早期选择偏开源的组件，并逐步发展自有团队，减少对外部供应商的依赖。这种过渡过程可能需要数年的时间，但随着本地团队的成长，将顺利过渡为一个完全内部化的方案。
实施和部署策略
选型之外，在实施和部署实时数据湖时，还需要考虑以下关键因素和策略。
① 系统架构设计与规划
架构设计：基于业务需求和技术特点，设计合适的实时数据湖架构。包括数据流管理、流处理引擎、数据存储、转换和操作逻辑等方面的设计。
规划布局：规划系统组件的布局和拓扑结构，确保各个组件之间的协作和集成。考虑到系统的扩展性和容错性，合理划分模块和节点。
② 技术选型与实施计划
流处理引擎选择：根据业务需求和系统要求，选择合适的流处理引擎。比较不同引擎的优缺点，制定实施计划和时间表。
数据存储系统选择：评估各种数据存储系统的性能、扩展性和可靠性，选择最适合的存储方案。
转换和操作逻辑设计：设计和实现数据转换和操作逻辑，确保数据在流与表之间的高效转换。
③ 测试与验收流程
测试计划：制定系统测试计划，包括单元测试、集成测试和系统测试等各个环节。确保系统各个组件和功能的正确性和稳定性。
验收标准：定义系统验收标准和指标，包括性能指标、功能完备性等方面。与业务方沟通确认验收标准，并进行验收测试。
④ 迁移和集成策略
数据迁移策略：制定数据迁移计划和策略，确保现有数据能够顺利迁移到实时数据湖中。考虑到数据的格式和结构，选择合适的迁移方法。
系统集成：与现有系统进行集成，确保实时数据湖与其他系统的无缝集成和协同工作。制定集成计划和接口规范，确保系统之间的数据交换和通信畅通。
小结
无论是什么样子的架构设计或者理论实践，最终要因地制宜的匹配资源，也要实事求是的面对技术问题，前期的技术债务后期也要老老实实的还掉。根据当前时代的实际情况，做出最恰当的选择，是顺应技术的趋势，也是让项目能够存在和发展的正确选择。
07
案例解析：东北某知名汽车制造企业的实时数据湖之路
下面我们还是以该地处东北的汽车制造企业为例，重走其在数据管理方案上摸索而来的这些年，并从中总结各个层面的经验和反思。
需求与挑战
作为行业巨头，随着国内、国际业务的不断扩展，该车企所面临的运营和决策需求也日益复杂。为支持全球化战略和快速增长，开发团队需处理大量的数据请求，并在短时间内将数据整合到企业的数据湖中。每周需同步 1~3 个业务库的指定表进入湖内仓库，确保数据的及时性和一致性。
因此，企业需要高效、灵活的研发响应机制，确保业务需求能够迅速得到满足。然而，资源分配和优先级冲突使得研发团队难以快速响应业务部门的频繁数据请求，导致决策和运营效率受限。
换言之，数据能力已成为数字化转型的瓶颈，严重制约了该车企的 IT 生产力和业务响应速度。主要体现在以下几个方面：
数据准备耗时长：数据采集、同步、清洗、去重和建模等过程占总工作量的 70%，压缩了核心业务开发的时间，仅剩 30% 用于核心业务。
数据源复杂多样：公司内部存在大量异构数据源（如 Oracle、MSSQL、MySQL、PG、MongoDB、Kafka、Excel、XML），增加了数据整合的复杂度，拖慢了数据处理和分析速度。
系统孤岛问题严重：数据分散在多个系统中，形成数据孤岛，难以实现统一管理和高效利用。传统 ETL 方式多为 T+1，不能支持实时业务需求，导致业务响应滞后。
开发效率低下：大量 SQL 脚本和 ETL 流程需要重复开发，开发人员难以快速响应不同业务组的数据请求，严重影响开发效率和业务响应能力。
高并发数据处理需求：单表记录数可达几千万，增量并发请求超过 20000+/秒，对数据处理时效性和高性能要求极高。
充分考虑到以上因素，该车企考虑采纳新一代实时数据湖方案，用于实时接收、存储和处理来自多个数据源的数据存储系统。
选型与对比：实时数据湖的“腱鞘”
在为实时数据湖架构挑选组件的过程中，我们一直在试图寻找能够在业务库与湖内仓之间充当某种“软连接”的工具。
这种连接将不同于 Golden Gate + Veridata 组合这样的传统硬连接，以及更偏向粗放的连接方式（如 Kafka）。软连接应当介于此二者之间，有一定的弹性与强度，高效但不失严肃，能够快速适应不同的环境和需求，同时又能保证数据传输的稳定性和可靠性。
这意味着“软连接”不仅仅是一个简单的传输工具，还要求其引擎的计算能力足够强大，能灵活够处理负责的逻辑。
此外，这个工具还需要具有耐用性，不会导致频繁出现故障。考虑到生产线的严肃性，停线事故将导致严重的损失，因此开源工具不再具有优势，更需要一种可定制性、强度、效率都接近于硬件的组件来做中间的连接。
不仅如此，从人力成本的角度来考虑，通过计算发现，如果使用类似 Canal 这样的开源或是偏开源的解决方案，综合考虑开发和运维需求，需要投入一个人均年薪 40 万的 5~10 人团队。
因此，同样以流驱表模式为底层逻辑设计的工具会是恰好合适的一块拼图，例如本案例中最终用到的就是前面提到过的 TapData。这样的工具体量非常小，在整个实时数据湖架构中其实并不起眼，但是切实起到了必不可少的“垫片”作用，在大数据分布式引擎和数据库之间，形成了一个软连接状态，区别于业界流行的 Flink CDC，更加严肃且兼具弹性。
现代企业的实时数据引擎：实时数据湖方案落地
方案架构
如上图所示，最终该车企落地的实时数据湖架构包含以下几个核心层：
采集层
采集层是数据架构的基础，负责从不同的数据源中获取原始数据。这些数据源包括：TDS、营销中心、财务基台、风控系统、ERP V6、采购商城等。
虚拟数据层
虚拟数据层通过实时数据同步，将采集层的数据整合并构建虚拟模型。这一层分为几个部分：
贴源层：直接从源系统获取数据，确保数据的原始性和准确性。包括客户信息、订单数据、历年财报、风控维度、门店信息等。
虚拟数据模型：创建多个虚拟模型，以便更好地管理和利用数据。这些模型包括：车辆主档案数据模型、订单管理数据模型、风险管理数据模型、财务数据模型、员工数据模型和经销商数据模型。
服务层
服务层通过 API 接口，将虚拟数据层的模型数据暴露给上层系统。包括：汽车模型 API、订单模型 API、组织架构 API、风控模型 API、财务报表 API、认证服务 API 等。这些 API 接口使得上层业务系统能够方便地获取和利用数据，支持业务运营和决策。
业务层
业务层是数据的最终消费者，使用数据来支持各种业务系统和应用。这一层包括：智能网联云平台 TSP1.0、数字投放平台、预批量管理系统、采购满意度、智能网联运营服务升级、分析系统（如工厂供应链 BI 系统、财务报表、生产调度中心大屏等）。
数据管理功能
右侧的功能支持数据的整体管理和治理，确保数据的一致性、质量和可靠性：
数据目录：管理和组织数据资产，提供数据的目录服务。
数据治理：确保数据的质量和一致性，包括数据标准化、数据清洗、数据安全等。
数据开发：支持数据的开发和处理，提供开发工具和平台。
数据同步：实现数据在不同系统之间的同步和共享，确保数据的实时性和一致性。
该架构通过将不同的数据源整合到虚拟数据层，利用服务层提供 API 接口，支持上层业务系统的各种需求，实现了数据的实时同步和高效利用。从而支持企业复杂的业务需求，确保数据的一致性、准确性和实时性。
成果收益
通过实施实时数据湖解决方案，该车企在多个方面获得了显著的收益：
支撑业务部门取数：
支持超过 60 个业务部门的使用需求。
在 6 个月内，开发了 29 条业务数据链路，满足了多样化的业务需求。
2. 大幅提升开发效率：
实现了从数星期到 1 天的数据链路开发时间的缩短。
为数据开发团队提供了快速开发数据链路的能力，大幅提高了开发效率。
构建实时数据同步链路：
解决了传统 ETL 的通病，即离线数据不实时的问题。
通过实时数据同步，维护成本低，学习周期短，极大地提升了数据的时效性和准确性
4. 企业数据目录的建设：
研发团队可以在平台上快速查找到所需的数据，减少了 70% DBA 的日常查询工作量。
提升了 90%开发效率，无需跨部门沟通数据，极大地简化了数据查询和使用流程。
通过这些改进，企业在数据管理和业务支持方面取得了显著的进步，实现了更高效的数据处理和业务响应，为企业的持续创新和市场竞争力提升提供了坚实的数据基础。
其他注意事项
① 全行业的错误：异构难题
如果纵横来看汽车制造行业的数据汇总方案，严格来说，全行业都在犯一个错误，那就是异构问题——最典型的案例就是业务库是 MySQL，而汇总库却是 PostgreSQL——业务库和数仓用的是两套技术。
该车企也不能免俗：业务库使用 Oracle，数仓使用 IBM DB2。这种技术不兼容性导致数仓难以实现其功能，甚至无法保证重新生成业务报表。由于业务库不断变动，数仓难以及时同步，导致数据质量下降，最终项目失败。参考前文的设计思路可知，此处解决异构问题的关键在于实时传输与数据验证，以及构建同构技术的防火墙，确保源端业务逻辑在数仓中可直接重现。
② 明确岗位责任：实时数据湖成功的重要因素
实时数据湖要想成功，必须要保证数据湖内部的逻辑责任与源端保持一致。这意味着负责数据湖中数据的正确性和一致性的团队或个人，必须与源数据的管理方保持一致。具体来说，这涉及到两个方面：
责任主体一致性：以确保数据的处理和解释方式在整个数据流程中保持一致。
业务同构性：数据湖内部采用的技术和处理方式必须与源端的技术环境和业务逻辑相匹配，以确保数据在整个处理流程中的一致性和正确性。
这是业务逻辑得以在湖内直接重现的原因，也是实时数据湖成功的必要考虑。
此外，也要求企业的运维团队在具备一定自主能力的基础上，学会平衡人力成本，面对需要耗费大量时间成本和人力成本的组件，要擅用成熟的商业工具来进行适时替换。
08
总结与延伸
在传播学领域有一本书叫作《字母表效应》，其中有讲到这么一段：在人类发展早期，文字出现之前，表格已经存在于人类社会中。这是因为最初人们在进行交易时，考虑到食物不易保存，开始用小泥巴或石头雕刻成动物形象，代表交易的数量，同时也进行实物交换。随后人们发现这些雕刻品数量繁多，不便携带，于是就有了将它们装在泥盒子中的想法。但是盒子需要封口，也很麻烦，于是人们开始在盒子表面上刻下记号。这种记号刻在盒子上的行为与书写不同，书写源自雕刻，通常是在巨大的墙面上进行的牛耕式记录。而这些盒子上的记号则既有横向，又有纵向。而横向和纵向同时存在的情况就形成了表格。
这段历史表明，表格的出现与文字是分开发展的，即人们对数据的理解实际上是独立于语言的。由此可见，数据的第一性原则是脱离语言，甚至是脱离 IT 这门技术二存在的，因为 IT 技术的核心是编程语言，而数据的根源却是表格。这也就暗示着数据技术极有可能脱离信息技术的束缚，需要更多专门的研究与探索。
由此可见，数据的第一性原则，是脱离语言的存在，这产生了一个问题，即对于“数据的第一性原则”的思考，甚至要脱离 IT 这门技术，因为 IT 的核心是编程语言，而数据的发源地是表，本质是脱离语言范畴的。剖析到此处，我们悚然发现数据技术极有可能是脱离信息技术而独立存在的，这又是一个历史的误读。
前文中我们谈了很多实时数据湖成功的关键要素，但最基础的一点还是要回归到数据的本质——关注数据本身的属性，而不是被市面上各种各样的组件迷乱双眼，像是各种新兴的数据库、平台服务、实时架构等等。
但日光下无新鲜事，其实万变不离其宗，回到最后仍是数据的二象性问题，本质都是在回答数据的第一性原则是什么——答案要么是 message 信息，要么是规范化有 schema 的表。这就是我们对数据技术究其根本的理解。
实时数据湖的“实时性本质”：延迟的极限压缩
从今天的趋势上来看，很明显组织内部对于数据传输和处理能力的速度和准确性要求正在且将不断提升。
各部门之间的高效协同，将帮助组织在激烈的竞争环境中跑得更快。这种协同要求数据能够更快地传输并且准确无误。为了满足这个需求，计算性能和并发处理能力就显得尤为重要。
打个比方，数据传输在企业中扮演的角色与神经系统高度类似。就像生物进化的规律一样，神经系统的演化使得生物的反应速度越来越快。同样地，企业组织对数据同步速度的要求也只会不断增强。
首先，我们需要承认数据的延迟是由计算需求的逻辑复杂度决定的。而我们能做的，就是找到真正拥有强计算能力的数据同步工具，尽可能压缩这一延迟，从而在逻辑复杂度同等的情况下，能够以相对更快的速度完成任务。
未来，数据平台的时效性无疑将成为更大的焦点，时效性的提高是必然的，因为企业和组织永远存在于竞争之中，竞争推动着组织向前进化——各个功能之间越来越协调，各个部门间的反应延迟在缩小，数据传输效率客观上得到了提高。
不论是使用数据湖、数据仓库还是数据总线，最终都将顺应这一发展趋势，即企业部门之间的协同效率提高，数据的一致性和实时性也随之提高。这并非主观臆造的伪需求，而是企业发展的必然要求及时代环境共同推动产生的结果。在这样的背景下，数据中间件，尤其是高时效、高算力的数据中间的意义与价值也将愈加清晰。
作者介绍：徐智，数据架构专家，汽车行业工作 15 年，历经央企、外资科技、民企、高校各类组织的甲乙方角色，洞察数据技术的客观规律，掌握各技术流派肌理，能恰当的设计和实现组织需要的湖、仓、库、平台，并实际推进数据驱动业务、数字化转型、数据治理、人工智能大模型等前沿项目。
关于 TapData
TapData Inc.「深圳钛铂数据有限公司」，成立于 2019 年 9 月，核心员工来自 MongoDB、Oracle、百度等，研发人员占比超 80%，至今已获五源资本等多家头部风投数千万美元融资。已服务中国移动、中国联通、南方电网、中国一汽、中芯国际、周生生、富邦银行等数十家行业标杆企业。TapData 坚持“开放+开源”战略，推出 TapData Cloud，将无代码数据实时同步的能力以 SaaS 的形式免费开放，目前已积累 1,000+ 云版和企业版客户，覆盖金融、制造、零售、能源、政府等多个行业。此外，TapData 社区版也已发布，正在面向开发者逐步共享其核心功能。
TapData Live Data Platform 是一个以低延迟数据移动为核心优势构建的现代数据平台。企业可以用来实现核心数据系统之间的实时同步、实时交换及实时处理。当实时数据需求日益增多时，企业可以结合分布式存储，使用 TapData 将孤岛数据无缝集中到中央数据平台，为众多下游业务提供一站式的实时数据交换和发布服务。
产品优势：
开箱即用与低代码可视化操作
内置 100+ 数据连接器，稳定的实时采集和传输能力
秒级响应的数据实时计算能力
稳定易用的数据实时服务能力
【推荐阅读】
口腔专科医院实时数据中心：如何高效拆除数据烟囱，建立患者 360 视图，助力智慧医疗？
TapData 信创数据源 | 国产信创数据库 PolarDB MySQL 数据同步指南，加速国产化进程，推进自主创新建设
制造业数字化转型创新思路 |《数智新时代制造业数字化创新实践白皮书》上线！
Make Your Data on Tap 2021-04-23 加入
Tapdata 能够快速帮助企业快速打通数据孤岛，构建主数据服务平台，为业务提供统一、完整、实时的数据。现已上线永久免费的异构数据库同步工具cloud.tapdata.net ，支持主流数据库间的双向实时同步。
评论