申请网站建设,建站模板哪里好,建筑工程有限责任公司,无极县城内招聘临时工#x1f680; 优质资源分享 #x1f680;
学习路线指引#xff08;点击解锁#xff09;知识定位人群定位#x1f9e1; Python实战微信订餐小程序 #x1f9e1;进阶级本课程是python flask微信小程序的完美结合#xff0c;从项目搭建到腾讯云部署上线#xff0c;打造一… 优质资源分享
学习路线指引点击解锁知识定位人群定位 Python实战微信订餐小程序 进阶级本课程是python flask微信小程序的完美结合从项目搭建到腾讯云部署上线打造一个全栈订餐系统。Python量化交易实战入门级手把手带你打造一个易扩展、更安全、效率更高的量化交易系统导读 本文将介绍过去15年中网易大数据团队在应对不断涌现的新需求、新痛点的过程中逐渐形成的一套逻辑数据湖落地方法。内容分为五部分
关于网易数帆为什么做逻辑数据湖怎么做逻辑数据湖未来规划精彩问答
–
01 关于网易数帆
网易数帆是从网易杭州研究院孵化出来的。网易杭研的重要职责是公共技术的研究和产品孵化。下图是网易数帆的整体产品架构。 1. 网易大数据发展历史
网易是国内领先的互联网技术公司从2006年就开始对大数据相关技术进行探索。2009年为了支撑网易博客等产品的海量数据开始了分布式文件系统、分库分表中间件网易DDB等技术的研发并且于当年引入了Hadoop进行探索。2014年到2017年网易对大数据平台的建设在内部取得了良好效果同时发现业界存在普遍相似痛点于是开始对外做商业化尝试。2018年支持网易严选、考拉、音乐、新闻数据中台构建。通过在商业化过程对市场需求的摸索实践终于在2019年形成了“全链路数据中台”解决方案致力于将“数据生产力”的理念能力落实到解决方案中。 纵观网易大数据的发展历史可以看到这个过程中贯穿了数据理念的变化。有数从公共数据平台逐渐转变为具备有业务属性的数据中台最后逐步向“数据生产力”理念靠拢。在这个理念下会要求我们要不断贴近用户、了解用户实际情况做到第一时间提供更好的服务。同时在服务用户的过程中为了给用户提供更多价值交付逻辑数据湖的产生是必然的。这个过程从技术发展角度看也伴随着湖仓一体的探索和落地。
2. 业务支撑情况介绍 上图最上层是网易有数对公司内外提供的业务支撑情况。网易有数的技术能力通过一套方法论、一个工具平台和公共数据建设三部分对上层输出整体的价值。同时在落地过程中形成了技术业务双循环的模式。双循环中涉及三个角色两种驱动力。三方分别是内部用户、外部用户、数据中台业务场景、技术前瞻是推动双循环的驱动力。这两种驱动缺一不可大数据技术和应用发展日新月异数据中台的业务支撑能力特别依赖于底层的技术能力和前瞻性。 –
02 为什么做逻辑数据湖
1. 数据生产力不足的问题
网易有数最早想要提升数据生产力是从建设数据开发平台开始的。在建设使用过程中暴露出各种问题导致了数据生产力不足 2. 数据生产力低下的原因
在梳理了数据开发平台碰到的问题之后我们开始思考问题的根本原因是什么。最终结论就是这不仅是一个技术问题更是产品体系问题。我们缺少一套贴近需求的数据产品力体系。这也是业内的数据平台在业务支撑中的普遍问题。
所以我们重新打造了我们的产品体系来保证整个数据应用的生产力落地第三部分会展开来讲我们如何通过构建逻辑数据湖来支撑这套产品力的落地。 3. 数据生产力支撑——大数据底座 最近十几年大数据相关技术的发展主要是基于开源的技术构建我们团队也以主动积极的态度看待开源争取回馈社区。我们积极培养技术专家参与社区建设输出技术贡献这些帮助我们夯实了大数据的底座。
4. 数据生产力方法论 数据生产力建设的方法论我们从上图的三个维度来表达。首先是算让数据研发足够敏捷保证工程效率和质量其次是管让不同类型不同来源的数据融合统一抽象对外表达最后是用做到低门槛用户不需要关心底层的情况这很符合用户的使用场景。
5. 数据生产力提升成果 6. 数据产品建设成果 除了在技术指标层面的成果衡量数据生产力建设在业务系统中也体现了巨大的价值。上图是浙江卫视对我们在电商业务数据生产力提升的成果报道切实提升了业务运转效率并且产生了良好的社会和经济价值。
7. 产品核心优势 有数产品的核心优势从方法论开始对于复杂的产品系统建设理论先行。基于生产力方法论我们建设了完整度很高的产品体系产品同时具备良好的兼容性基于开源技术体系做到了支持跨云部署。
8. 企业用户的灵魂拷问 开始商业化后有数在调研外部用户需求的过程中经常会碰到上图中的三个重要问题。
这个三个问题都非常实际因为相比传统的IT系统大数据体系的技术架构还是要复杂一些的。
第一个问题是对业务的担心技术是对业务的支持每个企业用户的技术建设情况不同业务复杂度也不一很多传统企业已有的IT系统已运行了很多年只是无法再支持日益增长的数据需求他们在大数据技术体系的经验几乎空白当面对一个比如lambda架构的大数据解决方案时往往会觉得过于复杂和难以掌握对落地成效心存疑虑。还有部分用户的业务在现有技术框架上比如MPP运行良好出于对未来发展的前瞻性考虑需要提前进行大数据的基础技术建设这部分用户对于大数据未来的必要性是肯定的但是会特别关心其适用的场景、业务覆盖度以及如何平滑地进行业务的迁移。在我们与用户的合作中有很多行业标杆用户通过帮助标杆用户建设数据平台过程我们也逐渐积累了很多行业经验在和后续其他用户的合作中通过组织培训和实施的方式和客户一起把方案落地但是这个过程需要一定的成本并且需要逐步给用户信心。
第二个问题也是用户非常关心的问题。再优秀的系统也都是需要运维的对于用户而言他们非常关心数据平台能否自主运维至少能参与基础的运维一方面这个是企业内部的硬性要求一方面私有化部署模式下这也是一种良好的合作共建模式特别是某些环境是闭网部署。这个问题就涉及到系统整体复杂度、运行状态透明程度、以及运维团队是否好组建等多个维度的考量。对于运维网易内部有多年的经验沉淀总结了丰富的培训教材同时也开发了便捷的运维工具通过分享和培训基本能够让用户进行基础的运维操作但是总体而言用户还是需要有一个学习的时间成本很多情况下用户已有的运维团队对于老系统已经积累了很多经验技术架构一刀切的方式对原有团队稳定性的冲击也比较大。
第三个问题来自于这部分用户他们看中的是解决方案中的产品体系。有数的产品功能能够解决他们在数据工具、数据管理和数据赋能上的痛点。但是并非一定需要Hadoop数据底座产品功能和底层集群不需要强绑定。这也是我们做逻辑数据湖的重要出发点之一满足更多类型用户的实际需要。
以上的这三个问题都可以通过逻辑数据湖的技术方案来解决。 上图是一个常见的实时数仓解决方案在互联网公司应该是非常常见的。这样的架构明显的特点就是
组件多多种数据源、CDC、消息队列、实时计算框架、存储系统、Adhoc查询系统等等
链路长从数据源到最后数据结果产出至少需要3-4个步骤
技术专每个组件都可以有专门的团队来研究运维。
得益于大厂完善的基础建设、业务量级以及人员储备这样的模式还能相对顺畅得运行但是对于一般性的传统企业而言学习和运维压力还是非常大的哪怕是随着湖仓一体技术的发展整体的架构可以持续简化也难免心生敬畏因此在必要的场景采用必要的技术是对用户的一种负责。
9. 为什么要做逻辑数据湖 以上是我们在调研企业用户数字化转型中对相当比例用户痛点的总结。在实现数字化转型的过程中数据湖Hadoop解决的是数据统一汇聚的问题而统一元数据则是解决数据连接、资产、管理的问题对于相当部分的用户而言当前最大的痛点不是海量数据的存储而是如何将散落到各个子数据系统的数据孤岛统一管控起来。因此通过构建一个逻辑层面的数据湖实现统一的元数据分散的物理存储避免不必要的物理数据入仓湖从而将产品上层功能比如主题域构建、数据地图等等及早给用户使用才是解决问题的根本之道逻辑数据湖方案依然可以使用物理湖Hadoop同时提供通过虚拟表直连数据源的方案将其他类型的数据源也纳入平台的管控中用户可以根据实际的需要选择适合的存储方案把选择权还给用户。
10. 网易有数产品特色 以上是网易有数的十大产品特色能力其中“流批一体湖仓一体“对标的就是Lakehouse而逻辑数据湖的目标是让其他8个产品能力跑在不同的数据源上实现中台数据治理能力和底层存储架构的解耦让即使使用传统数仓技术的用户也能享受到数据生产力的福利。
–
03 怎么做逻辑数据湖
1. 逻辑数据湖构建方法论
关于如何构建逻辑数据湖我们的构建方法论主要分为如下三个大的层面
数据源支持类型除了HadoopHive体系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实现智能缓存刷新等。
8. 字段血缘 关于血缘我们最后再看下字段血缘。在大部分情况下表级别的血缘已经能够满足业务需求但是在某些场景下表粒度还是太粗最典型的就是大宽表的计算需要迫切清楚字段关联的影响。
除了要能正确解析SQL以外字段血缘关键点在于确定映射规则和元信息替换静态血缘目前我们是基于投影Project和过滤Filter规则来分析字段依赖关系而元信息的替换元数据中心可以通过表关联的数据源直接获取确保实时性。通过递归分析各个子查询过程最终得到字段级别的血缘。对于任务多SQL的场景我们需要进行session化的模拟一些中间临时表的信息要缓存起来对于create and drop的临时表需要正确地更新其缓存信息确保下游SQL解析时有正确信息输入。
–
04 未来规划 产品细节的打磨主要是支持更多类型的数据源提升血缘的覆盖率和精准度。对于逻辑数据湖来说资产安全和权限落地也会更加复杂同样需要去覆盖更多类型的数据源。
统一代码是我们在完成统一元数据和数据源之后希望将离线实时代码做统一同时实现跨源查询和统一的数据脱敏。
最后持续完善流批一体和湖仓一体技术方案实现统一的存储和高性能数仓。
–
05 精彩问答
Q动态血缘和静态血缘的使用场景分别是什么为什么动态血缘不能完全替代静态血缘
A首先动态血缘只有在某些提供hook的引擎能够拿到比如hive和spark另外执行时的血缘经过了引擎优化的逻辑优化可能会丢失原SQL中的一些表达信息从而造成血缘不准。而静态血缘是用户原始执行sql基于既定的sql语法规则进行解析以后的血缘虽然在准确性上会有风险但是在业务信息上是全面的。在构建血缘信息方面要二者相结合。静态血缘在依赖推荐、稽查规则检查等场景可以直接应用动态血缘获取更加底层在任务开发比如脚本任务等场景可以有不错的覆盖率。
– 今天的分享就到这里谢谢大家。 本文首发于微信公众号“DataFunTalk”。
