关于数据公共层建设

调研

问题

• 数据仓库目前有多少个表？
• 有多少个认证表？
• 数据开发团队有哪些？
• 数据使用团队有哪些？

数据模型图

整理现有的数据模型E-R图，归属到不同主题域。

公共数据层定义

统一化内部数据整合包括一致性的指标定义体系、模型设计方法和配套工具。通过这一体系，构建统一、规范、可共享的全域数据体系，避免数据冗余和重复建设，规避数据烟囱和不一致性。

衡量measure

分析数据需求量是一个十分庞大的数字，如果可以将分析查询，应用建模都建立统一的公共数据层上面，不仅仅可以在业务侧避免调取使用过程中出现的指标不一致、多次建设、重复建设等问题，另外的意义在于可以下线重复计算任务，减少资源消耗。

定位

建设统一的、规范的数据接入层（ODS）和数据宽表层（DW）即数据公共层建设。提供标准的、共享的、数据服务能力，规范模型层次、统一命名规范、降低数据搜索、互通的成本，提高应用开发的工作效率。

其业务意义在与提高业务开发效率，并且保障数据的服务质量。

原则

数据调用优先使用公共数据层数据，当公共数据层没有数据时，需评估是否需要创建公共数据层，当不需要建设公共数据层时，方可直接使用ODS层数据。

个性化推荐和数据应用作为特定产品，一般不对外提供数据服务。

数据服务

离线数据存在于Hive数据库中，准实时数据存在于Kudu列数据库中。那么在取数据的时侯，需要将两者结合起来返回作为结果集。在考虑到数据延时的造成准实时数据数据的差异性，返回的结果以离线数据为准，准实时数据为补充。

宽表设计

事实表作为公共数据层的核心，需要围绕业务过程和需求来确定宽表的类型，同时需要确定维度的粒度和冗余度。为了便于业务分析，需要对每个业务过程建立至少一个事实宽表。以订单为例，就需要建立一个订单事实宽表，其中包含订单号，订单创建日期，买家号，卖家号，商品号，销售金额，数量。之所以称之为宽表，除了这些信息以外，还会包含退化的维度，比如会加上商品的多级类目信息来通过反范式来减少Join提高取数效率。

维度表设计

维度代表了数据的属性信息，必须保持一致性和权威性。尽管事实表设计的时侯会做反范式处理，但是维度表还是要保持最完整的维度层次和尽可能多的信息。作为公共维度表必须保持命名规范统一、字段类型统一、代码值统一、业务含义表述统一。对于一些维度表过大的，比如会员表，可以进行水平和垂直拆分来提高查询效率。

主题域设计

主题维护这逻辑上对于物理宽表的映射关系。这么做的主要原因是宽表的建设是迭代的，但是提供的数据服务需要一个稳定的结构。同时主题是面向业务问题的，而宽表更加面向于内部ETL和效率的。通过这一层的业务抽象，可以隔离这种复杂性。业务方只需要关系逻辑表的结构，不需要关系这些数据从哪些数据库的哪些底层物理表产生的。

实施方案

实施需要通过系统的方式来减少人工的干预，提高流程化。工具准备步骤：

1. 公共数据层认证表的认定和列表，指明认证表的负责人，业务逻辑，wiki链接等消息以及动态统计日访问信息信息。

2. 建表工具，通过引导的方式来建立表，这样可以让开发者思考是否真的需要建立一张新的表，而不是重用已有的认证表。

3. 存量部分通过表的比对等方式，定期强制迁移。

4. 表负责人归属流程化，可以列出表的负责人和批量修改表负责人。可以自动检查表的负责人离职或者离开岗位，并提示应用负责人修改，和作业一样，自动修改为应用负责人。

5. 表的列表清单，可以挂钩到不同的级别，从集群级别到应用级别，数据库级别，负责人级别。开发者可以在这个列表里看到表的基本属性和进行删除清理及更改负责人等操作。点击开来具体的表，可以看到最详细的表的信息。

6. 表清理流程化，临时库里面无任何规则的自动删除，比如3个月。临时库里有日期标示的和正式库一样按照预设清理逻辑删除。没有设置清理逻辑的正式库，将会定期告警。用户可以将表设置为数据永久保留，屏蔽告警。