在今天的文章中，我将讨论现代数据堆栈中最大的挑战。我们是如何做到这一点的，主要问题是什么，以及如何解决这些问题。如果您还没有订阅，请考虑订阅。如果你想建立联系，请访问领英。
标签：现代数据堆栈|数据产品|数据战略|数据工程
早期的数据情况
十年前，许多公司对数据的渴望主要局限于商业智能（BI）。他们希望能够生成报告和仪表盘，以管理运营风险，响应法规遵从性，并最终以较慢的节奏根据事实做出业务决策。
除了BI之外，经典的统计学习也被用于保险、医疗保健、制造和金融行业的商业运营。这些早期用例由高度专业化的团队提供，是过去许多数据管理方法最具影响力的驱动因素。
在简历中，这就是早期数据的样子：
- 数据用于具体案例分析，而非战略决策
- 数据主要用于自动化报告
- 业务统计建模的开始
传统数据堆栈
传统的数据堆栈（TDS）是预处理数据系统的另一个名称。
组织管理自己的基础设施和硬件，这在脆弱性（对任何更改的高抵抗力）、高维护成本（非常手动密集的维护）、缺乏可扩展性（当堆栈需要时很难提供新的基础设施）、刚性（由于自下而上的维护）和复杂的根本原因分析方面都是一种负担。
数据格局开始发生变化
或多或少在2010年前后，大型科技的兴起和技术的整体增长给数据堆栈带来了不同的挑战。各组织现在必须处理以下问题：
- 增加数据量-这将需要从数据仓库中的严格治理和繁重建模转移到可存储数据的可控性较低的数据湖环境。存储如此多数据的成本也成为管理的一大挑战。
- 新型数据-出现了新型数据，如文本、图像或音频。当时的大多数组织甚至不知道如何利用这些非结构化数据。
- 更多的业务用例-组织现在可以利用大量和新类型的数据来构建更准确的模型，以改进决策系统。NLP、计算机视觉和推荐系统变得更容易被所有组织访问。
现代数据堆栈
面对新的挑战，数据堆栈不得不发展到一个新的状态。这就是现代数据堆栈（MDS）的到来。
MDS最大的成就是向云的转变，从技术角度来看，云使数据更易于访问、恢复和管理。MDS方便了数据收集和接收，支持高速数据流，并以低成本实现了高可扩展性。
MDS是多个工具的集合，这些工具彼此连接在一起，以实现从物理数据到业务见解的主动流。
它们的特点是在云中的简单部署、可扩展性和基于组件的特性。每种工具都解决了数据方面的不同挑战，如计算和存储的分离（Snowflake、DataBricks）、数据沿袭（Stemma、Alation）、转换（dbt）、作业编排（Airflow、Prefect）、模式管理（Protobuf）、流式处理（Kafka）、监控（Monte Carlos、Bigeye）等等。
出现了哪些问题？
MDS是作为一组断开连接的工具出现的，它们将重型管道和数据转储发送到中央湖泊，在各个行业造成了难以管理的数据沼泽。这些工具从来不是为了在整个数据价值链中协同工作而构建的。
此外，数据已经超过了为高管提供仪表板的最初用例，并在短短几年内发展成为数百个模型和仪表板。这导致了一系列问题：
- 随着从不同来源获取数据，理解数据的上下文变得更加困难，因为数据仓库不再是通过数据复制真实世界，实体和表将相互连接。
- 许多数据计划重用具有不同名称的相同数据或引用未维护的表。
- 良好的测试是罕见的。调试很有挑战性。
- 团队很难理解重要数据的真相来源，并开始为导致“数据债务”的特殊问题创建自己的定制表（更多关于未来帖子中的数据债务）。
- 数据团队花费数月时间为ML模型生成特征集、创建度量、运行实验和数据挖掘。
- 关键数据集总是出现故障，缺乏责任感和所有权。
我们正在目睹数据债务的增加，每天要处理的错误越来越多，对数据仓库的控制严重不足，尽管数据仓库是组织中最重要的数据资产，但在过去十年中却失去了重要性。
大多数组织现在都在目睹这些问题，要么是因为他们的数据堆栈已经发展，要么是在他们继续投资于数据之旅的过程中即将目睹这些问题。
现在可以做什么？
现代数据堆栈最终解决了与成本和性能相关的大部分工程挑战，在如何使用数据解决业务问题方面产生了更多问题。
利用数据的主要目标过去和将来都是丰富业务体验和回报，所以这是我们应该关注的。
以下是可以做些什么来减少数据生产和数据消费之间的瓶颈的一些想法：
数据仓库作为所有分析的基础
在从不同来源获取的所有数据之间建立语义映射，将为数据消费者提供真正有效的数据仓库和更好的体验。需要投入更多的时间来了解不同的数据源是如何相互连接并绘制真实世界的。
将软件工程师（SWE）连接到数据工作流
软件工程师生成业务报告、实验和模型中使用的大部分数据。然而，他们不知道自己的数据是如何被消耗的。
数据工程师最终成为了中间商团队，他们花更多的时间修复管道，因为上游（后端或前端服务）发生了变化，而不是创造新的管道来推动商业机会。也就是说，在这个过程中需要发生一些变化：
- 数据契约第一-数据契约是对数据的期望。这些期望可以是业务意义、数据质量或数据安全和治理的形式。这可确保数据工程师了解上游数据，避免因上游变化而导致管道中断。
- 深入数据生成生命周期的工程设计-工程团队需要了解他们正在生成的数据将如何用于下游流程。这将确保他们在规划变更时考虑到这一点。
- 数据质量由工程团队所有，因为他们是产生数据的人，至少在数据加载到湖中之前是这样。
更接近业务环境的数据工程
数据工程师负责建立和管理数据平台及其工作流程。他们充当软件工程师、数据科学家和分析师之间的中间人。然而，大多数时候，他们都在构建管道，既没有业务背景，也不知道他们交付的表格的最终目标。
如果没有业务上下文，数据工程师就无法理解不同的数据点应该如何连接，也无法构建映射到现实世界的数据仓库。
数据产品思维
数据团队需要确保他们正在构建的数据产品能够解决真正的用户问题。仅仅从技术角度处理数据产品已经不够了。确保数据产品和用户之间的市场匹配问题必须成为数据工作流程的一部分。
你可以在我之前的文章中阅读更多关于数据产品思维的内容：
新的数据建模框架
传统的数据建模面临着高治理、非常严格的流程、不容易迭代以及更长的洞察时间等挑战。数据建模设计在数据受到控制的时候工作得很好，团队可以确保摄入的数据符合特定的模式。
但随着数据量和数据源的增加，应用数据建模变得越来越困难，这就是数据仓库开始失去其主要用途的时候。
数据生态系统需要考虑现代数据堆栈的数据建模2.0。去中心化的数据体系结构，即数据跨域分布，可以解决这个问题。
定义数据治理策略
过去几十年来，对数据举措的大部分投资都集中在更多更好的技术上。在流程和数据管理方面投入的时间不多。以下是一些确保数据得到有效、安全和合乎道德管理的做法：
- 数据所有权-谁拥有并负责特定数据。这确保了数据所有权和问责制。
- 数据质量标准-确保数据准确、完整、一致和及时的一套标准。此标准可确保数据的可靠性和可信赖性。
- 数据目录—组织内所有数据产品的存储库，为元数据、文档和数据沿袭提供了一个位置，使其更容易发现、理解和使用数据。
- 数据策略和过程-一组过程，用于定义应如何在组织中收集、存储、处理、验证和使用数据。
- 数据行-提供对数据来源和移动的清晰理解。
数据网格是一个有效的解决方案吗？
在我看来，最重要的不是框架，而是我们确保数据能够成功丰富业务的能力。
数据网格涵盖了我在本文中提到的几个挑战，但它并不是所有问题的解决方案，也不可能适用于所有闭着眼睛的组织。此外，它在早期是一个框架，随着企业开始采用它，对数据网格的真正含义的调整将开始出现。
最后，尽管我对现代数据堆栈的看法似乎是负面的，但我对数据行业的未来以及我们适应和改进的能力非常乐观。
