数据中台建设

官网:https://haomo-tech.com

作者:毫末科技

邮箱:hxg@haomo-studio.com

微信二维码:

1 概述

1.1 技术描述

数据湖是一个集中式存储库,允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据(无需先对数据进行结构化处理),并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习,以指导做出更好的决策。

一般来讲,数据湖的存储应该支持以下特性:

  1. 可扩展性:企业数据湖充当整个组织或部门数据的集中数据存储,它必须能够弹性扩展。注意,虽然云原生架构比较容易支持弹性扩展,但是数据中心都会有空间和电力限制,准备建设大规模数据湖的企业需要考虑多数据中心或混合云的架构,否则就会陷入几年就要"搬家"的窘境。
  2. 数据高可用性:数据的及时性和持续可用性是辅助决策制定的关键,因此必须使用HDFS、Ceph、GlusterFS等支持多备份、分布式高可用的架构。
  3. 高效的存储效率:数据湖的数据量是以PB计的,而且因为需要多备份(3份或更多),其存储效率就非常重要。例如,使用LZO压缩存储HDFS文件可以达到1∶6甚至1∶7的压缩比例,而且可以通过系统支持实现透明访问,也就是说,程序可以直接使用数据而无须先展开到临时空间。另外,列式存储也是一种常用的利于压缩的存储方式。存储效率越高,意味着需要的服务器越少,使用的电量越少,扩容的时间间隔越长,因此存储效率对数据湖的运营非常重要。
  4. 数据持久性:数据一旦存储,就不能因为磁盘、设备、灾难或任何其他因素而丢失。除了使用分布式架构,一般还需要考虑多数据中心和混合云架构支持的异地备份。
  5. 安全性:对于本地和基于云的企业数据湖来说,安全都是至关重要的,应将其放在首位。例如,数据必须经过加密,必须不可变(在任何需要的地方),并且必须符合行业标准;数据系统的访问必须支持端到端的授权和鉴权集成等。应该从刚开始建设数据湖时就进行安全性的设计,并将其纳入基本的体系结构和设计中。只有在企业整体安全基础架构和控件的框架内部署和管理,数据湖的安全性才有保障。
  6. 治理和审计:要能够应用治理规则及数据不变性,识别用户隐私数据以及提供完整的数据使用审计日志的能力,这对于满足法规和法定要求至关重要。
  7. 可以存储任何内容:数据湖在设计之初,有一个主要考虑的因素:存储任何格式(结构化和非结构化)的数据并提供快速检索。当然,这里的"快速"并不是说要像面向用户的系统一样提供实时响应,在数据湖上运行的应用对交互的要求会低一些。即便如此,Presto、Impala等SQL-on-Hadoop的解决方案正在逐步提高数据湖的交互体验。
  8. 可以支持不同存储文件的大小和格式:在很多场景中,系统需要存储很多小文件,这些文件的尺寸远小于Hadoop文件系统(HDFS)的默认块大小128MB。在基于Hadoop的框架中,每个文件在集群的名称节点的内存中均表示为一个对象,每个对象通常占用150B。这意味着大量文件将消耗大量内存。

