大数据开发第一站ODS篇_ods cdm ads

前言

互联网的高速发展，行业内事实的分工有了精细化，不过网上的段子还停留在那些程序员加班熬夜掉光头发的梗，很多人的观念也是停留在敲敲打打就倒腾出一个软件的层面吧，前一阵接触了一些求职者，面向的是大数据开发工程师、数据开发、数仓工程师的这些岗位，其实面向的工种就是写SQL的那群人，但是发现基本都是一开头就是结束。因为技术人员都是觉得高并发，底层，百度起来也方便,这写个SQL能聊出什么花来呢，今天我就以ODS的话题，聊一聊关于数仓里面的一些事情。

不断变化的数仓

数仓一面戛然而止的问题

但凡数据开发，一定会问一个问题:“你了解数仓分层么”，我们收到几乎清一色的回答都是，知道啊，就是ods,dwd,dws,adm呀，进一步问一下，为什么需要这样子划分呢？或者比如说如果不要dwd可以么？这种时候很多情况要么是说团队内这样子划分的，要么也说不上所以然来，然后就没有然后了。

回顾数仓

这个是阿里巴巴Dataphin中的数仓划分，原文

传统的数据其实就是ods->dwd->dws->adm这种划分，实际上图中给我们的是叫做
ods->cdm->ads这种划分，dwd、dim、dws其实是在cdm里面的，目测也不是那么一串下去的。再看看下图京东的划分。

一看还多出来了一些缓冲层啥的，其他也不枚举了，数仓的划分一直就没有规定说一定需要怎么划分，只是在数据加工的时候有些本身的形态，需要估计整个数仓的业务覆盖、性能、质量、成本以及团队协作效率的因素，这个时候出来的形态才是真正的样子。

ODS的话题

ods和炼油的对应关系

其实面试中如果问了数仓分层的话，一定会接着问(ods|dwd|dws|adm)是什么这类的问题，常规的对ods的回答大部分就是上游、或者业务数据流入、这些其实都对，但是总感觉少了点什么，触及不到面试官的兴奋点。我们一定听说过大数据就是石油的比喻，这个比喻其实不光是宏观层面，细节层面也是使用的，石油也是经过原油多到工序加工出来的，对于我们的ODS来说就是对应的原油了，我们可以看看石油的加工链路：

我们再看看数据的链路

其实里面核心的逻辑就是，原油经过不断提炼，在各个阶段都可以加工出各种产品，
数据的提炼也是，在ods层面可以也可以加工出各种结果，这种情况取决ods数据的易用程度，大部分情况来说可以有以下的情况：

ODS的划分

模拟信号数据 Analog data

模拟信号相对于数字量而言，指的是取值范围是连续的变量或者数值。模拟数据是指在某个区间产生的连续值，例如，声音、图像、温度、压力，当然这个是工业上的概念搬过来而已，在我们实际大数据处理的时候，例如监控类程序，我们一般会在内存维护一个监控量，再开一个后台线程去读取，还有就是一些程序内部的Metrics信息，还有一些业务监控指标，日志流量这种数据、这一类的特点我们都可以用发送到Kafka消息中，然后用Flume或者Flink之类的进行落盘分析。这一类数据一般没有明确的结构，比如啥里头的JSON啦，需要再加工才能方便使用。

应用程序数据 application data

这一类是指应用程序和业务处理产生、传统的数据放在数据库中（dbms）这类数据特点是数据比较规范，有明确的结构，基本数据库里面的信息拿过来就可以用。

文本数据 textture data

这一类数据就是不会按照特定的格式存储，像网页啦，文档啦，一些直接的文件格式oss信息之类的，这种一般需要比较麻烦的解析才能使用

ods越炼越香

这类的特点就是真正的原始数据，里面的信息是最全的，这类数据的价值在于随着数据加工技术的不断升级，里面过去一些信息没有加工的在未来有可能存在新的价值。大数据的历史并不长，所以记得也必将清楚。大数据的加工一直是不断变化的，大概09-15年左右，那时候我们倒腾一个手写的mapreduce jar还是比较兴奋的阶段，工作中大部分还是处于hive阶段，那个时候hadoop可以做到比较大量的存储，那段时间互联网也是高速发展阶段，已经可以大量采集流量日志了，但是真正的加工也只是计算pv，uv之类的事情，进一步加工的情况不多，再到后面的阶段，流量信息里面的地理位置信息，电量，wifi信号强度，ip地址啥的也会用来做风控使用。再然后呢，随着机器学习技术的不断引进，这些数据价值也不断体现出来，浏览页面的顺序，角度，海拔，还有一些生物信息面部信息指纹也被采集。有人比较好奇，为毛一开始不就可以加工么？这个就是我们的炼油技术了，一方面我们需要知道怎么使用、一方面有时效要求、还一方面需要时效性上有要求才能有效果。大家熟知的各大app推荐技术，一说的大家脑袋里面可以蹦出来很多淘宝、京东、抖音、快手、小红书，像商品推荐，内容推荐这类现在生活依赖的功能想必都很熟悉，因为互联网上面的信息是海量，我们又要快速的推荐，需要技术上做到实时，如果我昨天的数据你今天推荐出来，效果不好，要实现这个事情，需要不断升级系统算法，这个时候才会去提出对这类数据的实时依赖，这就是前后的原因。

ods数据的进一步规范

