网易实时数仓实践与展望.docxVIP

网易实时数仓实践与展望 2021-09-14 “数据智能” (Data Intelligence) 有一个必需且基础的环节，就是数据仓库的建设，同时，数据仓库也是公司数据进展到肯定规模后必定会供应的一种基础服务。从智能商业的角度来讲，数据的结果代表了用户的反馈，猎取结果的准时性就显得尤为重要，快速的猎取数据反馈能够挂念公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不行替代的作用。 本文次要叙述知乎的实时数仓实践以及架构的演进，这包括以下几个方面 实时数仓 1.0 版本，主题：ETL 规律实时化，技术方案：Spark Streaming。 实时数仓 2.0 版本，主题：数据分层，目标计算实时化，技术方案：Flink Streaming。 实时数仓将来展望：Streaming SQL 平台化，元信息管理系统化，结果验收自动化。 实时数仓 1.0 版本 1.0 版本的实时数仓次要是对流量数据做实时 ETL，并不计算实时目标，也未建立起实时数仓体系，实时场景比较单一，对实时数据流的处理次要是为了提升数据平台的服务力量。实时数据的处理向上依靠数据的收集，向下关系到数据的查询和可视化，下图是实时数仓 1.0 版本的全体数据架构图。 第一部分是数据采集，由三端 SDK 采集数据并通过 Log Collector Server 发送到 Kafka。其次部分是数据 ETL，次要完成对原始数据的清洗和加工并分实时和离线导入 Druid。第三部分是数据可视化，由 Druid 担任计算目标并通过 Web Server 协作前端完成数据可视化。 其中第一、三部分的相关内容请分别参考： 知乎客户端埋点流程、模型和平台技术， ?Druid 与知乎数据分析平台，此处我们具体引见其次部分。由于实时数据流的稳定性不如离线数据流，当实时流消灭问题后需要离线数据重刷历史数据，因而实时处理部分我们接受了 lambda 架构。 Lambda 架构有高容错、低延时和可扩展的特点，为了实现这一设计，我们将 ETL 工作分为两部分：Streaming ETL 和 Batch ETL。 Streaming ETL 这一部分我会引见实时计算框架的选择、数据正确性的保证、以及 Streaming 中一些通用的 ETL 规律，最终还会引见 Spark Streaming 在实时 ETL 中的稳定性实践。 计算框架选择 在 2021 年年初，业界用的比较多的实时计算框架有 Storm 和 Spark Streaming。Storm 是纯流式框架，Spark Streaming 用 Micro Batch 模仿流式计算，前者比后者更实时，后者比前者吞吐量大且生态系统更完善，考虑到知乎的日志量以及初期对实时性的要求，我们选择了 Spark Streaming 作为实时数据的处理框架。 数据正确性保证 Spark Streaming 的端到端 Exactly-once 需要下游支持幂等、上游支持流量重放，这里我们在 Spark Streaming 这一层做到了 At-least-once，正常情况下数据不重不少，但在程序重启时可能会重发部分数据，为了实现全局的 Exactly-once，我们在下游做了去重规律，关于如何去重后面我会讲到。 通用 ETL 规律 ETL 规律和埋点的数据结构息息相关，我们全部的埋点共用同一套 Proto Buffer Schema，大致如下所示。 复制代码 message LogEntry { optional BaseInfo base = 1; optional DetailInfo detail = 2; optional ExtraInfo extra = 3; } BaseInfo：日志中最基本的信息，包括用户信息、客户端信息、时间信息、网络信息等日志发送时的必要信息。DetailInfo：日志中的视图信息，包括当前视图、上一个视图等用于定位用户所在位置的信息。ExtraInfo：日志中与特定业务相关的额外信息。 针对上述三种信息我们将 ETL 规律分为通用和非通用两类，通用规律和各个业务相关，次要应用于 Base 和 Detail 信息，非通用规律则是由需求方针对某次需求提出，次要应用于 Extra 信息。这里我们列举 3 个通用规律进行引见，这包括：动态配置 Streaming、UTM 参数解析、新老用户识别。 动态配置 Streaming 由于 Streaming 任务需要 7 * 24 小时运转，但有些业务规律，比如：存在一个元数据信息中心，当这个元数据发生变化时，需要将这种变化映射到数据流上便利下游使用数据，这种变化可能需要停止 Streaming 任务以更新业务规律，但元数据变化的频率格外高，且在元