共计 5071 个字符，预计需要花费 13 分钟才能阅读完成。
本文为字节跳动基于数据湖技术的近实时场景实际，次要包含以下几局部内容：数据湖技术的个性、近实时技术的架构、电商数仓实际、将来的挑战与布局。、
数据湖技术个性
1. 数据湖概念
从数据研发与利用的角度，数据湖技术具备以下特点：
首先，数据湖可存储海量、低加工的原始数据。在数据湖中开发成本较低，能够反对灵便的构建，构建进去的数据的复用性也比拟强。
其次，在存储方面，老本比拟低廉，且容量可扩展性强。
与传统数仓建模应用的 schema on write 模式相比，数据湖采纳了一种 schema on read 的模式，即不会当时对它的 schema 做过多的定义，而是在应用的时候才去决定 schema，从而反对上游更丰盛、更灵便的利用。
2. 字节数据湖
Apache Hudi 有上面十分重要的个性：
- Hudi 不仅仅是数据湖的一种存储格局（Table Format），而是提供了 Streaming 流式原语的、具备数据库、数据仓库外围性能（高效 upsert/deletes、索引、压缩优化）的数据湖平台。
- Hudi 反对各类计算、查问引擎（Flink、Spark、Presto、Hive），底层存储兼容各类文件系统（HDFS、Amazon S3、GCS、OSS）
- Hudi 应用 Timeline Service 机制对数据版本进行治理，实现了数据近实时增量读、写。
- Hudi 反对 Merge on Read / Copy on Write 两种表类型，以及 Read Optimized / Real Time 两种 Query 模式，用户能够在海量的低加工的数据之上，依据理论需要，在“数据可见实时性“和“数据查问实时性”上做出灵便的抉择。
（其中，Read Optimized Query 是 面向 数据可见实时性 需要的；Real Time Query 是面向数据查问实时性 需要的）
业界目前有多套开源的数据湖的实现计划，字节数据湖是基于 Apache Hudi 深度定制，实用于商用生产的数据湖存储计划，其个性如下：
- 字节数据湖为买通实时计算与离线计算，及实时数据、离线数据共通复用提供了桥梁。Hudi 的开源实现反对多种引擎，在字节跳动的实现中，集成了 Flink、Spark、Presto，同时反对 streaming 和 batch 计算。
- 字节数据湖领有良好的元数据管理能力，并在此之上实现了索引。应用行、列存储并用的存储格局，为高性能读写提供松软的根底。
- 字节数据湖新增了多源拼接性能，对于须要交融多种数据源或者构建集市型数据集的场景，多源拼接性能简化了数据操作，使数据集的构建更加简便。
- 字节数据湖反对 read optimize 和 real time 两种 query 模式。同时提供 upsert（主键更新）、append（非主键更新）两种数据更新能力，利用扩展性强，对用户应用敌对。
近实时技术架构
3. 近实时场景特点
近实时场景在个别分为为两种类型，第一类是面向剖析型的需要，第二类是面向运维型的需要。
- 面向剖析型的需要，次要用户为分析师、经营人员或决策层，其特点是需求量大，并且要求数据研发疾速响应。从数据内容来讲，剖析型需要旺，须要从多视角、多维度进行剖析，试验性质比拟强，须要在底层加工的时候进行跨数据域的关联。不嵌入到具体的产品性能或者业务流程中，所以对提早和品质 SLA 的容忍度较高。
- 面向运维型的需要，次要用户是数据研发人员和数据运维人员。这类场景须要老本低廉、操作便捷的存储来进步研发和运维的效率。
总结以上两类场景的共同点为：均需以“较高人效、较低存储老本“的解决方案进行反对。
4. 数据湖技术适用性
数据湖为什么实用于近实时场景，其起因能够总结为三点：
复用流批的后果：
- 对于流式计算来说，能够利用批式计算的后果解决历史累积后果、数据冷启动、数据回溯等问题。
- 对于批计算来说，通过将次日凌晨大数据量的批式计算，转换为复用用流计算当日更新增量的后果，从而进步离线数据的产出时效性。升高数据基线破线的危险。
通过复用批流计算的后果，也能够进步开发的人效。 - 对立存储：字节数据湖采纳 HDFS 作为底层存储层，通过将 ods、dwd 这类偏上游的数仓档次的数据入湖，并将加工 dws、app 层的计算放在湖内，从而把实时计算的“两头数据”、“后果数据”都落入数据湖中，实现了与基于 hive 存储的离线数据 在 存储上的对立。
- 简化计算链路：利用了数据湖多元拼接的性能，缩小 join 操作，解决多数据源的交融问题，简化数据链路。也能够通过将离线维表导入到近实时计算中，复用离线计算的后果，从而简化链路。
5. 近实时架构计划
咱们摸索的近实时架构时，并没有抉择业界比拟风行的批流一体计划，而是在流式计算和批式计算两头寻求优势互补的两头态。尽管以后业界在计算引擎层面做到了流批一体，然而，在理论的数据生产加工过程中，在数据品质、数据运维、血统治理、开发套件等方面，实时计算、离线计算主观上存在着较大差别。
因而，咱们采取的策略是设计一种近实时的计算架构，在保留离线计算数据的丰盛度和复杂度的同时，又兼顾实时计算的时效性高的特点，将两者进行优势互补。这种近实时的计划，能满足方才提到的剖析型、运维型的业务需要。
另一方面，针对数据产品里要求秒级跳变的数据大屏、或者是嵌入到业务流程中的，对数据精准性要求高的事务型解决需要，则不适宜近实时架构。
6. 近实时架构计划
演进上面这张图展现的是数仓研发人员较为相熟的离线和实时数仓的架构：从业务零碎中抽取数据，ODS 层到 App 层逐层加工。离线和实时数仓的数据交互次要产生在 DIM 维表，对于迟缓变动的属性信息，会加工离线的数据，导入到实时的 Redis 或 HBase 存储，而后复用到实时计算中。
下图是基于 Hudi 构建的湖仓架构，该架构强调实时、离线数据的复用性（从图中虚线能够看出）。数据湖近实时同步的数据，能够通过增量的形式同步到离线数仓的 ODS 层，晋升同步效率。而数据湖中的 DWD 和 DWS 层，也能够复用离线数仓中建设的维表，因为自身都是基于 HDFS 存储，免去了数据同步和加工的老本。此外，对于新型的业务或者是数据源，也能够将数据从业务零碎导入湖中，再依照 ODS 到 DMS 分层开发。
传统离线数仓中的 DWD 层通常不面向利用，这点和基于数据湖的架构是有所区别的。数据湖的思维是 schema-on-read，心愿尽量把更多原始的信息凋谢给用户，不进行适度的加工，从图中大家也能够看到，数据湖中的 DWD 层是面向 Presto 查问，提供给用户构建数据看板或剖析报表，也能够通过更深度的加工后提供给用户。
电商数仓实际
接下来介绍一下抖音电商实时数仓团队在各类业务具体场景的实际案例。
7. 剖析型场景实际
营销大促
对于 618、双 11 等购物节日，平台须要提前进行大促招商和资源提报，业务有当日剖析和当日决策的需要。营销大场景的特点是数据自身变更频率不高（小时级），然而须要反对一段周期（5-15 天）至今的累积值统计。之前的纯离线计划，是每小时对 T – 1 的数据进行全量计算，上游应用 Presto 剖析。这种计划的毛病是数据的时效性差，且往往小时级任务难以保障一小时内产出数据后果。
另一种纯实时的计划是将数据源导入到 Flink，由 Flink 进行长周期大状态的计算（15 天的所有信息都保护在作业的状态内）。这种计划的长处是实效性好。然而，工作稳定性难以保障，此外，还须要将数据结导入到实时 OLAP 数据库中（如 clickhouse），存储老本较高。
对于这类场景，近实时架构提出的解决方案是：将实时的数据流入湖，利用 Spark 进行小时级的调度，合并离线 T – 1 周期内的全量数据和 T 增量数据，将后果存储到数据湖中，通过 Presto 供实时剖析决策应用。通过在湖内合并实时和离线数据, 既解决了纯实时计划中大状态稳定性的问题，又解决了纯离线计划时效性低的问题。同时，这种计划充沛复用了已有数据，开发和操作老本绝对低廉。
流量诊断
流量诊断这类场景是对举荐零碎召回的各阶段流量进行实时监控剖析，从而为举荐零碎提供策略优化倡议。同时，也可能改善商家的流量获取、为经营同学排查 case 提效。
流量数据和其余业务数据相比，自身的数据量级十分大，且属于单条事件型数据，数据没有业务主键。需要上，通常须要察看工夫窗口内的趋势性指标。
针对这类场景，数据湖计划就体现出了其解决海量数据的适用性。在解决方案中，是将流量数据增量入湖，以 append 的形式写入 non_index 类型的湖表，定时 15 分钟调度进行窗口汇总计算，通过 Presto 反对近实时剖析诊断。对于更简单的计算或者离线的业务需要，也能够定时同步到 Hive 表，在满足了近实时剖析的同时，也实现了离线的复用。
物流监控
物流监控的业务需要是串联物流链路中的关键性业务节点，比方包裹的发货、揽收、签收，为经营同学提供物流单的全景图，帮忙商家实现物流的实时监控。
物流监控场景最大的特点是，物流履约的过程中，波及的业务零碎多，数据源多，且没有对立的业务主键。从另一方面来讲，因为物流自身的业务链路比拟长，对于数据的观测的时效性不高，可延缓至分钟级。
对于多业务零碎多数据源关联问题，一种传统的实现形式是做多源 join 的操作，然而 join 操作须要 Flink 保护大状态，其次是计算复杂度也比拟高。为了解决该问题，咱们利用字节数据湖多源拼接性能：在业务零碎上、上游的两两数据源共用主键状况下，每个数据源各自更新其业务字段到两头后果湖表中，再将多个两头后果表做拼接，从而实现了多业务零碎数据源的串联。由此利用了湖表的个性代替了计算中的 join 操作，简化 stateful 计算。下图所示的具体例子可供参考。
危险治理
危险治理是电商交易业务中不可或缺的环节。危险治理通过会话、举报、评论、交易等多业务视角去近实时地剖析，预判出商家的欺诈行为，或者辨认黑灰产业、资金资损的危险事件。这类需要的特点是：对于实时性要求不高（业务变动 15 分钟可见），然而须要反对灵便的自主查问，来满足上游报表、看板，数据集等多样的需要。
其次，危险治理须要关联多个数据域，进行整体的危险排查。比方推断疑似黑灰产商家，须要查验资质信息、举报信息或者交易的信息。在剖析的过程中，须要关联很多离线维表来获取商家的资质、等级、评分等信息，再做最终的预判。这类需要特点和近实时剖析所反对的场景是相吻合的。因而，可采纳基于数据湖的解决方案，利用数据湖的海量低加工的数据处理个性，将多数据源实时增量入库，防止过多的 join 或者是汇总计算，同时又把离线的表去做复用。整体间接面向查问引擎，由用户去决定在查问剖析时候的 schema，也就是转化为 schema on read 的模式。
8. 运维型场景实际
该类场景面向的用户次要是：数据研发人员、数据运维人员。
数据产品异动监控
指标异动监控是数据生产中十分重要的环节，通过在数据内容层面提前感知问题，有助于问题的疾速定位和解决，保障数据产出的 SLA。在实践中，如果仅仅监控计算组件：比方监控 Flink、Spark 等组件 metrics、Kafka 的 lag、数据库性能，并不能无效的保障数据产品的 SLA。对于实时计算链路来说，因为兜底逻辑，或者源数据脏数据等起因，即便计算链路上的组件没有问题，最初出现给用户的指标仍有可能不合乎预期。
为了更好的查问和剖析两头后果，须要将音讯队列和存储组件中的的数据落盘，以往的形式是：离线小时表的模式同步到 Hive 中，又或者是落盘到老本较高的 OLAP 数据库中。然而以后，能够通过将两头后果近实时增量同步至数据湖，在湖中反对多种类型的剖析监控，比如说多数据源对照，全局异样检测，大型商家或要害 KOL 达人的实体抽测等等。从而实现了操作简便、老本低廉的对数据内容的运维。
实时音讯落盘检测
下图是大家比拟相熟的实时数据链路，和离线链路最大的不同之处在于两头的计算结果都是基于音讯队列存储，不反对数据的全局观测和整体数据校验。
通过 CDC 将音讯队列里的数据落盘到数据湖中，实现两头数据的全面可见、可测，对于进步数据研发同学的效率和数据品质有很大帮忙。
将来挑战与布局
随着在抖音电商场景的落地，数据湖技术在近实时场景反对业务的可行性失去了验证。最初从数据研发的角度，讲一下数据湖将来的挑战和布局。
- 为了今后接入更多、更大数据量的业务，对数据湖性能提出了更高的要求。对于实时数仓来说，次要是数据可见性晋升和数据查问 RT 的晋升。
- 和 Flink、Spark 更深度集成，例如在 failover 阶段提供更强的稳定性保障。
- 在良好的读写性能、稳定性保障的根底上，由近实时剖析型利用转向近实时产品型利用。
点击跳转火山引擎湖仓一体剖析服务 LAS 官网理解更多
