我们从定义业务问题陈述的任务开始。
“企业面临不断变化的技术环境。竞争要求企业在规模上进行创新以保持相关性，这导致了在系统生命周期的运行/管理阶段中，必须不断地分配总拥有成本（TCO）预算来进行重构和重新规划。”
这种快速变化意味着目标不断在变化。“我们到了吗？”——这是我和孩子们旅行时常听到的问题。这源于他们不知道我们在哪里，也不了解到达目的地需要付出多少努力，而司机（我）以前从未去过那个地方。幸好有Garmin（汽车导航系统）和Google Maps，而不是过去用的过时纸质地图。看看技术是如何影响这个比喻的吧？Garmin逐渐被Google取代，这并不总是因为它更好，而是因为Google是免费的（前提是你愿意接受数据收集和广告干扰），而且它可以在每个人的智能设备上运行。
现在，我可以告诉我的孙子们，他们将在1小时29分钟后回到家中，结束与祖父母共度的周末。孙子们空洞的表情说明了一切——地图数据和实时技术的呈现彻底改变了我们的生活。
技术变革在发生时似乎是革命性的，但回顾过去时，这些变革的过程往往显得理所当然，甚至是渐进的。这正是今天云端中的数据、信息、知识和分析数据存储正在经历的变化。Andy Palmer（Tamr公司联合创始人兼CEO）推广了“DataOps”这一术语 {packt-debp.link/MGj4EU}，数据管理和分析领域也频繁提及这一概念。2015年，Palmer表示，DataOps不仅是一个流行词汇，而是在当今复杂且数据驱动的世界中管理数据的关键方法。
“我认为，是时候让数据工程师和数据科学家接受一种类似于DevOps的新学科了——我们称之为DataOps。其核心在于满足现代互联网和现代企业中数据专业人士的需求。”（Andy Palmer {packt-debp.link/ihlztK}）
在图1.1中，你可以看到数据质量、集成、工程和安全性如何通过一个可靠的DataOps实践紧密联系在一起：
本章的目标是为理解本书中提出的最佳实践为何以这种结构呈现奠定基础。这一基础将为你在日常工程任务中采用的框架提供更加稳固的支撑，使其更加安全且扎实。解决数据工程挑战有多种方法，每个供应商、工程学院和云服务提供商对成功的公式都会有自己的理解。但成功最终取决于你今天能让什么工作正常运行，并确保它在未来持续有效运转。实现这一目标需要在各种力量之间找到独特的平衡。然而，如果基础不正确，这种平衡很容易被打破。
作为读者，你可能已经对某些工程挑战形成了固有偏见，这可能会导致你专注于某些特定领域（或单一思维模式）。例如，你可能沉迷于实现高度健壮和高可用的多区域操作，而忽略了管道软件开发的投入，导致系统过度追求健壮性，却未能开发出关键功能。反之，你也可能把开发变更的超敏捷流转推入生产环境置于优先地位，却以牺牲数据质量为代价。更普遍地说，单纯将重点放在IT上而忽视我们为何需要在现代信息处理系统中精心设计数据处理流程，也存在重大风险。你必须重视在捕获数据时保留其语义上下文，以确保数据真实且具有相关性，而不仅仅让软件系统成为数据的唯一解释者。这种自由使数据与上下文结合成为真正适用的信息，不仅在现在，而且在未来都能满足需求。
现在，我们可以从业务问题陈述开始。
什么是业务问题陈述？
数据工程方法正在迅速演变，并将最终融合为一个系统化且一致的整体。这一转变的核心在于认识到数据是信息，必须能够代表事实和真相，并且这些事实和真相需要通过合理化逐步构建。在未来的信息系统中，不能存在虚假的事实。这一术语或许让你觉得奇怪——事实会虚假吗？这个问题可能有些挑衅性，但我们不是经常构建IT系统来判断事实是否真实吗？
我们在软件系统中处理数据时，会保留业务上下文和含义，但这些系统将数据限制为只能通过其本身来提供。数据无法独立存在，如果脱离上下文来使用，它会导致虚假事实在业务环境中传播。如今，数据不能单独存在，必须通过信息处理系统转化，而这些系统存在技术局限性。正如《实用程序员》{packt-debp.link/zS3jWY}所提到的，不完美的工具和技术会产生不完美的解决方案。然而，工程师的任务是在设计解决方案时尽可能消除（甚至完全消除）虚假事实，这一直是过去难以实现的目标。
我们经常走捷径，并用各种理由为这些捷径辩解，例如：“时间不够！”、“我们不可能获取所有数据！”、“业务无法负担正确地管理数据的成本！”或者“我们没预算去解决所有问题。”但我们不需要“煮沸整个海洋”。
我们需要思考的是，如何直接将这片海洋转化为蒸汽！这应该是我们的应对方式，而不是妥协。正是这种重新思考问题的心态，才能让我们设计出面向未来的解决方案。即使很困难的问题，通过彻底重新思考依然是可行的。换句话说，我们将把数据作为创新引擎的新燃料。
趣闻
2006年，数学家Clive Humby提出了“数据是新的石油”这一说法 {packt-debp.link/SiG2rL}。
数据系统必须具备自我修复虚假事实的能力，才能实现知识的完整性。毕竟，什么才是真正的事实？事实不正是建立在证据支持的假设上吗，直到未来的观察推翻这一真相？同样，组织信息为知识不仅需要捕捉语义、上下文和时间序列的相关性，还需要阐明事实作为信息真相在数据集中得以表达的原因。这正是知识所定义的：真相！但真相需要正确的表达。
注意
知识库的真相由经得起时间考验的事实组成，并且这些事实不会隐藏构成知识库真相的上下文信息。
然而，有时当我们缺乏足够信息时，我们只能进行猜测。这些猜测基于直觉以及我们在相关领域中与类似信息模式的过往经验。人类的猜测可能非常不准确，但基于强烈直觉的猜测也可能带来重大的创新突破，并可以在之后通过实证数据来验证。
在此之前，我们常用扭曲事实的方式来填补知识的空白。信息关系模式必须保留下来，同时也要记录准确的、有依据的猜测。以这种方式，可以通过猜测来推导数据真相，并且这些猜测可以在被证明错误时进行纠正。为了支持智能系统，必须以新的方式组织数据，支持假设的推理与验证，以及将信息作为知识存储以形成真相。如果我们不在框架内将大数据组织为可供业务使用的知识和真相，那我们只是在浪费云服务提供商的资源和资金。
本书将聚焦于最佳实践，同时也会指出一些糟糕的实践。这些不良实践形成了数据工程师工具箱中逐渐渗入的反模式，阻碍了我们的成功。接下来，让我们探讨这些反模式。
需要避免的反模式
什么是反模式？
反模式是一种需要避免的架构模式。就像建造物理建筑时，建筑师会使用蓝图向工程师明确传达预期。如果某个解决方案屡次成功并广泛应用，它就会被作为一种模式重用，比如墙体的框架结构或屋顶的桁架设计。同样，反模式是一种应当避免的模式，就像在寒冷气候中将管道安装在外墙上会导致管道冻结一样。
第一个反模式涉及保留一些我们认为有价值的数据，但由于存储方式的问题，这些数据变得无法理解或处理，而且其上下文意义也因最初存储时未捕捉到而丢失。
第二个反模式则是不了解业务数据的列格式含义，也不知道这些列之间如何形成业务意义。这是因为这些含义只保存在软件系统中，而没有记录在数据本身。我们依赖实体关系图（ERD）来澄清这些含义，但一旦敏捷开发人员未及时更新它们，这些关系就会失去价值。在构建面向未来的数据工程解决方案时，了解必须避免的反模式，有助于为本书奠定基础。
反模式示例
反模式 #1：我们必须保留无用数据吗？
过去，我分析过一个系统，该系统保留了多年的数据，但这些数据在三个月后就变得毫无价值。原因是生成这些数据的处理代码在过去几年中已被更改了数百次，并且不断演变，而这些变化未被记录在生成的数据集中。由于数据框架未保留这些假设信息，保留这些数据纯属多此一举，只会诱导未来的大数据分析师错误地尝试使用它。当我问为什么要保留这些数据时，得到的回答是：“公司政策要求这样做。” 我们经常遇到认为“大量数据=有价值”的人，即使这些数据不可处理。有些数据不仅没有价值，还可能成为业务风险，如果误用会带来严重后果。即使使用传统的瀑布式需求或大量敏捷开发故事，这个问题也无法解决，除非有一个包含数据语义和数据沿袭的智能数据框架，否则所获得的洞察将是错误的！
反模式 #2：这一列是什么意思？
在另一个例子中，我曾构建了一个精美的图形展示，分析了几篇已发布文章的网络用户使用情况。虽然我认为这是一件艺术作品，但它却是一场彻底的灾难，最终被弃用。原因在于，我错误地使用了一个关键数据列。该列的值实际上是用户访问的倒排排名，而不是实际的使用量。
在开发数据处理系统时，之前的开发人员未提供元数据目录、数据架构文档或列的文本定义。这些信息都掌握在一个自私的数据分析师手中。该分析师垄断了业务数据，并因此获得了高额报酬，因为只有他能够生成这些洞察。任何试图替换他的努力都会遭到关键业务利益相关者的阻挠，从而使得IT管理层无法实施必要的治理标准。结果是本应强制执行的企业分析标准无法落地，这让数据使用变成了穿越技术雷区。
组织必须避免这种情况。这种反模式是一种数据孤岛的糟糕实践，通常源于个人试图维护自己在组织中的独特地位或推动某种孤立的业务议程。在上述例子中，反模式的表现是阻止企业治理标准的实施。要防止此类滥用，必须在数据框架中正确实施治理，让数据能够自我解释。
一个结合了两个反模式的真实案例
一家大型电子商务公司拥有多年的客户购买数据，其中包含一个名为customer_value的字段。最初，这个字段根据客户的消费总额计算，但随着时间的推移，它的含义不断变化而没有及时更新文档。几年后，它变成了total_spending - total_returns，后来又根据机器学习（ML）模型变为predicted_lifetime_value。当一位新加入的数据科学家使用该字段对客户进行营销活动的分类时，结果灾难性地失败了！早期的高价值客户被低估了，而新客户被高估了。
这个例子说明了没有合适的上下文保留数据（反模式 #1）和缺乏清晰的数据字段文档（反模式 #2）如何导致重大错误。
面向未来的架构模式
我们在撰写本书的过程中，努力向数据工程师展示这样一个现实：在当前的信息技术解决方案中，我们处理的数据是作为信息使用的，而实际上，我们希望这些数据能为业务提供有价值的见解。
今天，我们用代码拼接解决方案，以操控数据，模仿信息供业务使用。然而，我们真正想要的是在数据中保留业务信息，使数据更加智能，从而通过上下文中的信息形成知识，为数据消费者提供洞察。数据的转化路径从原始数据开始，经过语义和上下文的保留，逐步转化为信息和知识，最终发展为分析产生的洞察，这些内容将在未来的章节中详细阐述。第18章中还包含了一些有趣的实际用例。从多年的经验中，我了解到，让数据更智能总是值得的。
当业务需要时，生成的洞察可以以创新的方式呈现给业务部门。技术领域的一个空白在于，要让数据真正成为洞察的生成器，其数据旅程必须是基于信息的。这种创新无法由软件工程师预先设计出来，而是通过IT系统在数据旅程各阶段展示的知识，由业务和IT领导者共同探讨得出。这需要在数据系统中保留数据的语义、沿袭关系、概念间的直接或推断关系、时间序列以及上下文。
目前的技术工具和数据处理技术还无法通过单一解决方案满足这一需求。一个单一的数据仓库、数据湖、知识图谱或内存存储库无法解决用户提出的所有需求。工具需要时间演化。因此，我们需要在战术上实施，并从战略上思考如何向分析师提供合适的数据（即真相）。
关键思考
- 实施：做到“刚刚好、恰逢其时”。
- 战略思考：数据应该是智能化的。
采用创新的建模方法可能会带来系统性和内在的风险，但利用新技术可以为业务带来关键优势。因此，减少技术或交付失败的风险至关重要。在数据网格与数据织布之间的学术讨论中，我们可以看到各种云供应商和工具提供商在拥抱创新的同时，也在创造一种技术重力，可能吸引缺乏信息的业务IT领导者。
这是一场进化事件，对某些人而言，甚至可能成为灭绝级事件。微软和亚马逊等公司能够采用经过良好架构设计的最佳实践，从而推动云支出并加深云供应商锁定。而云平台即服务（PaaS）方案、云架构模式和供应商偏见的培训也可能导致系统及其构建者陷入困境。类似情况同样可能出现在关系数据库管理系统（RDBMS）、数据湖、知识图谱或实时内存存储系统的提供商及其咨询服务中。这些供应商并不会附带警告标志。
作为领导者，你需要最小化风险、最大化收益，并时刻关注最终目标：
“我想构建一个无人能离开的数据解决方案，并让它永远持续下去！”
为实现这一目标，你需要明确使命，并保持清晰的愿景。通过一套完善的原则、最佳实践以及关于关键问题的明确立场，加上无可争议的治理模型，这一目标是可以实现的。但要做好准备迎接挑战！随着时间的推移，架构会面临挑战，甚至可能在投入运营前就受到考验。我们的建议是始终准备好应对这些挑战，而不要仅依靠政治权力来强制执行架构的合规性和治理。
构建现代系统时，你需要考虑以下步骤：
- 收集业务的目标和关键结果（OKRs），并尽早、频繁展示成功。
- 随时准备好为关键利益相关者进行演示。
- 持续吸引并让关键利益相关者满意，同时展示投资回报（ROI），因为他们是项目的资金来源。
- 仔细跟踪功能与成本的比率，了解谁获得了价值以及成本如何，作为系统总拥有成本（TCO）的一部分。
- 永远不要在没有足够时间告知利益相关者和用户的情况下违约于数据服务级协议（SLA）或数据合同。最好永不违约，因为这些协议明确定义了数据消费者的期望！
- 设计与业务需求兼容的架构系统，一旦业务依赖于系统获取洞察，就不要打破任何合同。因为一旦让业务部门失去依赖，比起未交付解决方案的后果，影响会更大。
正如你所看到的，在构建现代数据解决方案时，有许多模式需要考虑，也有一些反模式需要避免。软件工程师、数据管理员、数据科学家和数据分析师会带着自己的观点和技术需求来到项目中，此外还需要满足业务要求的目标和关键结果（OKRs）。并非所有技术参与者都会重视其他领域所需的细微差别。然而，数据工程师必须在变化的浪潮中保持平衡，交付面向未来的解决方案。
在下一节中，我们将展示如何保持技术优势，并保持实现持久解决方案所需的平衡。
面向未来的定义与实现
什么是面向未来的解决方案？
构建面向未来的解决方案意味着创建一个在当下具有相关性、可扩展且具有成本效益，并且在未来仍然适用的系统。要实现这一目标，必须专注于使用最佳实践和设计模式来构建参考架构。
目标如下：
开发一种可扩展、经济的IT战略、架构和设计，促成一个面向未来的数据处理系统的创建。
在追求这一目标时，需要认识到变化是渐进的而非革命性的。因此，数据架构必须是稳固且面向未来的。虽然实现100%面向未来的系统是一种幻想，但我们必须始终以追求接近面向未来的系统为核心原则。
警惕“炫目技术”
炫目的新技术可能会吸引大量风险投资或种子资金，甚至在个人简历上添彩。然而，这些技术突破也可能在被颠覆者实现突破后迅速过时。例如，当OpenAI推出ChatGPT及其相关的大型语言模型（LLM）技术时，会话式AI已经改变了许多系统。
技术一旦普及，曾经困难的事情变得简单，甚至可能通过开源项目商品化。即使某些商业软件方法或流程被知识产权（IP）锁定，通过专利保护，它们在10、15或20年后也会被公开并供其他人使用。IP披露文件中的宝贵见解也可能被竞争对手借鉴。总会有更多的失败者而非赢家，因为在同一时间，不同的团队会围绕同一问题进行研发，直到取得突破，且方法通常相似。如今，数据工程正在接近这一拐点。
追逐“流星”与避免失败
组织的预算规模和对风险回报的容忍度决定了它是否能将一个闪亮的创意变成燃烧的明星。然而，追逐这种“流星”的90%的尝试都可能最终导致失败，耗尽整个IT预算。因此，我们建议遵循业务方向，采用敏捷开发方法，以降低因IT驱动的失败带来的风险。
“数据是新的水资源”与智能系统架构
国际数据公司（IDC）和Qlik提出了“数据是新的水资源”的说法。无论将数据比作“油”还是“水”，关键在于数据必须转化为信息，而信息需要进一步转化为知识。真相应在语境中定义，包括时间维度。我们的系统应从简单的数据处理系统转变为知识感知系统，支持智能、洞察力和经得起时间考验的真相。
然而，当前的数据常常如同浑浊的水，受到以下因素的干扰：
- 支持现有机器不足而开发的无效结构
- 对数据含义和沿袭的误解导致的错误
- 出于隐私和安全考虑的刻意不透明
- 元数据缺失导致的上下文丢失
- 复杂关系未被记录而导致的语义缺失
数据生命周期的成本和过程常常未被充分考虑。业务用例决定了哪些数据重要（本书第5-7章会详细探讨如何通过概念、逻辑和物理架构表示用例）。数据服务的缺乏记录和维护，导致数据在时间中逐渐失去价值，如同在雨中融化的糖块，变得毫无价值。数据效用的丧失可能会因业务和技术合同未维护而加速，最终导致对数据集治理的信任崩塌。
解决方案之一是创建带有数据合同的业务数据服务。数据合同通过元数据定义数据集的静态状态（语义）、起源（沿袭）和安全性措施，并包括软件服务合同来维护质量指标。
关键目标：
- 不要随意移动数据，而是直接在数据原地丰富其元数据，以保留语义和沿袭。
构建持久系统的最佳实践
随着时间推移，维护数据的正确性、上下文和相关性的成本可能超出任何单一组织的能力。这使得IT领导者倾向于将数据封装为数据孤岛。为了防止系统崩溃，我们必须允许数据在不断演变的同时保持正确性和可维护性。
当前系统往往仅满足“目前足够好”的标准，却不适用于未来的重用。这种数据保留了创建时的假设、缺失、碎片化以及不完整的实现。如果数据是自解释且准确的，数据服务代码就会更简单，系统解决方案会更优雅。这样的系统能够承受变化的压力，因为数据架构被设计为能够随时间演变，并始终保持与业务领域的完全一致。
“第一次永远没有足够的时间或预算做到完美，但总有机会不断改进。”
这种务实的方法可以避免IT领导者陷入对“更好框架”的无止境追寻中。虽然我们不应该修复那些正常工作的解决方案，但仍需在选择工具时保持现实，并在适当时抓住技术创新的机会。
云与语义图技术的选择也很重要。例如，在OWL-RDF语义图与自定义代码的标记属性图之间进行权衡，并根据具体需求决定使用哪种技术。然而，无论哪种技术，都需要变更数据捕获（CDC）机制来同步内存分析存储区，以支持实时分析。
云技术并未提供一刀切的解决方案来满足所有用例。逻辑分段甚至物理分段的数据存储，往往是满足业务需求的必要手段。数据工程师需要在成本、安全性、性能、扩展性和可靠性之间保持平衡，同时应对供应商的限制。
就像一只鞋不能适合所有人，一套解决方案也无法满足所有业务需求。因此，我们的解决方案必须具备可持续性，能够随着时间推移保持功能性并不断演进。
根据区域进行组织的考量
本书提出的数据工程最佳实践之一，是为重要的数据模式设计主要的数据表示形式。我们设想了一个原始导入区，用于存储物联网（IoT）数据、零售商的销售点（POS）数据、化学属性参考数据或网页分析使用数据。我们建议将“区域”概念正式化为类似于Databricks Medallion Architecture（www.databricks.com/glossary/me…）所设定的层次结构。阅读该架构模式的结构或等待第6章的详细解释都将对理解有帮助。
原始数据在导入处理时可能需要数据分析系统支持，以确保输入数据不会因语法或语义错误被拒绝。这些数据在进入数据管道的下一阶段之前，可能会进行基础的标准化。数据的转化流程从青铜区（bronze zone）开始，随后进入白银区（silver zone） ，再到黄金区（gold zone） ，最终准备好供**消费区（consumption zone）**使用（适用于实时、自助分析场景）。
- 青铜区：存储类似数据湖的数据
- 白银区：作为缓存支持的数据湖，包含从青铜区推导、推算和推断的数据
- 黄金区：类似于传统数据仓库，支持在线事务处理（OLTP）用例，并存储处理后的数据输出
消费区支持用户的度量、计算指标以及在线分析处理（OLAP）需求。如果没有明确的框架和最佳实践来保持系统的正确性，确保这些区域同步将变得非常复杂。例如，在AWS或Azure云平台即服务（PaaS）解决方案中，可能会因缺乏线性数据流控制而导致混乱。因此，明确架构、数据框架、最佳实践和治理对于减少试错至关重要。
云服务的局限性
构建数据工程解决方案时，必须考虑当前云提供商的局限性，包括数据移动和分析工具部署所带来的成本。设想一下：一个具备毫秒级访问能力的zettabyte内存阵列，能够支持大量数据的计算任务——今天尚不可实现，但也许明天就是现实。在此期间，我们需要考虑如何构建一个解决方案，使未来的迁移变得轻松。这是本书最佳实践的核心：所有趋势都指向大数据和AI驱动的数据系统的创建。
未来的数据共享、机密计算，以及“将算法带到数据端”的理念，都将成为重用数据集、其语义及其商业价值的核心方法。在数据、信息和派生知识的基础上形成的数据消费方式，不仅是松散定义的元数据集合，还包括数据的沿袭、语义、上下文和时效性，这些都至关重要以维持信任并实现增值信息流的货币化。与出版书籍类似，数据也可以发布并售卖。我们将在本书中展示如何通过最佳实践，支持基于数据的增值服务的开发，使智能数据成为一个增值生态系统，与以往的处理系统一样重要。
智能时代
未来的数据即服务（DaaS）将依赖于本书所描述的新型数据工程框架。本书还将展示该框架所需的开发环境的最佳实践。将数据和元数据整理成信息，再进一步转化为洞察力，这一过程需要将数据转化为经得起时间考验的真相。这一新颖的数据框架对信息商品化至关重要，因为我们正从信息时代迈向智能时代。
在智能时代中，由人类和AI系统处理信息所形成的知识将成为洞察力的来源。实现AI目标需要应用各种机器学习和深度学习算法，这些算法定义了智能时代的特征。我们可以预见量子计算和zettabyte级内存存储的发展，它们将成为新数据工程组织的一部分。然而，数据工程框架对于支持这些算法的实施至关重要，否则数据湖很快就会变成数据沼泽。
构建面向未来的数据工程体系
本书旨在通过为数据工程架构提供最佳实践和高级IT管理的思考，帮助实现面向未来的设计。同时，本书还提出了一些实用的数据架构方法，并通过用例为数据架构师和数据工程师提供参考，使这些最佳实践更加具体。
- 不要移动数据，而是在原地丰富其元数据，以保留语义和沿袭。
- 逻辑和物理分段：为满足不同业务需求，数据需要合理的逻辑和物理分段。
在建立现代系统时，数据工程师必须在成本、安全性、性能、扩展性和可靠性之间找到平衡，同时应对云供应商的限制。
正如一只鞋无法适合所有人，一种数据表示方式也无法满足所有用例需求。单一的数据湖、Delta Lake或数据仓库无法满足业务需求。构建合理的架构，确保它不仅能在当下实现，还能在未来保持功能，是数据工程师的最终目标。
用例定义
问题：为什么任何数据工程系统的开发都应该以用例为驱动？
回答：如果无法开发出与业务需求集成的解决方案，那么它就是无关紧要的：无法沟通其价值，也无法量化其有效性。
没有用例的情况下，数据处理系统无法提供维持资金持续投入所需的具体价值。即使解决方案再完美，当无法满足预期时，也会迅速陷入令人沮丧的事后分析讨论。
因此，解决方案需要构建成一个自文档化、自演示的用例集合，以支持基于测试驱动的交付方法。
这既是艺术也是科学，但如果系统数据架构明确专注，则完全可以实现。定义参考用例以及这些用例如何支持架构是一个极高的标准。在开发计划中将用例层层嵌入作为解决方案的功能时，必须避免迷失方向。为了保持专注，你需要一个愿景、战略和明确的使命。
使命、愿景与战略
你应从愿景和使命开始，本部分的概述已经为此奠定了基础。这些愿景和使命应与组织的战略保持一致。如果不一致，则必须实现对齐。我们将在后续部分对此进行详细阐述。
原则与开发生命周期
原则是制定业务战略和定义架构时的指导标准，技术人员在此基础上结合艺术与科学来满足业务需求。保持对齐是必须的，否则在出现问题时会难以解决。早期错误的成本远大于开发生命周期后期的错误。因此，数据工程生命周期应从架构设计开始。
架构定义、最佳实践与关键考量
架构的开发有多种方式，但作为工程师、架构师和作者，我们发现核心架构交付件需要包括以下三个主要组成部分：
- 概念架构
- 逻辑架构
- 物理架构
- 概念架构展示业务的使命、愿景、战略和原则，并作为一个向上和向外的沟通工具。在定义概念架构时，会建立一个能力矩阵，展示解决方案所需的所有能力及其交付方式。这将在第5章详细介绍，但现在需要知道的是：解决方案的核心概念基础应是与你的愿景、使命和战略一致的原则。
- 逻辑架构展示实现概念架构所需的软件服务和数据流，并将概念与其逻辑实现联系起来。
- 物理架构定义了解决方案中可部署的软件、配置、数据模型、ML模型和云基础设施。
我们的最佳实践和关键考量源于多年在金融、医疗、出版和科学领域大数据处理系统和初创企业中的经验。这些项目涉及社交媒体、健康和零售分析数据的处理。
如何基于架构创建用例
用例可以从逻辑和物理架构中提取：
-
逻辑用例：
- 软件服务流
- 数据流
-
物理用例：
- 基础设施配置信息
- 运营流程信息
- 软件组件清单
- 算法参数设置
- 数据质量/测试定义及配置信息
- DevOps/MLOps/TestOps/DataOps 跟踪信息
可重用的设计模式
可重用设计模式是这些用例的组合，具备简洁的接口，并且足够通用，可跨多个数据领域复用，从而降低开发和运营成本。由于智能数据框架的组织简化了软件设计，用例将自然地整合为模式。这将成为未来软件开发的加速器。
数据流将由这些设计模式表示，使其不再仅仅是静态的文档定义，而是能够反映数据在框架中的工程化解决方案中的数据旅程，并与架构保持一致的操作设计模式。
DataOps 融合
数据旅程是一条从原始数据导入开始，通过分类处理，最终将转化后的信息提供给终端用户消费的路径。经过精心整理的可消费数据，会依次经过不同的活动区域。这些区域将在后续章节中详细定义，包括青铜区（bronze） 、白银区（silver）和黄金区（gold） 。数据集在数据工厂的模式下经过逻辑和物理分组，并被划分到这些活动区域内。所有定制构建并配置的数据工厂管道旅程都依赖于数据工程师的标准流程，否则IT运营和通过合同维护的服务水平将面临风险。
数据的转化和目录管理活动围绕着业内称之为DataOps的方法展开。
据Gartner预测，到2025年，采用DataOps实践和工具的数据工程团队的生产力将比未采用DataOps的团队高出10倍。（2022 Gartner DataOps工具市场指南，{packt-debp.link/6JRtF4}）
Gartner 对 DataOps 的核心能力定义
DataOps 由以下五个核心能力组成：
-
编排能力（Orchestration capabilities）：
- 连接性（Connectivity）
- 调度（Scheduling）
- 日志记录（Logging）
- 数据沿袭（Lineage）
- 故障排查（Troubleshooting）
- 警报（Alerting）
- 工作流自动化（Workflow automation）
-
可观察性能力（Observability capabilities）：
- 实时或历史工作流监控
- 工作流性能洞察
- 成本指标（Cost metrics）
- 影响分析（Impact analysis）
-
环境管理能力（Environment management capabilities）：
- 基础设施即代码（IaC）
- 资源配置（Resource provisioning）
- 凭证管理（Credential management）
- 可重用的 IaC 模板
-
部署自动化能力（Deployment automation capabilities）：
- 版本控制（Version control）
- 审批流程（Approvals）
- 云CI/CD及管道（Cloud CI/CD and pipelines）
-
测试自动化能力（Test automation capabilities）：
- 验证（Validation）
- 脚本管理（Script management）
- 数据管理（Data management）
DataOps 实践应用示例
为了说明这些DataOps原则的应用场景，设想一家大型零售公司部署一个库存管理系统。请参考图1.2，以直观了解DataOps在这种业务场景中的实现方式。
许多第三方供应商已经抓住了DataOps的热潮，推出了出色的工具，加速了DevOps、MLOps 和 TestOps实践在现代云数据系统中的融合。
本书的数据工程最佳实践也将支持Gartner所提出的DataOps实践，同时保持对具体工具选择的中立性。我们的重点将放在数据工程框架上，而DataOps的努力将使这一框架更加简化、高效且面向未来。
请参考图1.3：
很明显，DataOps 为传统数据管理流程增添了大量价值，使得未来的新功能成为可能。以下引用展示了现代 DataOps 流程如何加速开发：
一位参考客户表示，通过采用适合其环境的 DataOps 工具，他们每月能够进行120次发布，而在一年前，他们每三个月才能发布一次。（Gartner，2022，{packt-debp.link/41DfFu}）
总结
在这一业务问题概述中，你了解了多个基础要素，这些内容将在后续章节中详细阐述。本章介绍了理解当前数据工程现状和构建面向未来的设计所需的话题。你已经了解到，企业面临不断变化的技术环境，竞争需要企业在规模上进行创新以保持其相关性。这促使系统生命周期中本应处于运行/管理阶段时，不断分配**总拥有成本（TCO）**预算用于重构和重新规划。
在本章及后续章节中，我们多次提及解决方案的TCO，以提醒所有利益相关者开发的解决方案必须置于真实的业务环境中，而非脱离预算约束的抽象真空。预算限制会不可避免地影响可能性，并且这些限制会反复出现在企业的月度和季度报告中，往往会带来风险。没有持续的提醒，业务方将很快忘记这些约束如何影响了解决方案。
此外，构建一个维持虚假事实（即使被包装为真事实）的系统是愚蠢的。让未来的数据解决方案变得智能吧！我们正迈入一个激动人心的未来，在这个未来中，数据和信息解决方案将变得更加智能，支持知识和智能能力。拥抱这种变化，并了解其对你数据工程选择的影响。DataOps 是当今复杂、数据驱动世界中管理数据的关键方法，数据专业人士必须加以采用。
没有一种解决方案适用于所有情况，因此，在设计时考虑数据合同，将迫使开发的数据存储在逻辑上与物理数据架构保持一致，并以适用性为目的实现平行实例化。正确构建面向未来的数据解决方案需要愿景、战略、使命和架构方法，以防止由于在可用性和服务性之间不断妥协而导致方案夭折。
第三方供应商和云提供商将提供架构良好的解决方案，但这些解决方案要么无法集成，要么更糟糕的是助长了需要避免的架构反模式。因此，在充分理解数据网格（data mesh）和云提供商的数据织布（data fabric）概念并将其合理化为企业架构和目标之前，这些术语仅仅是流行语。数据解决方案必须与架构保持一致，并在整个系统中开发用例，测试、回归测试并监控它们，以确保服务的持续性，并通过数据合同维护建立的信任。
最后，保持敏捷！阅读、学习、创新！一旦掌握全局视角，你将具备前瞻性，能够看清前方障碍并超越它们。你将通过受治理的敏捷架构流程保持数据解决方案和数据的新鲜与实时。
在下一章中，我们将介绍基于本概述的架构背景挑战。
