数据治理方向

这是一篇关于数据治理方向的思维导图，主要内容包括：一、对每个工作范畴，梳理和相关部门的界面分工，二、对每个工作范畴，梳理相关业务部门对我们的要求，最关注的事项（具体到具体业务场景），三、对每个工作范畴，梳理部门负责人，梳理职责（我们做什么合作方做什么，我们做了什么，我们该做的没做什么）。

在线营服数据平台系统能力

• 能力概览
• 数据开发流程
  • 数据批处理
    • 数据资源目录-已授权 1152个数据模型
      • 数据开发-模型开发 （大数据平台数据架构）
        • SI指标层
          • 空着
        • RP报表层
          • 报表，.py，省公司接口
        • DM魔方层
        • DW汇总层
          • 模糊 暂未有
        • DWV融合层
        • DWS业务层
          • 存储数据洞察
        • DIM配置层
          • 维表，字典表，下拉框
        • ODS接口层
          • 第三方传给我们的数据
        • DWD明细层
          • 暂未明确
        • IN手工录入层
          • 业务部门传数据给我们
            • 系统能力-数据录入
      • 程序开发，执行SQL过程 配置调度，存在本地
      • 开发者中心
        • 模型、开发、交换、调度上线下线都在此功能模块
      • 数据查询
        • SQL查询
          • hive库用来存储，查询比较慢
        • 数据操作IDE，MySQL库，查询比较快， 用的OLK，支持MYSQL语言（hive语言底层差不多） 不能使用hive的聚合函数。
          • 最终是2003版sql, JAR包：hive转换成 mysql转换成——
      • 数据采集
        • 内存使用情况和CPU使用情况
          • 与广西共享
      • 归属团队分层分级
        • 服务类
          • 呼入生产 满意等 接通率 工单
        • 营销类
          • 业务办理 甩单
        • 综合能效
          • 既有服务 又有营销
      • 数据源
        • 中心
          • hive
          • hashdata
          • vertica
          • ftp
          • csf
          • 实时流
            • 只有一个开发支撑
        • 省市公司
          • 资产库
            • ftp
          • kafaka
          • excel
          • IOP实时标签接口
            • 直接用于数据洞察
          • 沉淀数据：userID iPhone 用户星级
        • 分中心
          • oracle
            • 166经分库 ——给各个部门使用
            • 业务办理计算封闭库——不开放
          • MySQL
            • 伏羲导入
              • 丁荣荣
            • 二级应用生产库
              • 刘升霞
          • ftp
      • 层次
        • 定义
          • ODS接口层：用于接收和存储原始数据，是数据仓库的第一层。
          • DWD明细层：对原始数据进行清洗和转换，生成明细数据。
          • DWS业务层：对明细数据进行汇总和分析，生成业务数据。
          • DWV融合层：将业务数据和其他数据源进行融合，生成更全面的数据。
          • DM魔方层：对融合数据进行多维分析，生成多维数据。
          • DW汇总层：对多维数据进行汇总和分析，生成汇总数据。
          • RP报表层：将汇总数据生成各种报表，供用户查看和分析。
          • SI指标层：对汇总数据进行计算和分析，生成各种指标数据。
          • DIM配置层：用于存储和管理数据仓库中的元数据和配置信息。
          • IN数据录入层：用于数据录入和数据质量控制。
          • 行为分析：对用户行为数据进行分析，生成用户行为画像和行为分析报告。
      • 主题
    • 数据交换
      • 给省公司数据源tb.csv.txt 加校验文件.chk
      • 单元管理
        • ETL单元： 抽取 转换 装载
          • 完成从数据库A到数据库B
          • 完成从数据库A到文件接口或从接口到数据库A
          • 对接文件（接口）
      • 模板管理
      • 集群监控
      • 资源监控
      • 模板授权
    • 数据治理
    • 调度监控
  • 数据流处理 （看样例）
    • 数据管理
      • 表管理
      • 方法管理
    • 流程设计
      • 拖拽组件编辑流程
    • 元件管理
      • 服务管理
        • 主机
        • Kafka
        • redis
        • 数据库
        • ftp
        • csf
        • hive
        • hashdata
• 数据洞察
  • 标签集市
    • 标签集市中心686个客户标签，152个坐席标签； 江苏分中心自建21个标签，自建140个客户标签。
  • 客户群集市
  • 统一标签服务
    • 王宇 API集市-实时标签
  • 差权限：查看调度 和配置信息
  • 推送服务
    • ftp
    • 一体化
    • 服营
