读数据工程之道：计划和构建健壮的数据系统28数据服务常见关注点 ...

1.       使用场景

1.1.         为分析和BI，也就是统计分析、报表和仪表板提供数据服务

• 1.1.1.           是数据服务最为常见的目标
  
• 1.1.2.           这些概念的提出早于IT和数据库，但是它们对于了解业务、构造和财务流程的利益干系者来说仍然至关紧张
  

1.2.         为机器学习应用程序提供数据服务

• 1.2.1.           机器学习完全依赖于高质量的数据
  
• 1.2.2.           数据科学家和机器学习工程师需要在数据工程师的资助下来获取、转化以及交付必要的数据，从而训练模型
  

1.3.         为反向ETL提供数据服务

• 1.3.1.           反向ETL是一种将数据回传给数据源的过程
  
• 1.3.2.           反向ETL和BI以及机器学习有着深度的共生关系
  

2.       常见关注点

2.1.         信托

• 2.1.1.           人们需要相信你提供的数据
  
• 2.1.2.           花20年建立的名誉可能只需要5分钟就可以毁掉。假如你明白这一点，你就会换种方式办事变。
  
• 2.1.2.1.            沃伦·巴菲特(Warren Buffett)
  
• 2.1.3.           信托一旦丢失就极难挽回
  
• 2.1.3.1.            不可避免的了局是业务方不能发挥数据的潜在代价，数据团队也会丢失信誉（甚至被解散）​
  
• 2.1.4.           信托是提供数据服务的根本关注点
  
• 2.1.4.1.            终端用户需要信托他们接收的数据
  
• 2.1.4.2.            失去信托通常是数据项目无声的表钟，即使这个项目直到几个月或几年后才正式取消
  
• 2.1.5.           利用数据验证流程以及数据可观测性流程，同时与利益干系者一起目视检查和确认数据有用性
  
• 2.1.5.1.            数据验证使用数据分析方法来保证数据可以忠实反映财务信息、客户行为以及销售记载等信息
  
• 2.1.5.2.            数据可观测性提供了一个观测数据和数据处置惩罚的持续视图
  
• 2.1.6.           SLA和SLO也是工程师建立终端用户和上游利益干系者信托的必要手段
  
• 2.1.6.1.            当用户开始依赖数据来完成业务需求时，会要求使用的数据有持续的可用性以及数据工程师保障的最新状态
  
• 2.1.6.2.            高质量的数据在没有达到预期内的可用性时很难发挥辅助商业决策的代价
  
• 2.1.6.3.            SLA和SLO也可以采用正式或者非正式的数据契约形式
  
• 2.1.6.4.            SLA都给了用户对于数据产物的预期
  
• 2.1.6.5.            SLO是SLA的关键部分，阐述了用于衡量契约的方法
  
• 2.1.7.           肯定要确保各方的预期是清晰的，并且你有能力验证可否满足约定的SLA和SLO
  
• 2.1.8.           对SLA达成同等是不够的
  
• 2.1.8.1.            持续的沟通才能维持一个好的SLA：对可能对SLA和SLO预期有影响的事项进行沟通，并提供补救和改进措施
  

2.2.         用例是什么，用户又是谁

• 2.2.1.           需要了解你的用例和用户、产出的数据产物以及怎样提供数据服务（是否自助服务）​、数据定义和逻辑，以及数据网格
  
• 2.2.2.           数据服务层是为了数据的使用
  
• 2.2.2.1.            数据在决策中的作用才是核心
  
• 2.2.3.           数据的用例远远超出了查看报告和仪表板的范围
  
• 2.2.3.1.            一份数据往往被用于多个用例
  
• 2.2.4.           高质量、高影响力的数据自然而然地会吸引很多很有趣的用例
  
• 2.2.5.           尽量挑选有着最高ROI的用例
  
• 2.2.5.1.            数据工程师喜欢纠结于他们搭建的系统的技术实现细节，而忽略目的
  
• 2.2.5.2.            当工程师能够以代价和用例为导向时，产出就能更有代价和效率
  

1. >  2.2.5.2.1.             很多工程师只想做最擅长的事情：搞工程

复制代码

• 2.2.6.           当开启一个新的数据项目时，倒排工序是很有必要的
  
• 2.2.7.           问自己的一些标题
  
• 2.2.7.1.            谁会使用这些数据？怎么用？
  
• 2.2.7.2.            利益干系者有什么期望？
  
• 2.2.7.3.            怎么和数据利益干系者（数据科学家、分析师、业务用户）合作，更好地了解这些数据的用途？
  
• 2.2.8.           在开展数据工程的时候，肯定要从用户及其用例入手
  
• 2.2.8.1.            在了解他们的期望和目标后，就会更容易产出优秀的数据产物
  

