读数据自助服务实践指南：数据开放与洞察提效01数据介绍 ...

1. 数据介绍

1.1. 数据是新的石油

• 1.1.1. 当今的企业拥有丰富的数据，但缺乏数据洞察力
  
• 1.1.2. 现在，企业内部的结构化数据、半结构化数据以及非结构化数据的数据量呈指数级增长
  
• 1.1.3. 尽管在数据湖中网络了大量数据，但它们可能不一致、无法解释、不准确、不及时、未尺度化或不充实
  

1.2. 工程师通常缺乏必要的业务背景

• 1.2.1. 工程的复杂性限制了数据分析师和科学家获取数据，导致数据无法在产品管理、营销、金融、工程等范畴得到应用
  

1.3. 开发机器学习洞察的自助服务平台

• 1.3.1. 谷歌的TensorFlow Extended
  
• 1.3.2. Uber的Michelangelo
  
• 1.3.3. Facebook的FBLearner Flow
  

1.4. 没有普遍实用的银弹策略

• 1.4.1. 每个企业在现有技术构建块、数据集质量、支持的用例类型、流程和人员技能方面都是独一无二的
  

1.5. 自助服务数据平台筹划在执行过程中要么失败，要么中途放弃的缘故原由

• 1.5.1. 在沟通中迷失了数据用户真正的痛点
  
  
  
  • 1.5.1.1. 数据用户和数据平台工程师的视角差别
    
  • 1.5.1.2. 数据工程师不懂详细的业务题目且把握不到数据用户的痛点
    
  • 1.5.1.3. 数据用户不了解大数据技术的局限性和现实情况
    
  • 1.5.1.4. 导致团队之间相互指责，无法得出一个持久的解决方案
    
  
  
• 1.5.2. 为了技术而接纳“闪亮”的新技术
  
  
  
  • 1.5.2.1. 鉴于解决方案众多，团队经常接纳下一个“闪亮”的技术，而不清楚减缓提取洞察的题目
    
  • 1.5.2.2. 很多时间，企业终极是为了技术而投资技术，而没有淘汰提取洞察的总体时间
    
  
  
• 1.5.3. 在转型过程中处置惩罚过多的题目
  
  
  
  • 1.5.3.1. 在转型过程中处置惩罚过多的题目
    
  • 1.5.3.2. 团队的目的通常是处置惩罚全部方面的工作，这无异于煮沸大海
    
  • 1.5.3.3. 开发自助服务数据平台应该像开发自动驾驶汽车（具有差别级别的自动驾驶能力）一样，在自动化水平和实现复杂性方面有所差别
    
  
  

2. 从原始数据到洞察

2.1. 传统上，数据仓库聚合了来自事务性数据库的数据，并生成回首性的批处置惩罚陈诉
2.2. 数据仓库解决方案通常由单一的供应商打包贩卖，集成了元数据编目、查询调理、接入毗连器等功能
2.3. 在本日的大数据时代，数据平台是由差别的数据存储、框架和处置惩罚引擎组合而成的，支持多种数据属性和洞察类型
2.4. 大数据时代的标语是根据数据类型、用例需求、数据用户的复杂水平以及与已部署技术的互操作性，使用“符合的工具来完成符合的工作”​
2.5. 提取洞察分为四个关键阶段：发现、预备、构建和实施
2.6. 在提取洞察的每个阶段，数据用户都把大量时间花在数据工程任务上，比如迁移数据、了解数据沿袭、搜刮数据工件等。数据用户的理想“天堂”是一个数据自助服务平台，它可以简化和自动化日常工作中遇到的任务
3. 发现

3.1. 全部洞察项目都是从发现可用的数据集和工件，并网络提取洞察所需的任何额外数据开始的
3.2. 数据发现的复杂性源于企业内部知识扩展的困难性
3.3. 数据团队往往从小规模开始，团队知识容易获得且可靠
3.4. 随着数据量的增长和团队规模的扩大，会在各业务线之间形成孤岛，导致没有可信的单一数据源
3.5. 发现数据集的元数据细节

• 3.5.1. 第一步是理解元数据的属性，比如数据来自何处、数据属性是怎样生成的等
  
• 3.5.2. 数据用户起首获取其他用户提供的团队知识，这些知识可能是过时的和不可靠的
  
• 3.5.3. 在数据集被网络和转换的过程中，没有尺度化的格式来跟踪数据集的元数据
  

3.6. 搜刮可用的数据集和工件

• 3.6.1. 具备理解数据集元数据细节的能力后，下一步就是找到全部相关的数据集和工件，包括视图、文件、流、变乱、指标、仪表盘、ETL和即席查询等
  
• 3.6.2. 根据规模的差别，数据用户可能必要耗费数天或数周的时间来确定相关细节
  
• 3.6.3. 可用的数据集和工件在不停地演进，必要不停地更新元数据
  

3.7. 为机器学习模型重用或创建特征

• 3.7.1. 作为机器学习模型输入的属性（如收入）称为特征
  
• 3.7.2. 如果汗青数据可用，那么属性就可以作为特征使用
  
• 3.7.3. 重用现有特征可以从根本上淘汰机器模型的开发时间
  

3.8. 聚合缺失的数据

• 3.8.1. 为了访问横跨差别应用步伐孤岛的数据集，通常必要将这些数据集汇总并迁移到一个集中式的中心存储库中，类似数据湖
  
