读数据工程之道：设计和构建健壮的数据体系29分析

1. 互助脚色

1.1. 数据分析师
1.2. 数据科学家
1.3. MLOps/机器学习工程师
1.4. 业务侧

• 1.4.1. 数据或非技术的利益相干者、经理和高管
  

1.5. 数据工程师更多的是在支持这些利益相干者的工作，不一定对数据的最终使用方式负责
1.6. 数据工程师负责的是产出高质量的数据产物

• 1.6.1. 在数据服务阶段，数据工程师的一项紧张任务是将职责和工作内容分离
  

1.7. 数据工程走到了交付阶段后会产生反馈循环

• 1.7.1. 数据很少以静态存在，外部环境会影响到被获取和提供的数据，以及被二次获取和提供的数据
  

1.8. 采用数据网格会在很大程度上重新分配团队职责，每个领域的团队都必要承担各种提供数据服务的任务
2. 底层设计

2.1. 数据服务是数据工程生命周期底层设计的末了一部分内容

• 2.1.1. 数据生命周期是一个闭环，在环中的一切都是一脉相承的
  
• 2.1.2. 数据工程师必要一直寻找底层设计框架下可以或许资助数据产物提升的方法
  

2.2. 数据是一个无声的杀手

• 2.2.1. 提供数据服务是确保交付到终端用户手中的数据质量的末了一道屏障
  

2.3. 安全

• 2.3.1. 数据服务是最能体现数据安全必要性的一环
  
• 2.3.2. 对人和体系都要一如既往地推行最小权限的原则，只提供仅供当前工作所需的访问
  
• 2.3.2.1. 切忌对任何个人或任何服务给予完全开放允许
  
• 2.3.3. 提供数据服务一般只涉及只读权限，除非人或步伐必要更新被查询体系中的数据
  
• 2.3.3.1. 用户访问权限要限定在对特定命据库和数据集的只读权限，除非他们的工作必须使用更高级的权限，如写入或更新访问
  
• 2.3.3.2. 权限控制可以通过为用户组分配具有某些IAM脚色（即分析师组、数据科学家组）或自界说IAM脚色来完成
  
• 2.3.4. 访问控制应该尽大概地细化，并在不必要时收回
  
• 2.3.5. 访问控制在多租户环境中提供数据服务时是至关紧张的
  
• 2.3.5.1. 确保用户只能访问他们自己的数据
  
• 2.3.5.2. 过有过滤条件的视图来调整查询结果，从而削弱公用表的安全风险
  
• 2.3.5.3. 工作流中使用数据共享，这样就可以对数据使用方有只读粒度控制
  
• 2.3.6. 要检查数据产物的使用频率，以及考虑停止共享一些无用的数据产物
  
• 2.3.6.1. 如果数据产物没有在使用，就去问问用户是否还必要它们
  
• 2.3.6.2. 如果不必要，那就把该数据产物停掉，可以减少一个安全漏洞
  
• 2.3.7. 访问权限控制和安全不应该是数据服务的停滞，恰恰相反，它们是推动数据服务的关键因素
  
• 2.3.7.1. 由于安全措施没有得到正确落实，有效的数据大概很少能被访问
  
• 2.3.7.2. 细致、健壮的访问权限控制意味着可以进行更有代价的数据分析和机器学习，同时对企业及其客户也是一种保护
  

2.4. 数据管理

• 2.4.1. 关注点是确保人们可以或许获得高质量和值得信赖的数据
  
• 2.4.2. 信任是数据服务中最关键的因素
  
• 2.4.2.1. 如果人们信任他们的数据，就会使用它
  
• 2.4.2.2. 不受信任的数据会被闲置
  
• 2.4.2.3. 一定要收集用户的反馈，使数据信任和数据改进走向良性循环
  
• 2.4.2.4. 当用户与数据交互时，要让他们可以或许报告问题并提出改进
  
• 2.4.2.5. 在响应改进需求时，也要积极地与用户进行沟通
  
• 2.4.3. 使用数据脱敏手段可以向终端用户提供合成、打乱或匿名的数据
  
• 2.4.3.1. “假”数据集应该足以让分析师或数据科学家从数据中获得必要的有效信息，且可以防止暴露现实世界的实体
  
• 2.4.3.2. 在一些强力的数据处理方法下，许多数据集可以被实名或者逆向工程，但这些脱敏手段或多或少地降低了数据泄露的风险
  
• 2.4.4. 将语义层和度量层纳入数据服务层，同时建立可以正确表达业务逻辑和界说的严谨数据模型，可以或许为分析、机器学习、反向ETL或其他服务用途提供可信单一数据源
  

