京东零售海量日志数据处理实践.docxVIP

京东零售海量日志数据处理实践 01 京东零售流量数仓架构 1. 京东零售——流量简介 ① 什么是流量？? 简单来说，流量就是用户作用在京东页面上，产生一系列行为数据的集合。 ② 流量数据的来源 数据来源主要是移动端和PC端，以及线下店、外部采买、合作商的数据等。 这些数据是如何流转到数仓的呢？ 2. 京东零售——流量数据处理架构 由架构图可以看出，对不同的终端采取不同的采集模式；例如，对APP原生页面采取SDK的采集模式，对于PC、H5页面是JS采集，数据采集后按照实时和离线双写，离线直接写到CFS分布式文件系统中，每小时从CFS拉取数据文件，同时对数据文件大小、采集ip进行监控，防止数据丢失；实时是以白名单的方式动态配置，写到kafka中，最后将数据入仓。 3. 京东零售——流量数仓分层介绍 数据流转到数仓会进行一些统一化的管理，数仓是如何分层的呢？ 受京东业务复杂度和数据体量的影响，整体分层较细，分为：数据缓冲层（BDM）、贴源数据层（FDM）、基础数据层（GDM）、公共数据层（ADM）、应用数据层（APP）五层。 ① BDM层 是源业务系统的一些数据，会进行永久性保存。 ② FDM层 主要是从报文日志转化成业务格式，对业务字段进行拆解、排序和数据回写等，例如用户逛京东时前期未登录，最终下单时才登陆，那对用户全链路回写便是在这一层进行。 ③ GDM层 按照主题域进行标准化封装，整体会屏蔽生产系统干扰，同时会处理数据回灌事情。 ④ ADM层 ADM是公共数据层，面向主题、面向业务过程的数据整合，目前划分成两层：ADM-D、ADM-S。 ADM-D负责统一的数据口径封装，提供各主题统一维度和指标的最细粒度数据； ADM-S提供各主题统一维度和指标的聚合数据， 为各业务方提供统一口径的共享数据。 ⑤ APP层 数据看板的数据整合，也可以进行一些跨主题的聚合数据处理。 ⑥ 维度层 DIM层主要就是一些通用的维度数据。 基于以上的数仓分层方案，来看下京东流量数仓架构在离线和实时上别分是如何处理的。 4. 京东零售-流量离线数仓架构 ① 基础数据层 离线数仓最下面一部分是基础数据，主要面向实体模型建设，按照数据渠道和不同类型做数据整合，例如渠道：app、pc、m等；日志类型：浏览、点击、曝光等。 ② 公共数据层 这一层也是大家应用比较广泛的一层，上面也提到了adm面向业务过程的模型建设，这层也是分成了明细和汇总两层。在明细层，我们会把所有的业务口径沉淀到adm明细中，封装各种业务标识，保障数据口径统一管理，避免口径二义性，同时，为数据可视化管理，提供源数据依赖。 ③ 应用数据层 应用层主要是面向数据看板的建设，提供预计算和OLAP两种方式服务模式，这一层整体上会很薄，重点解决数据引擎查询效率问题，高频访问的维度提供预计算、低频应用的数据由OLAP方式提供数据服务。 ④ 数据服务层 面向多维数据分析场景，进行指标和维度的统一管理，以及服务接口的可视化管理，对外提供统一的数据服务。 5. 京东零售——流量实时数仓架构 实时数仓与离线数仓的建设理念是基本一致的。 RDDM是分渠道、分站点、分日志类型的实时数据流，构建过程中主要考虑解耦，如果只消费部分数据，依然需要全量读取，对带宽、i/o都是一种浪费。同时，也方便下游按照业务实际情况进行数据融合。 RADM面向业务场景，在RDDM的基础上进行整体封装整合，例如商详、来源去向、路径树等业务场景。 在整体封装后，数据会接入到指标市场，按照统一的接口协议和元数据管理规范进行录入，对外提供统一的数据服务。 以上主要介绍了京东流量场景的数据处理架构，接下来我们结合一个京东实际案例，讲述京东特殊场景下的数据处理方案。 02 京东零售场景的数据处理 1. 京东零售——流量挑战 首先是数据爆炸式的增长。2015年至今，整体的数据量翻了约十几倍，但资源情况并没有相应成比例的增长。其次，业务的复杂度升高，包括新增了小程序、开普勒、线下店的一些数据以及并购的企业的数据等，因此整体的数据格式以及完备度上还是存在较大差异的。再次，随着业务发展，流量精细化运营的场景增多，但数据服务的时效并没有较大变化，需要我们在有限时间内处理一些更多更大体量的数据，以满足更多场景化应用。特别是京东刷岗这样的场景，对数据的范围、需要处理的数据量，以及数据时效都是一个比较大的挑战。 2. 海量数据更新实践——刷岗 什么是刷岗？将发生在该SKU的历史事实数据，按照必威体育精装版的SKU对应运营人员、岗位、部门等维度信息，进行历史数据回刷。 刷岗在京东也经历了多个阶段，从最初数据量较小，采取全量刷岗的模式，后续逐渐升级成增量的刷岗。后续采取OLAP的刷岗模式，也就是将数据写到CK中，通过Local join进行关联查询。目前我们通过iceberg+ol