[目录]
- 第一章：概述
- 第二章：整体数据分层
- 第三章：整体实现框架
- 第四章：元数据
- 第五章：ETL
- 第六章：数据校验
- 第七章：数据标准化
- 第八章：去重
- 第九章：增量/全量
- 第十章：拉链处理
- 第十一章：分布式处理增量
- 第十二章：列式存储
- 第十三章：逻辑数据模型（数仓模型）
- 第十四章：数据模型参考
- 第十五章：维模型
- 第十六章：渐变维
- 第十七章：数据回滚
- 第十八章：关于报表
- 第十九章：数据挖掘
数据仓库实践杂谈（十七）——数据回滚
在OLTP系统，数据回滚一般直接依赖于数据库的事务机制，出现问题直接执行回滚操作即可。但在数据仓库中，是无法使用数据库的事务机制的。对于使用关系数据库加载数据的情况，往往会关闭事务以提高效率。毕竟，需要批量加载很多张数据量很大的表的情况下，如果要在一个事务里面完成所有数据的加载，除了对服务器要求很高（undo表空间巨大）之外，一旦出意外，只能全部回滚，不能实现断点恢复。另外，Hadoop生态的平台并不支持事务。这种情况下，就需要自己记下来所做的操作，或者仓库中表的初始状态，以便出问题之后恢复。
考虑会出现的问题或者意外：
- 数据问题
前面谈数据校验的时候说到过数据有问题往往是无法重试恢复，并且很有可能无法当时修复的。所以，数据校验很重要，而且，数据校验必须单独一个步骤，全部数据校验通过之后，才开始真正的数据处理和加载。
如果校验规则不完善导致进去的数据在后期处理中无法进行或者报错，会很麻烦。排查脏数据是一个浩瀚的工作。而且，还很可能系统运行期间不报错，直到用户看到结果才发现有问题。这种情况很有可能就得把数据恢复 - 程序bug
程序bug也是个无解的事情，尤其是上线初期，测试不充分，导致某些处理程序跑出bug。这种问题是需要技术人员及时解决，同时把当前处理程序的数据恢复。 - 环境故障
网络中断、机器崩溃等导致当前处理失败，环境恢复之后（机器崩溃情况会把操作迁移到集群其他服务器），需要把失败的操作步骤恢复到操作之前，然后重新当前步骤，继续往下走。
实际上，数据处理的整个过程是由一组（很多）可以单独运行的处理程序按照特定的顺序组成。和工作流定义任务一样，需要定义任务的执行顺序，分支/条件分支，回退等。因为数据处理的工作量巨大，为了提高效率，任务都会设计成并行模式。这首先要分析数据的依赖关系，无依赖关系的数据可以并行处理。有依赖的需要注意分析后面步骤出错回滚后，是否需要把前面的数据有同步回滚。
综合上面的讨论，分几个方面讨论在发生异常的情况下如何保证数据的准确性。
- 数据处理程序
从单个数据处理程序的角度，应该注意：- 每个数据处理程序，都应该有配套的反程序，也就是对应的数据清理程序，以便发生错误的时候调用清理数据。
- 插入数据之前，尽可能把需要插入（变更）的数据整理到一个临时表里面，然后再更新仓库表，避免插入了一部分后出错需要恢复仓库表数据。
- 整体设计时候需要确定数据处理错误的类型，根据错误类型确定处理的级别：忽略，重试，回滚；在数据处理程序中应遵循此原则。
- 整体数据处理流程
在数据处理的全流程设计，应该考虑：- 分层设计数据处理框架，全量、整合、汇总等层次分离，尽可能一个层全部完成后，再进行下一个层的处理。后面层的错误，单独清理即可，不影响前面层。
- 根据数据依赖关系确定某一个处理程序失败除了当前步骤数据恢复之外，之前的步骤产生的数据是否需要恢复。
- 支持断点恢复，对于可以现场处理的问题，修复之后，可以手工从当前节点开始继续处理。
数据处理流程控制一般会使用ETL工具来进行。前面提到过，ETL工具的一个核心是工作流引擎，一般提供图形化的界面设计流程。ETL工具应该支持分布式处理机制，并支持failover（失效转移）和failback（自动回复）机制。
未完待续。
