ODS层

一.基本概念

数据引入层（ODS，Operational Data Store，又称数据基础层）：将原始数据几乎无处理地存放在数据仓库系统中，结构上与源系统基本保持一致，是数据仓库的数据准备区。这一层的主要职责是将基础数据同步、存储。

一般来说 ODS 层的数据和源系统的数据是同构的，主要目的是简化后续数据加工处理的工作。从数据粒度上来说 ODS 层的数据粒度是细的。ODS 层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存 3-6 个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存。

注意：在这层，理应不是简单的数据接入，而是要考虑一定的数据清洗，比如异常字段的处理、字段命名规范化、时间字段的统一等，一般这些很容易会被忽略，但是却至关重要。特别是后期我们做各种特征自动生成的时候，会十分有用。
注意：有的公司ODS层不会做太多数据过滤处理,会放到DWD层来处理。有的公司会在一开始时就在ODS层做数据相对精细化的过滤.这个并没有明确规定,看每个公司自己的想法和技术规范。
一般企业开发时,都会对原始数据存入到ODS时,做一些最基本的处理。

二.ODS数据的基本特征

ODS中的数据具有以下4个基本特征：

1. 面向主题的：进入ODS的数据是来源于各个操作型数据库以及其他外部数据源，数据进入ODS前必须经过 ETL过程（抽取、清洗、转换、加载等）。
2. 集成的：ODS的数据来源于各个操作型数据库，同时也会在数据清理加工后进行一定程度的综合。
3. 可更新的：可以联机修改。这一点区别于数据仓库。
4. 当前或接近当前的：“当前”是指数据在存取时刻是最新的，“接近当前”是指存取的数据是最近一段时间得到的。

三.ODS的功能

1. 实现企业级的OLTP操作
   传统的操作型数据库往往只存放企业某一类业务或者某一个部门的数据，因此无法面向企业全局数据的OLTP，而ODS可以实现。因为ODS的数据是面向整个企业进行集成汇总的，克服了原来面向应用的操作型数据库数据分散的缺陷。
2. 实现即时的OLAP操作
   在数据仓库上进行OALP，往往由于数据量十分庞大而需要较长的时间。而在企业实际应用中，对于一些较低层次的决策，往往并不需要太多的历史数据，可能只需要参考当前的或者接近当前的数据就可以完成，并且要求具有较快的响应时间，因此数据仓库显然无法满足这样的要求，但是ODS可以实现。ODS中不仅有面向企业全局的细节数据和汇总数据，而且规模比数据仓库小，具有较强的实时响应能力。

四.ODS的业务目标

a.统一准实时的数据共享
b.生产经营数据质量检查
c.统一客户视图的提供与展示
d.生产经营报表统一的提供与展示
e.关键生产经营绩效指标与经营风险的监控
f.跨系统的批量计算

五.数据来源区分

数据按照时间分区存储,一般是按照天,也有公司使用年、月、日三级分区做存储的。
进行最基本的数据处理,如格式错误的丢弃,关键信息丢失的过滤掉等等。
数据实时离线
离线方面：每日定时任务型：跑批任务，业务库，比如我们典型的日计算任务，这里经常会使用 Sqoop 来抽取，比如我们每天定时抽取一次。每天凌晨算前一天的数据，早上起来看报表。这种任务经常使用 Hive、Spark 来计算，最终结果写入 Hive、Hbase、Mysql、Es 或者 Redis 中。
实时数据：日志埋点数据或者业务库，这部分主要是各种实时的系统使用，比如我们的实时推荐、实时用户画像，一般我们会用 Spark Streaming、Flink 来计算，最后会落入 Es、Hbase 或者 Redis 中。数据源是业务数据库，可以考虑用 Canal 监听 Mysql 的 Binlog，实时接入即可，然后也是收集到消息队列中，最终再由 Camus 拉取到 HDFS。
数据主要来源：
数据源是业务数据库，公司所有的系统产生的数据是通过在客户端埋点上报，收集用户的行为日志，以及一些后端日志的日志类型数据源。对于埋点行为日志来说，一般会经过一个这样的流程，首先数据会上报到 Nginx 然后经过 Flume 收集，然后存储到 Kafka 这样的消息队列，然后再由实时或者离线的一些拉取的任务，拉取到我们的离线数据仓库 HDFS外部数据（包括合作数据以及爬虫获得的数据），将所采集的数据汇总到一起。