探迹×云器Lakehouse：重塑数据架构，实现全域数据低成本实时洞察

探迹科技是智能销售SaaS开创者，基于1.8亿+市场主体的全量数据信息形成知识图谱，为企业提供从线索挖掘、商机触达、客户管理到成单分析的全流程智能销售服务，帮助企业高效获取精准销售线索，降低获客成本。探迹通过将数据进行超大规模的处理、分析，并通过结合大模型、NLP、机器学习算法等人工智能技术，产生为客户提供智能信息服务，是以数据产生核心竞争力的杰出代表性企业。

2016年成立至今，先后荣获"专精特新"、"高精尖"、"高科技高成长企业"及"全球独角兽"等荣誉，服务客户超过30000家，其中包括阿里巴巴、微软、亚马逊、戴尔等行业巨头。

• 数据处理是探迹销售云的核心竞争力

• 数据驱动的智能销售SaaS平台

探迹科技的销售云服务，是构建在强大的数据处理能力之上的。核心竞争力在于能够处理和分析海量数据，为企业提供深度洞察和价值信息服务。

• B2B 数据即服务：经过精细处理，能够为客户提供实时、准确的信息服务。平台能够从海量数据中提取有价值的信息，帮助企业在B2B市场中做出明智的决策。
  
  
• 数据时效性愈加重要：在快速变化的商业环境中，数据的时效性对于企业来说至关重要。客户需要最新的数据和经过深度加工的信息分析结果，以便迅速作出行动和决策。

2.1 架构现状

这套数据架构采用离线实时混合处理的设计思路（Lambda架构）：

1. 离线链路处理全量数据+完整逻辑

   基于Spark进行天/周/月级别的全量计算，完整实现复杂的业务逻辑，结果存储于OSS以确保数据完整性。

   
   

2. 实时链路处理核心增量数据+精简逻辑增量

   针对增量数据，通过python开发加工任务，处理部分核心数据 + 精简业务逻辑，实现分钟级延迟。

   
   

3. 数据出问题可以进行局部幂等重算覆盖

   出现数据异常后可以局部重新计算异常数据并更新到线上。

   
   

4. 应用层查询时结合增量数据和全量数据实时合并提供更新结果

   实时链路的增量数据分钟级更新到线上增量表中；

   离线加工数据定期更新到线上离线表中，更新周期包括天/周/月级；

   增量数据和离线数据合并后对生产提供服务。

   
   

5. 数据有版本概念，离线数据发布时，通过MongoDB 主备切换实现数据版本发布。

2.2 架构痛点分析

前面的架构体系，灵活支撑了早期的业务快速发展，但随着业务的快速发展，数据量越来越大，业务加工逻辑越来越复杂，业务对数据时效性要求越来越高，数据质量要求越来越高，当前这种数据处理架构越来越面临处理瓶颈和挑战，具体如下：

挑战一：同一业务，两份代码，带来数据不一致问题

1. 同一个业务，离线处理全量的数据 + 全量的业务逻辑，实时链路处理部分核心数据+精简后的逻辑，数据和逻辑的差异必然带来数据的不一致问题。
   
   
2. 为了减少数据不一致问题的影响，只能定期刷新离线全量加工后的结果到线上，刷新周期包括天级，周级，月级(一月一次)，但这只能缓解不一致问题，无法根治。

1. 双链路架构都有自己的运维方式，开发方式和使用方式，从而增加了运维成本和学习成本。
   
   
2. 双链路架构下，增量的合并，离线数据的发布等相关工作量巨大。

1. 探迹的业务场景是大规模数据量的高频更新，同时业务逻辑计算非常复杂，有限的资源无法满足全部数据+全部业务转化为实时加工，否则成本无法承受。
   
   
2. 业务的高速发展，对数据的整体质量和时效性都提出了更高的要求，部分数据实时无法满足业务快速发展的需求。
   
   

2.3 改造目标

面向以上的痛点问题进行详细分析后，我们首先定义做这次技术改造的目标如下：

• 目标一：两套代码维护升级为一套代码，减少维护成本，同时解决数据不一致问题。
  
  
• 目标二：部分数据+部分逻辑实时，升级为全量数据+完整逻辑实时。
  
  
• 目标三：时效性提升后整体成本可控。
  
  
• 目标四：人肉排查升级为工具/产品化排查方式。

整个调研过程持续1年多的时间，没有找到好的解决方案，直到听了云器的产品发布会，了解到增量计算技术，云器在做基于增量计算的流批一体方案，和我们探索的流批一体方向思路一致，所以云器的产品发布后我们做了POC验证，效果不错，就将一个完整的加工链路上了生产。

