数据开发0经验入职: 开发流程梳理>>调研, 需求沟通,采集,存储,ETL,测试,可视化, 项目环境
调研
一般跳过这一步, 从需求沟通开始
需求沟通
中途加入项目组(常见), 一般不需要搭建数仓,搭实时架构,模型的规范设计等, 只有从0到1参与项目或项目重构的时候才需要做这些
进入项目组>>熟悉环境>>熟悉业务以及整个数据架构>>进行数据开发
开发的第一步是需求沟通
沟通: 和谁沟通>>谁给的需求任务和谁沟通
重要性: 需求不明确>>加大工作量
比如: 指标的一个取值出现问题/统计口径出现问题>>bug>>返工
沟通的4个角色
1. 业务人员
对外沟通: 行方业务人员
和他充分了解业务需求是什么, 包括
需要的表, 表字段以及数据
指标的加工逻辑
指标从哪些业务表中去提取
清洗规则
开发可能会产生的一些业务问题
然后你再把指标进行落地
有时候是leader在担任这个角色, 此时是对内沟通
可能是你的上级领导给的需求, 一般先问上级有没有这些东西或跟组内的组长沟通
需求的最终解释权在业务人员, 是业务人员>>组长>>你
2. 审计人员
对外沟通
对于银行项目, 银行审批人员需要确保项目的合规性>>提出有关银行硬性规定的需求
比如: 数据的隐私保护(身份证号,手机号进行MD加密), 数据生命周期
和业务部门人员是类似的, 可以合并到一类>>甲方
区别
业务人员是项目的固定角色, 而审计人员一般只有政法相关单位才有
业务人员: 业务需求; 审计人员: 业务之外的需求
3. 做分析和做挖掘的团队
团队人员包括: 数据开发, 分期, BI, 挖掘, 测试, 前端, 后端
对内沟通
做分析和做挖掘的团队要需求的原因>>它们要把握数仓数据的颗粒度, 数据质量
数据开发工作也要保证数据质量的一致性和完整性
对接比较简单: 双方都比较熟悉现有的模型,数据库,表, 以及目前的项目阶段
4.leader
和上级的沟通属于对内沟通
learder的角色: 项目统一调度, 技术兜底
沟通内容: 你今天的工作进度, 未来一周的工作进度/工作饱和度>>可能需要写日报/周报/月报
leader也需要根据你开发的质量, 工作进度去安排项目工作(比如你忙不过来,给你加人)
沟通核心
数据分析/数据开发在业内被统称为数据
数据的核心是从哪里来(源头), 到哪里去
源头: 谁找你要数据, 你要对他负责; 清楚数据从哪里来
比如: 在工作中负责DWD层>>数据来源ODS层>>找负责ODS层对应的负责人
取数>>取哪个是最为标准的, 让对方给你; 和对方核实现在拿到的需求文档是否准确
找你提需求的一般是APP(实际应用层) ,问他要我需要给出什么样的数据
如果项目比较小, 可能全流程都要看
如果刚进组谁也不认识, 谁带你进组告诉你谁是组长, 找他问一下这一层谁负责?我要取什么数,取哪里的最准
银行的数仓项目一般会分组做
不排除有从前做到后的情况, 即没有一个角色单独做ETL或分层等, 经常大部分事情都要做, 两个不太需要做的是: 分层, 建模
注意: 沟通的会议记录; 私下沟通的聊天记录要保
采集
了解需求后是采集数据, 如果已经在数仓里面, 跳过这一步
采集工具: 即 ETL工具>>Kettle, sqoop, flume
sqoop表对表采集
从oracle, mysql(关系型数据库)抽取数据到hive里面要注意的点
源表/目标表字段保持一致;
数据类型转换>> 把varchar改成string ; decimal两边都支持
表的分区>>如果Oracle数据库中的表是分区表,需要在Hive中创建相应的分区表
数据类型转换
如果是采集一些非结构化的数据, 需要先进行数据预处理, 把其转换成能够储存在hive表中的一种形式再采集. 比如JSON格式的数据
flume 采集流式数据/批处理数据都可以
从源端采集到HDFS上形成一个文件>>在hive里面建表>>把文件load上去
需要写采集脚本, 有固定写法, 类似shell>>写配置信息,数据流入方案, 属于高可用的分布式组件
基本上市面上所有的数据源都支持
使用场景
网站的log日志: 记录了用户什么时候登录,任何时候都可能有用户登录>>流式数据
使用flume可以随时接收log日志传递的信息, 即实时采集
发送不涉及实时
谁去采集?
有时候是自己采集, 有时候是有采集需求告诉组长(组长提需求), 对接采集人员
项目里面有ETL工程师, 数仓开发工程师,建模开发工程师, Hadoop工程师, 但是在项目里面, 你不一定只做一个岗位的工作,
比如你负责某个指标, 做好DM层, 把数据抽取到oracle, 是你自己去做
比如任务根据业务线划分, 你负责某条业务线, 也是从前到后做, 就涉及到其他岗位的工作(etl ,BI )
存储
HDFS, hive
特殊情况: 数据采集到DWD层, 做好轻度汇总之后, 把表copy存到MYSQL, 业务人员拿去做测试
考虑: 用什么东西存什么数据, 哪条业务链存在什么地方; 所有的数据都在数仓里面有一份, 但有一些额外的数据需要在其他地方再存一份
ETL, 数据处理, 测试
ETL: 数据的抽取,转换, 加载>>数据清洗>>去空格,统一日期格式, 异常数据的处理
示例
手工填报系统会出现很多错误, 会出现不符合业务逻辑的数据, 比如180岁的人
处理方法>>跟需求方确定>> 置空; 设置特殊值; 标识出来
测试: 同事之间互测>>甲方测试
可视化
指利用图形化界面和交互式工具,将存储在数据仓库中的复杂数据转换为易于理解和分析的视觉化表示形式
数据表格, 图表、图形、仪表盘
图表
展示数据的分布、趋势和关系,
类型: 包括条形图(Bar Chart)、折线图(Line Chart)、饼图(Pie Chart)、散点图(Scatter Plot)、直方图(Histogram)、箱线图(Box Plot)等。
适用场景: 比较不同类别的数据、展示数据随时间的变化或分析变量之间的关系
图形
用于展示数据的视觉元素
类型: 图表、地图、信息图, 网络图、流程图
仪表盘(Dashboard)是一种数据可视化工具,它提供了一个集中的界面来展示、监控和交互各种指标(Metrics)、关键性能指标(KPIs)、报表和数据视图。仪表盘通常用于实时或定期报告业务运营的状态,帮助用户快速获取关键信息,识别趋势,做出决策
其他
有的指标是口述, 有的指标会落地成文档
在银行做开发, 不会让你充分了解业务, 只是开发, 因为一些信息比较私密, 不会让开发人员去全权管理, 即给指标, 不会涉及分层,建模等, 这些可能是银行的内部人员/第三方做
在日常开发过程中, 通常数仓的表也是分级, 有权限管理>>如果你只负责ETL, 可能只有访问ODS和DWD的权限>>有权限访问, 没有权限增删改, 只能通过取数, 计算逻辑, 再出数
项目的环境
-
开发环境(Development Environment):
-
这是开发者编写代码、实现功能和进行单元测试的环境。
-
开发环境通常配置较为简单,可能只包含应用程序运行所需的最小服务和依赖。
-
开发者可以在本地机器上设置开发环境,也可以使用共享的开发服务器。
-
该环境主要用于日常的开发工作,频繁的代码更改和功能迭代。
-
-
仿真环境(Testing Environment):
-
仿真环境,也称为测试环境或 staging 环境,用于在接近生产环境的条件下测试软件的功能和性能。
-
这个环境的配置应尽可能模拟生产环境,包括硬件、软件、网络配置和数据。
-
在仿真环境中进行集成测试、系统测试、性能测试和用户验收测试(UAT)。
-
仿真环境有助于发现和修复在开发环境中可能未暴露的问题,确保软件在生产环境中的稳定性和可靠性。
-
-
生产环境(Production Environment):
-
生产环境是软件正式发布并供最终用户使用的运行环境。
-
这个环境通常具有最高的配置要求,包括安全性、可靠性、可用性和性能。
-
生产环境中的系统需要24/7的监控和维护,以确保服务的连续性和数据的完整性。
-
任何对生产环境的更改都需要经过严格的变更管理流程,以避免对用户造成影响。
-
仿真环境: 类似生产环境, 做测试用的, 项目经过测试没有问题后到生产环境
生产环境里面的所有东西都不能任意修改, 只能查, 只有甲方内部人员才有其他权限>>用户能访问, 比如淘宝页面
仿真环境和生产环境是一摸一样的, 仿真环境是对内做测试用的, 生产环境是服务用户的
文档上线: 大部分公司选择周四晚上, 上线之前做测试
划分环境的好处
通过在仿真环境中进行充分测试,可以减少在生产环境中出现严重问题的风险。
可以有版本迭代, 上线之后发现有问题可以回退一个版本
项目生命周期/版本迭代的生命周期>>根据项目需求
如果项目结束时发现自己负责的工作出了问题怎么办?
你有责任, 领导也有责任, 因为他没有检查出来, 大锅在领导
解决方案>>平时有不明白的及时问, 问同事, 问领导, 问业务人员
注: 不要在同事思考的时候问, 可以说XX, 你什么时候有空我想问个问题