谈谈如何搭建数据平台以及演进趋势

在当今时代，IT组织正在努力应对数据复杂性和规模呈指数级增长的问题，其特点是三个V：数量、速度和多样性。市场的快速而持续的变化使这一挑战变得更加复杂，需要灵活地适应不断变化的业务目标。现在，比以往任何时候都更需要数据驱动的决策。高质量和及时的见解不仅仅是奢侈品，而且是明智的决策和行动的必需品。

为了满足这一迫切需求，数据管理者需要加速提供卓越的分析。这需要在不影响质量的情况下最大限度地缩短数据产品的上市时间。我们需要坚实的技术基础来依靠它来大规模实现这一目标。

一什么是数据平台

在一次对某化工企业参观期间，我对其效率和自动化感到震惊。尽管每天生产超过万吨的产品，但工厂车间的人员却出人意料地稀少。其运营效率的关键不在于孤立的自动化，而在于每个组件相互补充的互连系统。

这种整体方法在各个行业中引起共鸣，每个行业都有其独特的要求，但共享与领域无关的基础服务——工业控制系统、库存和仓库管理、人力资源和法律服务等等。例如，扩大工厂的规模不仅仅是购买更大的制造设备。它涉及同步各种流程——包装、分销和工艺——以消除瓶颈。

同样，在数据管理领域，仅仅添加新的数据库或ETL工具并不是灵丹妙药。我们需要的是一个数据平台——一个与领域无关的服务的集成良好的集合，用于处理数据摄取、集成、转换、管理和数据交付。该平台专为模块化、灵活性和成本效益而设计。其主要功能是支持高级分析，与事务系统不同。该平台标志着从单一或孤立架构到联合分布式系统的范式转变。

虽然Databricks等多家供应商声称提供全面的解决方案，但这些平台往往无法满足所有实际需求。使这些预构建的系统适应特定业务流程的复杂性可能很复杂，并且某些服务的质量可能不一致。

例如，我们来看看Databricks平台。虽然核心Spark运行时和Delta表是最先进的，但平台的其余部分却不是。由于其多云最小公分母设计，Databricks面临着与本机服务集成的挑战，例如监控和编排。安全模型非常不一致，难以实施和支持。此外，它的数据目录功能并不总是与Collibra或Alation等专业解决方案相提并论。

鉴于数据类型的多样性和业务特定需求，构建一刀切的数据平台不仅具有挑战性，而且成本高昂。相反，数据平台应被视为概念蓝图，通过基于云的组件或本地服务来实现。

无论部署模型如何，每个数据平台都包含五个关键的松散耦合模块：数据摄取、存储、数据转换、数据服务和通用补充服务。这些模块依赖于提供网络和计算等基本功能的基础设施。

二数据存储：数据平台的基石

任何数据平台架构中不可或缺的部分是其存储子系统，其任务是以批处理或流传输模式保护数据以实现长期可访问性。该层通常是多层的，可满足不同的性价比要求：

低延迟存储：专为“热”数据和缓存存储而设计，该层优先考虑速度，但对于较大的数据量可能成本过高。

对象或文件存储：该层适合经济地存储大量数据并提供高吞吐量，但可能会产生延迟权衡。

档案存储：该层针对成本进行了优化，旨在长期保留大量数据。

一个有效的存储层应该体现以下属性：

可靠性：承受故障至关重要。根据恢复点目标(RPO)和恢复时间目标(RTO)考虑因素，系统可能需要跨多个位置的冗余和自动数据复制。

可扩展性和成本效益：容量规划和存储采购方面的早期挑战已将重点转向弹性且经济的存储解决方案。

性能：以高吞吐量或低延迟提供数据，特别是在大量负载下，是不可协商的要求。

安全性：应严格执行授权访问，通常需要静态透明加密。

集成和可观察性：与通用服务的兼容性以及强大的可观察性和审计功能至关重要。

对于本地环境，可以使用多种途径：

混合基础设施：可以利用AzureStack或AWSOutposts等解决方案。

基于对象的存储：将商用硬件与MinIO或Ceph架构结合使用可以产生可扩展的存储。

基于Hadoop的数据湖：Hadoop集群可以成为强大的数据湖基础。

供应商特定的解决方案：供应商提供专为大规模数据管理量身定制的专业存储解决方案。

三数据摄取：数据平台的网关

数据摄取层作为平台的网关发挥着关键作用，从一系列外部源摄取数据并安全地保存数据以供长期使用。为了保持数据完整性，应以尽可能接近其原始状态的形式捕获信息。

