在过去的几个月里，我一直在与 freeCodeCamp 创始人 Quincy Larson 协作设计 2021 New Coder Survey（2021 年新开发者调查问卷）。我很高兴地宣布它现已上线。

与过去的调查一样，我们将把调查问卷的结果作为开放数据集发布。调查是匿名的，我们不要求提供任何个人身份信息。所有问题都是选择题。

你可以在这里参加调查。请务必点击问卷底部的 “submit” 按钮进行提交——即使你没有回答所有问题，也可以提交。

我是如何参与 2021 New Coder Survey（新开发者调查）的

去年这个时候，我第一次发现了 freeCodeCamp。正如你们中的许多人可能已经做过的那样，我开始在业余时间尝试各种编程工具。我想看看我是否可以从零计算机科学背景的起点开始学习编码。

在我开始学习编程后不久，我的社会科学家的一面就被激发出来——我发现自己想要更多地了解这个快速发展的新开发者的社区。

然后我发现了 freeCodeCamp 的 2016、2017 和 2018 New Coder Survey 开放数据集。 这些调查结果帮助我对我们这个时代最伟大的现象之一——日益增长的学习编程的兴趣——进行了一些透视。这些信息也促使我提出更多问题，所以我参与进来了。

我们如何规划今年的 New Coder Survey

3 月，我给 Quincy 发了电子邮件，询问 freeCodeCamp 是否计划在 2021 年启动一项新调查，并提出我愿意帮忙做这件事情。

我没有希望会收到太多回应，或者我想根本就不会有任何回应。但幸运的是，Quincy 接受了我的帮助，第二天我们就开始准备了！

几个月来，我们就修改现有问题和创建新问题交换了意见，以更好地了解新开发者是谁，以及他们如何学习编程。

我们有很多问题要问。但我们也知道，我们需要注意调查对象的时间，尽量不要让他们感到厌烦，所以我们不得不做出一些艰难的选择。

我们决定保持简洁明了的设计。我们将 2021 New Coder Survey 创建为单页表单，其中包含 49 个选择题。

从调查设计的角度来看，这不是理想的解决方案，但它是一个实用的解决方案。现在，每个人都可以看到所有的问题，并选择跳过那些不适用于他们的问题。

如何参加 2021 New Coder Survey

49 个问题可能看起来很多，但请耐心等待！ 回答所有问题只需要大约 10 分钟。这很有趣。😃

即使你没有时间回答所有问题，也请不要退出调查，只需向下滚动到底部并单击 “Submit”。无论你回答了多少问题，都可以提交。

与之前一样，调查是匿名的（我们不要求提供任何个人身份信息）。当调查结束，我们将公开整个数据集。

事不宜迟，这里是 2021 New Coder Survey！感谢你抽出宝贵时间分享你的见解和经验。

关于调查的更多介绍

还有一件事——我还对美国的自学程序员进行了单独的研究。我很乐意与你交谈，并更多地了解你在成为开发人员的道路上的经历。

你有兴趣与我（通过 Zoom/Skype 保密地）聊聊你的学习编程之旅吗？

如果你愿意，请填写这个简短的表格与我联系（只需不到一分钟的时间）。

你可以在这里和这里了解更多关于我和我的研究。

我很高兴成为这个重要项目的一部分。今天，全球数以百万计的人正在学习编程，我们期待更多地了解这个快速发展的全球新开发者的社区。

即使你不是程序员，你仍然可以通过在 Twitter 和其他平台上分享这篇文章来帮助我们。

请继续关注调查结果——当调查结束，我们将在同一个 URL 上公布它们。

Happy coding!

原文：The 2021 New Coder Survey is Now Live – and Here's How We Designed It，作者：Dilan Eren

前言

为了实现数据驱动、能使用数据进行竞争、或者使用数据在规模上驱动价值，今天的架构和组织都面临挑战，之前的文章《如何从单一数据湖移动到分布式数据网格》对此中痛点深表同感（阅读下文前，鼓励你先读这篇文章）。它提供了另一种视角，这一视角已经引起了许多组织的注意，并为不同的未来带来了希望。虽然最初的文章描述了这个方法，但它也留下了很多设计和实现的细节，让人去想象。我无意在本文中作明确的界定，从而扼杀了围绕数据网格实现的想象力和创造力。这里，将阐明数据网格的架构方面，作为推动范式向前发展的垫脚石。