3.1 新架构解决方案

方案说明：

• 将原有离线+实时Lambda架构升级为流批一体Kappa架构。
  
  
• 把Spark + OSS + Python + EMR + 调度系统等组件替换为云器 Lakehouse 一体化平台。
  
  
• 基于云器Lakehouse增量计算实现整个数据链路实时加工。
  
  
• 加工后的结果数据实时导出给业务系统应用，直接就是完整数据，无需合并。

云器Lakehouse 平台是新一代的湖仓一体产品，核心基于Single-Engine的理念，统一了批、流、交互式分析多种负载，既能支持结构化数据处理分析，也能和AI能力结合，支持对非结构化进行管理和分；本次在探迹场景下，主要应用了以下几个技术特点：

技术一：基于动态表实现了离线链路与实时链路的代码级别统一

• 基于云器 Lakehouse 的动态表(支持增量计算)不再需要开发两套加工逻辑，只需要将离线复杂、完整的加工逻辑改造为增量计算任务，统一成一套完整逻辑，满足了实时性，也保障了数据的完整性。
  
  
• 云器的增量计算支持复杂关联分析以及任务分区逻辑，增量表不止可以全量或者增量更新，也可实现分区级别的异步刷新，同时支持历史分区数据通过 DML 语句插回到增量任务，大大方便了任务的改造开发。
  
  
• GENERAL PURPOSE通用增量处理解决方案，具备最广泛的适应性，支持最广泛的算子，进而实现复杂业务逻辑增量化，包括多流join/UDF/窗口函数等复杂的场景。

技术二：低成本实时加工

• 基于云器 Lakehosue 的增量计算技术 + 顶级引擎性能 + 资源极致弹性等关键技术，实现全域数据实时加工的同时，极大降低了计算成本。

• 基于云器 Lakehosue 的增量计算任务允许我们根据业务需求灵活设置数据新鲜度，无需修改代码，只通过调整调度周期，即可实现数据及时性的精准控制。数据新鲜度降低的同时，成本线性降低。

• 云器 Lakehouse Table 的 Time Travel功能可以让我们像时间旅行一样访问时间窗口中的任何时间点的数据，包括已更新或删除的数据、恢复已删除的表或恢复已过期的表。通过Time Travel，可以轻松查看历史版本数据，恢复历史数据。
• 查看版本信息: DESCRIBE HISTORY Table。
• 支持数据一键回滚：RESTORE TABLE table_name TO time_travel_version。
• 支持获取delta数据：table_changes。

4.1 迁移完成后的效果总结

4.2 落地效果细节展示

4.2.1 简化了数据架构，离线+实时两条链路升级为一条实时链路

• 离线+实时两条链路升级为云器Lakehouse上的一条实时链路，只有一份代码，处理完整数据+完整逻辑
• 一份代码从根上解决了数据不一致问题
  
  
• 新的架构里MongoDB CDC数据实时同步到云器Lakehouse，云器Lakehouse获取增量数据进行实时加工
  
  
• 整个Pipeline加工后的结果，以CDC数据方式导出，给到下游应用

• 基于同样的业务场景，同样的输入，得到同样的结果，对比两边资源消耗
  
  
• 云器 Lakehouse资源消耗降低18倍，离线全量执行资源消耗革命性降低
  
  
• 注：1 CRU = 8 core 32 G 内存用1小时

4.2.3 数据一致性与准确性的双重保障

• 复杂业务逻辑不精简情况下实现无损的增量计算：包括支持10+表的Join，UDF等，最终实现全量数据 + 完整逻辑的增量计算加工链路，数据时效性提升的同时，保证了数据的准确性。

4.2.4 数据新鲜度与成本的精益平衡

• 我们能够灵活平衡成本和数据新鲜度的诉求，最低可以设置1分钟的数据更新间隔，确保业务决策始终基于最新数据。

4.2.5 问题排查与数据恢复的便捷性

• 每张表的变化都有历史记录：DESC HISTORY birds
  
  
• 可以查询任何一个历史时间点的数据：SELECT * FROM birds TIMESTAMP AS OF '2024-10-14 01:26:29.644'
  
  
• 删除数据后也可一键恢复数据：RESTORE TABLE birds TO TIMESTAMP AS OF '2024-10-14 01:26:29.644'

综上，这些落地效果基本解决了探迹核心的痛点问题，Lambda架构升级为Kappa架构，保证数据时效性的同时也解决了数据不一致问题，解决了多套代码维护成本高的问题等等，为探迹后续业务的快速发展打好了一个坚实的基础。