读数据质量管理：数据可靠性与数据质量问题解决之道01数据质量 ...

1. 为什么数据质量值得关注

1.1. 数据是你的CEO的首要任务
1.2. 下游数据消耗者（包括产品分析师、营销向导者和销售团队）则依赖于数据驱动的工具
1.3. 数据宕机

• 1.3.1. 指数据丢失、不准确或出现错误的情况，它表现为过时的仪表板、不准确的报告，甚至是糟糕的决策
  
• 1.3.2. 数据宕机的根源是不可靠的数据
  
• 1.3.3. 受数据宕机影响的不仅仅是公司的利润
  
• 1.3.3.1. 数据宕机每年都可能使公司丧失数百万美元，更不用说丢掉客户信任了
  
• 1.3.3.2. 处置惩罚数据质量问题将消耗数据团队40%以上的时间，这些时间本可以用于更风趣的项目或举行真正的业务创新
  
• 1.3.4. 数据宕机是软件工程和开发人员运营的必然结果，在这个天下中，应用程序的正常运行时间或宕机时间[即你的软件或服务可用（正常运行）或不可用（停机）的频率]都被细致度量，以确保软件的可访问性和性能
  

1.4. 卖弄信息还是技能错误造成的糟糕数据质量和不可靠的数据，不停都是构造所面临的重要问题
1.5. “坏数据”(bad data)和糟糕的数据质量这两个概念几乎与人类存在的时间一样长，尽管情势各有不同
1.6. 分析管道在过程的任何阶段都极易受到最无害变化的影响
1.7. 生产中的数据

• 1.7.1. 来自源系统（如CRM、CMS和前面提到的其他类似系统的数据库）的数据
  
• 1.7.2. 这些数据已经被数据仓库(data warehouse)、数据湖(data lake)或其他数据存储和处置惩罚解决方案接收，并通过数据管道流动（提取-转换-加载，即ETL）​，以便分析层将其呈现给业务用户
  

1.8. 数据管道既可以处置惩罚批数据，也可以处置惩罚流数据，并且在较高的条理上，度量这两种范例数据质量的方法都大致相同

• 1.8.1. 为构建决策仪表板、数据产品、机器学习模型和其他数据科学输出的数据分析数据管道提供动力
  

2. 数据质量

2.1. “数据质量”自从人类开始网络数据以来就已经存在了

• 2.1.1. 数据质量也是一种了解数据是否符合业务需求的有效方法
  

2.2. 在过去的几十年里，数据质量的定义已经开始具体化为度量数据可靠性、完整性和准确性的功能，因为它与报告时的状态相干
2.3. 高数据质量是全部强大分析程序的第一步
2.4. 数据质量定义为数据在其生命周期中任何阶段的健康状况

• 2.4.1. 数据质量可能在数据管道的任何阶段受到影响，无论是接收数据前、生产过程中，还是在分析过程中
  

2.5. 数据质量经常是一个糟糕的代表，数据团队知道他们必要优先思量它，但它并没有像“机器学习”​“数据科学”甚至“分析”那样一挥而就，许多团队没有充足的带宽或资源来找人全职管理它
2.6. ​“没数据总比坏数据好”这句话是该范畴专业人士经常抛出的一句话，固然它确实有道理，但这每每不是实际
3. 数据运营

3.1. 数据不仅是一种产出，更是一种金融商品，所以这些信息的可信度非常重要
3.2. DevOps是一个致力于收缩系统开发生命周期的技能范畴，催生了业界领先的最佳实践

• 3.2.1. DevOps的目标是通过自动化来发布更可靠、性能更好的软件
  

3.3. “数据运营”(DataOps)的情势将这些概念应用于数据

• 3.3.1. 数据运营指的是通过自动化来减少数据孤岛并促进更快、更容错的分析，以提高数据可靠性和性能的过程
  

3.4. 不准确、缺失或错误的数据会耗费公司的时间、款项以及客户的信任
3.5. 实施更妥当的测试到投资包括监控和数据可观测性在内的数据运营最佳实践，来不停复制这些努力
3.6. 影响数据的变量

• 3.6.1. 迁移到云端
  
• 3.6.1.1. 20年前，你的数据仓库（转换和存储布局化数据的地方）可能位于办公室的地下室内，而不是在亚马逊云计算服务(Amazon Web Services，AWS)或微软的Azure云计算服务上
  
• 3.6.1.2. 在许多方面，云都让数据变得更易管理，更容易被广泛的用户所访问，并且能以更快的速率举行处置惩罚
  
• 3.6.1.3. 在数据仓库迁移到云端后不久，数据湖也迁移到了云端，这为数据团队在管理数据资产方面提供了更大的灵活性
  
• 3.6.2. 更多的数据源
  
• 3.6.2.1. 数十到数百个内部与外部数据源来生成分析和机器学习模型
  
• 3.6.2.2. 任何一个来源都可能以意想不到的方式在没有事先通知的情况下发生变化，从而影响到公司用于决策的数据
  
