数据仓库是解决方案，真正落地的时候，还要依托于工具平台。
工具平台包括两种，一种是存储系统如hdfs，计算系统如hive/mr/spark/flink等，是数据仓库的基础，在此基础上进行数据的建设与使用(主要说的是依赖自建的集群进行数据建设，其它的情况后续再说)。
而本文说的是第二种，数据仓库的辅助系统:数据服务平台。
数据服务平台：数据建设，数据使用的辅助与后盾。
对于外部用户，如分析师，项目团队来说，数据可视化/元数据是重要的，通过这两个系统，可以很容易的知道数据的基本情况以及统计结果，可以进行多种分析。
对于内部用户，如数据团队来说，调度系统/质量监控是必不可少的，调度系统可以让任务准时地完成，质量监控可以保证提前发现数据问题。
下面分别对这四个系统进行说明。
1. 数据可视化/报表/数据查询 —— 数据的服务员。
数据的意义是知晓历史，查看现状，规划未来，前提是我们能"看到数据"。能被看到，能被理解的数据才有意义。用合适的方法把数据展示出来，让用户轻松理解，是一个比较困难的事情。
不同的数据，需要用不同的方法，比如看数据，用表格；看趋势，用折线图；看分布，用饼图；看流量变化，用漏斗图；看分布，用热力图等等。合适的表现形式，才能让人更好地从数据中获取知识。
举一个真实的例子，在一家公司时，只做数据建设，没有好好地做数据可视化，然后我们给高管做汇报的时候，在命令行敲命令，得到一个黑底白字的表格，尴尬至极。
汇报之后，我们就立刻组建了数据可视化的团队。
分析师，数据PM，是使用数据的用户，而他们往往没有技术能力，无法直接使用数据。同时，在离线/实时两种数据场景中，需要使用比如mysql/hive/kylin/druid/clickhouse/es等等工具，无疑更增加了用户的使用成本，并且工具是发展的，随时可能引入新的工具，难不成需要用户随时学习新工具的用法么？
当然不应该这样，所以需要一个统一的系统，能够展示报表数据、图表分析，能让用户在一个界面轻易地查多个平台甚至跨平台的数据。
常用的工具就是BI系统，比如帆软的FineBI平台。一方面对接经整合过的数仓数据，另一方面在前端展示报表、面向高管的驾驶舱、让数据用户自主分析。
没有好的数据查询系统，就无法服务好需求方。常说的"一站式数据服务平台"用户最直观地看到的，通常就是这类。
2. 元数据 —— 数据的解说员。
元数据，是描述数据的数据，通过元数据可以了解数据的基本情况和使用方法等。
包含数据的基本情况(数据层级，作用，建表语句，字段，存储位置等)，数据信息(数据类型，数据规范化逻辑，枚举值列举，数值盒图，数据示例等)，数据增长信息(新增条数，存储消耗)，数据血统(数据流转路径)等。
理想的场景中，当一个新的主题建设出来，只要给一份元数据，用户就能清晰的知道数据的来源，逻辑，样例，以及使用方法，而不用一一宣讲。
3. 数据质量 —— 忠实的观察员。
及时发现数据波动，协助查找原因。数据波动，有时是由于数据异常导致的(整个数据链路中，原始数据，数据收集，数据计算都可能出错，所以数据出错是无法避免的)。
当然多数时候都是正常的波动，但是还是要尽职的观察，随时发现数据波动，提前找到波动的原因，主动把数据问题抛出来，防止小错积累成大错。
数据计算
- 自动多维分析，找出指标变化波动大的维度与变化情况。
数据转移
- 数据在多个数据源之间流转过程中，有无数据变化。数据条数，数据内容。
报表数据
- 多个报表包含相同维度，从总量/相同维度明细两个方面对比相同的指标。
- 通过多方面的自动检查监控，可以很好地了解数据的健康情况。例行检查，给出数据质量报告，保证做到"好数据，用得放心"。
4. 调度系统 —— 勤劳的操作员。
保证任务的稳定执行。众多计算逻辑，包括hql，Java程序，python程序，spark程序，需要在一定条件下顺序执行，可能是时间驱动:每天3点开始执行；可能是条件驱动:上游任务都执行完再进行当前步骤。
当然实际上往往是两种方法并存。在这个需求背景下，调度系统就产生了。调度系统不仅能做到最基本的版本管理控制，控制任务按条件执行，对于数据系统来说，数据的修改往往伴随着一系列下游的任务执行，那么就需要有级连筛选执行的能力。
另外，对任务的执行情况需要有监控，及早发现包括执行失败，产出延迟等任务异常情况，以便及时应对。
小结
这四个工具是按照用户感知的强弱来排列的，都不是数据建设/使用中"必须"的，没有它们，依然可以做，但是为了让数据更好的使用，它们是相辅相承，不可或缺的重要组成部分。
所以，数据工作不能仅仅埋头于数据，也要关注一下工具。
