提取意义：数据优先公司的经验教训

提取意义：数据优先公司的经验教训

介绍

我有意避免在本文标题中使用流行词“大数据”，但我并不是要低估我们正在处理的数据量。大量不同的数据集通过我们的应用程序快速进入，尽快分析它们是揭示隐藏模式的关键，这些模式使我们的客户和利益相关者能够做出决策。数据的这些特征通常被称为大数据的四个 V：Volume、Velocity、Variety 和 Veracity。今天，我们拥有非常有效的工具来存储、分析和理解大型数据集。为了让您了解我们正在利用大数据解决的问题，请允许我简要介绍一下我们在公司所做的工作。

在 WearHealth，我们构建了增强劳动力的解决方案：我们的平台揭示了人体工程学风险，并为利益相关者提供了实施正确解决方案的客观见解。这是由从智能手机到可穿戴设备和物联网设备的各种数据流推动的。此外，我们还从专业的人体工程学专家和 HSE 经理那里提炼出知识，并以本体的形式进行整合。然后将这些不同的数据集转换为上下文丰富的信息，例如作为给工人的安全通知或给主管或经理的详细报告。请检查我们的 网站 如果你想了解更多。

在本文中，我将分享我在从数据中提取意义的过程中的经验和教训。我不会具体说明我们使用的第三方服务或工具，我会保持这种与云无关的高水平。

数据管道构成了我们平台的核心

什么是数据管道？

将我们的数据从客户端的可穿戴设备移动、处理和转换到我们的分析和商业智能工具和应用程序的一组服务和应用程序，我们称之为“数据管道”。该术语经常与“ETL/ELT”（即“提取、转换、加载”）或“ETL/ELT 管道”互换使用，但区别通常在于数据摄取和处理的同步性，并且转换是一种数据管道系统的可选步骤。实际上，最好将 ETL/ELT 视为数据管道的子集。

上图是我们的数据管道包含的步骤的高级说明。首先，我们从可穿戴设备、物联网传感器、智能手机和 API 实时（流式摄取）和设定间隔（批量和批量）摄取数据。然后通过验证编码、mime 类型、模式和其他参数来验证摄取的数据。接下来，在清理过程中，系统会捕获编码错误、意外格式并删除不明确或重复的记录。然后将该数据存储在数据湖中，我们将在下面的小节中对其进行扩展。

进一步进入转换流程，经过验证和清理的数据继续进入分析和上下文丰富服务；这就是我们的 AI/ML 模型发挥作用的地方。之后，数据在模式中被规范化并存储在数据仓库中。稍后再谈。

在进行这些过程的同时，正在生成包含数据质量、数据人工制品、总体处理时间等指标的日志并将其发布到消息队列中。

值得一提的是，在管道的接收端是一个多元化的消费者群体，每个人都有自己的需求和目标。利益相关者可以通过前端应用程序和报告访问精细且上下文丰富的数据；数据科学家可以对来自数据湖的数据使用他们的工具和脚本来运行测试并进一步开发他们的算法和模型；开发人员可以访问其诊断和性能工具的日志。这里值得一提的是，出于合规性和隐私目的，并非所有人都可以使用所有信息。例如，当我们的数据科学团队访问时，记录是匿名的。

我们正在摄取什么样的数据？

鉴于我们在本文前面概述的生产者，以下是通过我们管道的数据的简短列表：

• 包含传感器数据的 CSV 和 Parquet 文件（例如加速度计、陀螺仪……等）；
• 来自 SQL 数据库的结构化数据；
• 通过我们的 REST API 获取 JSON 数据

早期，CSV（或您可能使用的任何分隔记录格式）是在 Excel 工作表上查看数据或在我们的 Python 脚本中导入数据时的首选格式。这个过程变得乏味，随着文件大小的不断增加，我们切换到 Parquet（来自 Apache）。除了占用更少的空间外，Parquet 的面向列的特性还加快了查询速度：我们不必读取整个表，而是独立读取单个列。此外，从 Amazon Athena 到 Google BigQuery、Hadoop、Spark 等的许多服务、工具和框架都“开箱即用”地支持这种格式。

什么是数据湖？

数据湖中存储的数据很少或有时不进行转换，因此它们的结构和源内容非常相似。此外，数据湖通常承载各种数据类型、结构和内容。在这样的环境中，大多数查询将运行次优。最初，我们将所有内容保存在一个文件中，没有任何底层数据库引擎或模型。这是与我们的数据科学团队进行存储和共享的最精简方法。

什么是数据仓库？

想象一家分销电子产品的公司的仓库。该仓库中的员工和/或自动化机器能够以非常有效的方式导航空间、取货、分类和组织新商品。诸如“我们有多少 X 的备件？”之类的问题。或者“我们什么时候可以订购下一批 Y 以满足需求？”很容易回答。这弥补了一个非常快乐的物流部门。在类似的思维方式中，数据仓库是一个数据库，其中数据以最有效地回答对我们的业务很重要的问题的方式进行建模和存储。

