什么是数据仓库？

数据在一开始的时候，体量比较小，就好比创业公司，还不足够引起人们的注意。但是当数据体量上来了，就变成了独角兽公司，这时候就大不一样了。

比如银行传统的存取款业务，当业务量是几十个人的时候，可以通过oracle这类强大的数据库搞定。但是当数据量激增或者要用到除了处理、读写、删除这类基本的需求之外的功能，比如把这些数据聚合到一起做分析，那数据库基本上就做不到了。

于是，人们在现有的数据库基础上，对数据进行加工，也就是常说的ETL：抽取、转换、加载。

然后，数据仓库就生成了，里面有各种不同的数据，分成不同的业务包，都是为了数据分析，用在报表和BI上面。

数据仓库是一种解决方案，真正要落地的时候，还是需要依托于工具平台。

以最常见的制造业为例，底下不同分厂的信息系统厂商各不相同，这就导致数据仓库中可能有来自前端系统（供应商、招标系统等）、MES系统（不同分厂的MES）、业务系统（不同分厂的CRM、OA、SAP系统等）的数据，因此导致系统中数据结构、数据标准、流程流转方式都存在差异。

再具体点说，例如在统计良率、OEE的时候，各厂按各自的方法进行统计然后汇报给领导，但由于各厂的数据过于分散，没有统一的计算标准，所以对良率的计算逻辑也不同，导致指标口径不一致，无法统一管理指标数据，这个数据也就失去了参考价值，到头来白忙活一场。

而这种时候，我们通常的解决方法是：实现数据中心化，逻辑统一化。

从众多跨地域的业务系统通过实时同步增量方式，将分散在各处的数据，汇聚到统一的数据中心，从业务数据库中原表原样取出数据，形成数据仓库的ODS层，为后续加工提供原始材料

数据编排能力：多样化算子和多种任务调度方式，提供多样化异构数据处理能力；在标准化的要求下，通过各系统原始的指标定义，形成统一的数据处理逻辑，在低代码实时数据调度平台FineDataLink进行内部数据转换，完成对异构数据的梳理，进行ODS>DW>DM层的数据逐层编排，最后形成统一逻辑的数据输出，以供企业进行统一管理。

• ODS层：数据存储。本层数据一般会按照来源业务系统的分类方式而进行分类，在ODS数据存储层中，我们不会对数据模型进行修改，会维持原有的数据模型不变。
• DW: 数据仓库的主体。DW层将ODS层中获得的数据按照主题建立各种数据模型。
• DM层：数据集市或宽表。DM层为面向最终应用的主题层，一般依据前端报表/业务包需求进行设计，所以DM层表不需要考虑复用，每一张DM表仅为一张报表所服务；

数据仓库涉及的两大类工具

数据仓库的工具平台包括两种：

一种是存储系统如hdfs、计算系统如hive/mr/spark/flink等，是数据仓库的基础，在此基础上进行数据的建设与使用(主要说的是依赖自建的集群进行数据建设，其它的情况后续再说)。

另一种是数据仓库的辅助系统：数据服务平台，是数据建设、数据使用的辅助与后盾。

对于外部用户，如分析师、项目团队来说，数据可视化、元数据是重要的。通过数据服务平台，可以很容易地知道数据的基本情况以及统计结果，进行多种分析。

对于内部用户，如数据团队来说，调度系统、质量监控是必不可少的，调度系统可以让任务准时地完成，质量监控可以保证提前发现数据问题。

下面分别对这四个系统进行说明。

1. 数据可视化/报表/数据查询 —— 数据的服务员。

用到的工具是FineReport和FineBI

数据的意义是知晓历史，查看现状，规划未来，这一切的前提是我们能”看到数据”。用合适的方法把数据展示出来，让用户轻松理解，是一个比较困难的事情。

不同的数据，需要用不同的方法，比如看数据，用表格；看趋势，用折线图；看分布，用饼图；看流量变化，用漏斗图；看分布，用热力图等等。合适的表现形式，才能让人更好地从数据中获取知识。

举一个真实的例子，在一家公司时，只做数据建设，没有好好地做数据可视化，然后我们给高管做汇报的时候，在命令行敲命令，得到一个黑底白字的表格，尴尬至极。

汇报之后，我们就立刻组建了数据可视化的团队。

分析师、数据PM乃至领导，是使用数据的用户。他们往往没有技术能力，无法直接使用数据。同时，在离线、实时两种数据场景中，需要使用比如mysql/hive/kylin/druid/clickhouse/es等等工具，无疑更增加了用户的使用成本，并且工具是发展的，随时可能引入新的工具，难不成需要用户随时学习新工具的用法么？

当然不应该这样，所以需要一个统一的系统，能够展示报表数据、图表分析，能让用户在一个界面轻易地查多个平台甚至跨平台的数据。

常用的工具就是BI系统，比如帆软的FineBI平台。一方面对接经整合过的数仓数据，另一方面在前端展示报表、面向高管的驾驶舱、让数据用户自己做分析。

没有好的数据查询系统，就无法服务好需求方。常说的”一站式数据服务平台”用户最直观地看到的，通常就是这类。

2. 元数据 —— 数据的解说员。

元数据，是描述数据的数据，通过元数据可以了解数据的基本情况和使用方法等。

包含数据的基本情况(数据层级，作用，建表语句，字段，存储位置等)，数据信息(数据类型，数据规范化逻辑，枚举值列举，数值盒图，数据示例等)，数据增长信息(新增条数，存储消耗)，数据血统(数据流转路径)等。

理想的场景中，当一个新的主题建设出来，只要给一份元数据，用户就能清晰的知道数据的来源，逻辑，样例，以及使用方法，而不用一一宣讲。

3. 数据质量 —— 忠实的观察员。

及时发现数据波动，协助查找原因。数据波动，有时是由于数据异常导致的(整个数据链路中，原始数据，数据收集，数据计算都可能出错，所以数据出错是无法避免的)。

当然多数时候都是正常的波动，但是还是要尽职的观察，随时发现数据波动，提前找到波动的原因，主动把数据问题抛出来，防止小错积累成大错。

数据计算

• 自动多维分析，找出指标变化波动大的维度与变化情况。

数据转移

• 数据在多个数据源之间流转过程中，有无数据变化。数据条数，数据内容。

报表数据

• 多个报表包含相同维度，从总量/相同维度明细两个方面对比相同的指标。
• 通过多方面的自动检查监控，可以很好地了解数据的健康情况。例行检查，给出数据质量报告，保证做到”好数据，用得放心”。

4. 调度系统 —— 勤劳的操作员。

保证任务的稳定执行。众多计算逻辑，包括hql、Java程序、python程序、spark程序，需要在一定条件下顺序执行，可能是时间驱动：每天3点开始执行；可能是条件驱动：上游任务都执行完再进行当前步骤。

当然实际上往往是两种方法并存。在这个需求背景下，调度系统就产生了。调度系统不仅能做到最基本的版本管理控制，控制任务按条件执行，对于数据系统来说，数据的修改往往伴随着一系列下游的任务执行，那么就需要有级连筛选执行的能力。

另外，对任务的执行情况需要有监控，及早发现包括执行失败，产出延迟等任务异常情况，以便及时应对。

小结

这四个工具是按照用户感知的强弱来排列的，都不是数据建设/使用中”必须”的，没有它们，依然可以做，但是为了让数据更好的使用，它们是相辅相承，不可或缺的重要组成部分。