数据源有两种：

批量数据：源自结构化来源，例如外部供应商或内部交易系统。可以通过将数据从预定义位置（例如FTP服务器）移动到存储子系统或直接连接到外部系统来加载和保存数据来摄取数据。摄取过程可以是预定的，也可以是事件触发的。

流数据：作为事件或数据点的连续源到达，通常在物联网(IoT)场景或变更数据捕获(CDC)事件中。数据可以存储为流、文件，或者在CDC的情况下，存储在内部数据库中的复制事务。

除了基本的数据传输之外，摄取组件还应该提供：

元数据收集：创建并注册详细的元数据，包括有关数据的信息（源、格式、维度、大小、快照版本）和提取过程（版本、请求参数、开始和结束时间戳、连接详细信息）。

流程可观察性：记录流程状态、数据吞吐量和延迟等基本指标，以实现全面监控。

监控和警报：持续监督活动数据摄取流程，以识别故障、连接问题和性能偏差，并在需要时触发警报。

通知下游系统：当新数据可用时通知后续流程。

有多种工具可用于构建强大的数据摄取框架：

传统ETL工具：Informatica、Pentaho和Matillion等既定解决方案仍然具有相关性。

特定于云平台的服务：AWS数据迁移服务或Azure数据工厂等产品。

流媒体服务：Kafka受到普遍支持，而GCPPub/Sub或AWSKinesis等云原生解决方案也提供了强大的选项。

自定义解决方案：使用Kubernetes等容器编排平台或AWSLambda等无服务器函数部署自定义代码。

无论选择哪种工具，都必须有一个统一的实施蓝图来强制执行商定的模式，例如内置元数据管理。

四数据转换：数据平台的认知引擎

如果存储是数据平台的核心，那么数据转换层无疑是其智能中心。在这里，原始数据经过业务逻辑的转换、塑造和提炼，成为可供使用的数据产品。无论是处理批处理、临时转换还是近实时数据流，这一层都至关重要。

一个成熟的数据转换组件应具备以下品质：

弹性可扩展性：能够处理从小到大的数据量。

数据类型多功能性：精通批处理和流数据处理。

迭代转换支持：对于机器学习(ML)模型训练至关重要。

编排和执行：利用通用服务进行流程编排以及计划和事件触发的执行。

可观察性和指标：确保系统透明度并提供一致的元数据、性能指标和关键绩效指标(KPI)

数据转换管道可以通过多种工具执行，每种工具都有自己的一套权衡：

图形ETL工具：Informatica、DataStage和AzureADF等解决方案提供用于构建数据管道的图形界面。然而，它们通常无法满足复杂的数据处理需求和自定义代码要求，并阻碍标准CI/CD流程。利用大数据技术的SaaS平台旨在解决这些问题，但并不总是成功。

MPP数据库：Redshift、BigQuery和Snowflake等平台可以充当执行引擎，其中自定义ELT脚本可以在Kubernetes等容器化环境中运行或作为无服务器函数运行。

基于Spark的系统：Databricks和AWSGlue等选项为数据转换提供了一个强大的基于Spark的环境。

机器学习管道：对于ML模型的结果，可以使用Spark、TensorFlow和Kubernetes等技术构建复杂的管道。

流数据服务：Kafka流、Spark结构化流等解决方案或GCPDataflow等云原生服务在实时数据处理方面表现出色。

五数据服务：数据平台的交付部门

数据服务组件是数据产品生命周期的最后阶段，有助于将数据产品安全高效地交付给内部或外部消费者。该组件应该是多功能的，可以满足不同的业务需求，适应不同的数据格式、容量和访问模式。具体来说，应该是：

安全：确保只有授权用户才能访问。

可观察：记录和审核所有合规和监控请求。

可扩展且可靠：即使需求波动，也能保持指定的服务质量。

可重现：支持时间点查询和/或在数据更改时提供对不可变数据快照的访问。

数据产品可以以多种形式具体化：

文件：

标准格式（例如CSV、JSON、Excel、Parquet或XML）的结构化数据文件。

BI工具的专用文件，例如Tableau断开连接的数据集。

非结构化或半结构化文档，例如Excel、Word或PDF报告。

二进制文件，例如图像、音频或视频。

采用ONNX等开放交换格式的ML模型。

相关数据：

关系数据库，如PostgreSQL、MySQL或Oracle，用于低延迟、高选择性查询。

Redshift、Snowflake或Teradata等企业数据仓库平台内的数据集市支持BI工具和OLAP查询。

