E数据源头部分

1. 涉及哪些业务流程，有些什么系统

• 越南版考勤，中控，海康考勤系统，hr系统
• 范围：越南，各个厂分属于不同的事业部
• 管控：各个工厂的业务有一定的个性化（数据平台做缓冲）如：工厂也有自己的报表bi
• 大背景：中国希望越南自建本地应用系统，自建IT团队，共性的系统总部统一（如PS）,共性数据可以申请总部支持

1. 系统的数据库及版本有哪些，读写分离的情况，数据库大小及负载情况

• access，mysql，sqlserver，没有做读写分离，待定
• 越南网络环境不稳定（ps只能走增量）

1. 是否有源数据字典，单表条数及大小大约在什么量级

• 需要厂家提供数据字典
• 3000~5000左右员工

1. 主要表是否具备数据更新时间字段

• 待定，起码考勤时间

1. 现有数据管道或ETL工具是什么

• 还没有

T数据构建部分

1. 现有数据仓库采用的什么技术平台

• 没有，目的就是通过考勤启动数仓建设的准备

1. 现有数据仓库的构建规范、方法

• 没有

1. 是否已有数据开发工具、任务调度平台、调度任务监控工具

• 没有

1. 对云数仓的接受程度，对开源工具和平台的接受程度

• 不接受云（但是没有确定一定用什么），开源工具和平台可以接受。考勤系统和hr系统都在国外。ps在国内。

1. 对自建数仓可能的IT团队资源情况

• 没有真正的DBA，是内部员工兼职的。目前的团队以应用和项目为主，兼职DBA。

L数据消费部分

1. 主要的消费业务部门

• 人力资源部，只会被hr系统读取到

1. 数据消费的主要需求，如：数据跨部门拉通，指标规范统一，性能提升，数据治理……

• 计算出勤的时间，和约定的时间有没有偏差
• 对数据进行建模统一提供给考勤系统
• 自带的考勤终端自带的考勤系统不好用，历史考勤硬件有多种，希望统一软件
• 之前是统一硬件统一软件的思路迟迟谈不下来，每一个工厂都要等新方案，现在的需求是新工厂新方案，老工厂老方案

1. 数据消费的粒度，如：公司级汇总指标，员工级明细台账，交易级原始明细……

• 提供考勤的明细数据
• 工号唯一识别

1. 数据消费的最低高频率，如：秒级、分钟级、小时级、半天、一天

• 半小时级别读取数据
• 数据转换的过程是实时的，数据转换过程的透明
• 生产业务比非生产的实时性要求更高，看板问题可能会导致停产

1. 现有数据服务采用的什么技术平台

• 倾向于api服务，自动实现服务

1. 对项目的预期成果描述

• 以工号为唯一标识统一各个考勤系统为一个标准的考勤数据供hr计算考勤
• 生产和非生产能不能放同一个平台？
• 还能支撑其它业务需求数据需要进入数仓，比如：夸系统拉通的报表，驾驶舱等