• 数据资产运营
  • 资产目录
    • 资产设计
  • 资产查询
  • 新上线：任务影响血缘关系+调度任务（红绿灯）
  • 血缘维护
• 其他功能区域
  • 自助分析
  • 指标地图
  • 可视化分析
  • Python工具
  • 专区
    • 8个任务
      • 重复建设模型-RAG+手工
      • 数据逻辑化，OLK，hive库
      • 指标库 原子化 大模型回答——王辉
      • 调度无人值守
      • 2小时调度查杀能力
        • 运维 RPA
      • 打标签 业务负责人 支撑哪个部门的 批量修改应用负责人
        • 业务标签有哪些个 系统标签有哪些个 模型列表 服务请求的 市场的 先维护标签 再打标签
      • 数据资产UI设计展示
• 解决办法

数据治理方向

• 一、对每个工作范畴，梳理和相关部门的界面分工。
  • 在线报表应用业务人
    • 提出报表需求
      • 1.业务告知我们用哪些表？ 难道不是我们不应该比他们更知道数据吗？ 2.业务不知道用哪些表的，需求分析侧就更不知道，缺乏一个工具给大家查询，帮开发提前预判断，没有在需求下发前完成。 导致报表套报表。 3. 开发人员不是很熟悉业务，没有数据资产，即使做过也无处可循。 缺乏规范性的，缺乏客观科学的共享机制，大家各建各的。 以前离职的无人维护，导致口径变更，数据报障 生命周期字典规范
        • 宽表使用情况
        • 问题解决
          • 上线机制
          • 需求组炮弹
    • 紧急需求
      • 王宇
        • 开门红
          • 为什么紧急 之前的数据不能用吗 缺失什么？
      • 黄鑫
        • 待梳理
      • 翁磊
        • 是否能根据业务规划 定好我们数据架构 根本性解决紧急需求
    • 报障
      • 分类
  • 在线数据分析运营人员
    • 淮安数据分析组 员工维度 热线 渠道 月结分析 降收 收入 精确营销 升档 接盘 权益 宽带业务统计
      • 省公司要的数据-资产库 +集市库 + 手工配置表+在线数据平台
      • 区分哪些是他们开发的 哪些是我们开发支撑的
        • 他们自行开发 我们协同支撑
          • 他们自行的：前期积累的固化脚本，每天在oracle定时跑数据
          • 哪些是他们做不到的五大工作：1.数据入库，业务配置表更新；2.新增复杂统计-3.处理oracle故障（一个月5次，固化脚本所需的源数据），4.上报表-在线营服数据平台的开发；5.数据沉淀到本地
        • 哪些是上报表的
          • 口径不固定的不上报表，能固化的上报表；
          • 自动邮件
          • 业务需要：给省公司看+给一线督导
          • 前期，于工做规范管理，大部分都是自行分析处理； 近期，代码无规范管理，业务侧报障，合作方优化处理。
          • 他们自己写好的 我们抽到hive库 上报表
            • 后期需要管控SQL代码
              • 技术方案自有人员？？
              • 开发负责人
        • 3月份实现业务办理数据同步
          • 他们比我们更知道省公司的表，一部分开放给我们卜有账号（资产，CSV文件入在线平台再直接给到166库，或者datastation入库后期因续费减少使用），一部分给到zhaohui集市库，审计平台的oracle，帮他捞取入库166库——开发支撑。 ——计划：省公司直接ftp给我们，开发任务定时入库。
    • 南京
      • 陈晓俊 领导要看的数据 统计
        • 省公司要的数据-资产库 +集市库 + 手工配置表
        • 业务办理 宽带 营销的 降档的 人员工号
      • 高璐
        • 外呼结算相关的 效能数据
          • oracle166数据抽到hive，做成报表，有的交换到伏羲展示——存储过程不规范卡死急需优化，无时间排期，导致重复报障一个月有50%报障率
            • 418_tb_dwd_ct_wh_detail_pay_day_oracle2hive🔜oracle2mysql_wh_succ_outcome🔜oracle2mysql_ym_t_whdljtmxym🔜oracle2mysql_ym_t_whygsrbym 外呼队列兼推没数据/外呼收入 没有rhsr21列(融合收入
              • 放到hive库跑 能看到报错日志 能优化
              • 缺乏开发规范管理
        • 伏羲录入表，任务启动时间
          • csap--csap250--oracle166-mysql
            • 伏羲页面数据更新但MySQL未更新，一个月两三次
      • 邓洁
        • 满意度数据故障问题
          • 翁磊+陈刚
      • 薛艳杰
        • 经分会的材料需要数据
          • 业务理解，为什么会变？数据需求分析。
  • 省公司数据支撑对接
    • 重要数据巡检日报 服务请求、外呼接触明细、企业微信、中台商机
      • ftp229专用
        • 一个月3到4次报障
        • 小时优化释放资源、缺失前置依赖补充减少报障
          • 中心提供清单-开发规范未配置-需工具自查
• 二、对每个工作范畴，梳理相关业务部门对我们的要求，最关注的事项（具体到具体业务场景）。
  • 1、服务运营部 1、中心及省公司重点考核运营指标 2、经分会材料数据支撑--运营监控指标（见孙慧慧2月25日邮件）日/日累计/月 2、市场部 营销漏斗转化模型 外呼酬金 3、服务营销中心 1、呼入酬金（收入） 2、众包积分（支出） 3、重点业务监控
    • 外呼酬金变化
    • 服务运营部-指标多-需求组对接
• 三、对每个工作范畴，梳理部门负责人，梳理职责（我们做什么合作方做什么，我们做了什么，我们该做的没做什么）。
  • 需求组
    • 要了解有哪些数据
      • 1.业务告知我们用哪些表？ 难道不是我们不应该比他们更知道数据吗？ 2.业务不知道用哪些表的，需求分析侧就更不知道，缺乏一个工具给大家查询，帮开发提前预判断，没有在需求下发前完成。
        • 导致报表套报表。
        • 开发人员不是很熟悉业务，没有数据资产，即使做过也无处可循。
          • 缺乏规范性的，缺乏客观科学的共享机制，大家各建各的。 以前离职的无人维护，导致口径变更，数据报障
            • 生命周期字典规范
    • 避免开发重复数据
    • 通过临统分析业务规划
      • 具体分析为什么会有临统？都有哪些需求
    • 了解在线营服数据平台基础功能
  • 开发组
    • 开发资源统筹管理（排期透明化等）
    • 开发质量
    • 开发效能
    • 自主研发 工作量细化
      • 1、数据源确认后，表权限申请 2、建立数据模型 3、执行数据模型 4、创建数据交换/程序开发： 5、执行程序查看日志成功情况——提前给业务侧验证 6、配置依赖：查询依赖情况-任务依赖、时间依赖 7、调度监控——平台任务监控查看前置依赖运行时间和时长 8、上线程序申请 9、上线报表生成名称 10、验收报表
    • 数据报障问题
      • 反馈数据不全面，哪天什么数据什么字段缺失，沟通浪费时间
        • 制定数据报障模板：时间、表名、字段名、正常数据格式、异常原因说明
        • 合作方对接会
      • 资源优化
        • 21年-24年数据都在用吗？——对应合作方开发不在职，无从查起，想优化或者下线无法确认
          • 对所有数据建立数据生命周期每月更新。
  • 合作方
    • 方案评估
      • 能否按照理想状态 按时按需 数据运行完成，及对 数据量级 占用资源的评估，业务 实时性 是否必要， 需在需求下发前提前判断沟通好，如源表关联关系分析
    • 需求预沟通
      • 所需模型表，数据源口径及筛选条件 编辑 说明文档 要在 下发需求前全部完成， 并避免多次修改口径变更，如确认变更，需及时补充临时意见，沟通开发 后续排期，再次评估变更后的工作量。
    • 反映问题：需求口径、验收存在通过合作方直接跟业务对接；未到岗就开发；
• 四、对每个工作范畴，梳理中心对接的部门（包括中心做什么我们做什么），承载的系统（分析平台、数据洞察等），提给中心的流程等；
  • 模型权限-联系最多-六七 步——透明处理-业务方，说清楚多少天。
  • 本部数据源问题支撑-1小时到一天不等，补刷。
  • 平台使用，版本更新，功能等使用的技术支撑
  • 7天连续报错/报表端执行查询超时/运行时间过长脚本整改
• 2025年江苏分中心数据运营