数据流转到数仓会进行一些统一化的管理,数仓是如何分层的呢?
受京东业务复杂度和数据体量的影响,整体分层较细,分为:数据缓冲层(BDM)、贴源数据层(FDM)、基础数据层(GDM)、公共数据层(ADM)、应用数据层(APP)五层。 ① BDM层
是源业务系统的一些数据,会进行永久性保存。 ② FDM层
主要是从报文日志转化成业务格式,对业务字段进行拆解、排序和数据回写等,例如用户逛京东时前期未登录,最终下单时才登陆,那对用户全链路回写便是在这一层进行。 ③ GDM层
按照主题域进行标准化封装,整体会屏蔽生产系统干扰,同时会处理数据回灌事情。 ④ ADM层
ADM是公共数据层,面向主题、面向业务过程的数据整合,目前划分成两层:ADM-D、ADM-S。
① 基础数据层
离线数仓最下面一部分是基础数据,主要面向实体模型建设,按照数据渠道和不同类型做数据整合,例如渠道:app、pc、m等;日志类型:浏览、点击、曝光等。 ② 公共数据层
这一层也是大家应用比较广泛的一层,上面也提到了adm面向业务过程的模型建设,这层也是分成了明细和汇总两层。在明细层,我们会把所有的业务口径沉淀到adm明细中,封装各种业务标识,保障数据口径统一管理,避免口径二义性,同时,为数据可视化管理,提供源数据依赖。 ③ 应用数据层
应用层主要是面向数据看板的建设,提供预计算和OLAP两种方式服务模式,这一层整体上会很薄,重点解决数据引擎查询效率问题,高频访问的维度提供预计算、低频应用的数据由OLAP方式提供数据服务。 ④ 数据服务层
面向多维数据分析场景,进行指标和维度的统一管理,以及服务接口的可视化管理,对外提供统一的数据服务。 5. 京东零售——流量实时数仓架构
① 数据倾斜的原因及处理方式
数据倾斜出现的一个主要原因是数据分布不均,出现热点key。对于数据倾斜的处理方案,比较常见的有:优化参数,如增加reduce的个数、过滤一些异常值、赋随机值,或者按经验值设置固定阈值,把大于某阈值的数据单独处理。赋随机数的处理方式,当任务执行过程中,某个节点异常,切换新节点重新执行,随机数据会发生变化,导致数据异常。通过这种经验值设定阈值的一个弊端是,在不同的场景下,不容易界定阈值大小,包括对于热点key的识别,通常也只能事后发现处理。
② 数据倾斜的解决方案
基于此,我们在探索的过程中建立了一套智能监测倾斜的任务。
首先,利用实时的数据,提前对数据进行监测,针对数据分布特点,通过3倍标准差确定离群点,离群点即倾斜阈值。
其次,根据倾斜阈值计算分桶数量。
最后,按照对列资源在不同时段的健康度进行作业编排。 ③ 如何寻找热点key及倾斜阈值
热key寻找的核心思想,就是根据数据的分布特点,通过3倍标准差确定离群点,离群点即倾斜阈值,如下图所示,整体的数据是呈右偏分布,我们通过两次3倍标准差得到最后的倾斜阈值X2。
第二步计算分桶的数量,根据整体的数据分布情况看,第一阶段的拒绝域面积与第二阶段的拒绝域面积相等。根据积分原理,频率绝对数与频次绝对数呈反比,因概率密度分布曲线未知,所以用两次离群点的频次均值比例,代表两次抽样数据量比例,进而得到分桶数。
首先,目前我们基于Flink+Spark的方式来做流批一体的探索。图中可以看到传统的Lambda数据架构有一个很大的特点:实时和离线是两套不同的数据链路。整体的数据处理过程中,研发的运维成本相对较高,而且两条不同的数据链路,会容易导致数据口径上的差异。 后续通过FlinkSQL+数据湖存储实现同一套代码两种计算模式,同时保证计算口径一致性。同时也会有一些挑战,开发模式的改变,CDC(change data capture)延迟目前是分钟级延迟,如果调整为秒级,频繁提交,会生成很多小版本,对数据湖的吞吐量造成影响,总体来说,在部分应用场景下存在一定局限性,但分钟级延迟可以满足大多数的实时应用场景,对于研发成本和效率都会有较大提升,当然,目前也在不断的完成和探索。总体来说,目前在一些特殊场景下具有一定的局限性。