数据湖的特征:

  1. 保真性:数据湖中对于业务系统中的数据都会存储一份"一模一样"的完整拷贝。与数据仓库不同的地方在于,数据湖中必须要保存一份原始数据,无论是数据格式、数据模式、数据内容都不应该被修改。在这方面,数据湖强调的是对于业务数据"原汁原味"的保存。同时,数据湖应该能够存储任意类型/格式的数据,包括结构化、半结构化和非结构化数据。
  2. 灵活性:如果数据仓库属于计划经济,那数据湖就属于市场经济[7],数据仓库强调"写入型schema", "写入型schema"背后隐含的逻辑是数据在写入之前,就需要根据业务的访问方式确定数据的schema,然后按照既定schema,完成数据导入,带来的好处是数据与业务的良好适配;但是这也意味着数仓的前期拥有成本会比较高,特别是当业务模式不清晰、业务还处于探索阶段时,数仓的灵活性不够。数据湖强调的是"读取型schema",背后的潜在逻辑则是认为业务的不确定性是常态:我们无法预期业务的变化,那么我们就保持一定的灵活性,将设计去延后,让整个基础设施具备使数据"按需"贴合业务的能力。
  3. 可管理:数据湖应该提供完善的数据管理能力。既然数据要求"保真性"和"灵活性",那么至少数据湖中会存在两类数据:原始数据和处理后的数据。数据湖中的数据会不断的积累、演化。因此,对于数据管理能力也会要求很高,至少应该包含以下数据管理能力:数据源、数据连接、数据格式、数据schema(库/表/列/行)。同时,数据湖是单个企业/组织中统一的数据存放场所,因此,还需要具有一定的权限管理能力。
  4. 可分析:从批处理、流式计算、交互式分析到机器学习,各类计算引擎都属于数据湖应该囊括的范畴。一般情况下,数据的加载、转换、处理会使用批处理计算引擎;需要实时计算的部分,会使用流式计算引擎;对于一些探索式的分析场景,可能又需要引入交互式分析引擎。随着大数据技术与人工智能技术的结合越来越紧密,各类机器学习/深度学习算法也被不断引入,例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行训练。因此,对于一个合格的数据湖项目而言,计算引擎的可扩展/可插拔,应该是一类基础能力。
  5. 可追溯:数据湖是一个组织/企业中全量数据的存储场所,需要对数据的全生命周期进行管理,包括数据的定义、接入、存储、处理、分析、应用的全过程。一个强大的数据湖实现,需要能做到对其间的任意一条数据的接入、存储、处理、消费过程是可追溯的,能够清楚的重现数据完整的产生过程和流动过程。
  6. 可存储:数据湖需要提供足够用的、可扩展的统一数据存储能力,理论上,数据湖本身应该内置多模态的存储引擎,以满足不同的应用对于数据访问需求(综合考虑响应时间/并发/访问频次/成本等因素)。但是,在实际的使用过程中,数据湖中的数据通常并不会被高频次的访问,而且相关的应用也多在进行探索式的数据应用,为了达到可接受的性价比,数据湖建设通常会选择相对便宜的存储引擎(如S3/OSS/HDFS/OBS),并且在需要时与外置存储引擎协同工作,满足多样化的应用需求。

1.2 技术发展历史

数据湖技术演进路线:

  1. 第一阶段:以Hadoop为代表的离线数据处理基础设施
  2. 第二阶段:Lambda架构,核心理念是"流批一体"。流式计算引擎应运而生,例如Storm、Spark Streaming、Flink等
  3. 第三阶段:Kappa架构。"流批分离"的处理链路增大了研发的复杂性。Kappa架构统一批处理与流式处理两种计算模式。

1.3 技术发展趋势

1.4 名词解释

  • ODS:Operating Data Store,运营数据存储

2 建设内容

数据湖建设的4个目标:

  • 高效采集和存储尽可能多的数据。将尽可能多的有用数据存放在数据湖中,为后续的数据分析和业务迭代做准备。一般来说,这里的"有用数据"就是指能够提高业务还原度的数据。
  • 对数据仓库的支持。数据湖可以看作数据仓库的主要数据来源。业务用户需要高性能的数据湖来对PB级数据运行复杂的SQL查询,以返回复杂的分析输出。
  • 数据探索、发现和共享。允许高效、自由、基于数据湖的数据探索、发现和共享。在很多情况下,数据工程师和数据分析师需要运行SQL查询来分析海量数据湖数据。诸如Hive、Presto、Impala之类的工具使用数据目录来构建友好的SQL逻辑架构,以查询存储在选定格式文件中的基础数据。这允许直接在数据文件中查询结构化和非结构化数据。
  • 机器学习。数据科学家通常需要对庞大的数据集运行机器学习算法以进行预测。数据湖提供对企业范围数据的访问,以便于用户通过探索和挖掘数据来获取业务洞见。