• 3.6.3. 日益复杂的数据管道
  
• 3.6.3.1. 数据管道正变得越来越复杂：有多个处置惩罚阶段且各种数据资产之间存在重要的依赖关系
  
• 3.6.3.2. 如果不了解这些依赖关系，对一个数据集所做的任何更改都可能会产生意想不到的后果，从而影响相干数据资产的正确性
  
• 3.6.3.3. 源数据的提取、接收、转换、加载、存储、处置惩罚和交付，以及其他可能的步骤，其中包含了在管道不同阶段的许多API和集成
  
• 3.6.4. 更专业的数据团队
  
• 3.6.4.1. 随着公司越来越依赖数据来推动智能决策，公司正在招聘越来越多的数据分析师、数据科学家和数据工程师构建并维护数据管道、分析和机器学习模型，以支持其服务、产品以及业务运营
  
• 3.6.4.2. 当数据分析师重要负责网络、洗濯和查询数据集，以帮助各职能利益相干方对业务产生丰富、可操纵的见解时，数据工程师则负责确保支持这些分析的底层技能和系统是高性能、快速且可靠的
  
• 3.6.4.3. 在工业界，数据科学家通常会网络、整理、扩充和理解非布局化数据以改进业务
  
• 3.6.4.4. 更大型的公司可能会支持额外的脚色，包括数据管理员、数据管理负责人、运营分析师，甚至分析工程师
  

1. >  3.6.4.4.1. 分析工程师是一个数据工程师和分析师的混合角色，在可能还没有资源支持大型数据团队的创业公司和中型公司中很受欢迎

复制代码

• 3.6.4.5. 一个团队添加到数据表中的新字段可能会导致另一个团队的管道故障，从而导致数据全部或部分丢失
  
• 3.6.5. 去中央化的数据团队
  
• 3.6.5.1. 随着数据成为业务运营的中央，公司中越来越多的职能团队介入数据的管理和分析，以简化并加速洞察网络的过程
  
• 3.6.5.2. 越来越多的数据团队正在采用一种分布式、去中央化的模型，该模型模仿了整个行业从单体架构到微服务架构的迁移，这种迁移在20世纪10年代中期席卷了软件工程界
  
• 3.6.5.3. 不要把它与数据网格混淆，因为它是一种利用分布式的、面向域的筹划的构造范式，去中央化的数据架构由一个集中式数据平台团队管理，而分析和数据科学团队则分布在整个业务中
  
• 3.6.5.4. 多个域将生成并利用数据，这将不可避免地导致多个团队所使用的数据聚会集会随着时间的推移而重复、丢失或过时
  

4. 其他行业趋势

4.1. 数据网格

• 4.1.1. 数据网格在许多方面都是微服务的数据平台版本
  
• 4.1.2. 数据网格的概念还处于萌芽阶段，数据社区中有许多关于怎样（或是否故意义）在文化和技能层面上执行数据网格的讨论
  
• 4.1.3. 数据网格是一个社会技能范式，它识别了在复杂构造中人员与技能架构息争决方案之间的交互
  
• 4.1.4. 数据网格通过利用面向域的自助筹划来包含企业中无处不在的数据
  
• 4.1.5. 数据网格支持分布式、特定域的数据消耗者且视“数据即产品”​，在每个域中处置惩罚本身的数据管道，连接这些域及其相干数据资产的构造是应用相同语法和数据尺度的通用互操纵层
  
• 4.1.6. 数据网格团结了负责将数据作为产品提供的域数据全部者之间的数据全部权，同时也促进了跨不同位置的分布式数据之间的通信
  
• 4.1.7. 域的任务是管理数据的接收、洗濯和聚合，以生成可供商业智能应用程序使用的资产
  
• 4.1.8. 只有当数据可靠且值得信赖，并且跨域应用此“通用互操纵层”时，数据网格范式才能成功
  
• 4.1.9. 数据可靠和值得信赖的唯一方法是通过测试、监控和可观测性来密切关注数据质量
  

4.2. 流数据

• 4.2.1. 流数据指的是将一连的数据流传输到管道中，从而快速生成实时洞察的过程
  
• 4.2.2. 数据质量是通过批式数据进入生产管道前对其举行测试来欺凌执行的，但越来越多的企业正在寻求更为实时的分析
  

4.3. 湖仓一体(data lakehouse)的鼓起

• 4.3.1. 数据仓库（布局化数据存储库）和数据湖（原始非布局化数据池）都依赖于高质量的数据来举行处置惩罚和转换
  
• 4.3.2. 越来越多的数据团队选择同时使用数据仓库和数据湖来满足其业务不停增长的数据需求
  

4.4. 云、分布式数据架构和团队的鼓起，以及数据产品化的转变，使数据向导者有责任帮助其公司获得更值得信赖的数据（并因此得出更可靠的分析）​
4.5. 实现可靠数据的过程是一场马拉松，而不是一场短跑，它会涉及数据管道的多个阶段

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