阿里服务平台

阿里服务平台

大数据开发治理平台 DataWorks

大数据开发治理平台 DataWorks基于MaxCompute/EMR/Hologres等大数据计算引擎，为客户提供专业高效、安全可靠的一站式大数据开发与治理平台，自带阿里巴巴数据中台与数据治理最佳实践，赋能各行业数字化转型。每天阿里巴巴集团内部有数万名数据/算法工程师正在使用DataWorks，承担集团99%数据业务构建。

1.飞书使用 hologres 数据库和 maxcompute数据库 一样 是往里面同步的，原因是maxcompute比 hologres 性能好           dataworks 引擎链接  maxcompute 数据库

2.mc 迁移      dataworks 平台 / MaxCompute数据同步方式 

1.数据开发--跑代码  2.  数据集成同步数据    

cickhouse 数据库性能内存满足不了往hologres 上迁

vertica 老数据系统

3.数据来源 爬虫 mysql oss系统

oss 系统 mysql 的数据 python 爬虫抓取的数据 会统一 汇总到 vertica 老系统中--------老数据来源

ods 元数据  dwd 明细+轻度维度对维  dws 轻度维度和指标汇总  ads  数据应用------- 每层应用重点

ods层规范
分三种情况
1.    从vertica拉取数据，此方案非长期方案，使用此方要有对应的oss替换方案，owner是三大域负责人
a.    全量，分区字段dt=昨天，每天包含全量数据，表名结尾不带add
b.    增量，分区字段dt=业务日期，每天包含当天业务数据，表名结尾带add
2.    从MySQL拉取数据，MySQL数据源确认为备库，owner是三大域负责人
a.    全量，分区字段dt=昨天，每天包含全量数据，表名结尾不带add
b.    增量，分区字段dt=业务日期，每天包含当天业务数据，表名结尾带add
3.    从oss上拉取的
a.    csv格式，保留现状，owner是三大域负责人：
i.    按照主键去重取最近N天最新数据，
ii.    根据某些字段先删后插，
iii.    直接插入
b.    json格式：分三层表，odsopr，odspre，ods三个表。
i.    odsopr外部表：字段名：json_source，分区字段：table_name，统一使用报表名：odsopr_渠道名，如odsopr_reddit，生命周期：永久。配套加分区任务，和表名一致，此任务增加当天新增的分区，若后续增加新表则需要增加对应的分区。如任务odsopr_reddit所示。这一步主owner为朱松松，backup李开元、黄保宏
ii.    odspre：包含字段：现阶段json包含的字段+extra（保存未来新增的字段，去除已经解析的字段），生命周期10天。这一步主owner为朱松松，backup李开元、黄保宏
iii.    ods：包含字段：现阶段json包含的字段+extra（保存未来新增的字段，去除已经解析的字段），对应会做更新逻辑如根据某些建先删后插，直接插入，根据主键取最新插入，非全量生命周期根据业务定，全量7天。这一步owner是三大域负责人。

dwd层规范
1.    dwd层是基于ad_id+维度组成明细数据，如fb的明细表dwd_fb_adinsights_agegender_hh_add、dwd_fb_adinsights_country_hh_add、dwd_fb_adinsights_platformdevice_hh_add。
2.    除非是新增业务过程，新增的字段默认要增加到已存在的明细表里，不能同一个ad_id+维度出现两张表，比如违规广告相关，应该存在于三个明细表里，添加个字段标示是否违规即可，或者在维度表里标示下游通过维度表取，要根据业务特性和数仓模型特点决定。
3.    以fb为例，现在有三种明细数据，三种明细数据是越来越丰富的，所有数据都是基于这三种明细数据进行开发。
a.    账户层级消耗数据包含全渠道，dwd_pub_account_daily_spend
b.    ad_id+维度数据，dwd_fb_adinsights_agegender_hh_add、dwd_fb_adinsights_country_hh_add、dwd_fb_adinsights_platformdevice_hh_add
c.    账单消耗数据，dwd_pub_soa_invoice_add
dim层规范
1.    维度数据是全公司统一，从业务过程中抽象出来，即可从ods层抽象，也可从dwd层数据抽象。
2.    dim层开发要遵循易用性、通用性、杜绝二义性、空值统一原则
a.    易用性，下游可以直接使用维度表，不需要经过加工，如下游通过replace函数或者row_number使用的，就是不满足这个规范，如果下游使用在意SCD，则按照缓慢变化维的规范设计维度表。
b.    通用性，若某个字段时针对某个业务场景，则不需要加到dim层里面，比如最近7天消耗是否超过5w，则需要放到ads层。
c.    杜绝二义性，若不同维度表有相同字段，需要保证字段值一致，业务含义相同。

dws层规范
?    汇总层规范如下，dwd->dws ad_group粒度汇总层->dws campaign粒度汇总层->ads层。如dwd_fb_adinsights_country_hh_add->dws_fb_adinsights_country_adgroup_hh_add->ads_fb_adinsights_country_campaign_hh_add，所有fb相关数据都是基于dwd或者dws层，若基于ad_id关联取ad_id粒度级别的维度如ad_type的需求，需要从dwd出数据，其余一律从dws汇总层出。
?    dws层维护，如果缺少字段，分两种情况，
?    若不常用则需要通过dws关联维度表取出字段，将数据放到ads层。
?    该字段经常使用，怎么判断经常使用？数仓开发人员在开发ads，若上一步发现很多ads层表（>=5个）都用到了某个字段，则需要抽象到dws层，作为公用的字段。
?    dws层怎么和ads层区分？ads层是专门应用某个业务场景的，别的场景不会依赖，若ads层的重复使用越来越多，则需要抽象ads层数据到dws层。可以这样理解，dws层是基于ads层抽象出来的，而ads层是数仓在业务积累过程中必须要的阶段，先有再抽象。
ads层规范
1.    默认不提供ad_id粒度的应用表
2.    到ad_id粒度的明细数据需要产品、业务方说明具体原因、业务目标，需要经过域owner确认。
    对外提供的ad_id粒度数据，ads层默认只有一个（之前石成翠开发的三张明细数据），若字段不足，则需要往上添加。明细数据考虑进行拆分，通过四大行业进行拆分？产品需要向业务方announce以下共识：明细数据不保证数据查询速度。