写这篇文章更多是作为一个续集。它总结了数据网格方法，列举了它的基础原则，以及这些原则所驱动的高级逻辑架构。在以后的文章中深入研究数据网格核心组件的详细架构之前，高级逻辑模型是必要的基础。因此，如果您正在寻找数据网格的具体工具和方法，这篇文章可能会让您失望。如果您正在寻找一种简单的、与技术无关的模型来建立一种通用语言，那就来吧。

数据的巨大鸿沟

我们所说的数据到底是什么?答案取决于你问的是谁。今天提到的数据，可以分为运营数据和分析数据。运营数据位于由微服务提供的业务功能背后的数据库中，具有事务性，保持当前状态并满足运行业务的应用程序的需求。分析数据是对业务事实随时间推移产生的临时和聚合视图，通常用于建模以提供回顾或未来视角的洞见;它也用于训练ML模型或提供分析报告。

技术、架构和组织设计的当前状态反映了这两个数据平面的分歧——两个层次，既集成而又分离。这种分歧导致了一个脆弱的架构。许多人试图连接这两个数据平面，将数据从运营平面流动到分析平面，然后再返回到运营平面。然而不断失败的ETL（提取、转换、加载）作业和不断增长的迷宫般的数据管道的复杂性变得越发常见。

分析数据平面本身分为两大主要架构和技术栈: [数据湖](bliki: DataLake)和数据仓库;数据湖支持数据科学访问模式，数据仓库支持分析和商业智能报告访问模式。而同时，数据仓库正试图支持数据科学工作流程，数据湖也试图为数据分析和商业智能服务。本文将先把这两个技术栈之间的交错放在一边，数据网格最初的文章探讨了现有分析数据平面架构所面临的挑战。

数据网格认可并尊重这两个层面之间的差异:数据的性质和拓扑、不同的用例、数据消费者的角色，以及最终它们的不同访问模式。然而，它试图在不同的结构(基于领域的倒置模型和拓扑，而不是基于技术栈)下连接这两个平面，并将重点放在分析数据平面上。当今管理两种数据原型的可用技术中，都不应该导致组织、团队和工作人员的分离。在我看来，运营性和事务性数据的技术和拓扑是相对成熟的，并且主要由微服务架构驱动;数据隐藏在每个微服务内部，通过微服务的api控制和访问。当然，真正实现混合云本地操作数据库的这解决方案还有创新空间，但从架构的角度来看，它已经满足了业务的需求。然而，管理和获取分析数据仍存在大量的摩擦。这，就是数据网格的重点所在。

我相信，在未来的某个时刻，我们的技术将会发展，使这两各数据层面能更加紧密地联系在一起，但现在，建议先把关注点分离。

数据网格的核心原则和逻辑架构

网格目标是为了构建一个基础底座，便于从大规模分析数据获得价值，以及适应历史事物的不同维度变化，如数据环境的不断变化、数据源和消费者的扩散、用例所需的转换和处理的多样性、变化响应速度的改变。为了实现这一目标，我建议，任何数据网格实现都应遵循以下四个基本原则:

1. 面向领域的分析数据所有权和架构
2. 数据即产品
3. 自服务的数据基础平台
4. 联合计算治理

这些原则的实践、技术和实现会随着时间的推移而变化和成熟，但这些原则不会改变。

这四项原则合起来应该是必要和充分的;在解决不兼容数据竖井或运营成本增加的问题时，实现形式可弹性伸缩。下面，让我们深入研究每个原则，然后设计支持它的概念性架构。

原则一：领域所有权

数据网格的核心是将责任分散并分配给最接近数据的人，以支持持续的变化和可伸缩性。问题是，我们如何分解和分散数据生态系统的组件及其所有权。这里的组件由分析数据、元数据和为其提供服务所需的计算组成。

数据网格按组织单元的边界分解。而我们现在的组织单元是基于它们的业务领域划分的。这种划分的持续变化和演化(在大多数情况下)将影响到领域的的限界上下文。因此，使业务领域的限界上下文成为数据所有权分布的良好候选对象。

在本文中，我将继续使用与最初写作相同的用例，“一家数字媒体公司”。可以想象，媒体公司会根据域划分其运营，并从而划分支持运营的系统和团队。如“播客”领域，会有相应的系统和团队管理播客发布及其主机; 又比如“艺人”领域，也会有相应的系统和团队负责上线及付款。数据网格认为分析数据的所有权和服务应该尊重这些领域。例如，管理“播客”领域的团队，在为播客发布提供API的同时，还应该负责提供“已发布的播客”的历史数据和其他相关指标，比如“听众人数”。要更深入地了解这一原则，请参见[《面向领域的数据分解和所有权》](How to Move Beyond a Monolithic Data Lake to a Distributed Data
Mesh)。

