导读 相较于传统的数据仓库和数据湖，Lakehouse 融合了二者的优势，既保留了数据湖的灵活性和可扩展性，又具备了数据仓库的查询性能和治理能力。销售易作为一家 SaaS CRM 厂商，正是基于 Lakehouse 来支撑整个产品线的实时分析，不断提升用户的数据体验。本文将分享销售易利用 Lakehouse 实现数据智能应用的实践。
主要包含以下内容：1. 数据特点
2. 数据智能应用
3. 问题/瓶颈
4. Lakehouse 实践
5. 问答环节
分享嘉宾｜罗义 销售易 技术副总裁
编辑整理｜刘明城
内容校对｜李瑶
出品社区｜DataFun
数据特点
销售易是一家以 CRM 产品为主的 SaaS 公司，提供元数据驱动的多租户 SaaS 平台。我们所面对的挑战主要包括：销售易自创业至今已经有 13 年时间，租户数量非常庞大，已经超过 20 万。其中包括最核心的数千家企业级租户，涵盖了一些世界 500 强的大型企业，还有许多长尾的免费租户。随着业务的增长，租户数量包括大客户的数量都在持续增加，因此数据量也在不断增长。CRM 虽然主要面向企业，但已由企业内部的销售管理，延展到企业与其客户之间的连接和互动，所以也会有越来越多面向客户的高并发的场景。在不同行业中，销售管理的流程和场景都会有所不同，所以 CRM 系统面对的需求是多样化的。从另一个角度来看，今天的CRM 已经不再仅仅是传统的销售管理，它已经扩展到了营销和服务领域。因此，企业需要处理客户运营和客户管理的整个过程和场景，即全流程全场景的范围。在不同行业和不同场景下，对于数据的 CRUD 操作（创建、读取、更新、删除）的模式都存在较大差异。此外，还会面对丰富的搜索和数据分析场景。动态 schema，意味着我们的系统并不直接针对数据库进行操作，在架构上不存在 DDL（数据定义语言）。同时，能够实现无缝、无感知的系统升级，这使得客户的业务能够持续运行，而无需停机。对于 SaaS 服务来说，性能和稳定性是立足之本。销售易作为多租户 SaaS 的形式，在数据层面，大部分中型和长尾客户都是共享租户，意味着它们共享同一个数据库，而非每个租户都有独立的数据库实例。对于一些大型头部客户，则可以独享数据库实例。复杂权限管理是发展过程中始终面临的一项巨大挑战，因为 CRM 系统管理的是企业最核心的资产——客户数据，所以企业对于这些客户数据无论在业务层面还是数据层面的权限都有着非常严格的要求。特别是对于一些大型集团客户来说，他们在数据权限的管控上面临极大的复杂性。另一个挑战在于，特别是在国内，企业利用社交手段不断提升与客户之间的协同互动效率，这就会引入许多社交场景，如何在这些社交场景下精细化地管理数据权限也是一个挑战。
针对这些挑战，我们构建了一个支持多租户的数据平台。其最主要特点是资源共享，无论是在应用层还是数据层，最基本的原则就是租户平权。然而，随着业务的不断深化，我们为越来越多的大客户提供服务，在租户平权的基础上，我们需要考虑如何优先满足大客户的需求，确保其业务连续性不受影响。在我们的平台中，对于大客户，支持独立的数据库实例，并在共享存储的基础上实现。我们将面向业务的传统数据库称为业务对象或业务实体，并统一元数据化。作为 SaaS 应用，我们有标准的业务实体，比如 CRM 领域最常见的客户、联系人、商机、订单等。同时，也允许租户根据业务需要自定义实体元素，以支持个性化需求。比如，汽车行业的客户为车主，同时也可以在标准实体上定义扩展字段。我们采用多种存储模式，主要存储在 SQL 关系数据库中，同时使用缓存来减轻数据库压力。在搜索场景下，我们基于 Elasticsearch 构建了索引。除此之外，在过去的六七年间，我们一直在基于 Greenplum 构建数据仓库，以支持数据分析场景。对每个客户而言，我们实际上呈现的是一个虚拟数据库。客户看到的是一个数据库，但在物理上是多个租户共享的数据库实例和物理表。因此，有一个虚拟到物理的映射关系。在面对众多租户和海量数据的情况下，尤其在高并发场景中，我们采用分库分表和数据分片来处理数据。确保避免特别小的租户对系统稳定性造成问题。在处理基于元数据的物理存储时，面临的挑战之一是索引，针对宽表，不能简单地为所有列建立索引，因为每个租户的使用场景不同。去年将业务数据库从 MySQL 迁移到了 PostgreSQL，因为 PostgreSQL 能克服列数限制，执行动态分区，并基于分区建立索引。这允许为每个租户创建动态分区，并根据业务需求构建特定索引，以支持不同租户的需求。这些操作包含在查询计划和优化解决方案中。基于上述解决方案，我们构建了一个支持系统负载并满足不同租户灵活性要求的数据平台。2. 数据架构
我们构建了各种业务场景的产品，包括营销、销售以及服务等场景。这些应用与数据交互时，必须通过统一的数据服务进行，而非直接操作数据库表，因为这些都是宽表。在数据服务中，提供了实体元数据的管理和解析，以及表数据的存取。此外，对于业务对象和业务实体的验证和计算，以及日志和开放集成，提供了基于类 SQL 查询和基于搜索的 API。这些核心逻辑包含在数据服务中，并提供给我们的业务应用。此外，我们还从另一个角度提供了一系列数据管理能力。在底层数据存储方面，主体的业务数据已升级至 PostgreSQL，部分项目的元数据仍存储在 MySQL 中。缓存使用 Redis，并引用了 Elasticsearch。由于我们采用多云架构，涉及腾讯云、亚马逊云和华为云，因此会使用 S3 和 OSS。对于私有云客户，其中大多数客户使用阿里云的 OSS。此外，我们还使用一些配套的中间件，包括分库分表中使用的 MyCAT，以及消息中间件等。3. 虚拟数据库：实体界面 + 共享存储 + 租户隔离
基于以上数据架构，接下来深入探讨一下如何实现元数据驱动的多租户数据存取。从一个租户的角度来看，他所管理的业务实体，包括线索、商机、客户、订单、合同以及回款等，实际上面对的是一个虚拟数据库，要对其数据进行存取操作，是通过之前提到的数据服务。在底层，数据实际上存储在关系数据库中，包括索引表辅助表，用来描述租户的业务实体及其数据结构的元数据表，以及真正存储实体数据的实体主数据表（宽表）。4. 虚拟数据库：实体元数据
基于元数据，我们可执行多种操作，可定义字段格式和业务类型，例如个人业务类型或企业业务类型，不同类型对应的字段不同，展示时页面布局也可不同。业务实体间有各种关系，如主从关系、一对多、多对一及多态关联等。针对业务实体字段可进行查重校验，并支持自定义计算型字段，如基于一些公式自动填充字段值。5. 虚拟数据库：支持多租户的实体表结构
针对多租户实体表结构的支持，包括元数据表、索引表和实体主数据表。其中索引表是辅助表，用于管理不同租户的索引。实体主数据表是一个宽表，在元数据表中记录着某个字段存储在哪张主数据表的哪个字段上。这样，在业务应用层直接基于业务实体进行操作时，底层会映射到相应的宽表和字段上。这样做的好处在于，可以实现对租户无感知的升级。元数据的定义和底层实体数据的升级完全解耦，解决了许多 SaaS 应用所担心的升级时需要修改业务对象逻辑和关系的问题。目前行业中的主流 SaaS 平台基本上都是采用这种数据架构来支撑其业务。数据智能应用
接下来介绍销售易所提供的数据智能应用。其中使用最广泛、最高频的一个应用是我们自研的一体化 BI，其主要特点包括：首先，它是实时的，所有业务数据都能够实时地进入我们的数据仓库，提供给 BI 进行实时分析。其次，它是敏捷的，即 BI 可以直接面向业务人员，他们可以方便地定义出符合其关注点的数据报表或分析场景。为了实现“人人 BI”，需要严格控制数据权限，BI 与业务平台的数据权限无缝对接，以确保每个用户只能看到其权限范围内的数据。当然，BI也可以通过一些特殊配置来突破这一限制，但默认情况下它与我们的业务平台的权限是融合在一起的。1. 销售易数据智能产品概览
上图是销售易数据智能产品的概览图。首先，实现数据仓库与业务平台数据的实时同步。其次，实现了全员 BI，统一数据权限保障，以确保每位员工只能访问其权限范围内的数据。此外，在定义数据源或数据集时，并非直接面向底层的实体主数据宽表，而是基于业务元数据进行操作，因此更加贴近业务，操作非常简单。最后，我们的嵌入式 BI 可以嵌入到 CRM 各个业务场景相关页面中。我们拥有统一的组件，并且在嵌入过程中同样具备一套统一的数据权限保障。在过去的两年中，我们还引入了一系列 AI 产品，包括基于机器学习的线索商机客户评分和为销售提供最佳行动建议等场景。去年开始，我们也在着力开发基于大模型的产品能力，其中已经商业化的客服机器人就是一款代表性的产品。2. BI 架构
上图展示了我们提供数据分析能力的商业智能（BI）架构。其中包括一个数据同步的中间件，早期使用了国内的一家名为"Data Pipeline"的 ETL 工具，但自去年开始，全面切换为自研的工具。自研工具的优势在于系统定制度较高，能够轻松实现数据同步，并保证数据的时效性和新鲜度。我们的自研数据同步工具基本上可以在 15 分钟之内将业务库的数据同步到数仓，在大部分情况下甚至可以实现毫秒级的同步速度。数据仓库基于 Greenplum，其中包含相应的 BI 能力。特别要提及的是我们的解析引擎，因为数据集的定义是基于实体元数据的，而在 BI 上定义的视图和分析也是基于这些实体元数据的数据集。因此，对于数仓的任何查询，都需要通过解析引擎将其转化成对应数仓中宽表的查询，因此解析引擎尤为重要。另外，我们还需要自动地将相应权限的 CP 片段添加到查询中，以确保当前用户只能查看和分析其具备权限的数据。问题/瓶颈
在过去的六年中，公司的 BI 产品遇到了一些挑战和瓶颈。首先，因为没有专门进行数仓建模，而是直接将业务数据库的架构同步到数据仓库中，系统面临着频繁的架构演变。目前，拥有大约 8000 张数据库表，权限控制非常复杂。同时，公司希望实现亚秒级的交互式查询。基于这些特点和要求，六年前我们选择了 Greenplum 作为数仓平台，这在当时是一个明智的选择，但随着服务对象扩展至越来越多的世界 500 强等大客户，用户对数据分析工具和 BI 有更高要求，这对 Greenplum 的扩容成本也提出了挑战。此外，CRM 系统中引入了更多客户互动的场景后，数据越来越多元化，对结构化、半结构化数据和文档数据的处理需求增加。随着 AIGC 的兴起，公司也在积极跟进 AI 和大模型的发展，并正在将其商业化，如何让 AI 能够更便捷地消费数据也成为了需要解决的一个重要课题。基于上述背景，我们考虑要升级数据平台。Lakehouse 实践
1. 我们需要新一代数据平台来解决这些问题
数据集成和开放性
我们核心目标是以较低成本实现对 CRM 平台业务数据即插即用的集成。由于我们的产品是一体化的，集成过程中的 ETL（抽取、转换、加载）非常关键，新的平台要能够提供便捷的工具，来处理传统 CRM 业务数据以及行为数据和非结构化数据。
实时计算。
通过我们自行开发的数据集成同步工具，可以确保大部分情况下达到毫秒级的准时式同步，使数据具有实时性和新鲜度，从而支持实时计算和分析。
批、流、交互一体
针对大客户的外部批量数据同步以及交互式查询和分析，我们希望尽量将批处理、流处理和交互式查询与分析一体化，以降低整个链路的复杂度。
AI 友好性
我们期望新一代数据平台能更好地支持我们的产品在 AI 领域的持续发展。
因此，我们选择了云原生的 Lakehouse 作为新一代数据平台的基座，以构建我们的数据应用和 AI 应用。在进行长时间的分析和调研后，我们认识到云原生 Lakehouse 的诸多优势，例如它符合标准并且基于 SQL 兼容，同时可以解决 Greenplum 弹性伸缩的问题，因此它是一个企业级系统的理想支撑。2. 从 Greenplum 到 Lakehouse – 验证
在选定 Lakehouse 之后，我们首先进行了验证。我们使用一些尽可能模拟线上规模和多样性的脱敏数据，验证了 Lakehouse 的交互式查询能力，发现其表现非常出色。此外，它还具有灵活的弹性扩缩容能力。我们将一个端口相当于一个集群，在腾讯云、AWS 或者华为云上运行这些集群，为不同的客户提供服务。在 BI 场景下，单一集群 QPS 能够达到 150，而单一 SQL 查询的最长响应时间不超过四秒。当然，在处理大规模数据时，还是需要进行数据建模，但在绝大多数情况下，我们可以满足这些指标。在此基础上，我们重点关注如何高效支持数据集成。我们模拟了生产环境下的 8000 张表，并对 schema evolution 下数据变更的实施同步性进行了验证。在日常场景中，最高延时不超过五分钟，大部分数据都能在亚秒内同步。我们通过 Lakehouse 提供的线上数据对比工具持续观察和验证数据的一致性，实现了 100% 的数据一致性。3. 从 Greenplum 到 Lakehouse – 切换
在验证完成后，我们进行了实际的切换。在此分享切换过程中的几个关键点。首先，我们使用云原生 Lakehouse 平台，但实际上使用的是自己的存储，比如在 AWS 上，使用的是销售易自己的 S3 账号来存储客户数据。这一点非常重要，因为如果将数据存储在客户不知情或未授权的地方，会带来巨大的安全风险。特别是对于面向头部客户提供 SaaS 解决方案的企业来说，这一点至关重要。其次，我们进行了数据集成验证，包括语法验证和修正，以及压力测试。测试通过后再进行应用切换，并确保稳定运行。我们从双写数据开始，按租户切换并观察，经历了相当长的时间来保证无缝切换。截止目前，我们基本完成了国内腾讯云的北京和广州，以及正在进行的 AWS 北京所有集群的切换，国内几乎所有客户都能够使用基于 Lakehouse 的数据分析平台。4. Lakehouse 为我们带来的价值
Lakehouse 所带来的巨大价值主要体现在以下几个方面：首先，基于其原生提供的实时数据同步能力，我们重构了原本自研的数据同步工具，实现了数据实时性的大幅提升，从原先的 15 分钟到现在的五分钟，绝大部分数据的时效性基本达到了亚秒级。另外，实时计算能力提升了 30% 以上。我们终于能够逐步放开原先 BI 度量、数据导出等限制。特别是对于中大型的业务复杂的客户，我们更有信心去支持复杂场景的使用，因为在 Lakehouse 上，可以非常灵活地进行计算资源的快速扩缩容。同时，随着越来越多 AI 应用的构建，我们也更有信心地将 CRM 里传统的结构化数据，以及行为类半结构化数据和文档类数据都纳入管理范围。这为我们带来了更广泛的数据管控和应用拓展的可能性。问答环节
Q1：租户管理是在宽表里添加租户 ID 来实现吗？A1：是的，租户管理通常在宽表中通过添加租户 ID 来实现。在宽表中肯定会包含租户 ID，因为每个租户都有其自己的原始数据。原始数据分层中会包括通用标准的原始数据，比如商机和客户等，但每个租户也会有其特定的原始数据，比如汽车租户可能会有车主等。因此，在实体原数据表中也会包含租户 ID 以便进行租户管理。A2：动态 schema 相对来说比较简单。首先，我们有一个原数据表，这个表里面定义了你的业务实体，以及底层真正承载这个业务数据的宽表之间的关系。在所有的业务应用层，对于所有的数据操作都是基于原数据进行的。当到达数据库层时，它会将这些操作转化成真正针对业务组数据表的操作，因此中间实际上存在这样一种转化关系。A3：对于数据同步，是基于实时流进行的，我们使用了数据库 CDC 来进行采集。Lake House 本身提供了基于实时流的功能，我理解它底层可能使用了类似 Flink 这样的工具，通过数据库的 CDC 进行数据变更的捕获。Q4：数据量支持亿级别维度下钻，上卷有更好的解决方案吗？A4：这是一个很好的问题。目前来看，如果只是维度的下钻，且当前视图的查询没有问题的话，通常下钻到下一个维度可能问题也不大。当然，从另一个角度来看，基于 cube 的一些方案可能在处理实际复杂问题的情况下会更为合适。Q5：Greenplum 和 Lakehouse 的兼容性怎么样？迁移有困难吗？A5：我认为兼容性可以从两个层面来看。第一个层面是数据如何无缝地从数据仓库到 Lakehouse 迁移，这实际上相对比较简单，因为我们的业务数据源在业务数据库中。所以通过全量和增量的方式，在一定的时间内就能够将数据同步到 Lakehouse，因此这个问题相对来说比较容易解决。另一个层面是在查询分析场景中语法的兼容性。目前像我们与云器的合作，基本上在绝大部分场景下都能够做到无缝兼容，只是在少数情况下，比如时间函数等方面，我们也将马上进行一些兼容性处理。
分享嘉宾
INTRODUCTION
罗义
销售易
技术副总裁
罗义，武汉大学计算机本硕，曾任 IBM 中国开发中心电商平台首席架构师、Autodesk 家装数字化 SaaS 平台 Homestyler 首席技术专家、企加云联合创始人兼 CTO，自 2021 年 1 月加入销售易任技术副总裁，负责营销云、伙伴云、协同平台、BI、数据平台等产品的产研工作。
点个在看你最好看
SPRING HAS ARRIVED