基于数据湖的平台，如Databricks、Athena或Starburst，用于高级分析和机器学习。

专业产品：

用于连接数据和知识图的图数据库

时间序列数据库

支持地理空间数据、化学信息学、生物信息学和组学数据的专业数据库

全文搜索索引和文档存储库

适用于半结构化数据的NoSQL数据库，例如DynamoDB、CosmosDB或Cassandra

流媒体和通知：

高吞吐量消息代理，例如Kafka、GCPPubSub、AWSKinesis、AzureEventHub

面向消息的中间件或企业服务总线。

数据产品通常可以通过以下两种方式之一访问：

直接访问：通过特定于服务的API，例如ODBC、JDBC、sFTP、SMTP或S3。这些最常被内部或值得信赖的消费者使用。

产品特定的API：通过REST、gRPC或GraphQL等现代协议。这些可以使用API网关和无服务器或容器化功能来实现。

六通用补充服务：将数据平台缝合在一起

虽然这些服务并不处于数据转换和获取的最前沿，但它们充当将数据平台集成为一个整体的有凝聚力的结构。

开发支持

开发框架：提供可重用的组件和指南，提供常见的功能，确保与平台服务的顺利集成。为DevOps管道提供标准模板。减少样板代码，促进新团队成员的入职，并简化数据摄取和转换管道的开发。

技术元数据收集：用于收集和分析数据平台组件状态的一致方法，例如数据管道的执行状态和版本、数据对象、可用性、系统参数等。启用不同部分之间的依赖关系跟踪例如，用于触发数据重新处理。

性能指标：监控平台的健康指标，例如CPU使用率、网络活动和系统故障。这有利于事后分析和性能优化。

ML训练：建立统一的方法或模型训练和质量指标收集。

事件处理和通知：为异步、事件驱动的数据处理奠定基础。实现平台环境可观察性、复杂事件处理、基于事件的调度以及通知消息的系统范围分发。

探索环境：为数据专业人员提供直观的自助服务工作区，用于处理数据发现和分析、产品原型设计和机器学习模型开发。

日志记录：用于内部流程日志记录和分析的内聚框架，支持主动系统监控和警报生成。

DevOps：CI/CD、可编写脚本的基础设施和自助服务配置的统一方法。

治理

数据目录：集中技术和业务元数据，提供有关数据格式、质量、沿袭、所有权、数据产品SLA和SLO、数据质量属性、常见统计数据、数据分类、保留和归档要求等的广泛详细信息。促进数据产品发现和采样。

数据保护：与身份和访问管理集成，防止未经授权的数据访问。监督安全策略、加密技术和标记。

数据质量和数据治理：用于数据分析、保留、合规性和质量相关警报的综合框架。

主数据和参考数据管理：确保跨域数据标准化和协调。监督企业范围的参考数据。

本体和知识图：建立标准化的组织业务术语，阐明各种概念和实体之间错综复杂的关系。集成推理引擎，促进高级数据检索并跨域连接数据。促进属性的声明性验证、上下文和概念的映射以及策略规则的简化解析。

运营

流程编排：促进复杂的管道调度、工作流程设计、故障管理和重试机制。

审计和监控：用于平台健康检查、合规性审计、日志分析、警报生成、合规性访问审计、事后日志分析和活动跟踪的统一系统。

DataOps：简化数据生命周期，包括备份和数据归档、异常检测和数据流监控

MLOps：自动化ML模型生命周期，强调性能监控、数据和概念漂移检测。

七数据平台的演变：应对增长和复杂性

数据平台是大规模构建数据产品的强大工具。然而，创建最先进平台的旅程并不需要立即使用最先进的工具和系统。与此类似，人们不需要一辆高性能跑车来日常购物。拥抱增量增长战略，同时始终牢记最终目标，可能是构建强大而高效的平台的关键。

确定要实施的初始服务取决于您组织的当前优先事项。例如，在金融服务和制药等监管合规性至关重要的行业，主要重点可能是加强数据治理服务。然而，对于其他企业来说，这可能不是一个紧迫的问题。挑战在于辨别路线图、查明具有重大潜在影响的领域，并根据投资回报(ROI)不断调整决策。由于组织目标会随着时间的推移而发生变化，因此将平台开发锚定在普遍认可的基本原则（例如渐进式架构和关注点分离）中变得至关重要。

同样重要的是平台发展中的人性化因素。监控平台的采用并确保其在组织内的有效利用至关重要。必须与用户建立持续的反馈循环，以确保平台根据他们的需求和期望不断发展。毕竟，如果仍未得到充分利用，即使是最先进的平台也会变得多余。优先考虑用户体验并提供全面的培训可以弥补这一差距。

