同步业务库的数据到ODS层，之前一直是全量同步数据，主要考虑IO太大，耗时太长，重复拉取同样的数据，现在考虑增量同步的方式实现，同时对库表数据做分区。
公司主营业务：成都网站设计、网站建设、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。成都创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联推出仓山免费做网站回馈大家。
增量同步主要分为两步，第一步，存量数据一次性同步；第二步，在存量数据的基础之上，做增量；后期的每一次同步都是增量同步。以下是具体同步方案：
用Sqoop同步表中全部数据到Hive表中；
a．根据hive中最大更新时间，用Sqoop提取更新时间为这个时间之后的增量数据；
1）获取表的所有列，把datetime和timestamp类型，统一在java中映射成TIMESTAMP类型，脚本如下：
2） 用sqoop import拉取数据，脚本如下：
1）创建增量同步的sqoop job，脚本如下：
a、从hive中获取表的最大更新时间
b、以上面获取的最大更新时间，作为起点，创建sqoop job，脚本如下：
c、创建sqoop job之后，就是执行job了，脚本如下：
具体参数详解，参考：
照你的需求来看，可以有两种方式，一种是分表，另一种是分区 首先是分表，就像你自己所说的，可以按月分表，可以按用户ID分表等等，至于采用哪种方式分表，要看你的业务逻辑了，分表不好的地方就是查询有时候需要跨多个表。 然后是分区，分区可以将表分离在若干不同的表空间上，用分而治之的方法来支撑无限膨胀的大表，给大表在物理一级的可管理性。将大表分割成较小的分区可以改善表的维护、备份、恢复、事务及查询性能。分区的好处是分区的优点： 1 增强可用性：如果表的一个分区由于系统故障而不能使用，表的其余好的分区仍然可以使用； 2 减少关闭时间：如果系统故障只影响表的一部分分区，那么只有这部分分区需要修复，故能比整个大表修复花的时间更少； 3 维护轻松：如果需要重建表，独立管理每个分区比管理单个大表要轻松得多； 4 均衡I/O:可以把表的不同分区分配到不同的磁盘来平衡I/O改善性能； 5 改善性能：对大表的查询、增加、修改等操作可以分解到表的不同分区来并行执行，可使运行速度更快； 6 分区对用户透明，最终用户感觉不到分区的存在。
建立两个单域的表格。一个表格中为姓名列表(表格名：data)。
另一个表格中是所插入字符的字符数(表格名：chars)。在data表格中定义一个触发器。
每次在其中插入一个新姓名时，chars表格中运行的总数就会根据新插入记录的字符数目进行自动更新。
(见列表A)
mysql CREATE TABLE data (name VARCHAR(255));
Query OK, 0 rows affected (0.09 sec)
mysql CREATE TABLE chars (count INT(10));
Query OK, 0 rows affected (0.07 sec)
mysql INSERT INTO chars (count) VALUES (0);
Query OK, 1 row affected (0.00 sec)
mysql CREATE TRIGGER t1 AFTER INSERT ON
data FOR EACH ROW UPDATE chars SET count = count + CHAR_LENGTH(NEW.name);
Query OK, 0 rows affected (0.01 sec)
列表A
理解上面代码的关键在于CREATE TRIGGER命令，被用来定义一个新触发器。这个命令建立一个新触发器，假定的名称为t1，每次有一个新记录插入到data表格中时，t1就被激活。
在这个触发器中有两个重要的子句：
AFTER INSERT子句表明触发器在新记录插入data表格后激活。
UPDATE chars SET count = count + CHAR_LENGTH(NEW.name)子句表示触发器激活后执行的SQL命令。在本例中，该命令表明用新插入的data.name域的字符数来更新 chars.count栏。这一信息可通过内置的MySQL函数CHAR_LENGTH()获得。
放在源表格域名前面的NEW关键字也值得注意。这个关键字表明触发器应考虑域的new值(也就是说，刚被插入到域中的值)。MySQL还支持相应的OLD前缀，可用它来指域以前的值。
可以通过调用SHOW TRIGGER命令来检查触发器是否被激活，如列表B所示。
mysql SHOW TRIGGERS\G
*************************** 1. row ***************************
?Trigger: t1
?Event: INSERT
?Table: data
Statement: UPDATE chars SET count = count + CHAR_LENGTH(NEW.name)
Timing: AFTER
?Created: NULL
ql_mode:
1 row in set (0.01 sec)
列表B
激活触发器后，开始对它进行测试。试着在data表格中插入几个记录：
mysql INSERT INTO data (name) VALUES ('Sue'), ('Jane');
Query OK, 2 rows affected (0.00 sec)
Records: 2?Duplicates: 0?Warnings: 0
然后检查chars表格看触发器是否完成它该完成的任务：
mysql SELECT * FROM chars;
+-------+
| count |
+-------+
| 7|
+-------+
1 row in set (0.00 sec)
data表格中的INSERT命令激活触发器，计算插入记录的字符数，并将结果存储在chars表格中。如果往data表格中增加另外的记录，chars.count值也会相应增加。
触发器应用完毕后，可有DROP TRIGGER命令轻松删除它。
mysql DROP TRIGGER t1;
Query OK, 0 rows affected (0.00 sec)
注意：理想情况下，你还需要一个倒转触发器，每当一个记录从源表格中删除时，它从字符总数中减去记录的字符数。这很容易做到，你可以把它当作练习来完成。提示：应用BEFORE DELETE ON子句是其中一种方法。
现在，要建立一个审计记录来追踪对这个表格所做的改变。这个记录将反映表格的每项改变，并向用户说明由谁做出改变以及改变的时间。需要建立一个新表格来存储这一信息(表格名：audit)，如下所示。(列表C)
mysql CREATE TABLE audit (id INT(7), balance FLOAT, user VARCHAR(50)
NOT NULL, time TIMESTAMP NOT NULL);
Query OK, 0 rows affected (0.09 sec)
列表C
接下来，我将在accounts表格中定义一个触发器。(列表D)
mysql CREATE TRIGGER t1 AFTER UPDATEON accounts
FOR EACH ROW INSERT INTO audit (id, balance, user, time)
VALUES (OLD.id, NEW.balance, CURRENT_USER(), NOW());
Query OK, 0 rows affected (0.04 sec)
列表D
要是已经走到这一步，就很容易理解。accounts表格每经历一次UPDATE，触发器插入(INSERT)对应记录的id、新的余额、当前时间和登录audit表格的用户的名称。
实现中的例子：用触发器审计记录
既然了触发器的基本原理，来看一个稍稍复杂的例子。常用触发器来建立一个自动“审计记录”，以记录各种用户对数据库的更改。为了解审计记录的实际应用，请看下面的表格(表格名：accounts)，它列出了一个用户的三个银行账户余额。(表A)
mysql SELECT * FROM accounts;
+----+------------+---------+
| id | label| balance |
+----+------------+---------+
|1 | Savings #1 |500 |
|2 | Current #1 |2000 |
|3 | Current #2 |3500 |
+----+------------+---------+
3 rows in set (0.00 sec)
表A
然后，检查触发器是否被激活：
mysql SHOW TRIGGERS \G
*************************** 1. row ***************************
?Trigger: t1
?Event: UPDATE
?Table: accounts
Statement: INSERT INTO audit (id, balance, user, time)
VALUES (OLD.id, NEW.balance, CURRENT_USER(), NOW())
Timing: AFTER
?Created: NULL
Sql_mode:
1 row in set (0.01 sec)
再来看最后的结果(列表E)：
mysql UPDATE accounts SET balance = 500 WHERE id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1?Changed: 1?Warnings: 0
mysql UPDATE accounts SET balance = 900 WHERE id = 3;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1?Changed: 1?Warnings: 0
mysql UPDATE accounts SET balance = 1900 WHERE id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1?Changed: 1?Warnings: 0
列表E
注意，对accounts表格所作的改变已被记录到audit表格中，将来如果出现问题，可以方便地从中进行恢复。
mysql SELECT * FROM audit;
+------+---------+----------------+---------------------+
| id| balance | user| time|
+------+---------+----------------+---------------------+
|1 |500 | root@localhost | 2006-04-22 12:52:15 |
|3 |900 | root@localhost | 2006-04-22 12:53:15 |
|1 |1900 | root@localhost | 2006-04-22 12:53:23 |
+------+---------+----------------+---------------------+
3 rows in set (0.00 sec)
分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控，详细来讲，主要有下面几个原因：
清晰数据结构：
每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
方便数据血缘追踪：
简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
减少重复开发：
规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
把复杂问题简单化：
将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤 ，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
屏蔽原始数据的异常:
屏蔽业务的影响，不必改一次业务就需要重新接入数据
数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上 数据分为三个层 ， 数据运营层 、 数据仓库层 和 数据服务层 。基于这个基础分层之上添加新的层次，来满足不同的业务需求。
数据运营层(ODS)
Operate data store（操作数据-存储），是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装入ODS层 。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。例如：MySQL里面的一张表可以通过sqoop之间抽取到ODS层ODS层数据的来源方式：
数据仓库层（DW）
Data warehouse（数据仓库） 。在这里， 从ODS层中获得的数据按照主题建立各种数据模型 。例如 以研究人的旅游消费为主题的数据集中 ，便可以结合航空公司的登机出行信息，以及银联系统的刷卡记录，进行结合分析，产生数据集。在这里，我们需要了解四个概念：维（dimension）、事实（Fact）、指标（Index）和粒度（ Granularity）。
数据服务层/应用层（ADS）：
Application Data Service(应用数据服务)。该层主要是提供数据产品和数据分析使用 的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。例如：我们经常说的报表数据，或者说那种大宽表，一般就放在这里。
ODS 数据准备层
功能：
ODS层是数据仓库准备区，为DWD层提供基础原始数据，可减少对业务系统的影响
建模方式及原则：
从业务系统增量抽取 、保留时间由业务需求决定、 可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致 、按主题逻辑划分
DWD 数据明细层
功能：
为DW层提供来源明细数据，提供业务系统细节数据的长期沉淀 ，为未来分析类需求的扩展提供历史数据支撑
建模方式及原则：
数据模型 与ODS层一致，不做清洗转换处理 、为支持数据重跑 可额外增加数据 业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理
DW(B/S) 数据汇总层
功能：
为DW、ST层提供细粒度数据，细化成DWB和DWS；
DWB是根据DWD明细数据进行转换 ，如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理、IP清晰转换、账号余额清洗、资金来源清洗等；
DWS是根据DWB层数据按各个维度ID进行高粒度汇总聚合 ，如按交易来源，交易类型进行汇合
建模方式及原则：
聚合、汇总增加派生事实；
关联其它主题的事实表，DW层可能会跨主题域；
DWB保持低粒度汇总加工数据，DWS保持高粒度汇总数据；
数据模型可能采用反范式设计，合并信息等。
Data Market (数据集市)层
功能：
可以是一些宽表，是根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段进行汇总统计并作为单独的列进行存储 ；
满足一些特定查询、数据挖掘应用
应用集市数据存储
建模方式及原则：
尽量减少数据访问时计算 (优化检索)
维度建模，星型模型；
分表存储
ST 数据应用层（ADS层）
功能：
ST层面向用户应用和分析需求 ，包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析， 面向最终结果用户
适合做OLAP、报表模型，如ROLAP,MOLAP
根据DW层经过聚合汇总统计后的粗粒度事实表
建模方式及原则：
本篇文章主要讲解数仓项目中为什么分层，比如 我们在完成一个需要的需求的时候也许只需要一个复杂的SQL语句就可以完成。但一个复杂的SQL语句方便后面维护吗？当出现了问题方便追踪吗？ 这时候就体现出分层的好处。顺便给大家分享阿里的数仓模型是什么样的。信自己，努力和汗水总会能得到回报的。我是大数据老哥，我们下期见~~~