逻辑架构：面向领域的数据和计算

为了促进这样的划分，我们需要对分析数据的按领域建模。在这个架构模型中，领域与组织其他部分的接口不仅包括运营能力，还包括对领域服务的分析数据的访问。例如，“播客”领域提供了运营API来“创建一个新的播客集”，但也提供了一个分析数据接口来检索“过去n个月的所有播客集数据”。这意味着架构模型必须消除任何摩擦或耦合，以让领域能服务于它们的分析数据，并独立于其他领域发布计算数据的代码。为了规模化，架构必须支持领域团队在发布和部署其运营或分析数据系统方面的自主权。

下面的示例演示了面向领域的数据所有权原则。这些图只是逻辑表示和示例性的。它们并非是完整的。每个领域可以发布一个或多个运营api，以及一个或多个分析数据接口。

当然，每个领域都可以依赖于其他领域的运营和分析数据接口。在下面的例子中，“播客”领域作为消费者，从“用户”领域获取“用户更新”的分析数据，从而能通过“播客听众人数统计”数据集提供一个播客听众人数的视图。

注意:在示例中，我使用了命令式语言（动宾）来访问运营数据或功能，如“支付艺人”。这只是为了强调访问运营数据和分析数据的意图之间的区别。我认识到，在实践中，运营性API是通过声明性更强的接口实现的，比如RESTful资源访问或GraphQL查询。

原则二：数据即产品

现有分析数据架构的挑战之一是对于发现、理解、信任和最终使用高质量数据的高摩擦和成本。如果不加以解决，随着提供数据领域的系统和团队数量的增加，这个问题只会随着数据网格划分而加剧。这将是去中心化第一原则的结果。数据即产品原则旨在解决数据质量和古老的数据竖井问题;或如Gartner所称的“黑暗数据”问题——“组织在常规业务活动中收集、处理和存储的信息资产，但通常不会用于其他目的”。领域提供的分析数据应该被视为产品，数据的消费者应该被视为客户——需要被满足的客户。

原文中列举了一系列能力，包括可发现性、安全性、可探索性、可理解性、可信赖性等，这是数据网格在支撑数据即产品时应该提供的能力。它还详细描述了角色，比如组织必须引入的领域数据PO，负责确保数据作为产品交付的客观度量。度量包括数据质量，减少数据消耗的前置时间，以及一般通过净推广者评分获得的数据用户满意度。

领域数据PO必须深入了解数据用户是谁，他们如何使用数据，以及他们习惯使用什么方式获取数据。这种对数据用户的深入了解能促使数据产品接口的设计满足用户需求。实际上，对于网格上的大多数数据产品，都有一些传统的用户画像，他们拥有独特的工具和期望，比如数据分析师和数据科学家。所有数据产品都可以通过开发标准化接口实现。数据用户与PO之间的对话是建立数据产品接口的必要环节。

每个领域将包括数据产品开发者，她们负责构建、运维和提供领域的数据产品，数据产品开发者将与该领域的其他开发人员一起工作。每个领域团队可以提供一个或多个数据产品。也可以组建新的团队来提供那些不适合现有运营领域的数据产品。

注:与过去的模式相比，这是一种反向的责任模式。数据质量的责任向上游转移，尽可能接近数据的来源。

逻辑架构：数据产品作为架构量子

在体系结构上，为了支持数据作为一种产品，领域可以自主地服务或消费，数据网格引入了数据产品的概念作为其架构量子。架构量子，在《演进式架构》中定义为最小的架构单元，它可以独立部署，具有高度的功能内聚性，并包含其功能所需的所有结构元素。

数据产品是网格上的节点，它封装了其功能所需的三个结构组件，作为产品提供对领域分析数据的访问。

• 代码
• 数据管道代码， 以消费、转换和服务那些从领域的运营系统或上游数据产品接收的数据
• api代码，以提供对数据、语义和语法模式、可观察性指标和其他元数据的访问
• 强制特征的代码，例如访问控制策略、合规性、来源等
• 数据与元数据
• 这就是这里的目的所在，以多种语言的形式来获取潜在的分析和历史数据。
• 根据领域数据的性质及其消费模型，数据可以展现为事件、批处理文件、关系表、图形等多种形式，同时维护相同的语义。
• 为了数据的可用性，需要一组相关的元数据，包括数据计算文档、语义和语法声明、质量指标等；数据固有的元数据，例如它的语义定义；以及传递计算治理用于实现预期行为特性(如访问控制策略)的元数据。
• 基础设施
• 基础架构组件支持构建、部署和运行数据产品的代码，以及存储和访问大数据和元数据。

