做数据已经有段时间了，整个数据流程也基本上搭建完成了，所以这里做个小结。
数据仓库
数据仓库是传统数据领域的概念，互联网公司则更喜欢说『大数据』，但两者不存在冲突。数据仓库代表的是一种对数据的管理和使用的方式，它是一套包括了etl、调度、建模在内的完整理论体系，而大数据更多的是一种数据量级的增大和工具的上的更新。因此大数据相对于数据仓库是部分的升华。随着数据量的增大，hadoop系的大数据工具会越来越受青睐，但数据仓库里的理论一段时间内依然是数据管理的基础，这其中主要说下数据分层。
数据分层
数据分层是整个数据流程的基础，它类似于软件开发中的模块化，将各个数据过程拆分，简化了整个流程的复杂性，同时也保证了复用和业务解耦。
一般整个数据流程会分为3层，包括ODS数据运营层、DW数据仓库层和DM数据集市层。其中ODS层主要负责数据的汇总、异常过滤，还有数据名、数据类型等方面的统一，因为大部分时候，业务是分散的，所以数据可能存在不同业务库以及各种日志文件中，甚至相同数据在不同位置表现形式也不一样（比如有的订单时间为时间戳，有的却是date形），这样要在复杂的数据处理过程中加入汇总的过程，一方面增加了作业的复杂度，另一方面也降低了数据流程的复用性。DW层是核心ETL层，传统理论喜欢完整的建模过程，但互联网环境里，一方面业务层变动过于频繁，二方面数据量增大导致对性能的要求越来越高，因此像『针对每个主题做宽表』的简化模型做法更满足要求。DM是直接面向业务的一层，当DW层的基础数据（比如订单宽表、用户宽表）准备好后，DM为满足业务的各种需求所需的定制化ETL表就相当容易开发了。ODS、DW、DM作为独立层，对外的权限可独立设置（一般只有DM开放），因此并行开发的可能性更高。
调度
调度是个非常重要但复杂的部分，对于数据量小到没必要上分布式的公司，调度主要集中在依赖管理上。但随着数据量的增加，分布式环境下的调度就还需要考虑任务调度和资源调度的问题，而这也是大家一直在研究的课题。
ETL
ETL表示对数据的抽取、转换和加载的过程，它本来也是数据仓库的核心，但它太重要了，而且在数据仓库建立完成后，后面的绝大部分工作都是围绕ETL流程的，所以单独讲也不为过。
ETL做为核心工作，自然问题也不少，以下是常见的可抽象的三个流程问题，单独拿出来说下
添加表字段和历史数据
一般常见的ETL流程都是T+1的，除了业务需求的原因外，另一个原因就是将计算分散，每天只算当天的。想象一下，如果每次都要计算历史所有的数据，那再多机器都搞不定性能问题。但业务总在发展，所以最初的设计总是需要扩展的，在DW里就常会碰到宽表需要加个属性进去，如果不需要历史数据还好，需要历史数据的时候，除了需要单独写脚本跑数据外，表的老数据都要执行更新操作，要知道更新的速度是远慢于插入的，那么这个时候一个办法就是将数据全部拉出来分布式联合宽表数据，然后插入一张新表，最后改表名成老表，也就是『挪表』的处理方法。
重跑
重跑是个必须面对的问题，因为不可能从来不出错，但只要错了，就必须有补救的办法。如果出错了，都需要手动去删除数据，然后再重新跑作业，那这个就太麻烦了，所以在做ETL作业的时候，可以在作业开头就做『新数据』的清理，清理完后再进行ETL流程，清理的方式常常可以结合表的分区设计来做。
业务表结构变化
业务表结构变化的解决方案其实就体现了分层的重要性，即通过分层解耦来实现对上层的屏蔽，这里的上层即DM，所以如果业务表变化，我可以只改造ODS层（这里的改造依旧是简单照搬业务表）以及DW作业即可。
流式计算
搞技术的有时候也喜欢诌概念，离线计算、实时计算、流式计算，这些看似完全不一样的东西，如果从数据和需求的角度看，实际上只是数据处理间隔大小的区别（其中实时计算和流式计算从这个角度讲没有区别，它们的区别主要体现在概念的侧重上，实时计算主要强调实时的反馈，流式计算则主要强调计算方式属于流式处理）。所以相比离线计算，流式计算实时性一般会强得多，而且由于计算的分散，系统的最大负载也会小得多。但数据处理间隔的缩小带来的一个问题就是错误的可容忍性降低，因为实时的2小时可是比T+1的半天更重大的事故！