数据湖必须支持以下特性。

  • 数据源的全面性:数据湖应该能够从任何来源高速、高效地收集数据,帮助执行完整而深入的数据分析。
  • 数据可访问性:以安全授权的方式支持组织/部门范围内的数据访问,包括数据专业人员和企业等的访问,而不受IT部门的束缚。
  • 数据及时性和正确性:数据很重要,但前提是及时接收正确的数据。所有用户都有一个有效的时间窗口,在此期间正确的信息会影响他们的决策。
  • 工具的多样性:借助组织范围的数据,数据湖应使用户能够使用所需的工具集构建其报告和模型。

数据采集

  • 传统数据库数据采集:数据库采集是通过Sqoop或DataX等采集工具,将数据库中的数据上传到Hadoop的分布式文件系统中,并创建对应的Hive表的过程。数据库采集分为全量采集和增量采集,全量采集是一次性将某个源表中的数据全部采集过来,增量采集是定时从源表中采集新数据。
  • Kafka实时数据采集:Web服务的数据常常会写入Kafka,通过Kafka快速高效地传输到Hadoop中。由Confluent开源的Kafka Connect架构能很方便地支持将Kafka中的数据传输到Hive表中。
  • 日志文件采集:对于日志文件,通常会采用Flume或Logstash来采集。
  • 爬虫程序采集:很多网页数据需要编写爬虫程序模拟登录并进行页面分析来获取。
  • Web Service数据采集:有的数据提供商会提供基于HTTP的数据接口,用户需要编写程序来访问这些接口以持续获取数据。

2.1 数据存储

  • HDFS:一般用来存储日志数据和作为通用文件系统。
  • Hive:一般用来存储ODS和导入的关系型数据。
  • 键-值存储(Key-value Store):例如Cassandra、HBase、ClickHouse等,适合对性能和可扩展性有要求的加载和查询场景,如物联网、用户推荐和个性化引擎等。
  • 文档数据库(Document Store):例如MongoDB、Couchbase等,适合对数据存储有扩展性要求的场景,如处理游戏账号、票务及实时天气警报等。
  • 图数据库(Graph Store):例如Neo4j、JanusGraph等,用于在处理大型数据集时建立数据关系并提供快速查询,如进行相关商品的推荐和促销,建立社交图谱以增强内容个性化等。
  • 对象存储(Object Store):例如Ceph、Amazon S3等,适合更新变动较少的对象文件数据、没有目录结构的文件和不能直接打开或修改的文件,如图片存储、视频存储等。
  • 时序数据库:例如InfluxDB等。适合用来存储时间相关的监控类数据,可以实现较高的插入和查询性能、相当高的数据压缩比等。

2.2 数据ETL

  • Pentaho

  • Sqoop

2.3 元数据管理

元数据贯穿整个数据仓库,根据情况可以分为三种:业务元数据、技术元数据和管理元数据。

业务元数据

业务元数据主要描述 ”数据”背后的业务含义;从业务角度描述业务领域的相关概念、关系——包括业务术语和业务规则。

  • 主题定义:每段 ETL、表背后的归属业务主题。
  • 业务描述:每段代码实现的具体业务逻辑。
  • 标准指标:类似于 BI 中的语义层、数仓中的一致性事实;将分析中的指标进行规范化。
  • 标准维度:同标准指标,对分析的各维度定义实现规范化、标准化。

业务元数据,在实际业务中,需要不断的进行维护且与业务方进行沟通确认。

技术元数据

指技术细节相关的概念、关系和规则,包括对数据结构、数据处理方面的描述。以及数据仓库、ETL、前端展现等技术细节的信息。

