早期的数据呈现形式

十年前，许多公司对数据的期望主要局限于商业智能（BI）。他们希望能够生成报告和仪表盘，以管理运营风险，响应合规要求，并最终根据事实做出商业决策，但决策的速度相对较慢。

除了商业智能，经典统计学习还被用于保险、医疗保健、制造和金融等行业的业务运营中。这些早期的用例由高度专业化的团队提供，并对过去的许多数据管理方法产生了最大的影响。

总之，早期的数据情况如下：

数据用于特定案例分析，而不是战略决策
数据主要用于自动化报告
开始进行业务的统计建模

传统的数据栈

传统数据堆栈（Traditional Data Stack，TDS）是指本地数据系统的另一个名称。

组织机构管理自己的基础架构和硬件，这在可靠性（对任何更改的高抗性）、维护成本（需要很多人工维护）、可扩展性（在堆栈需要时很难提供新的基础架构）、刚性（由于自下而上的维护）和复杂的根本原因分析方面带来了负担。

数据领域开始发生变化

大约在2010年左右，大型科技公司的崛起和技术的整体增长给数据栈带来了不同的挑战。组织现在需要处理以下问题：

数据量增加 - 这需要从数据仓库的刚性治理和繁重建模转向一个不太可控的数据湖环境，可以在其中存储数据。存储如此大量的数据也成为管理的一大挑战。
新类型的数据 - 出现了新类型的数据，如文本、图像或音频。当时大多数组织甚至不知道如何利用这些非结构化数据。
更多的业务用例 - 组织现在可以利用大量和新类型的数据来构建更准确的模型，以改善决策系统。自然语言处理（NLP）、计算机视觉和推荐系统对所有组织来说都变得更加可行。

现代数据栈

面对新的挑战，数据栈必须演进到一个新的状态。这就是现代数据栈（MDS）出现的时候。

现代数据栈最大的成就是向云端的转变，从技术角度上使数据更易访问、恢复和管理。现代数据栈简化了数据的收集和摄取，支持高速数据流，以低成本实现高扩展性。

MDS是由多个工具组成的集合，它们相互连接，实现从物理数据到业务洞见的活跃流动。

这些工具以其简单的云端部署、可扩展性和组件化特性而被特征化。每个工具解决数据领域中的不同挑战，例如计算和存储的分离（Snowflake、DataBricks）、数据血统（Stemma、Alation）、转换（dbt）、作业编排（Airflow、Prefect）、模式管理（Protobuf）、流处理（Kafka）、监控（Monte Carlos、Bigeye）等等。

会出现哪些问题？

MDS作为一个不相互连接的工具组合出现，从而在各个行业中产生了繁重的流程和数据转储到中央数据湖，导致无法管理的数据混乱。这些工具从未被设计为能够在整个数据价值链中协同工作。

此外，数据已经超越了最初为高管提供仪表盘的用例，短短几年内发展成了数百个模型和仪表盘。这导致了一系列问题：

由于数据来自不同的源头，理解数据的上下文变得更加困难，因为数据仓库无法再通过数据对现实世界进行复制，使实体和表之间能够相互连接。
许多数据项目会使用不同的名称或引用未维护的表来重复使用相同的数据。
缺乏良好的测试。调试非常具有挑战性。
团队难以确定重要数据的真实来源，并开始为临时问题创建自定义的表，导致出现“数据债务”（关于数据债务的更多内容将在未来的文章中介绍）。
数据团队花费数月时间为机器学习模型生成特征集、创建指标、运行实验和数据处理。
关键数据集频繁出现问题，缺乏责任和所有权。

大多数组织要么正在目睹这些问题，因为他们的数据堆栈已经发展，要么正因为继续在数据领域投资而即将面临这些问题。

可以怎么解决呢？

现代数据堆栈主要解决了与成本和性能相关的工程挑战，但在数据如何用于解决业务问题方面却产生了更多问题。

利用数据的主要目标是丰富业务体验和回报，因此我们应该将重点放在这方面。

以下是一些可以减少数据生产和数据消费之间瓶颈的想法：

将数据仓库作为所有分析的基础

建立从不同来源摄取的所有数据之间的语义映射，将使数据仓库真正有效，并为数据使用者提供更好的体验。需要投入更多的时间来了解不同数据源之间的连接方式，并进行真实世界的映射。

将软件工程师（SWE）与数据工作流连接起来

软件工程师产生了大部分用于业务报告、实验和模型的数据。然而，他们并不知道他们的数据是如何被使用的。

数据工程师最终成为中间人团队，花费更多时间修复管道问题，因为上游（后端或前端服务）发生了变化，而不是创建新的管道来支持业务机会。在这个过程中，需要进行一些改变：

首先考虑数据契约 - 数据契约是对数据的期望。这些期望可以是业务含义、数据质量或数据安全和治理等形式。这确保数据工程师了解上游数据，并避免由于上游变化而导致管道中断。
在数据生成生命周期中进行更深入的工程化 - 工程团队需要了解他们生成的数据将如何在下游流程中使用。这将确保他们在计划变更时考虑到这一点。
数据质量由工程团队负责，因为他们是数据的生产者，至少在数据加载到数据湖之前是如此。
数据工程更贴近业务背景

数据工程师负责建立和管理数据平台及其工作流程。他们充当软件工程师和数据科学家、分析师之间的中间人。然而，大多数时候，他们在没有业务背景或对所交付的表格的最终目标毫无头绪的情况下构建管道。

缺乏业务背景，数据工程师无法理解不同数据点之间应该如何连接，无法构建与现实世界相对应的数据仓库。

数据产品思维

数据团队需要确保他们构建的数据产品解决了真正的用户问题。仅从技术角度考虑数据产品已经不再足够。确保数据产品与用户问题之间的市场匹配必须成为数据工作流的一部分。

传统的数据建模面临诸多挑战，如高度的治理、非常刚性的流程、难以迭代和获取洞见所需的时间较长。在数据仍然可控且团队能够确保所摄入的数据符合特定模式的时候，数据建模设计效果良好。

但是随着数据量和数据来源的增加，应用数据建模变得更加困难，这也是数据仓库开始失去主要目标的原因。

数据生态系统需要思考适用于现代数据堆栈的数据建模2.0。分散的数据架构，即数据在各个领域之间分布，可能是解决这个问题的方案。

过去几十年对数据项目的大部分投资都集中在技术上，追求更多更好的技术。对于流程和数据管理的投入不多。以下是一些实践方法，以确保数据能够有效、安全和合乎伦理地进行管理：

数据所有权 - 谁拥有和对特定数据负责。这确保了数据的所有权和责任。
数据质量标准 - 一组标准，用于确保数据准确、完整、一致和及时。这些标准确保数据可靠和可信。
数据目录 - 组织内所有数据产品的存储库，提供元数据、文档和数据血统的位置，使发现、理解和使用数据更加容易。
数据政策和流程 - 一套程序，用于定义组织中数据的收集、存储、处理、验证和使用方式。
数据血统 - 提供对数据起源和流动的清晰理解。

现代数据堆栈（Modern Data Stack)中存在的问题