2.3.         数据产物

• 2.3.1.           数据产物的精良定义是能够通过使用数据促成最终目标的产物。
  
• 2.3.1.1.            D.J.Patil
  
• 2.3.2.           数据产物不是凭空产生的
  
• 2.3.2.1.            开辟数据产物像是一项需要全身心投入的运动，在技术的框架下混合了产物和业务
  
• 2.3.2.2.            核心利益干系者加入数据产物的开辟黑白常紧张的
  
• 2.3.2.3.            一个好的数据产物应该有着正反馈循环
  

1. >  2.3.2.3.1.             更多的数据产品使用产生更多的有用数据，产品也因此得以改进

复制代码

• 2.3.3.           在大多数公司，数据工程师会负责除了终端用户操纵外的数据产物全流程
  
• 2.3.3.1.            优秀的数据工程师会尽力去了解提供给直接用户（好比数据分析师、数据科学家或公司外部客户）的产物
  
• 2.3.4.           当创造一个数据产物时，应该从“完成使命”的角度思索
  
• 2.3.4.1.            用户为了“完成使命”才“雇用”数据产物
  
• 2.3.4.2.            常犯的错误是在不了解终端用户的需求或者没有产物市场调研的情况下盲目开辟
  
• 2.3.5.           做大家都爱用的数据产物是很难的
  
• 2.3.5.1.            没用的特性和失信的数据会破坏数据产物的采用
  
• 2.3.5.2.            需要专注在数据产物的采用和利用上，并且愿意做出令用户满足的调整
  

2.4.         是否用自助服务

• 2.4.1.           让用户可以自己构建数据产物
  
• 2.4.2.           落地难度高，数据自助服务项目容易有头无尾
  
• 2.4.3.           假如面向的用户是高管级别的，他们想知道业务运行情况，那么一个清晰且有着可操纵指标的预定义仪表板往往就充足了
  
• 2.4.3.1.            假如报告展现了更多标题，那么他们可能会找分析师来深挖数据
  
• 2.4.4.           乐成搭建自助服务数据项目从找对受众开始，辨认自助服务用户和他们要做的“工作”​
  
• 2.4.5.           具备数据干系技术背景的业务主管，他们就很适合自助服务，他们可能想要自己对数据进行切片，而又不重拾SQL技能
  
• 2.4.6.           构建好的数据自助服务要确定如作甚特定用户提供数据服务
  
• 2.4.7.           更多的数据带来更多的标题，而这又需要更多的数据来办理
  
• 2.4.8.           需要理解机动性和范围之间的玄妙平衡，这将有助于你的受众找到代价和洞见，而不会产生错误的结果和混乱
  

2.5.         数据定义和逻辑

• 2.5.1.           构造中利用数据看重的是它的准确性和可信度
  
• 2.5.1.1.            数据的准确性不仅仅是对源系统中事件值的忠实再现
  
• 2.5.1.2.            数据准确性包罗了准确的数据定义和逻辑，这两个要素必须融入数据的全生命周期，从源系统到数据管道，再到BI工具等
  
• 2.5.2.           数据定义指的是数据在一个构造中的共识
  
• 2.5.3.           数据逻辑规定了指标计算公式
  
• 2.5.3.1.            符合的逻辑必须融汇数据定义以及完备的统计方法
  
• 2.5.3.2.            要计算客户流失率指标，就需要定义谁是客户
  
• 2.5.3.3.            要计算净利润，就需要一系列的规则来规定从收入总额扣除哪些支出
  
• 2.5.4.           数据定义和逻辑的存在经常被认为是理所当然的，并且在构造内以构造知识(institutional
  

knowledge)的形式流传

• 2.5.5.           构造知识有着自己的生态，很大程度上会以“奇闻”代替数据推动的洞见、决策和行动
  
• 2.5.6.           数据定义体现为多种形式，有些是显式的，但是多数是隐式的
  
• 2.5.6.1.            隐式是指为查询、仪表板或者机器学习提供数据服务时，数据和指标总是可以被持续准确地展示
  
• 2.5.7.           语义层可以整合业务定义和逻辑，使其可复用
  
• 2.5.7.1.            一次建立，全局通用
  
• 2.5.7.2.            范式是建立指标、计算规则和逻辑的面向对象头脑的体现
  

2.6.         数据网格

• 2.6.1.           一种日益流行的数据服务提供方式
  
• 2.6.2.           数据网格从根本上改变了构造内部的数据服务提供方式
  
• 2.6.3.           与孤立的数据团队服务于内部成员差别，数据网格需要每个业务领域的团队同时担负起去中心化的、点对点的数据服务的责任
  
• 2.6.3.1.            团队要对其他团队的数据消耗负责
  
• 2.6.3.2.            数据必须都是开箱即用的
  

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