下面的示例建立在前一节的基础上，将数据产品演示为架构量子。图中内容仅为示例，并不打算包括所有完整的设计和实现细节。虽然这仍然是一种逻辑表示，但正在接近最终物理实现。

注意：过去，管道(代码)被视为独立于它们所产生的数据的组件; 通常基础设施，如仓库或湖泊存储帐户的实例，会在许多数据集之间共享，而数据网格模型不同于过去的这些范例。数据产品是所有组件(代码、数据和基础设施)的组合，其粒度与领域的限界上下文相同。

原则三：自服务数据平台

正如您所想象的那样，要构建、部署、执行、监视和访问一个简单的元素(一个数据产品)，需要配置和运行大量的基础设施;提供此基础设施需要特定的技能，很难在每个领域复制。最重要的是，团队能够自主拥有其数据产品的唯一方法是访问基础设施的高阶抽象，从而消除配置和管理数据产品生命周期的复杂性和摩擦。这就需要一种新的原则，即将自服务数据基础设施作为一个平台来实现领域自治。

数据平台，可以视为用于运行和监视服务的交付平台的扩展。然而，今天支撑数据产品的底层技术栈看起来与服务交付平台非常不同。这只是由于大数据技术栈与运营平台的分歧。例如，领域团队可能将他们的服务部署为Docker容器，交付平台使用Kubernetes进行编排;然而，相邻的数据产品可能在一个Databricks集群上以Spark作业的形式运行其管道代码。数据网格需要配置和连接这两组非常不同的基础设施，而在此之前，两组基础设施不需要这种级别的互操作性和互联性。我个人的希望是，能看到运营和数据基础设施的融合。例如，可能在同一个编排系统（例如Kubernetes）上运行Spark。

实际上，为了让普通开发人员、领域现有的开发人员能够访问及开发相关的分析数据产品，除了简化配置之外，自服务平台还需要提供新型的工具和接口。自服务数据平台必须创建工具，以支持领域数据产品开发人员在工作中能创建、维护和运行数据产品，而不需要具备特定的专业知识;自服务基础设施必须包括降低当前成本和构建数据产品所需的专有功能。原文内容中，还包括了自服务数据平台提供的一系列功能，包括可伸缩的多语言数据存储的访问、数据产品格式定义、数据管道声明和编排、数据产品血缘、计算和数据本地化等。

逻辑架构：一个多平面的数据平台

自助服务平台功能可以分为多个类别，或在模型中称之为平面。注意:一个平面代表了一个整合而又分离的层次存在。类似于物理和意识的层，或网络中的控制层和数据层。平面既不是层，也不意味着强层次访问模型。

自服务平台可以有多个平面，每个平面为不同的用户提供服务。在以下示例中，列出了三种不同的数据平台平面:

• 数据基础设施平面：底层基础设施的配置，以支撑运行数据产品的组件和产品的网格。这包括提供分布式文件存储、存储帐户、访问控制管理系统、数据产品内部代码运行的编排、在数据产品图形上提供分布式查询引擎，等等。这是一个相当底层的数据基础设施生命周期管理平面，希望只有其他数据平台或者高级数据产品开发人员直接使用这个接口。
• 数据产品开发者体验平面：这是典型的数据产品开发人员使用的主界面。这个界面对数据产品开发人员工作流程所需的许多复杂性进行了抽象，比数据基础设施平面更高层。它使用简单的声明式接口来管理数据产品的生命周期。它自动实现切面上的公共关注点，这些关注点被定义为一组标准和全局约定，应用于所有数据产品及其接口。
• 数据网监督平面：有一组功能最好在网格级别综合提供：如数据产品的连接全景图。虽然每个能力的实现可能依赖于单独的数据产品功能，但在网格级别上提供这些功能更方便。例如，通过搜索或浏览数据产品的网格的功能，为特定用例提供发现数据产品的能力;或者通过执行一个数据语义查询，将多个数据产品关联起来以创建更高层次的洞察力，该查询可以跨网格上的多个数据产品进行操作。

下面的模型仅作为示例而非完整的。虽然平面的层次结构是可取的，但并不意味着严格的层次结构。

原则四：联合计算治理