2.5. DataOps

• 2.5.1. 数据管理，也就是数据质量、数据管理和数据安全，都应该在DataOps的监控下
  
• 2.5.2. 监控的内容
  
• 2.5.2.1. 数据健康程度和数据不可用时间
  
• 2.5.2.2. 用来提供数据服务的仪表板、数据库等体系的延迟
  
• 2.5.2.3. 数据质量
  
• 2.5.2.4. 数据以及体系的安全性和访问权限
  
• 2.5.2.5. 提供的数据和模型的版本
  
• 2.5.2.6. 到达SLO标准的可用时间
  
• 2.5.3. 流行的数据可观测性工具旨在减少数据不可用时间和进步数据质量
  
• 2.5.4. 可观测性工具可以从数据领域跨越到机器学习领域，支持对模型和模型性能的监控
  
• 2.5.5. 传统的DevOps监控对DataOps也很紧张
  
• 2.5.6. 数据工程生命周期的每个阶段都要对代码进行版本控制并将代码摆设可操纵化
  
• 2.5.7. 使用多阶段的摆设（开辟、测试、生产）分析报告和模型
  

2.6. 数据架构

• 2.6.1. 在提供数据服务阶段，用户反馈循环要快速且精密
  
• 2.6.2. 应该让用户可以或许尽快访问所需数据
  

2.7. 编排

• 2.7.1. 数据服务是数据工程生命周期的末了阶段
  
• 2.7.2. 编排不仅仅是一种将复杂工作变得有组织和主动化的方式，也是协调跨团队数据流的手段，以便在答应的时间内将数据提供给消费者
  
• 2.7.3. 谁来负责数据任务编排是一个关键的组织决定
  
• 2.7.3.1. 非集中式方法让小型团队可以或许管理自己的数据流，但增长了跨团队协调的负担
  
• 2.7.3.2. 团队不能只管理单一体系内的数据流，而必要直接触发属于其他团队的DAG或任务，各团队必须跨体系传递消息或查询
  
• 2.7.3.3. 集中式方法意味着工作更容易协调，但把关也必须存在，以保护唯一的生产环境
  
• 2.7.3.4. 集中式的编排必要高标准、主动化的DAG测试和对体系的把关
  

2.8. 软件工程

• 2.8.1. 许多向终端用户提供数据服务的方法涌现出来，而数据工程师的重点变成了了解这些体系如何工作以及如何交付数据
  
• 2.8.2. 数据工程师必要负责的另一部分任务是了解代码和查询对存储体系的性能影响
  
• 2.8.3. 底子办法即代码的兴起意味着之前专注写代码的脚色正在转向构建可以支持数据科学家和分析师的体系
  
• 2.8.3.1. 数据工程师大概会负责建立CI/CD管道并为数据科学家和分析师的数据团队建立数据流程
  
• 2.8.3.2. 数据工程师也会培训和支持这些数据团队使用数据工程师所建立的Data/MLOps底子办法，以便这些数据团队走向自给自足
  
• 2.8.4. 对于嵌入式分析，数据工程师必要与应用步伐开辟人员互助，以确保查询可以或许快速且经济有效地返回
  
• 2.8.4.1. 应用步伐开辟人员负责面向用户的前端代码，数据工程师负责让前端收到准确的数据
  
• 2.8.5. 优秀的数据工程师总是乐于接受新的反馈，并不断改进
  

3. 分析

3.1. 最常见的数据服务用例是分析
3.2. 分析指的是发现、探索、识别以及让数据中的关键洞见和模式变得可见
3.3. 分析是通过统计方法、报告和BI工具等进行的
3.4. 作为数据工程师，了解各种工具和分析方法是完成工作的关键
4. 业务分析

4.1. 业务分析是一门科学，也是一门艺术

• 4.1.1. 业务分析会运用汗青和新产生的数据来做计谋性的且可实行的决定
  

4.2. 通过统计数据和趋势分析以及领域专家和人为判断的共同配合，来做出会影响长期业务走向的决定

• 4.2.1. 好的分析师往往可以或许参与到业务当中，并且可以深入数据答复问题，解密隐藏或者反直觉的趋势和洞见
  
• 4.2.2. 可以和数据工程师一同来为数据质量、可靠性问题以及新的数据集需求提供参考意见
  
• 4.2.3. 数据工程师则必要负责落地这些参考意见并且为分析师提供新的数据集
  
• 4.2.3.1. 必要考虑对现有和未来数据的各种潜在应用
  
• 4.2.3.2. 数据工程师必须使用最符合的后端技术方案来为业务分析提供数据服务
  

4.3. 仪表板

