A Glossary with Use Cases for First-Timers in Data Engineering
你是一个对现代数据基础设施感兴趣的数据工程新手吗？ 我敢打赌你是，这篇文章就是为你准备的！
在本指南中，数据工程与F1相遇。但我们将保持简单。
引言
我坚信通过例子来描述一个概念是最好的方式，尽管我的一些大学教授曾经说过，“如果你需要一个例子来解释它，那意味着你没有理解”。无论如何，我在大学课堂上没有付足够的注意力，今天我将带你了解数据层，使用——猜猜看——一个例子。
商业场景与数据架构
想象这样一种情况：明年，一支新车队红色雷霆车队(Red Thunder Racing)将会召唤我们（是的，我和你）来建立他们的新数据基础设施。
在当今的F1中，数据是核心，比起20或30年前更重要。赛车队通过令人瞩目的数据驱动方法不断提高性能，每个毫秒都在进行改进。
这不仅仅关乎圈速；F1是一项价值数十亿美元的产业。提高粉丝参与度不仅仅是为了好玩；增加体育运动的吸引力不仅仅是为了车手的乐趣。这些活动产生收入。一个强大的数据基础设施是F1产业竞争的必备条件。
我们将建立一个数据架构来支持我们的赛车队，从三个主要层次开始：数据湖、数据仓库和数据集市。
数据湖
数据湖将作为一个仓库用于存储来自F1生态系统内不同来源生成的原始和非结构化数据：来自赛车的遥测数据（例如每秒的轮胎压力、速度、燃油消耗）、驾驶员配置、圈速、天气条件、社交媒体信息、售票、注册参加营销活动的粉丝、商品购买等。
我们的统一数据湖中可以存储各种类型的数据：非结构化数据（音频、视频、图像）、半结构化数据（JSON、XML）和结构化数据（CSV、Parquet、AVRO）。
在将所有数据整合到一个地方时，我们将面临第一个挑战。我们将创建批处理作业从营销工具中提取记录，并处理实时流式遥测数据（请确保这种情况下延迟要求非常低）。
我们将有一个很长的系统列表需要进行集成，每个系统都支持不同的协议或接口：Kafka流式处理、SFTP、MQTT、REST API等等。
在这个数据收集过程中，我们不会孤单；谢天谢地，市场上有可供选择的数据集成工具，可以用来配置和维护一处摄取管道（例如按字母顺序列出的工具：Fivetran，Hevo，Informatica，Segment，Stitch，Talend等）。与依靠数百个安排在 crontab 上的 Python 脚本或使用自定义过程处理来自 Kafka 主题的数据流的方式不同，这些工具将帮助我们简化、自动化和编排所有这些过程。
数据仓库
经过几周的定义我们需要整合的所有数据流，我们现在正在将各种各样的数据导入我们的数据湖中。现在是时候进入下一个层次了。
数据仓库用于清洁、结构化和存储来自数据湖的处理过的数据，为分析和报告提供一个结构化、高性能的环境。
在这个阶段，重点不在于导入数据，我们将越来越专注于业务使用案例。我们应该考虑数据将如何被我们的同事利用，提供结构化的数据集，定期刷新，包括：
- 车辆表现：遥测数据经过清洁、规范化和整合，提供一个统一的视图。
- 战略和趋势分析：过去的比赛数据用于识别趋势、驾驶员表现以及理解特定策略的影响。
- 团队关键绩效指标：停车时间，停车前的轮胎温度，对车辆开发的预算控制。
我们将有很多专用于数据转换和规范化的流水线。就像数据整合一样，市场上有很多工具可以简化和高效管理数据流水线。这些工具可以简化我们的数据流程，降低运营成本，增加开发效果（例如按字母顺序排列：Apache Airflow，Azure Data Factory，DBT，Google DataForm等）。
数据存储
数据仓库和数据存储之间存在着微妙的界限。不要忘记我们在为红雷赛车队工作，这是一家规模庞大的公司，有成千上万的员工从事各种领域。数据必须可访问并根据特定业务单位的要求进行定制。数据模型是围绕业务需求构建的。
数据存储是数据仓库的专门子集，重点关注特定的业务功能。
- 车辆性能存储：研发团队分析与发动机效率、空气动力学和可靠性相关的数据。工程师将使用这个数据存储来优化不同赛道的车辆设置或运行模拟来了解基于天气条件的最佳车辆配置。
- 粉丝参与存储：营销团队分析社交媒体数据、粉丝调查和收视率，以了解粉丝的偏好。营销团队使用这些数据进行有针对性的营销策略、商品开发和提高他们的粉丝360度认识。
- 簿记分析存储：财务团队也需要数据（很多数据，我相信！）。现在比以往任何时候都更需要赛车队应对预算限制和法规。跟踪预算分配、收入和总体成本概览非常重要。
此外，通常要求确保敏感数据仅对授权团队可访问。例如，研发团队可能需要独占访问遥测信息，并需要使用特定的数据模型来分析这些数据。然而，他们可能不被允许（或感兴趣）访问财务报告。
我们分层的数据架构将使红雷赛车队能够充分利用数据的力量，进行汽车性能优化、战略决策、增强营销活动……以及更多！
就这些了吗？
当然不是！我们只是浅尝辄止地了解了数据架构的皮毛。还有可能有其他几百个我们应该考虑的集成点，此外我们还没有涉及到数据科学领域，这可能需要一篇专门的文章，同样适用于数据治理、数据可观察性、数据安全等。
但是，正如他们所说，“罗马不是一天建成的”。我们今天已经有很多事情要做，包括下面的数据架构的初稿。
结论
数据工程是一个神奇的领域，有很多书籍专门研究它。
在这个旅程中，数据工程师将使用各种各样的集成工具，不同的数据平台，旨在覆盖上面提到的一层或多层（例如按字母顺序：AWS Redshift，Azure Synapse，Databricks，Google BigQuery，Snowflake等），商业智能工具（例如Looker，PowerBI，Tableau，ThoughtSpot等）和数据流水线工具。
我们在Red Thunder Racing的数据工程之旅刚刚开始，我们应该为工具包留下足够的灵活性空间！
数据层经常可以组合在一起，有时在一个平台上。数据平台和工具按日发布新功能，提高了标准并填补了差距。这个市场竞争激烈。
- 你总是需要拥有一个数据湖吗？这取决于情况。
- 你总是需要尽快存储数据（即流数据和实时处理）吗？这取决于数据对业务用户的新鲜度要求。
- 你总是需要依赖第三方工具来管理数据流水线吗？这取决于情况！
<在这里放上你可能有的其他问题的占位符>？这取决于情况！
如果您有任何问题或建议，请随时在领英上联系我。我保证会回答你，而不是说“这取决于情况！”
本文中的观点仅代表我个人的观点，不代表我的雇主的观点。除非另有说明，所有图片均为作者所创作。
本文中描绘的故事、人名和事件均为虚构。与实际地点、建筑和产品的任何类似之处均不是故意或应当做出的推断。