本文为字节跳动根据数据湖技能的近实时场景实践，首要包括以下几部分内容：数据湖技能的特性、近实时技能的架构、电商数仓实践、未来的应战与规划。

▌数据湖技能特性

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 阶段供给更强的稳定性保证。

• 在杰出的读写功能、稳定性保证的基础上，由近实时剖析型运用转向近实时产品型运用。

跳转 www.volcengine.com/product/las…