• 4.3.1. 能简明扼要地将反映组织运行情况的几个焦点指标展示给决定层
  
• 4.3.1.1. 通过可视化（图表或热力图等）​、汇总统计，乃至是单个数字来展示
  
• 4.3.2. 最高决定层会看顶层仪表板，而他们的直属下级会看带有特定指标、KPI或者OKR（Objective and Key Result，目的和关键成果）的仪表板
  
• 4.3.3. Tableau、Looker、Sisense、Power BI，以及Apahe Superset/Preset
  

4.4. 报告

• 4.4.1. 业务利益相干者会要求分析师创建报告
  
• 4.4.2. 使用报告的目的是使用数据得出洞见和决定
  
• 4.4.3. 调查结果被汇总在一份报告中，并在仪表板地点的同一BI工具中发布
  

4.5. 专项分析

• 4.5.1. 深入探究某个潜在的问题并产出洞见，这就是专项分析的一个案例
  
• 4.5.2. 调查报告通常以专项需求作为起始
  
• 4.5.3. 如果专项分析的产出有影响力，那么就会演变成一个报告或仪表板
  

4.6. 报告、专项分析和仪表板用的都是类似的工具，比如Excel、Python、基于R的notebook、SQL查询等
4.7. 业务分析数据常常以批处理模式从数据堆栈或者数据湖供应
4.8. 为用例提供数据服务时，不同的更新频率经常混淆在一起使用

• 4.8.1. 从上游获取数据的频率是下游所使用数据更新频率的上限
  
• 4.8.2. 如果数据是由流式应用产生的，那么数据就应该通过流式获取，纵然下游使用批处理方式做数据的处理和服务也应如此
  

4.9. 在数据湖或者数据堆栈中运行查询

• 4.9.1. 优点是可以更好发挥OLAP数据库的能力
  
• 4.9.2. 缺点是成本、权限控制，以及时延方面的问题
  

5. 运营分析

5.1. 运营分析是用数据来进行即时的操纵

• 5.1.1. 在工厂摆设实时分析
  
• 5.1.1.1. 使用现成的云机器视觉工具来主动实时识别次品
  

5.2. 运营分析与业务分析=即时操纵与可供实行的洞见

• 5.2.1. 随着流数据和低延迟数据更加普遍，用运营分析的方法解决业务分析的问题才是正确的思绪
  
• 5.2.2. 数据架构会变成可以让“热到发烫”的低时延流数据和暖数据共存一处
  

5.3. 差别体现在时间上：业务分析用的数据是从更长远的角度对待所考虑的问题

• 5.3.1. 秒级的数据更新是很好的，但是并不会实质性地影响分析结果
  
• 5.3.2. 运营分析则恰恰相反，数据更新的实时程度对解决时下发生的问题有很大的影响
  

5.4. 例子是应用步伐的实时监控

• 5.4.1. 如果体系到达某个阈值，监控体系也可以通过短信、群聊通知和邮件发送告警
  

5.5. 正确的行动才会产生影响力和代价

• 5.5.1. 没有促成行动的实时数据只会变成一团乱麻
  

5.6. 从长远看，流数据会逐渐取代批处理数据

• 5.6.1. 未来十年的数据产物更有大概是流优先，并且有能力无缝衔接汗青数据
  
• 5.6.2. 实时采集的数据仍然可以按需求以批处理的形式来消费和处理
  

6. 嵌入式分析

6.1. 业务分析和运营分析更多关注于组织内部，而面向外部的，也就是嵌入式分析成了最新的趋势
6.2. 向终端用户提供更多的分析结果

• 6.2.1. 数据应用步伐，多数在应用步伐内部嵌入了分析仪表板
  
• 6.2.2. 面向终端用户仪表板的嵌入式分析可以给用户提供他们和应用相干联的关键指标
  

6.3. 数据工程师一般不会去开辟嵌入式分析的前端

• 6.3.1. 专业的应用步伐开辟人员来做这项工作
  

6.4. 数据工程师要维护嵌入式分析使用的数据库，因此必要了解嵌入式分析的速度和时延要求
6.5. 进步嵌入式分析的性能必要解决三个问题

• 6.5.1. 用户都希望获得低延迟的数据
  
• 6.5.1.1. 应用步伐的用户不会像公司内的分析师那样容忍批处理
  
• 6.5.2. 用户想要更高的查询服从
  
• 6.5.3. 支持高并发就是非常关键的
  
• 6.5.3.1. 必要支持发生在多个仪表板和浩繁用户中非常高的查询率
  

6.6. 转向新一代拥有快速查询、高并发，以及近实时更新并且易用（例如基于SQL的分析）的高性能数据库

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。