导读： 本文将介绍过去15年中，网易大数据团队在应对不断涌现的新需求、新痛点的过程中，逐渐形成的一套逻辑数据湖落地方法。内容分为五部分：
- 关于网易数帆
- 为什么做逻辑数据湖
- 怎么做逻辑数据湖
- 未来规划
- 精彩问答
--
01 关于网易数帆网易数帆是从网易杭州研究院孵化出来的。网易杭研的重要职责是公共技术的研究和产品孵化。下图是网易数帆的整体产品架构。
网易是国内领先的互联网技术公司，从2006年就开始对大数据相关技术进行探索。2009年为了支撑网易博客等产品的海量数据，开始了分布式文件系统、分库分表中间件（网易DDB）等技术的研发，并且于当年引入了Hadoop进行探索。2014年到2017年，网易对大数据平台的建设在内部取得了良好效果，同时发现业界存在普遍相似痛点，于是开始对外做商业化尝试。2018年支持网易严选、考拉、音乐、新闻数据中台构建。通过在商业化过程对市场需求的摸索实践，终于在2019年形成了“全链路数据中台”解决方案，致力于将“数据生产力”的理念能力落实到解决方案中。
纵观网易大数据的发展历史，可以看到这个过程中贯穿了数据理念的变化。有数从公共数据平台逐渐转变为具备有业务属性的数据中台，最后逐步向“数据生产力”理念靠拢。在这个理念下，会要求我们要不断贴近用户、了解用户实际情况，做到第一时间提供更好的服务。同时在服务用户的过程中，为了给用户提供更多价值交付，逻辑数据湖的产生是必然的。这个过程从技术发展角度看，也伴随着湖仓一体的探索和落地。
2. 业务支撑情况介绍
上图最上层是网易有数对公司内外提供的业务支撑情况。网易有数的技术能力通过一套方法论、一个工具平台和公共数据建设三部分对上层输出整体的价值。同时在落地过程中，形成了技术业务双循环的模式。双循环中涉及三个角色，两种驱动力。三方分别是内部用户、外部用户、数据中台；业务场景、技术前瞻是推动双循环的驱动力。这两种驱动缺一不可：大数据技术和应用发展日新月异，数据中台的业务支撑能力特别依赖于底层的技术能力和前瞻性。
--
02 为什么做逻辑数据湖 1. 数据生产力不足的问题网易有数最早想要提升数据生产力是从建设数据开发平台开始的。在建设使用过程中暴露出各种问题导致了数据生产力不足：
在梳理了数据开发平台碰到的问题之后，我们开始思考问题的根本原因是什么。最终结论就是：这不仅是一个技术问题，更是产品体系问题。我们缺少一套贴近需求的数据产品力体系。这也是业内的数据平台在业务支撑中的普遍问题。
所以我们重新打造了我们的产品体系来保证整个数据应用的生产力落地，第三部分会展开来讲我们如何通过构建逻辑数据湖来支撑这套产品力的落地。
最近十几年大数据相关技术的发展主要是基于开源的技术构建，我们团队也以主动积极的态度看待开源，争取回馈社区。我们积极培养技术专家，参与社区建设，输出技术贡献；这些帮助我们夯实了大数据的底座。
4. 数据生产力方法论
数据生产力建设的方法论，我们从上图的三个维度来表达。首先是算，让数据研发足够敏捷保证工程效率和质量；其次是管，让不同类型不同来源的数据融合，统一抽象对外表达；最后是用，做到低门槛，用户不需要关心底层的情况，这很符合用户的使用场景。
5. 数据生产力提升成果
除了在技术指标层面的成果衡量，数据生产力建设在业务系统中也体现了巨大的价值。上图是浙江卫视对我们在电商业务数据生产力提升的成果报道：切实提升了业务运转效率并且产生了良好的社会和经济价值。
7. 产品核心优势
有数产品的核心优势从方法论开始，对于复杂的产品系统建设，理论先行。基于生产力方法论我们建设了完整度很高的产品体系；产品同时具备良好的兼容性；基于开源技术体系做到了支持跨云部署。
8. 企业用户的灵魂拷问
开始商业化后，有数在调研外部用户需求的过程中，经常会碰到上图中的三个重要问题。
这个三个问题都非常实际，因为相比传统的IT系统，大数据体系的技术架构还是要复杂一些的。
第一个问题是对业务的担心，技术是对业务的支持，每个企业用户的技术建设情况不同，业务复杂度也不一，很多传统企业已有的IT系统已运行了很多年，只是无法再支持日益增长的数据需求，他们在大数据技术体系的经验几乎空白，当面对一个比如lambda架构的大数据解决方案时，往往会觉得过于复杂和难以掌握，对落地成效心存疑虑。还有部分用户的业务在现有技术框架上（比如MPP）运行良好，出于对未来发展的前瞻性考虑，需要提前进行大数据的基础技术建设，这部分用户对于大数据未来的必要性是肯定的，但是会特别关心其适用的场景、业务覆盖度以及如何平滑地进行业务的迁移。在我们与用户的合作中，有很多行业标杆用户，通过帮助标杆用户建设数据平台过程，我们也逐渐积累了很多行业经验，在和后续其他用户的合作中通过组织培训和实施的方式和客户一起把方案落地，但是这个过程需要一定的成本，并且需要逐步给用户信心。
第二个问题也是用户非常关心的问题。再优秀的系统，也都是需要运维的，对于用户而言他们非常关心数据平台能否自主运维（至少能参与基础的运维），一方面这个是企业内部的硬性要求，一方面私有化部署模式下这也是一种良好的合作共建模式（特别是某些环境是闭网部署）。这个问题就涉及到：系统整体复杂度、运行状态透明程度、以及运维团队是否好组建等多个维度的考量。对于运维，网易内部有多年的经验沉淀，总结了丰富的培训教材，同时也开发了便捷的运维工具，通过分享和培训，基本能够让用户进行基础的运维操作，但是总体而言用户还是需要有一个学习的时间成本，很多情况下用户已有的运维团队对于老系统已经积累了很多经验，技术架构一刀切的方式对原有团队稳定性的冲击也比较大。
第三个问题来自于这部分用户：他们看中的是解决方案中的产品体系。有数的产品功能能够解决他们在数据工具、数据管理和数据赋能上的痛点。但是并非一定需要Hadoop数据底座，产品功能和底层集群不需要强绑定。这也是我们做逻辑数据湖的重要出发点之一，满足更多类型用户的实际需要。
以上的这三个问题，都可以通过逻辑数据湖的技术方案来解决。
上图是一个常见的实时数仓解决方案，在互联网公司应该是非常常见的。这样的架构明显的特点就是：
组件多：多种数据源、CDC、消息队列、实时计算框架、存储系统、Adhoc查询系统等等；
链路长：从数据源到最后数据结果产出，至少需要3-4个步骤；
技术专：每个组件都可以有专门的团队来研究运维。
得益于大厂完善的基础建设、业务量级以及人员储备，这样的模式还能相对顺畅得运行，但是对于一般性的传统企业而言，学习和运维压力还是非常大的，哪怕是随着湖仓一体技术的发展，整体的架构可以持续简化，也难免心生敬畏，因此在必要的场景采用必要的技术，是对用户的一种负责。
9. 为什么要做逻辑数据湖
以上是我们在调研企业用户数字化转型中，对相当比例用户痛点的总结。在实现数字化转型的过程中，数据湖&Hadoop解决的是数据统一汇聚的问题，而统一元数据则是解决数据连接、资产、管理的问题，对于相当部分的用户而言，当前最大的痛点不是海量数据的存储，而是如何将散落到各个子数据系统的数据孤岛统一管控起来。因此通过构建一个逻辑层面的数据湖，实现统一的元数据+分散的物理存储，避免不必要的物理数据入仓（湖），从而将产品上层功能比如主题域构建、数据地图等等及早给用户使用才是解决问题的根本之道，逻辑数据湖方案，依然可以使用物理湖&Hadoop，同时提供通过虚拟表直连数据源的方案将其他类型的数据源也纳入平台的管控中，用户可以根据实际的需要选择适合的存储方案，把选择权还给用户。
10. 网易有数产品特色
以上是网易有数的十大产品特色能力，其中“流批一体&湖仓一体“对标的就是Lakehouse，而逻辑数据湖的目标是让其他8个产品能力跑在不同的数据源上，实现中台数据治理能力和底层存储架构的解耦，让即使使用传统数仓技术的用户也能享受到数据生产力的福利。
--
03 怎么做逻辑数据湖 1. 逻辑数据湖构建方法论关于如何构建逻辑数据湖，我们的构建方法论主要分为如下三个大的层面：
数据源支持类型：除了Hadoop（Hive）体系，MPP、RDMS、HTAP、KV、MQ等都需要支持，并且一视同仁，都可以作为具体逻辑数据湖具体对象的物理存储。
统一数据源 & 统一元数据：统一数据源要做的是规范每种数据源的登记注册，包括数据源URL格式、数据源Owner、唯一性校验、账号映射、联通性校验、支持的版本、特定的参数等；统一元数据，则是将数据源的技术（物理）元信息和业务元信息进行关联，提供统一的查询修改接口。
统一数据开发、治理和查询分析：这三个属于构建在统一元数据&数据源基础之上的应用层。统一的数据开发，包括不同物理数据源之间的交换、离线&实时开发、同源&跨源查询；统一的数据治理，则包括数据主题建设、权限管控、数据生命周期、资产地图等；统一查询分析，则是在完成数据主题建设、数据开发产出以后，提供同源&跨源的模型分析能力。
上图中最底层就是各种类型的数据源，通过统一元数据和统一数据源层，完成上层应用和资源层的解耦。对上层提供统一的计算、管理、应用的功能。上述这些就是我们构建逻辑数据湖的方法论。
2. 统一元数据
根据上一节讲到的逻辑数据湖构建方法论，第一要务是构建统一元数据。统一元数据，也可以叫做元数据中心，其实无论是物理湖，还是逻辑湖，都需要这么一个元数据中心的组件来统一管控湖中所有对象元信息。他的功能有点类似HMS，但是在业务维度和数据规模上会比单一的HMS大很多，因此在存储设计上可扩展性需要重点考虑。元数据中心组件主要有如下几个核心功能：
(1) 数据源信息的管理
负责存储各类数据源的接入登记信息，进行统一的合法性、连通性校验，确保数据源的可用性。除了支持传输的数据源，还需要支持API网关等。
(2) 元模型的设计，主要有3点：
a) 抽象设计通用的数据对象描述meta-schema（比如catalog-db-table类似的三元组），meta-schema除了要考虑基础的物理对象信息以外，还需要考虑业务层面比如同catalog有多环境的场景；其次要将不同的类型的数据源schema拟合映射到meta-schema中，需要注意的是不同的数据源，即使是相同的名词其逻辑概念会有很大不同，比如Database这个名词，在MySql和Oracle的实际作用就完全不同（Oracle是通过User/Schema来划分数据库对象的逻辑归属），某些Newsql系统也有类似的问题，这些细节都需要处理好。
b) 流表的构建，主要针对一些schema free的数据源，比如MQ、KV系统等。这些数据源缺乏结构化的消息体描述，但是在实时计算等场景却有重要的作用，我们在原有的数据对象（比如Topic）上创建流表，一方面可以让数据开发一目了然地知道消息体的详细格式，一方面也为数据开发SQL化奠定了基础。对于流表除了schema以外，还需要提供权限控制，避免数据污染。
c) 统一的字段字典和转换，不同的数据源系统支持的字段类型集合各不相同，元数据中心定义了一套字段类型字典以及各数据源字段类型的转换逻辑，对上层应用提供统一的类型转换支持。比如在数据传输的场景下，传输工具根据推荐的转换规则进行跨源的数据传导。在后续实现物理湖数据统一汇聚的场景下，湖中数据需要做到原始高保真，统一的类型字典&转换规则也是必须的。
(3) 元信息的连接管理
a) 数据源技术（物理）元信息的定期抽取。定期同步各个物理数据源的元信息，用于做快照管理、地图、IDE开发推荐等，可以做到多存储系统，需要考虑海量数据的场景。
b) 业务元数据的关联。在meta-schema的基础上，增加标签、主题、资产风险登记以及其他自定义的业务元信息的关联，并提供点、批量的修改查询能力。
c) 动态元数据的变更管理。根据任务运行实例的SQL信息等，及时调整血缘信息，同时对于流表&Topic等同源的对象，在血缘影响分析层面自动进行合并关联。
(4) 统一的接口调用
a) 元信息的操作调用接口。
b) 元信息变更消息订阅等。
3. 统一数据源
除了统一元数据，统一数据源也非常关键，某种程度上来说直接关系逻辑数据湖好不好用、能不能用，数据源的管理也是在元数据中心组件完成。关键功能如下：
(1) 确定数据源注册登记的流程
针对每一种类型的数据源，首先要明确其注册登记的URL信息格式、账号、认证token、version等信息，以及必需项和可选项，在能正确解析数据源URL的同时，还需要确定数据源唯一性的元组，确保同一个数据源实例不会被重复登记。
其次是数据源在业务上有效空间的管理，Hive数据源是和单一集群绑定的，而非Hive的数据源可以做到跨集群的共享，同时一个数据源也可能做到跨租户共享，因此对于统一个数据对象（比如db）需要确定好属主、避免相互覆盖。对于数据源，也需要确定好业务线归属，并且要有使用权限管控，同一个租户内不同业务线不能随意使用。最后需要关注的就是数据源的可用性，元数据中心需要根据登记的数据源的信息，进行连通性的检查，除了检查登记信息的正确性以外，还需要尽可能确保需要访问数据源的节点（比如传输任务运行的节点）都是正常的。
(2) 统一的账号管理
主要是支持不同方式/场景的身份认证，不同的数据源认证的方式不同，常见方式有账号密码、代理token，对于安全性要求比较高的场景，可能会是Kerbores等。除了认证方式的不同，不同的用户账号管理模式也有不同，有的用户为每个平台登录账号都创建对应的数据源账号，好处是安全性高，但是权限管理比较繁琐。有些场景则是，所有场景使用一个登记的公共账号，管理方便但是安全性不高。某些系统则可能给出一个具有代理权限的账号用来代理具体的身份，取一个折中，但是需要每个应用产品都支持其使用模式。
(3) 数据源应用
主要是根据接口调用，给出具体数据源的信息以及运行模式（开发、线上）关联的账号信息、配置文件等；拉取各个数据源的元信息，需要关注的技术细节是不同的数据源元数据的获取方式各不相同，需要逐一适配，同时对于同一类数据源不同版本的驱动，需要明确其支持覆盖的数据源的版本范围，当出现覆盖不了的版本时，要能够动态地加入新的驱动版本插件并更新驱动版本映射表。
总体来说数据源的统一管控，是逻辑数据湖的基础，提供了最基础的能力支持，除了关系到能否正确使用数据源以外，也对上层业务应用的展开规划有基调性的影响。
4. 统一应用
完成了统一的数据源&元数据层的构建以后，我们来看看如何在此之上构建统一的应用，从而实现各个数据源的统、算、管、用。从具体的产品维护划分，就是模型设计、数据传输、数据开发、自助分区取数、资产地图等都能在各个数据源上实现产品功能。
(1) 模型设计
基于元数据中心提供的业务元数据的接口能力，在具体数据源上数据主题域的构建和划分，数据对象的打标等。同时支持在该数据源上进行规范的建表管理，实现手动、批量的表处理。
(2) 数据传输
实现不同逻辑数据源之间的数据传导，同时也是后续数据入物理湖的基石。数据传输根据逻辑数据源的元信息，给出最佳的传输方案。例如，对于Hive表，元数据中心解析其实际location，传输根据真实的存储系统信息进行对应jar包的选择、传输任务参数设置，以及数据操作。
(3) 数据开发
一种是直接在源系统上进行开发，比如各类的SQL任务，用户选择对应的数据源，调度执行节点根据数据源相关的信息、驱动配置等直接连上数据系统执行任务，支持用户保留原有的开发习惯，也方便任务的迁移。对于跨源的SQL任务，主要依托Spark、Flink等计算框架的catalog-manger框架来实现。开发平台会根据任务执行的模式、运行环境，自动关联同catalog下对应的数据源实例和执行账号，动态注册关联的catalog-plugin和相关参数。同时数据稽查、数据探侧等依托于开发框架也同样支持相关数据源。
(4) 自助取数
自助取数和数据开发类似，在单源数据模型信息的基础上，根据登记的数据源信息以及应用场景的关联账号，提供直连数据源的取数能力。值得说明的是，某些专门提供自助查的业务数据系统（比如用户自研的脱敏平台）也可以作为逻辑数据源录入平台，从而实现建模取数。
(5) 资产地图
通过将各个来源的数据对象元信息进行串联和整合，给用户提供快速数据查找的能力。以地图表搜索为例子，通过解析逻辑数据源抽取并解析源系统的表元信息，关联主题、指标、标签等信息以后写入ES等检索系统，从而提供多个维度的库表检索能力，除了表详情以外，还将关联的产出任务、血缘信息、变更ddl等一并展示。
除了通用的产品能力，为了更好地支持逻辑数据湖的应用，还需要很多其他基础建设，比如权限和血缘。权限除了源系统自带的权限能力，元数据中心还需要提供逻辑数据源的使用权限、meta表的权限等。血缘则是实现高效数据资产的一个重要基础信息，基于此实现数据热度、资源消耗、产出订阅、依赖推荐等众多高阶管理能力。
5. 数据逻辑入湖
前文已经介绍完了逻辑数据湖的整体架构。我们来看看数据入湖的整体流程。有两种模式，用户可以根据实际的建设情况做选择。
如果还没有完成物理湖（湖仓一体）的建设，可以选择逻辑入湖的方式，具体步骤是：登记数据源、确定数据源Owner、基础技术元数据信息注册、以及账号的映射设置。然后在数据管理类产品中持续完善业务元信息，然后进行数仓建设、数据开发以及任务运维。
对于已经构建了物理湖的场景，用户可以将物理湖也作为数据源登记到元数据中心，然后通过数据传输实现数据的物理入湖，物理入湖中需要关注数据变更发现的实时性、字段映射等，确保入湖数据的保真性。入湖的方式不影响上层产品的使用。
6. 跨环境发布
接下来我们看看逻辑数据在一些典型场景下的应用。
第一个是跨环境。这里也有两种情况，一种是各个环境之间网络隔离，比如金融机构的测试、生产环境往往是硬隔离的，这种模式下，不同环境需要部署各自的数据源和平台，只需要保证业务相同的数据源能以相同的名字注册管理即可，平台提供任务发布包的导出和导入，实现测试环境到生产环境的一键发布。
还有一种情况是各个环境之间网络是可以打通的，比如开发、预发、线上，又或者业务全球化存在不同区域有独立的集群，但是区域业务模式是相同的。这种模式下，可以一套平台对多个集群，不同集群镜像的数据源登记为同一个catalog下的不同tag的源系统，这样一份任务代码可以运行在不同的环境，自动根据环境信息运行时访问对应的数据源系统，实现一次开发多环境执行。
7. 逻辑数据湖的核心——血缘
另一个核心场景是数据血缘。统一元数据提供了统一应用管理的基石，数据血缘则能够将数据应用管理的多个场景串联起来，相互协同发挥更大的作用。在任务提交阶段，我们就会对SQL进行静态解析，拿到输入输出表展示给用户，方便用户调试调整任务，在任务上线配置中根据历史血缘信息智能地推荐出依赖的上游任务。另外在任务执行时，执行调度引擎服务会把运行时SQL，结合静态的SQL形成的血缘表达式统一传送给元数据中心，元数据中心生产最后的实际血缘信息，并进行血缘生命周期的管理。
血缘包含两类：静态血缘和动态血缘。
动态血缘是从数据执行引擎获取的，以Hive和Spark为例，我们通过hook拿到运行时的AST就可以知道实际的执行计划，非常精准也很好解析。动态血缘的问题是AST是SQL经过执行引擎优化后的信息，可能会丢失一些业务信息。
静态血缘主要通过解析调度系统实际任务执行时的SQL来做，通过静动结合来保证最终的正确性。还有一些血缘需要通过数据传输、数据服务等上层产品的任务拿到。平台还可以对外提供开放接口能力，能让业务系统自己的数据系统和平台对接，将外部的血缘告知平台。所有这些血缘最终都会在相关的产品上展现给用户。
接下来我们来看下血缘信息有什么作用。
首先血缘信息有多个分类维度：基础信息&业务信息、离线&实时、逻辑&物理等。基础信息即根据SQL表达解析出来的纯粹的表、字段之间的输入输出关系，业务信息则是产生该血缘的任务、平台等业务层面的信息。离线&实时表示血缘来源的场景，不同场景生命周期管理不同，逻辑&物理则是逻辑湖表及其实际物理表的关系整理。我们通过多个层次的渠道收集先关信息，然后在元数据中心进行统一汇总维护，保证血缘信息完整有效。血缘的作用范围，除了常见的数据地图血缘展示，还包括：
- 任务依赖推荐，在设置任务调度依赖的时候一键式的智能推荐&检查上游依赖设置。
- 下游影响分析，当任务异常/变更的时候集合基线快速定位影响的应用。
- 表变预警：重点核心表发生变化的时候，自动告警表Owner。
- 资产成本分析：基于血缘可以计算每个表成本，从而评估具体数据应用的价值。
- 表产出订阅：订阅重点&核心的表的产出，上层应用比如BI实现智能缓存刷新等。
关于血缘，我们最后再看下字段血缘。在大部分情况下表级别的血缘已经能够满足业务需求，但是在某些场景下表粒度还是太粗，最典型的就是大宽表的计算，需要迫切清楚字段关联的影响。
除了要能正确解析SQL以外，字段血缘关键点在于确定映射规则和元信息替换（静态血缘），目前我们是基于投影（Project）和过滤（Filter）规则来分析字段依赖关系，而元信息的替换元数据中心可以通过表关联的数据源直接获取，确保实时性。通过递归分析各个子查询过程，最终得到字段级别的血缘。对于任务多SQL的场景，我们需要进行session化的模拟，一些中间临时表的信息要缓存起来，对于create and drop的临时表，需要正确地更新其缓存信息，确保下游SQL解析时有正确信息输入。
--
04 未来规划
产品细节的打磨，主要是支持更多类型的数据源，提升血缘的覆盖率和精准度。对于逻辑数据湖来说，资产安全和权限落地也会更加复杂，同样需要去覆盖更多类型的数据源。
统一代码是我们在完成统一元数据和数据源之后，希望将离线实时代码做统一，同时实现跨源查询和统一的数据脱敏。
最后，持续完善流批一体和湖仓一体技术方案，实现统一的存储和高性能数仓。
--
05 精彩问答Q：动态血缘和静态血缘的使用场景分别是什么？为什么动态血缘不能完全替代静态血缘？
A：首先动态血缘只有在某些提供hook的引擎能够拿到，比如hive和spark；另外执行时的血缘经过了引擎优化的逻辑优化，可能会丢失原SQL中的一些表达信息，从而造成血缘不准。而静态血缘是用户原始执行sql，基于既定的sql语法规则进行解析以后的血缘，虽然在准确性上会有风险，但是在业务信息上是全面的。在构建血缘信息方面，要二者相结合。静态血缘在依赖推荐、稽查规则检查等场景可以直接应用，动态血缘获取更加底层，在任务开发比如脚本任务等场景可以有不错的覆盖率。
--
今天的分享就到这里，谢谢大家。
本文首发于微信公众号“DataFunTalk”。