迄今为止我们学到的教训

我们是如何开始的

当我们刚开始时，我们收集的数据集更小——与我们现在收集的数据集相比——我们并不总是知道我们可以从数据中得到什么样的答案。因此，我们从简单的开始，通过摄取包含我们不一定知道我们需要的信息的大型平面文件。至少，我们可以灵活地进行试验并在以后做出决定。我们已经建立了一个 ETL 系统，我们将以固定的时间间隔以微批处理方式提供数据，然后运行查询和分析，并按每日计划生成指标。事后看来，随着我们的业务不断增长，这是一个正确的决定，因为我们的活动部件很少，而且我们可以在快速发展的东西上更快地迭代。

第 1 课：尽早弥补摄取数据的不可预测性

这是数据工程师的理想方案，只需要使用完美且一致的数据集，这样他们就不必为实际内容而烦恼。实际上，数据需要通过管道的第一步进行验证和清理。这是因为我们不能完全信任属于生产者组的系统的所有者。

一旦损坏的数据进入我们的数据仓库，它们并不总是会创建错误日志或以有害方式影响系统。这使得以后处理这些数据变得特别困难，因为它们变得越来越嵌入并与其他数据交织在一起。

第 2 课：在客户友好的时间计划批处理

对于特定的用例，摄取数据的源系统可以是一个关系数据库，其中包含后端应用程序的业务关键数据，反过来，它可以在浏览器或移动设备上运行的其他客户端应用程序中启用功能。因此，负责获取该数据的进程不得使这些系统的资源、网络带宽或 API 速率限制过载。

第 3 课：让您和您的团队能够有效地跟踪绩效、调查和排除故障

日志非常重要！我们从数据管道的每一步收集核心生命力和结果：

• 验证结果；
• 整体清洁度得分和质量；
• 模型预测和参数。这也应该启用您的 AB 测试；
• 应用程序警告和错误；
• 跟踪标识符、版本号……等。

第 4 课：提前计划任务执行顺序和数据流

在我们产品的开始阶段，我们会在没有明确计划的情况下逐步实施和协调必要的转型步骤。结果，有时我们的数据会循环回到上游服务，这会导致各种难以调试的问题。考虑到这一点，我们为数据流和任务的依赖关系定义了一个图表：

• 除非完成了依赖于另一个任务的任务，否则它不会开始执行
• 任务不应调用先前完成的任务。借用图论中的一个概念，DAG（有向无环图）设计模式规定任务不应该循环回来。

第 5 课：数据合同（即服务）

为了在服务之间可靠地交换数据，我们定义了一个中央模式注册表，用于 E2E 测试和数据验证。从本质上讲，它是一个微型 API，它收集所有合约（数据结构）并参与验证、文档和集成 (E2E) 测试。通过这种方式，我们能够跟踪架构更改并仔细规划我们的服务之间的向后和向前兼容性。

第 6 课：所有人的透明度、可观察性和报告

我们确保工程团队以外的每个人都能了解通过管道的数据流量以及每天的关键指标摘要。为此，我们为某些事件设置监听器，然后将其发布到我们数字工作空间平台的公共聊天和线程。

作为轶事证据，一位队友曾经注意到指标中的某些差异，并帮助我们发现了我们后来纠正的分析算法的问题。有时，帮助可能来自您最不期望的地方！

当然，严重错误也会出现在我们的聊天中，并通过我们的日志数据库，其中包含带有明确执行标识符的管道每个步骤的记录，我们能够轻松地进行故障排除。

第 7 课：正确设置时间戳

最后但并非最不重要的一点是，在设置这样的系统时，在步骤和服务中正确获取时间戳将使您免于大麻烦！例如，坚持使用标准格式（例如 ISO 8601）的 UTC 并在更接近管道的消费者端进行本地化是有意义的。至少，如果您碰巧同时使用或加入包含 UTC 和本地的数据集，则需要从数据属性中正确指示。

结束的想法

在内部，我们将我们的数据管道视为“数据高速公路”，其中“交通”受到监管，“停车位”或“停靠点”得到明确指示，并为每个业务需求提供设施和商品。我们服务的内部或外部利益相关者的观点是多种多样的，这需要反映在管道消费者端的数据上。

我们的第一步充满了许多未知数，但我们的方法仍然务实。一旦我们开始发现数据背后的含义，同时了解消费者的需求，我们手头的系统就有了一份明确的要求清单。

我希望本文中概述的经验和教训对您的数据工程工作有所帮助。

原贴于： https://threefields.media/blog/extracting-meaning-lessons-from-a-data-first-company

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/15500/43530509