下面我们分享“基本”数据平台的样子，并列出每个空间中的一些热门工具：
数据摄取
与几乎所有现代数据平台的情况一样，需要将数据从一个系统摄取到另一个系统。随着数据基础设施变得越来越复杂，数据团队面临着从各种来源摄取结构化和非结构化数据的挑战性任务。这通常称为提取转换加载 (ETL) 和提取加载转换 (ELT) 的提取和加载阶段。
下面，我们概述了该领域的一些流行工具：
- Fivetran – 领先的企业 ETL 解决方案，可管理从数据源到目的地的数据交付。
- Singer – 一个开源工具，用于将数据从任何来源移动到任何目的地。
- Stitch – 基于云的开源平台，可让您将数据从任何来源快速移动到任何目的地。
- Airbyte – 一个开源平台，可让您轻松同步应用程序中的数据。
- Apache Kafka – 一个开源事件流平台， 用于处理流分析和数据摄取
编排和工作流自动化，具有Apache Airflow、Prefect和Dagster等工具，通常也折叠到摄取层中。编排通过获取孤立的数据，将其与其他来源相结合，并使其可用于分析，使摄取更进一步。
数据存储和处理
构建摄取层后，您需要一个地方来存储和处理数据。随着公司将他们的数据环境转移到云上，云原生数据仓库、数据湖甚至数据湖[url=https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html]库的出现[/url]已经占领了市场，相对于许多本地解决方案，为存储数据提供了更易于访问和负担得起的选择。
无论您选择使用数据仓库、数据湖还是两者的某种组合，都完全取决于您的业务需求。最近，在构建数据堆栈时，有很多关于是采用开源解决方案还是采用闭源解决方案的讨论（Snowflake和Databricks营销团队之间的对话确实揭示了这一点）。
无论您站在哪一边，如果不投资云存储和计算，您就无法构建现代数据平台。
- Snowflake – 原始云数据仓库，Snowflake 为数据团队提供灵活的支付结构，因为用户为计算和存储数据支付单独的费用。
- Google BigQuery – Google 的云仓库 BigQuery 提供无服务器架构，允许通过并行处理进行快速查询，以及单独的存储和比较以实现可扩展的处理和内存。
- Amazon Redshift – Amazon Redshift 是使用最广泛的选项之一，它位于 Amazon Web Services (AWS) 之上，可轻松与该领域的其他数据工具集成。
- Firebolt – 一种基于 SQL 的云数据仓库，声称其性能比其他选项快 182 倍，因为该仓库采用压缩和数据解析新技术，以更轻松的方式处理数据。
- Microsoft Azure – 此列表中的 Microsoft 云计算进入者在利用大量 Windows 集成的团队中很常见。
- Amazon S3 – 一种用于结构化和非结构化数据的对象存储服务，S3 为您提供从头开始构建数据湖的计算资源。
- Databricks – Apache Spark 即服务平台 Databricks 开创了数据湖库，为用户提供利用结构化和非结构化数据的选项，并提供数据湖的低成本存储功能。
- Dremio – Dremio 的数据湖引擎为分析师、数据科学家和数据工程师提供了一个集成的数据湖自助服务界面。
数据转换和建模
数据转换和建模通常可以互换使用，但它们是两个截然不同的过程。当您转换数据时，您正在获取原始数据并使用业务逻辑对其进行清理，以便为分析和报告准备好数据。当您对数据建模时，您正在创建数据的可视化表示以存储在数据仓库中。
下面，我们分享了一个常用工具列表，这些工具允许数据工程师转换和建模他们的数据：
- dbt – 数据构建工具的缩写，是数据加载到仓库后转换数据的开源领导者。
- Dataform – 现在是 Google Cloud 的一部分，Dataform 允许您将仓库中的原始数据转换为 BI 和分析工具可用的数据。
- Sequel 服务器集成服务 (SSIS) – 由 Microsoft 托管，SSIS 允许您的企业从各种来源中提取并转换该数据，然后您可以将这些数据加载到您选择的目的地。
- 自定义 Python 代码和Apache Airflow——在 dbt 和 Dataform 等工具兴起之前，数据工程师通常用纯 Python 编写他们的转换。虽然继续使用自定义代码来转换您的数据可能很诱人，但它确实增加了出错的机会，因为代码不容易复制，并且每次过程发生时都必须重写。
数据转换和建模层将数据转化为更有用的东西，为其旅程的下一个阶段做好准备：分析。
商业智能 (BI) 和分析
如果您的员工不能使用，您收集、转换和存储的数据将无法为您的业务服务。
如果数据平台是一本书，那么 BI 和分析层将是封面，充满引人入胜的标题、视觉效果以及数据实际试图告诉您的内容的摘要。事实上，这一层通常是最终用户在描绘数据平台时所想到的，并且有充分的理由：它使数据具有可操作性和智能性，没有它，您的数据就缺乏意义。
下面，我们概述了顶级数据团队中一些流行的 BI 解决方案：
- Looker – 针对大数据优化的 BI 平台，允许您的团队成员轻松协作构建报告和仪表板。
- Tableau – 通常被称为 BI 行业的领导者，它具有易于使用的界面。
- Mode – 一个协作数据科学平台，将 SQL、R、Python 和可视化分析整合到一个 UI 中。
- Power BI – 基于 Microsoft 的工具，可轻松与 Excel 集成并为团队中的每个人提供自助分析。
数据可观察性
随着数据管道变得越来越复杂，以及组织依赖数据来推动决策制定，对这些数据被摄取、存储、处理、分析和转换为值得信赖和可靠的需求从未如此高。简而言之，组织再也不能承受数据出现故障，即部分、不准确、丢失或错误的情况。
通过将相同的应用程序可观察性和基础架构设计原则应用于我们的数据平台，数据团队可以确保数据可用且可操作。在我们看来，根据不良数据做出决策通常比根本没有数据更糟糕。
您的数据可观察性层必须能够监控以下可观察性支柱并发出警报：
- 新鲜度：数据是最新的吗？上一次生成是什么时候？包含/省略了哪些上游数据？
- 分布：数据是否在可接受的范围内？格式是否正确？是否完整？
- 卷：所有数据都到了吗？
- 架构：架构是什么，它是如何改变的？谁进行了这些更改，出于什么原因？
- Lineage：对于给定的数据资产，受其影响的上游资源和下游资产是什么？谁是生成这些数据的人，谁依赖它进行决策？
数据发现
在构建数据平台时，大多数领导者的任务是选择（或构建）数据目录，在我们看来，这种方法已经不够了。
不要误会我的意思：数据目录很重要，现代数据团队需要一种可靠、可扩展的方式来记录和理解关键数据资产。但随着数据变得越来越复杂和实时，平台这一层背后的流程和技术也需要发展。
在许多传统数据目录不足的地方（即通常是手动的、可扩展性差、缺乏对非结构化数据的支持等），数据发现弥补了这一不足。如果数据目录是一张地图，那么数据发现就是您智能手机的导航系统，它会根据最新的见解和信息不断更新和完善。
数据发现至少应满足以下需求：
- 自助发现和自动化：数据团队应该能够在没有专门的支持团队的情况下轻松利用他们的数据目录。数据工具的自助服务、自动化和工作流编排消除了数据管道各阶段之间的孤岛，并在此过程中更容易理解和访问数据。更高的可访问性自然会增加数据采用率，从而减轻数据工程团队的负担。
- 随着数据演变的可扩展性：随着公司摄取越来越多的数据和非结构化数据成为常态，扩展以满足这些需求的能力对于您的数据计划的成功至关重要。数据发现利用机器学习在数据资产扩展时获得对它们的鸟瞰图，确保您的理解随着数据的发展而适应。通过这种方式，数据消费者可以做出更明智、更明智的决策，而不是依赖过时的文档或更糟糕的基于直觉的决策。
- 数据健康的实时可见性：与传统的数据目录不同，数据发现提供对数据当前状态的实时可见性，而不是其“编目”或理想状态。由于发现包括消费者如何摄取、存储、聚合和使用您的数据，因此您可以收集见解，例如哪些数据集已过时且可以弃用，给定数据集是否具有生产质量，或者给定表何时最后更新。
- 支持治理和仓库/湖优化：从治理的角度来看，查询和处理湖中的数据经常使用各种工具和技术（为此使用 Databricks 的 Spark，使用 EMR 的 Presto 等），并且作为结果，读取和写入通常没有单一、可靠的真实来源（如仓库提供的）。一个合适的数据发现工具可以作为真相的中心来源。
数据发现使数据团队能够相信他们对数据的假设与现实相符，从而在您的数据基础设施中实现动态发现和高度可靠性，无论域如何。
总结：
构建数据平台并非易事，在此过程中需要考虑很多不应忽视的因素。我们的客户面临的最大挑战之一是他们是否应该只在内部构建某些层、投资 SaaS 解决方案，或者探索广阔的开源世界。
我们的答案？除非您是 Airbnb、Netflix 或 Uber，否则您通常需要将这三者都包括在内。
这些解决方案各有利弊，但您的决定将取决于许多因素，包括但不限于：
- 数据团队的规模。数据工程师和分析师已经有足够的能力，要求他们构建内部工具可能比您想象的花费更多的时间和金钱。简而言之，精益数据团队没有时间让新团队成员跟上内部工具的速度，更不用说构建它们了。投资于易于配置、自动化或流行的解决方案（即开源或低代码/无代码 SaaS）在非 Uber/Airbnb/Netflix 数据团队中变得越来越普遍。
- 您的组织存储和处理的数据量。在选择解决方案时，重要的是要选择一个能够与您的业务扩展的解决方案。很有可能，如果您只需要几行代码来完成这项工作，那么对于一家 20 人公司的独狼数据分析师来说，采用每年 1 万美元的转换解决方案是没有意义的。
- 您的数据团队的预算。如果您的团队预算有限但人数众多，那么开源选项可能非常适合您。但是，请记住，在跨数据堆栈设置和实施开源工具时，您通常要靠自己，经常依赖社区的其他成员或项目创建者自己来构建和维护功能。当你考虑到只有大约 2% 的项目在最初几年后看到增长时，你必须小心。
无论您选择哪条路径，以正确的顺序构建这些层都将为您提供增长和扩展的基础，最重要的是，提供您公司可以信赖的洞察力和产品。