读数据工程之道：设计和构建健壮的数据体系04数据工程生命周期（下）
https://img2024.cnblogs.com/blog/3076680/202410/3076680-20241008123448486-808556745.png1. 获取
1.1. 在相识数据源、所用源体系的特征以及数据的存储方式之后，你需要网络数据
1.2. 数据工程生命周期的下一阶段是从源体系中获取数据
[*]1.2.1. 源体系和获取代表了数据工程生命周期中最重要的瓶颈
[*]1.2.2. 源体系通常不在你的直接控制范围内，可能会随机变得无响应或提供质量差的数据
[*]1.2.3. 你的数据获取服务可能出于多种原因神秘地停止工作
[*]1.2.4. 不可靠的源和获取体系会在整个数据工程生命周期中产生连锁反应
1.3. 重要问题
[*]1.3.1. 正在获取的数据的用例有哪些？
[*]1.3.1.1. 可以重用这些数据而不是创建同一数据集的多个版本吗？
[*]1.3.2. 体系是否可靠地天生和获取这些数据，这些数据是否在我需要时可用？
[*]1.3.3. 获取后的数据目的地是什么？
[*]1.3.4. 需要多久访问一次数据？
[*]1.3.5. 数据通常以多大的体积到达？
[*]1.3.6. 数据的格式是什么？
[*]1.3.6.1. 卑鄙存储和转换体系可以处置惩罚这种格式吗？
[*]1.3.7. 源数据是否处于良好状态以供直接卑鄙使用？
[*]1.3.7.1. 假如是如许，连续多长时间，什么可能导致它无法使用？
[*]1.3.8. 假如数据来自流媒体源，是否需要在到达目的地之前进行转换？
[*]1.3.8.1. 在数据流自己内转换数据的情况下，进行中的转换是否合适？
1.4. 批处置惩罚与流处置惩罚
[*]1.4.1. 处置惩罚的所有数据本质上都是流式传输的
[*]1.4.2. 数据几乎总是在其源头不断地产生和更新
[*]1.4.3. 批量获取只是一种专门且方便的大块处置惩罚数据流的方法
[*]1.4.4. 流式获取使我们可以大概以连续、及时的方式向卑鄙体系提供数据
[*]1.4.4.1. 及时（或靠近及时）意味着数据在天生后的很短的时间内（例如，不到1秒后）就可以供卑鄙体系使用
[*]1.4.4.2. 符合及时性要求的耽误因范畴和要求而异
[*]1.4.4.3. 流处置惩罚似乎是个好主意，但它并不总是直截了当的；额外的成本和复杂性一定会发生
[*]1.4.5. 批量数据在预定的时间间隔或当数据达到预设大小阈值时被获取
[*]1.4.5.1. 批量获取是一扇单向门：一旦数据被分成批次，卑鄙消耗者的耽误就会受到固有的限定
[*]1.4.6. 批处置惩罚恒久以来不停是获取数据的默认方式
[*]1.4.6.1. 批处置惩罚仍然是为卑鄙消耗提取数据的一种非常流行的方式，特别是在分析和ML中
[*]1.4.7. 许多体系中存储和盘算的分离以及事件流和处置惩罚平台的普遍存在，使得数据流的连续处置惩罚更容易获得并且越来越受接待
[*]1.4.7.1. 选择在很大程度上取决于使用情况和对数据及时性的期望
[*]1.4.8. 关键考虑因素
[*]1.4.8.1. 假如我及时获取数据，卑鄙存储体系能否处置惩罚数据流的速率？
[*]1.4.8.2. 需要毫秒级的及时数据获取吗？
>1.4.8.2.1. 或者采用微批处理方法，例如每分钟收集和获取数据？
[*]1.4.8.3. 流式获取的用例有哪些？
>1.4.8.3.1. 通过实施流处理，我有哪些具体优势？
>1.4.8.3.2. 如果我实时获取数据，我可以对这些数据采取什么行动来改进批处理？
[*]1.4.8.4. 流处置惩罚方法在时间、金钱、维护、停机时间和机会成本方面是否会比简单地进行批处置惩罚耗费更多？
[*]1.4.8.5. 假如底子设施出现故障，我的流处置惩罚管道和体系是否可靠且冗余？
[*]1.4.8.6. 哪些工具最适合用例？
[*]1.4.8.7. 假如我正在部署ML模型，在线预测和可能的连续练习对我有什么好处？
[*]1.4.8.8. 我是从及时生产实例获取数据吗？
>1.4.8.8.1. 如果是这样，我的获取过程对此源系统有何影响？
[*]1.4.9. 许多出色的获取框架确实可以处置惩罚批处置惩罚和微批处置惩罚获取方式
[*]1.4.9.1. 批处置惩罚是许多常见用例的绝佳方法，例如模型练习和每周陈诉
[*]1.4.9.2. 只有在确定了可以权衡使用批处置惩罚的业务用例之后，才能采用真正的及时流
1.5. 推送与拉取
[*]1.5.1. 在数据获取的推送模型中，源体系将数据写入目标体系，无论是数据库、对象存储还是文件体系
[*]1.5.2. 在拉取模型中，数据是在源体系中检索
[*]1.5.3. 推送和拉取范式之间的界限可能非常模糊
[*]1.5.4. 数据在数据管道的各个阶段工作时，经常会被推送和拉取
[*]1.5.5. 在传统的ETL中，获取体系按固定的时间表查询当前源表快照
[*]1.5.6. 连续CDC
[*]1.5.6.1. 每当源数据库中的一行发生更改时，一种常用方法都会触发一条消息
[*]1.5.6.2. 这条消息被推送到一个队列中，获取体系在队列中获取它
[*]1.5.6.3. CDC方法使用二进制日志，它记录对数据库的每次提交
>1.5.6.3.1. 获取系统读取日志但不直接与数据库交互
>1.5.6.3.2. 这几乎不会对源数据库增加额外负载
[*]1.5.6.4. 某些版本的批处置惩罚CDC使用拉取模式
>1.5.6.4.1. 在基于时间戳的CDC中，获取系统查询源数据库并提取上次更新以来已更改的行1.6. 通过流式获取，数据绕过后端数据库并直接推送到终端，通常由事件流平台缓冲数据
[*]1.6.1. 此模式对于发射传感器数据的IoT传感器队列很有用
[*]1.6.2. 我们不是依靠数据库来维护当前状态，而是简单地将每个记录的读数视为一个事件
[*]1.6.3. 简化了及时处置惩罚，允许应用程序开发人员为卑鄙分析定制消息，并极大地简化了数据工程师的工作
2. 转换
2.1. 数据工程生命周期的下一个阶段是转换，这意味着数据需要从其原始形式转变为对卑鄙用例有用的形式
[*]2.1.1. 假如没有适当的转换，数据将处于惰性状态，并且不会以对陈诉、分析或ML有用的形式出现
[*]2.1.2. 转换阶段是数据开始为卑鄙用户消耗创造价值的阶段
2.2. 在获取后，根本转换立即将数据映射到正确的范例，将记录放入标准格式，并删除错误的记录
[*]2.2.1. 转换的后期阶段可能会转换数据模式并应用规范化
[*]2.2.2. 在卑鄙，我们可以应用大规模聚合来陈诉或对ML过程的数据进行特征化
2.3. 重要考虑因素
[*]2.3.1. 转换的成本和投资回报率(Return On Investment，ROI)是多少？
[*]2.3.1.1. 干系的商业价值是什么？
[*]2.3.2. 转换是否尽可能简单和自我隔离？
[*]2.3.3. 转换支持哪些业务规则？
2.4. 可以批量转换数据，也可以在传输过程中进行流式转换
[*]2.4.1. 几乎所有数据都以连续流的形式开始，批处置惩罚只是处置惩罚数据流的一种特殊方式
[*]2.4.2. 批处置惩罚转换非常受接待，但鉴于流处置惩罚办理方案的日益普及和流数据量的普遍增长，预计流式转换的受接待程度将继续增长，大概很快就会在某些范畴完全取代批处置惩罚
2.5. 转换视为数据工程生命周期的一个独立范畴，但生命周期的实际情况在实践中可能要复杂得多
2.6. ML的数据特征化是另一个数据转换过程
[*]2.6.1. 特征化旨在提取和加强对练习ML模型有用的数据特征
[*]2.6.2. 特征化可能是一门暗黑艺术，它联合了范畴专业知识（以确定哪些特征可能对预测很重要）与数据科学方面的丰富经验
3. 服务
3.1. 数据工程生命周期的最后阶段
[*]3.1.1. 现在数据已被获取、存储并转换为连贯且有用的结构，是时间从你的数据中获取价值了
[*]3.1.2. 从数据中“获取价值”对不同的用户意味着不同的事情
[*]3.1.3. 数据服务可能是数据工程生命周期中最令人兴奋的部分
3.2. 当数据用于实际目的时，它才有价值
[*]3.2.1. 未使用或未查询的数据只是惰性的
3.3. 数据虚荣项目是公司的一个重要风险
[*]3.3.1. 在数据湖中网络大量数据集，这些数据集从未以任何有用的方式使用过
3.4. 分析
[*]3.4.1. 是大多数数据工作的核心
[*]3.4.2. 一旦你的数据被存储和转换，你就可以天生陈诉或仪表板并对数据进行暂时分析
[*]3.4.3. 商业智能
[*]3.4.3.1. BI通过网络数据来描述企业的过去和当前状态
[*]3.4.3.2. BI需要使用业务逻辑来处置惩罚原始数据
[*]3.4.3.3. 用于分析的数据服务是数据工程生命周期各个阶段可能会纠缠在一起的另一个范畴
[*]3.4.3.4. 业务逻辑通常在数据工程生命周期的转换阶段应用于数据，但读取逻辑方法越来越流行
>3.4.3.4.1. 数据以干净但相当原始的形式存储，具有最少的后处理业务逻辑
[*]3.4.3.5. BI体系维护一个业务逻辑和定义的存储库
>3.4.3.5.1. 此业务逻辑用于查询数据仓库，以使报告和仪表板与业务定义保持一致
[*]3.4.4. 数据质量差、组织孤岛和缺乏足够的数据技能通常会阻碍分析技能的广泛使用
[*]3.4.5. 运营分析
[*]3.4.5.1. 运营分析侧重于运营的精细细节，促进陈诉用户可以立即采取行动
[*]3.4.5.2. 运营分析侧重于运营的精细细节，促进陈诉用户可以立即采取行动
[*]3.4.5.3. 数据是及时消耗的，直接来自源体系或流数据管道
[*]3.4.5.4. 运营分析中的洞察范例与传统BI不同，因为运营分析侧重于当前，不一定关注历史趋势
[*]3.4.6. 嵌入式分析
[*]3.4.6.1. 在SaaS平台上提供给客户的分析带有一组单独的要求和复杂性
[*]3.4.6.2. 内部BI面向的受众有限，一般呈现的同一视图数量有限
[*]3.4.6.3. 访问控制很关键，但并不特别复杂
[*]3.4.6.4. 使用少数角色和访问层来管理访问
[*]3.4.6.5. 每个客户都必须看到他们的数据，而且只能看到他们的数据
3.5. 多租户
[*]3.5.1. 数据工程师可能会选择将许多客户的数据存放在公用表中，以便为内部分析和机器学习提供同一的视图
[*]3.5.2. 该数据通过具有适当定义的控件和过滤器的逻辑视图在外部呈现给各个客户
[*]3.5.3. 数据工程师有责任相识他们部署的体系中多租户的细节，以确保绝对的数据安全和数据隔离
3.6. 机器学习
[*]3.6.1. 一旦组织达到高程度的数据成熟度，他们就可以开始辨认适合机器学习的问题并开始围绕它组织实践
[*]3.6.2. 数据工程师的职责在分析和机器学习方面有很大的重叠，而且数据工程、机器学习工程和分析工程之间的界限可能很模糊
[*]3.6.3. 特征存储是最近开发的一种联合了数据工程和机器学习工程的工具
[*]3.6.3.1. 在实践中，数据工程师是支持机器学习工程的特征存储的核心支持团队的一部分
[*]3.6.4. 注意事项
[*]3.6.4.1. 数据质量是否足以执行可靠的特征工程？
>3.6.4.1.1. 质量要求和评估是与使用数据的团队密切合作制定的
[*]3.6.4.2. 数据是否可发现？
>3.6.4.2.1. 数据科学家和机器学习工程师能否轻松找到有价值的数据？
[*]3.6.4.3. 数据工程和机器学习工程之间的技能和组织边界在哪里？
[*]3.6.4.4. 数据集是否正确代表了根本究竟？
>3.6.4.4.1. 是否存在偏见
[*]3.6.5. 在将大量资源投入机器学习之前，请花时间建立坚固的数据底子
[*]3.6.5.1. 意味着在数据工程和机器学习生命周期中建立最佳体系和架构
[*]3.6.5.2. 通常最好在转向机器学习之前先培养分析能力
[*]3.6.5.3. 许多公司已经因为在没有适当底子的情况下采取举措而幻灭了机器学习空想
3.7. 反向ETL
[*]3.7.1. 向ETL恒久以来不停是数据中的一个实际现实，被视为一种我们不喜欢谈论或用名字来表示的反模式
[*]3.7.2. 反向ETL从数据工程生命周期的输出端获取经过处置惩罚的数据，并将其反馈回源体系
[*]3.7.3. 随着企业越来越依靠SaaS和外部平台，反向ETL变得尤为重要
[*]3.7.3.1. 广告平台是一个一样寻常用例
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]