如你所见，数据网格遵循分布式系统架构;各数据产品集合具有独立生命周期，很可能也由独立的团队构建和部署。然而，对于大多数用例来说，若要以更高阶数据集、洞察或机器智能的形式获得价值，就需要这些独立的数据产品进行交互;将它们关联起来，创建并集，找到交集，或在它们上进行其他图形或集合操作。为了让这成为可能，数据网格实现需要一个治理模型，它应该包含去中心化和领域自治、通过全局标准化实现交互操作和动态拓扑，最重要的是能由平台自动执行决策。我称之为联合计算治理。决策模型由领域数据产品PO和数据平台PO组成联合领导小组，他们具有各自领域的决策权，同时创建并遵守一组全局规则(适用于所有数据产品及其接口的规则)，以确保一个健康和可交互的生态系统。这决策小组中有不同的职责，需要在集中和去中心化中作一个平衡，需要衡量哪些决策应该领域自治，哪些需要针对所有领域进行全局决策。最终，全球决策只有一个目的，即通过发现和组合数据产品，来创建交互和复合网络效应。

数据网格中治理的优先级不同于传统的分析型数据管理系统治理。尽管它们最终都从数据中获取价值，但传统的数据治理依靠的是：集中决策、建立支持少量变更的数据全球规范化。相比之下，数据网格的联合计算治理更拥抱变化和支持多重解释上下文。

Placing a system in a straitjacket of constancy can cause fragility to evolve.
给一个系统穿上一件恒定的紧身衣可能会导致脆弱性的进化
-- C.S. Holling, ecologist

逻辑架构：嵌入在网格中的计算策略

联合计算治理发挥作用需要的必要条件：一个支持性的组织架构、激励模型和架构，从而在尊重本地域自治的同时，又能达成全局决策和标准，并有效地实施全局策略。

正如前面所提到的，对于哪些需要全局标准化并推动所有领域及其数据产品的实现和执行，哪些该留给领域自治，这两者如何取得平衡是一门艺术。例如，领域数据模型的建模就应该交给最熟悉该领域的去实现，像如何定义“播客受众”数据模型的语义和语法都应该留给“播客领域”团队。然而，相比之下，如何确定“播客听众”则是一个全局关注的问题。播客听众是“用户”群体中的一员，限界上下文的上游可以跨越领域的边界，并在其他领域中被发现，也如“用户播放流”。统一的身份识别让“用户”既可以是“播客听众”，也可以是“播放流的听众”。

下面是数据网格治理模型中涉及的元素的示例。这不是一个完整的例子，只是表明了全局层面的关注点。

许多前数据网格治理的实践，作为一种集中式的功能，已不再适用于数据网格范式。例如，过去强调以黄金数据集认证作为治理的中心（即经过集中的质量控制和认证过程并被标记为值得信赖的数据集），现已不再适用。在前面的数据治理模式中,数据（无论质量和格式）从运营侧的数据库中提取和集中存储在一个仓库或一个湖,再需要一个集中的团队进行清洁、协调和加密过程; 这集中团队通常在一个集中的治理组的管理之下。而数据网格完全以去中心化处理这个问题。领域数据集只有通过领域内预期的数据产品质量指标及符合全局标准化规则后，才成为数据产品。领域数据产品PO最了解知道生成数据的领域操作细节，所以由他们去决定如何度量其领域内的数据质量。另一方面，尽管有这种领域内的决策和自治，数据产品还需要遵循由全局联合治理团队定义并由平台自动化的全球标准的质量和规范建模。

下表显示了数据治理的集中式(数据湖、数据仓库)模型与数据网格的对比。

原则总结和高阶逻辑体系结构

总结一下，我们讨论了支撑数据网格的四个原则:

• 领域所有权：这样，创建和消费数据的生态系统可以随着数据源的数量、用例的数量和数据访问模型的多样性的增加而扩展;并且只需增加网格上的自治节点。
• 数据即产品：让数据使用者可以轻松发现、理解和安全地使用高质量数据，并享受愉快的体验;包括跨越多个领域的数据。
• 自服务数据平台：这样，领域团队就可以使用平台抽象自主地创建和使用数据产品，从而隐藏了构建、执行和维护安全且可互操作的数据产品的复杂性。
• 联合数据治理：这样，数据用户就可以从独立数据产品的聚合和关联中获得价值——网格就像一个遵循全球互操作性标准的生态系统;以计算方式融入平台的标准。

这些原则驱动逻辑架构模型，该模型将分析数据和操作数据更紧密地结合在同一个域中，同时尊重它们的基础技术差异。这些差异包括分析数据的托管位置、处理操作服务和分析服务的不同计算技术、查询和访问数据的不同方式，等等。

希望到目前为止，我们已经建立了一种通用的语言和逻辑思维模型，我们可以共同向前推进，进一步详细描述网格组件的蓝图，如数据产品、平台和所需的标准化。

原文：Data Mesh Principles and Logical Architecture