从传统的孤立IT运营到与领域无关的服务和数据产品导向的转变最初可能看起来令人畏惧。因此，将组织变革管理深思熟虑地整合到数据平台的增长轨迹中是必不可少的。

八案例研究：使用AWS实现财务合规报告现代化

背景

一家成熟的金融服务公司必须努力维护市场诚信。其重要任务之一是对可能暗示内幕交易的可疑交易活动进行细致调查。这通常涉及观察重大市场新闻公开之前执行的交易。

每日“重大事件前交易”报告利用两个主要来源的数据：

公司的交易平台：这个历史悠久的系统是用Cobol编写的，在IBM大型机上运行。由于过渡到新平台的成本高昂，该公司继续维护它。交易从该平台提取，从EBCDIC转换为ASCII，然后以CSV文件形式保存在公司数据中心内的指定位置。

外部新闻聚合器：该服务使订户能够及时访问精选的公共信息，包括新闻稿、季度收益报告和各种新闻提要。可以通过FTP站点以JSON文件形式获取最新更新。

识别潜在内幕交易的过程包括：

从聚合的新闻提要中提取相关的“重大事件”。

将这些事件与最近的交易进行比较，强调那些在关键信息公开之前发生的事件。

如果交易符合特定标准，则对其进行标记：它们是在新闻发布前的预定时间范围内执行的，并且它们的方向（买入或卖出）与新闻的基调相对应。

然而，该公司面临着重大挑战：

现有的基础设施难以有效地处理从内部交易系统和外部新闻来源收集的大量数据。

他们传统的基于规则的方法常常无法准确地查明内幕交易的情况。为了解决这个问题，人们正在不断努力整合机器学习模型。这些模型旨在使用历史数据预测交易，并将其与新出现的新闻并列，以确保警报系统更加精确。

目标

尽管数据量不断增加，但仍确保及时处理报告。

从脆弱的基于规则的系统过渡到用于警报评估的机器学习模型。

将解决方案无缝集成到正在进行的云过渡中。

基于AWS的平台

虽然Azure和GCP提供了强大的解决方案，但我们将概述使用AWS服务的数据平台的基本设计，以满足金融公司的需求。

数据存储

AWSS3是一种高度可扩展的存储解决方案，适合存储大量交易数据和新闻源。存储设计具有三个不同的区域：

登陆区域：此临时区域与本地应用程序接口。它充当新执行的交易批次的初始下降点。每当此处上传新文件时，都会触发Lambda函数，向EventBridge发送通知消息。

原始数据：该区域提供长期存储，以原始格式保存贸易历史和新闻提要

准备好的数据：这里保留转换后的贸易数据、处理后的材料事件和警报，并将数据存储在高效的Parquet文件中。

数据摄取

Lambda：它将交易数据从瞬态登陆区重新定位到原始数据区。

Kubernetes服务：此服务中的容器化应用程序与新闻聚合器的sFTP站点进行交互。他们下载最新的数据块并将其放置在原始数据区域中以供后续处理。

数据转换

使用AWSGlue（一种在Spark上运行的完全托管的ETL服务），原始贸易数据和新闻将转换为合规性报告。结合机器学习模型，Glue可以根据某些交易的模式和时间将其标记为潜在可疑交易。

数据服务

AWSAthena是一种无服务器解决方案，充当PowerBI报告工具的后端。它能够使用标准SQL快速分析S3中的数据，从而实现动态、快速的报告生成。

常见补充服务

为了支持整体数据流程，多项支持服务与该平台集成：

数据目录：GlueCatalog是主要的技术元数据目录。对于与业务相关的元数据，Collibra数据目录无缝集成。

AWSIdentityandAccessManagement：指定谁或什么可以访问AWS中的服务和资源，集中管理细粒度权限，并分析访问权限以细化整个数据平台的权限。

AWSStepFunctions：该服务管理数据提取和转换过程中的多个操作流。它可以根据时间表或在收到特定通知事件时工作。

Lambda函数：这些函数管理目录中新数据工件的注册。它们还处理数据管道的状态报告，并对错误或不一致发出警报。

DynamoDB：存储操作元数据和系统参数至关重要。DynamoDB就是用于此目的，提供快速访问和可靠的存储。

ElasticSearch和Grafana：这些工具共同提供强大的日志分析功能，Grafana通过操作仪表板促进可视化。

本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。

该文观点仅代表作者本人，36氪平台仅提供信息存储空间服务。