数据仓库中的技术元数据一般包含以下 4 大系统:数据源元数据;ETL 元数据;数据仓库元数据;BI 元数据。

  • 数据源元数据。例如:数据源的 IP、端口、数据库类型;数据获取的方式;数据存储的结构;原数据各列的定义及 key 指对应的值。
  • ETL 元数据。 根据 ETL 目的的不同,可以分为两类:数据清洗元数据;数据处理元数据。
    • 数据清洗元数据。数据清洗,主要目的是为了解决掉脏数据及规范数据格式;因此此处元数据主要为:各表各列的"正确"数据规则;默认数据类型的"正确"规则。
    • 数据处理元数据。数据处理,例如常见的表输入表输出;非结构化数据结构化;特殊字段的拆分等。源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。
  • 数据仓库元数据。数据仓库结构的描述,包括仓库模式、视图、维、层次结构及数据集市的位置和内容;业务系统、数据仓库和数据集市的体系结构和模式等。
  • BI 元数据。汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的查询与报告。

由于元数据包含极广,我们在建立元数据管理系统的时候,绝对不能盲目追求大而全、一步到位,要坚持目标驱动的原则,在实施的时候要采取增量式、渐进式的建设原则。具体的建设步骤如下:

  • 在建设数据仓库系统的初期,只需确定源系统的元数据构成和 数仓我们想要实现的元数据内容:比如,我们只想通过元数据来管理数据仓库中数据的转换过程,以及有关数据的抽取路线,以使数据仓库开发和使用人员明白仓库中数据的整个历史过程。
  • 确定源系统和元数据构成后,先将源系统的元数据整理并记录,可以用文档记录;也可以存入关系型数据库中。
  • 随着数据仓库系统的建设,逐步将需要的元数据补充录入——例如 DM 的语义层、ETL 的同步规则;
  • 数据仓库建设完成后,对元数据进行结构化、标准化储存。

实现企业元数据管理需从两个方面考虑:

  • 一是盘点企业数据情况,搞清楚要管理哪些元数据以及这些元数据在什么地方,以何种形态存储,他们之间有有着怎样的联系。
  • 二是建模,这里的建模是建立元数据的模型及元模型,要抽象出企业的元模型,建立个元模型之间的逻辑关系。

管理元数据

管理领域相关,包括管理流程、人员组织、角色职责等。

2.3 数据分析

2.4 数据交换

数据交换的方式一般是根据数据的类型来进行区分,如结构化或半结构化的数据可通过ETL的数据交换方式进行,非结构化的数据像压缩文件、电影、图片等采用文件传输的方式进行交换,而对于一些实时性较高的交换一般采用接口形式进行。例如:restfull、webservice等。

  • 结构化数据交换方法。结构化和半结构化数据交换主要有:时间戳同步、全文比对同步、触发器同步、CDC增量同步、全量同步。
  • 非结构化数据交换。主要由:文件同步等。
  • 实时数据交换。实时数据交换适用于对于数据时效要求快速、高频度、少量数据传输的场景。实时数据交换通过将数据中心库中的数据快速的发布出来提供给外部系统共享调用,同时能够监控外部调用数据的情况提升数据的价值。

3 市场应用

3.1 xxx行业应用

3.2 xxx行业应用

3.3 xxx行业应用

4 产品方案对比

4.1 开源方案

Apache Iceberg、Apache Hudi、Delta Lake

Apache Atlas:包含一组可伸缩和可扩展的核心基础治理服务,能够方便地与各类大数据组件集成,自动监听并分析数据源变化情况,实时采集元数据基础信息和血缘管理,为数据湖提供统一高效的元数据采集和管理能力。

底层数据存储格式(如Parquet、ORC等)

4.1.1 开源数据湖方案 Apache Iceberg

网址:https://github.com/xxx

4.1.2 开源数据湖方案 Apache Hudi

网址:https://github.com/xxx

4.1.3 开源数据湖方案 Delta Lake

网址:https://github.com/xxx

4.2 商业方案

4.1.1 xxx商业项目

网址:http://xxx.com/

4.1.2 xxx商业项目

网址:http://xxx.com/

5 参考资料

results matching ""

    No results matching ""