| 编辑推荐: |
过去几年，数据仓库和数据湖方案在快速演进和弥补自身缺陷的同时，二者之间的边界也逐渐淡化。云原生的新一代数据架构不再遵循数据湖或数据仓库的单一经典架构，而是在一定程度上结合二者的优势重新构建。
本文来自 InfoQ，由火龙果软件Anna编辑、推荐。 |
|
业务背景
网易严选在 2017 年中开始搭建自己的大数据体系，如今该体系已经支撑了严选的商业分析、搜索、推荐、广告、供应链、风控、商品开发、品控等几乎所有的业务场景。数据是电商运转的生命线，随着业务发展对数据的依赖程度越来越高，我们发现原来的数仓建设方法论及相关技术存在着一些比较明显的问题：
数据的运转效率比较低。几乎所有的数据应用都重度依赖数仓模型，数仓模型本身的研发与迭代成本比较高，生产速度赶不上需求速度，这就导致我们的创新想法落地、业务策略迭代等都会被按下暂停键。
数据的运转效率拖慢了业务的迭代效率。所以提升数据运转效率是我们数据体系演进的重要命题。业务的快速迭代导致了我们基础数据
schema 的频繁变更，而每次数据 schema 变更，都是一次伤筋动骨。我们的数据平台需要提供更加灵活的能力来低成本支撑数据
schema 的变化。
需要更可靠的准实时镜像表。
要解决这些问题，都需要对我们的数据架构进行持续的迭代。先来看看我们迭代前的数据架构。
数据架构
图 1 数据体系架构图
图 1 是网易严选的数据技术体系，跟大多数公司的大数据架构和应用场景一致。数据从业务系统产生，经过数据的传输及集成，再到数据和算法加工，最后为数据产品
/BI 分析 / 算法业务（推荐 / 搜索 / 广告 / 风控）等使用，对业务提供数据辅助决策或自动化决策的能力。
图中有两条重要的大数据 Pipeline，一个是数据仓库流程，另外一个是机器学习流程：
数据仓库开发，事先定义数据结构，业务数据经过了清理、丰富和转换，结果通常用于报告和分析。
机器学习流程，倾向于使用未加工的原始数据，通过特征提取和模型开发，用于模型在线推理。
两者在数据的需求和处理上有很多的不同，但随着业务场景和技术发展，这两者有同样的需求：
数据和模型开发过程中，批流计算和存储的融合，提升开发效率；
更实时的数据和模型，给业务提供更及时的数据决策能力；
更加灵活的数据 schema，以应对业务和模型的快速迭代；
直接分析与处理原始数据的能力。
现状 & 目标
图 3 是严选数据集成和入仓流程图，和绝大部分公司一样。对于 Binlog 数据，通过采集组件（Canal）把相应的
Binlog 同步到 Kafka，对于日志数据，通过 Flume 采集同步到 Kafka，同时会经过一个
DataHub-Hound 组件，也就是一个 Kafka2Hive 的任务程序把它导入到原始数据，再经过
Merge 任务，产出数仓底层 ODS 数据。
图 2 数据流程图
图中的 raw data 其实算一个狭义的数据湖，只是受限于 HDFS 的存储特点，无法支持 update
操作，无法支持灵活的 shema 语义以及 ACID 的保证。
所以存在 merge 任务，主要基于历史数据，和流式同步的增量数据进行合并，生产 ODS 层的周期快照数据。这样的实现，对于
T+1 离线数仓数据来说是可以满足的需求的，但对于近实时的数据分析需求，尤其是数据量大的表，无法在分钟级别完成合并。
在引入新的技术和解决方案时，我们会从以下几个目标去评估和实施落地：
解决问题，新的技术和解决方案对我们整个数据 / 算法体系有没有新的能力突破，方法体系有没有革新？
引入一个新的技术是需要解决系统通用的场景问题，而不是部分场景的应用。提升效率，新的技术和解决方案对我们体系的运转效率有多少提升？
降低成本，是否能够降低存储 / 计算 / 使用成本？
稳定落地，如何保障在不影响现有业务的情况下，大规模落地新的技术和解决方案？
所以我们想要通过数据湖，并且在不引入额外的存储成本的情况下，提供更加实时的数据能力。一个数据入仓更实时，这样一方面可以减轻
T+1 数据计算的压力，另外一方面可以提供更加实时的数据访问，对于算法工程的场景来说，为实时模型训练提供更加实时的特征数据。
图 3 数据湖架构
数据湖是解法？
最近几年，数据湖概念及相关技术发展的很迅速。就像每一个时髦的技术名词，数据湖的概念也非常的混乱，很多基础设施都自称自己是数据湖解决方案。数据湖到底是什么，相关的技术包括哪些？这其实取决于我们要用它来解决什么具体的问题。从自己的需求出发，去寻求解决方案落地，这样才不容易在各类营销概念中迷失。
数据湖 vs 数据仓库
数据湖优先的设计，能够有更高的灵活性。数据湖的数据存储形式和结构可以不预先定义，可以是结构化的，也可以是半结构化的。计算引擎可以根据不同的场景读写数据湖中存储的数据，这意味着我们在对数据进行分析和处理时能获取到数据全部的初始信息，使用也更灵活，高效。
而数据仓库优先的设计，能够做到更加规范化的数据管理。数据进入数据仓库前，通常预先定义 schema，数据开发需要预先根据业务进行建模，构建数据模型，用户通过数据服务接口或者计算引擎访问数据模型来获取干净和规范的数据。
图 4 数据仓库 vs 数据湖
对数据湖和数据仓库的区别很多文章都有描述，二者有各自的优势和局限性，但并不是必须要二选一。
数据湖的优势
我们对数据湖的特性和严选业务实际的场景，做了一些探讨和分析，形成了我们自己的理解。
最初接触数据湖概念时，相信国内的许多同行会跟我有类似的疑惑：Hadoop 存储和计算非结构化数据的能力一直都没有问题，为什么需要郑重其事地提出这样的理念？
这可能要从数仓的发展历史看起，大量的数据仓库实践其实是从关系型数据库开始的，从数据仓库的概念开始，就没有把非结构化数据（比如图像）考虑在内。因此，数据湖理念是对数仓的一个变革，而对国内许多从
Hadoop 技术栈成长起来的同学而言，数据湖其实是天然的事情。
但是，数据湖的相关理念和技术依然对于 Hadoop 生态的数仓理念和方法有比较大的变革：
1.从特性角度来看：结构化 / 非结构化数据往往是区分数据仓库和数据湖的重要特征，但是在网易严选，我们对非结构化数据的分析需求并不强烈。对于日志类数据，我们还是会做一些清洗并将其结构化后存入数据湖。我们不应该教条的理解数据湖
RAW Data 的定义。原始日志经过清洗 / 结构化后，只要其包括的信息没有变化，它依然是 RAW
Data。
2.从使用角度来看：数据湖强调对原始数据的使用。灵活的使用数据湖数据，对严选的数据体系有两方面的价值：
提升数据开发效率。当我们需要探索数据洞察业务机会的时候，往往需要给数据开发提数据模型建设需求。由于数据探索的不确定性和临时性，几乎不可能为了临时的频繁的数据探索去排期建设数仓模型。同时数据模型建设完毕后，模型本身的能力就决定了我们探索数据价值的上限。
避免信息的丢失。数仓模型的建设往往是为了满足过去或者当前的业务需求，在模型的开发过程中，不可避免的丢失掉对当时认为价值不大的数据信息。但是，我们在构建机器学习模型或者探索数据的时候，往往需要更加充分的信息，而传统的数仓从根本上无法避免这个问题。
数据湖方案能够很好地解决以上两个问题。
3.从实时性角度来看：Delta/Iceberg/Huid 经常被宣传为数据湖解决方案。从我们的角度来看，这些技术很好的解决了数据湖
ACID 的问题，并且提供了较好的实时性。意味着我们可以通过这些技术以比较实时的方式提供可靠的原始数据访问能力给应用。在
Delta Lake 这类存储格式出现之前，严选也自己构建了类似的比较高实时性的原始数据访问方案，但由于缺乏
ACID 能力的支持，使得实际落地的时候往往可靠性不足。
Delta/Iceberg/Hudi 也往往被认为是批量一体的存储解决方案。批流一体跟数据湖的概念糅合在一起，给很多大数据行业的同学带来了困扰。我们用
Delta 技术来构建原始数据层，那么如果用 Delta 构建近实时的 DWD 层，是不是也是数据湖？在这里需要做一个概念上的澄清：数据湖关注的是对原始数据高效、灵活的处理，DWD
及其他数仓分层是充分设计的数据模型，它并不符合我们对数据湖的定义和需求。
落地实践
数据湖的建设，从技术层面需要解决的是数据写入和读取，以及如何跟现有的大数据平台及中台技术集成在一起。总结下来主要有以下几点内容：
数据的存储，选择什么样的存储格式作为数据湖的存储引擎；
数据的写入，也就是业务数据如何流向到数据湖存储；
元数据管理，数据湖里的数据如何进行元数据的存储 / 管理 / 查询；
数据的访问，也就是跟我们现有的计算引擎 /OLAP 引擎的集成。
首先，对于数据的存储，我们的数据主要以结构化的数据为主，同时文件存储系统也是单一的 HDFS。我们从
2019 年开始，最早关注的是 Delta，所以选择它作为了我们的存储格式。随着开源项目 Hudi
和 Iceberg 的发展，我们拥有了更多更灵活的选择。三个项目在 ACID/ 时间旅行 / 自动合并等功能的支持现状和规划都大同小异，有很多文章对其有详细的对比，这里就不展开赘诉了。比较大的区别是
Iceberg 跟计算引擎解绑，目前 Hudi 也在增加此特性。
由于 Iceberg 在早期没有支持 Row-level 的 delete 功能，这个对于我们数据集成的场景是必须的，所以我们选择的是
Delta 作为我们的解决方案并且落地。由于早期考虑到了多种存储格式的支持，所以做了逻辑封装和抽象，在
Iceberg 支持 row-level 的 delete 之后我们也完成了快速支持和集成。Iceberg
对 Flink 的支持，可以解决流计算引擎统一和应用场景的扩大，我们也在逐渐往其迁移。
对于数据的写入和访问主要是在计算引擎 Flink/Spark/Presto 等的集成，三个计算引擎生态建设都相对比较完善，这里不展开细说。
元数据管理这块，由于提前对统一元数据服务进行了抽象和实现，在接入数据湖之后，由统一元数据服务实现对表存储格式（Delta
及 Iceberg）定义和元数据的查询，这样多个平台或其它服务，能够快速的实现对数据湖的元数据管理。
完成计算引擎和基础服务的支持，用户即可在大数据平台，包括数据总线 / 流计算 / 离线开发平台 /
机器学习平台等对数据湖的数据进行访问和使用了。
同时，我们还需要考虑如何稳定可靠的应用到生产系统中。得益于我们的三大基础服务的建设，元数据服务 +
血缘服务 + 监控服务 。
图 5 数据湖架构
如图 5 所示，元数据和血缘服务，提供的元数据的管理和全链路数据追踪，为我们分级灰度切换提供了有力的支持。而全链路的数据监控体系，包括任务粒度的监控和自动容错，以及消息级别的处理延迟
/ 丢失 / 重复的探测，为我们 0 故障的上线和切换提供了有力的保障。
目前我们完成了数据湖建设的初步阶段，下面对于我们的一些落地场景应用和解决的问题展开介绍。
数据集成
数据集成在大数据流程当中是非常重要的一环，相信很多公司都经历了几代的技术发展和迭代。
图 6 数据集成 v1
严选在数据量非常小的时候，每天凌晨的时候业务 DB 的数据简单粗暴的全部 load 到数仓。但是随着业务的发展，对于数据量大的
DB 和表，全量 load 数据所花的时间，直接影响离线数仓数据的产出时间。
于是有了数据集成的 V2.0 方案，自研了增量 merge 的方案，把数据的传输变成了实时的同步，针对不同的应用场景提供不同的数据。
在凌晨的时候，基于 T+2 的快照和当天变更数据，生成 T+1 的快照数据，也就是我们离线数仓底层
ODS 数据，这样我们整个数据入仓的时间减少到一个小时了，大大提高了整个数据的产出效率
图 7 数据集成 v2
为了满足一些更加实时的场景，merge 模块提供了短周期快照 10/30/60 分钟级别的快照数据来满足这样的场景。但是这个方案存在比较大的缺陷：
实时性无法满足。尤其是数据量大的表，是无法满足分钟级别近实时的数据需求；
以空间换时间，有大量的存储资源浪费；
没有 ACID 的支持，更新期间并发数据访问短暂不可用。
随着 Delta/Iceberg/Hudi 这样开源的存储格式的发展，给数据集成方案提供了很好的优化支持，能够解决以上提到的
3 个问题。如图 8 中的 DataHund 框架在 delta 和 iceberg 的基础上进行封装开发，完成实时入湖的集成方案。
图 8 数据集成 v3
数仓建设
数据湖的数据，实时性更强，可靠性更高。除了能够提供近实时的数据分析，在此基础上可以构建我们 ODS
层的数据。如下图所示：
目前已经完成了近实时的数据访问场景，也就是我们的分钟 / 小时数据访问的场景需求，解决上面所提到的
3 个问题：
实时性。平均延迟在 1s 左右，对于大数据量的表同步延迟在分钟级；
节省了 70% 的计算和存储资；
有了 ACID 的支持，下游任务访问数据失败率减少为 0。
特征工程
除了数据分析应用的场景，我们把数据湖也应用在了机器学习的场景中。特征工程在机器学习中起着至关重要的作用，特征的好坏直接会影响到算法的最终效果，算法工程师将离线特征于算法模型的训练，同时实时特征用于在线推理服务。
原来的特征处理流程，存在有两个比较大的问题：
特征不一致，造成这个问题的原因有：1. 离线特征和实时特征的开发人员不是同一个；2 特征处理的引擎不一样。
离线训练模型。离线特征用于模型训练。数据产出到生成样本再到模型训练和部署上线，延迟在 24h 以上。
通过引入数据湖，我们优化了上述流程，解决了特征不一致和模型训练不实时的问题。特征的计算主要通过 Flink
任务进行处理，处理后写入 Redis 用于线上预测，再将处理后的特征 append 到特征表（Iceberg）中，使得整个模型训练都可以变得更加实时。
下图是我们特征存储的模块架构图，因为我们有特征存储的抽象和实现，所以集成数据湖的访问相对还是比较容易的，统一的特征读写
SDK，对于上层的特征处理任务和离线训练任务都能够无感知的迁移和使用。
特征存储服务包括三个部分：一块是特征的管理；一块是特征的存储，屏蔽底层存储介质；另一个模块是特征的访问，数据开发工程师通过
FeatureStore 提供的 SDK，将处理好的特征写入 FeatureStore。
特征存储架构
未来规划
数据湖和数据仓库在数据生产和服务效率上有很大的差别。我们在第一阶段完成了初步的平台集成和建设，正在灰度阶段，支撑了
5 个任务。接下来的工作更有难度和挑战，我们会跟算法团队、BI 团队协作，为更关键的服务和分析提供数据湖能力。比如搜索、推荐、风控等对数据模型的迭代需要非常频繁的服务；再比如对业务进行探索与分析等，对数据的使用存在比较大的随机性的场景。随着更多复杂场景的落地，需要我们对计算和存储引擎本身去做进一步的优化。 | 