• 3.8.2. 一旦将洞察部署到生产情况中，数据迁移就是一个持续的任务，必要作为管道的一部分进行管理
  

3.9. 管理点击流变乱

• 3.9.1. 点击流数据在用于生成洞察之前，必要经过聚合、过滤和丰富
  
• 3.9.2. 处置惩罚大量的流变乱非常具有挑战性，特别是在近及时的应用场景中，例如定向个性化
  

4. 预备

4.1. 预备阶段致力于为构建现实业务逻辑以提取洞察做好数据预备
4.2. 包括数据聚合、清理、尺度化、转换和反规范化
4.3. 在中心存储库中管理聚合数据

• 4.3.1. 业务仪表盘和猜测模型所需的数据现在聚合在一个中心存储库（通常称为数据湖）中
  

4.4. 结构化、清理、丰富和验证数据

• 4.4.1. 现在数据已经聚集在湖中，我们必要确保数据的格式是正确的
  
• 4.4.2. 转换不是一次性的，而是必要以可靠的方式持续应用
  

4.5. 确保数据权限合规

• 4.5.1. 假设客户差别意使用他们的行为数据来产生洞察，则数据用户必要了解哪些客户的数据可以用于哪些用例
  
• 4.5.2. 合规性是在给客户提供更好的洞察体验和确保数据的使用符合客户的意图之间的平衡
  

5. 构建

5.1. 构建阶段的重点是编写提取洞察所需的现实逻辑
5.2. 确定访问和分析数据的最佳方法

• 5.2.1. 构建阶段的起点是确定编写和执行洞察逻辑的策略
  
• 5.2.2. 数据湖中的数据可以持久化为对象，也可以存储在专门的服务层中，即键-值存储、图数据库、文档存储等
  
• 5.2.3. 数据用户必要决定是否使用数据存储的原生API和关键字，并确定处置惩罚逻辑的查询引擎
  

5.3. 编写转换逻辑

• 5.3.1. 业务仪表盘或模型洞察的现实逻辑通常是以提取-转换-加载（ETL）​、提取-加载-转换（ELT）或流式分析模式编写的
  
• 5.3.2. 业务逻辑必要被翻译成高性能、可扩展性良好且易于管理更改的代码
  
• 5.3.3. 必要监控逻辑的可用性、质量和变动管理
  

5.4. 训练模型

• 5.4.1. 随着数据集和深度学习模型的规模不停增长，训练可能必要几天乃至几周的时间
  
• 5.4.2. 训练是迭代的，有数百种模型参数和超参数值的排列组合，用于寻找最佳模型
  
• 5.4.3. 模型训练不是一次性的，必要针对数据属性的变化重新训练
  

5.5. 持续集成机器学习模型变化
5.6. 洞察的A/B测试

• 5.6.1. A/B测试（也称为桶测试、拆分测试或控制实验）正在成为做出数据驱动决策的尺度方法
  
• 5.6.2. 将A/B测试整合为数据平台的一部分，以确保在机器学习模型、业务陈诉和实验中应用一致的指标定义，这一点至关重要
  
• 5.6.3. 正确配置A/B测试实验非常重要，而且必须确保不存在不平衡，制止导致差别群体之间的兴趣度量在统计上出现明显差异
  

6. 实施

6.1. 在提取洞察的实施阶段，洞察模型已经部署到生产情况中
6.2. 此阶段不停持续到洞察模型在生产中被广泛使用为止
6.3. 验证和优化查询

• 6.3.1. 继续以业务仪表盘和收入猜测模型为例，数据用户编写了数据转换逻辑，可以是SQL查询，也可以是用Python、Java、Scala等实现的大数据编程模型
  
• 6.3.2. 好的查询和不好的查询之间的差异非常明显
  

6.4. 编排管道

• 6.4.1. 编排是确保管道服务水平协议（SLA）和有效使用底层资源的一种平衡行为
  
• 6.4.2. 管道调用的服务横跨接入、预备、转换、训练和部署
  
• 6.4.3. 管道的编排是多租户的，支持多个团队和业务用例
  

6.5. 部署机器学习模型

• 6.5.1. 猜测模型部署在生产情况中，以便差别的步伐调用它以获得猜测值
  
• 6.5.2. 部署模型不是一次性的任务—机器学习模型会根据重新训练定期更新
  
• 6.5.3. 数据用户使用非尺度化、自主开发的脚本来部署必要定制的模型，以支持广泛的机器学习模型类型、机器学习库与工具、模型格式和部署终端（如物联网设备、移动设备、浏览器和Web API）​
  

6.6. 监控洞察的质量

• 6.6.1. 不正确的值的缘故原由
  
  
  
  • 6.6.1.1. 差别步的源模式更改
    
  • 6.6.1.2. 数据元素属性发生变化
    
  • 6.6.1.3. 数据接入题目
    
  • 6.6.1.4. 源系统和目的系统的数据差别步
    
  • 6.6.1.5. 处置惩罚失败
    
  • 6.6.1.6. 生成指标的业务定义不正确
    
  
  

6.7. 持续本钱监控

• 6.7.1. 实施阶段的最后一部分是本钱管理
  
• 6.7.2. 在云端，本钱管理尤其关键，即付即用的付费模型会随着使用量的增加而线性增长（与传统的先买后用、固定本钱模式差别）​
  

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