互联网应用走入寻常百姓家，有一个很涉及我们个人事情，那就是隐私保护，实际上前面很多年的软件没有太多限制的，安卓早期版本一开始就可以拿到你手机的root权限，然后上传你手机的信息，所以我们在互联网上都是裸奔的，这个背景上，国家也是对个人信息立法，企业应当遵循各类通用法。

那这个对ODS是有什么影响么？影响就大了，在以前的加工采集数据的时候ods来说没太多约束，但是在个人信息保护法之后，数据的采集，加工都要遵循这类法规，那么具体ods来说则是会进一步被限制采集的范围，方式方式，简单理解来说未来你想拿ods数据的话需要合法，在使用方式上会有法律主体，加密策略，合约等方式，ods也需要带上这一类使用范围的声明。实际的例子：ods在采集个人信息的时候，需要用户进行授权，如果没有实际的授权则是非法的，这个时候ods的数据范围就只能在约束范围内。可以想到，这个需要一定隐私技术实现的，立法的时间也还不是很久，所以是进一步的规范，那么在不久的几年里面我们ods呈现出来的形态就会发生很大的变化了。

ods的加工特性

不进行任何数据加工

和其他的数据加工不同，ods是强调尽量保持他原有的样子，简单来说，数据内容不允许加工的，因为一旦加工了的话就破坏了最开始的样子，比如说一些字段null，有些强迫症的同学喜欢转化掉，或者过滤掉，这种事情是万万不可以的，因为ods内容不仅仅可以分析业务的指标，同时还能表达出异常情况，比如数据上因为某些系统异常出现了一些Exception的数据，对于实际业务分析可能是没价值，但是对于系统运维同学来说是可以通过这种数据了解到那个时候的异常情况的。

尽量保持全部内容

这个是指存在一些例如日志上面某些数据看起来确实无用，看着很鸡肋就干掉，这个也是不合理的，还是前面的情况，这类信息可能是有不同的使用场景，也有可能短期内还不好加工出来，但是未来会用到

需要可以还原历史

如果是每日增量数据，则需要保存全部的历史分区，如果是变化数据，则需要保留每日快照。实际情况是有一份增量数据和一份全量数据。这个反例就是比如数据每日发生变化，一开始业务觉得是可以使用最新的，但是ods如果只是保留最新的话，未来某一天需要看历史的时候没办法去做分析，因为ods不存在，所以下游的dwd更加没办法加工了

不太关注业务内容

ODS比较成熟的状态是已经工具化接入了，所以ods运维人员处于ods运维的角色，但并不真正负责里面的内容，当然一旦关心内容的话就会很重，在数仓分层中因为也会有下游的dwd层，实际的重数据业务可以依赖dwd，因为这个是一个需要投入很大的工作，同时和ods需要保持原始样子，所以不进行加工，自然也不关注业务内容

保证数据完整性

可能大部分的思维上ods的抽取就是凌晨00:00就抽取就是了，这个在实际情况不是这样子的，首先，业务上是比较难保证那一天的业务真的就在00:00点完成的，尤其是像流量那种，在大促的时候会存在延迟的情况，ODS普遍存在的问题就是数据漂移，数据缺失，类似23:58发生的业务实际要到00:15或者更晚才完成，ods的策略一般是尽量保证数据的完整性，可以多出来数据，但是不能少。一些常见的措施，例如前后跨15分钟数据抽取，在财务数据处理的时候需要配合在线系统做日切检查的方式，还有就是监控数据的完整性，其他严格的可以做幂等校验。

ods稳定性影响

时效、稳定这个其实在任何一个数据开发都有要求，只不过针对ods来说是很底盘的存存在，一旦核心ods延迟，那么整个公司的资源都会强制加剧，这个事情是比较残酷的，对ods来说也是不关注数据内容，所以可以通用化采用一些优化策略，类似分桶，hash之类的操作，需要把时效最大化

ods一般模型设计

一般的ods怎么做模型设计呢？简单说道说道~

模型设计

ods因为他处于最上游的特点，所以设计上一般面向的是时效不同的链路，常规来说一般是需要天全量表、天增量表、小时表,比如说订单表:

ods_pay_order_dd
ods_pay_order_delta
ods_pay_order_delta_hh
1
2
3

链路设计

数据的接入情况很多，系统的数据一般是接入从库，抽取工具也是sqoop,Datax等方式抽取，当下比较多的情况一般是监听binlog的方式获取增量数据，通过增量还原出当天的数据，如图所示：

日切检查

日切本身是账务上面的概念，在银行、财务这一类对数据质量强要求的场景时，是需要做日切的操作的，但是随着大数据的技术发展，业务上对数据的准确性的要求是不断提高，对大数据场景来说之前常规的保证数据的做法一般是把定时的时间往后做调整，但是这种方式只是减少了数据丢失的概率，还是有隐患，现在的数据处理是增加检查节点，这类检查节点就是日切。举例说明，概念上来说日终是银行系统每天下班前，是柜面业务的帐务结算，终了轧帐。日初是指开始上班做的工作前期准备工作的统称。

ods挂在在线跑批的链路之后再开始工作，这类操作就是日切检查。

后记

ods其实还涉及到流批一体操作、在离线联调、模板化加工等诸多话题，作为一个数仓人员来说，ods其实是最最基础的数据依赖，本身的生命周期还是需要有了解的，实际上ods的稳定带来的效益是整体业务的一个稳态，在数仓链路中属于那种不会挂在台面上却是至关重要的角色。