在当今时代，IT组织正在努力应对数据复杂性和规模呈指数级增长的问题，其特点是三个V：数量、速度和多样性。市场的快速而持续的变化使这一挑战变得更复杂，需要灵活地适应一直在变化的业务目标。现在，比以往任何一个时间里都更需要数据驱动的决策。高质量和及时的见解不单单是奢侈品，而且是明智的决策和行动的必需品。
为了满足这一迫切需求，数据管理者需要加速提供卓越的分析。这需要在不影响质量的情况下最大限度地缩短数据产品的上市时间。我们应该坚实的技术基础来依靠它来大规模实现这一目标。
在一次对某化工企业参观期间，我对其效率和自动化感到震惊。尽管每天生产超过万吨的产品，但工厂车间的人员却出人意料地稀少。其运营效率的关键不在于孤立的自动化，而在于每个组件相互补充的互连系统。
这种整体方法在各个行业中引起共鸣，每个行业都有其独特的要求，但共享与领域无关的基础服务——工业控制管理系统、库存和仓库管理、人力资源和法律服务等等。例如，扩大工厂的规模不仅仅是购买更大的制造设备。它涉及同步各种流程——包装、分销和工艺——以消除瓶颈。
同样，在数据管理领域，仅仅添加新的数据库或ETL工具并不是灵丹妙药。我们应该的是一个数据平台——一个与领域无关的服务的集成良好的集合，用于处理数据摄取、集成、转换、管理和数据交付。该平台专为模块化、灵活性和成本效益而设计。其基本功能是支持高级分析，与事务系统不同。该平台标志着从单一或孤立架构到联合分布式系统的范式转变。
虽然Databricks等多家供应商声称提供全面的解决方案，但这一些平台往往不足以满足所有实际的需求。使这些预构建的系统适应特定业务流程的复杂性可能很复杂，并且某些服务的质量可能不一致。
例如，我们来看看Databricks平台。虽然核心Spark运行时和Delta表是最先进的，但平台的其余部分却不是。由于其多云最小公分母设计，Databricks面临着与本机服务集成的挑战，例如监控和编排。安全模型非常不一致，难以实施和支持。此外，它的数据目录功能并不总是与Collibra或Alation等专业解决方案相提并论。
鉴于数据类型的多样性和业务特定需求，构建一刀切的数据平台不仅仅具备挑战性，而且成本高昂。相反，数据平台应被视为概念蓝图，通过基于云的组件或本地服务来实现。
无论部署模型如何，每个数据平台都包含五个关键的松散耦合模块：数据摄取、存储、数据转换、数据服务和通用补充服务。这些模块依赖于提供网络和计算等基本功能的基础设施。
任何数据平台架构中不可或缺的部分是其存储子系统，其任务是以批处理或流传输模式保护数据以实现长期可访问性。该层通常是多层的，可满足多种的性价比要求：
低延迟存储：专为“热”数据和缓存存储而设计，该层第一先考虑速度，但对于较大的数据量可能成本过高。
对象或文件存储：该层适合经济地存储大量数据并提供高吞吐量，但可能会产生延迟权衡。
可靠性：承受故障至关重要。根据恢复点目标(RPO)和恢复时间目标(RTO)考虑因素，系统在大多数情况下要跨多个位置的冗余和自动数据复制。
可扩展性和成本效益：容量规划和存储采购方面的早期挑战已将重点转向弹性且经济的存储解决方案。
性能：以高吞吐量或低延迟提供数据，特别是在大量负载下，是不可协商的要求。
集成和可观察性：与通用服务的兼容性以及强大的可观察性和审计功能至关重要。
基于对象的存储：将商用硬件与MinIO或Ceph架构结合使用可以产生可扩展的存储。
供应商特定的解决方案：供应商提供专为大规模数据管理量身定制的专业存储解决方案。
数据摄取层作为平台的网关发挥着关键作用，从一系列外部源摄取数据并安全地保存数据以供经常使用。为了保持数据完整性，应以尽可能接近其原始状态的形式捕获信息。
批量数据：源自结构化来源，例如外部供应商或内部交易系统。能够最终靠将数据从预定义位置（例如FTP服务器）移动到存储子系统或直接连接到外部系统来加载和保存数据来摄取数据。摄取过程可以是预定的，也可以是事件触发的。
流数据：作为事件或数据点的连续源到达，通常在物联网(IoT)场景或变更数据捕获(CDC)事件中。数据可以存储为流、文件，或者在CDC的情况下，存储在内部数据库中的复制事务。
元数据收集：创建并注册详细的元数据，包括有关数据的信息（源、格式、维度、大小、快照版本）和提取过程（版本、请求参数、开始和结束时间戳、连接详情信息）。
流程可观察性：记录流程状态、数据吞吐量和延迟等基本指标，以实现全面监控。
监控和警报：持续监督活动数据摄取流程，以识别故障、连接问题和性能偏差，并在需要时触发警报。
流媒体服务：Kafka受到普遍支持，而GCPPub/Sub或AWSKinesis等云原生解决方案也提供了强大的选项。
自定义解决方案：使用Kubernetes等容器编排平台或AWSLambda等无服务器函数部署自定义代码。
无论选择哪种工具，都必须有一个统一的实施蓝图来强制执行商定的模式，例如内置元数据管理。
如果存储是数据平台的核心，那么数据转换层无疑是其智能中心。在这里，原始数据经过业务逻辑的转换、塑造和提炼，成为可供使用的数据产品。无论是处理批处理、临时转换还是近实时数据流，这一层都至关重要。
可观察性和指标：确保系统透明度并提供一致的元数据、性能指标和关键绩效指标(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等云原生服务在实时数据处理方面表现出色。
数据服务组件是数据产品生命周期的最后阶段，有助于将数据产品安全高效地交付给内部或外部消费者。该组件应该是多功能的，能够完全满足不同的业务需求，适应不一样的数据格式、容量和访问模式。具体来说，应该是：
关系数据库，如PostgreSQL、MySQL或Oracle，用于低延迟、高选择性查询。
直接访问：通过特定于服务的API，例如ODBC、JDBC、sFTP、SMTP或S3。这些最常被内部或让人信服的消费者使用。
产品特定的API：通过REST、gRPC或GraphQL等现代协议。这些能够正常的使用API网关和无服务器或容器化功能来实现。
虽然这些服务并不处于数据转换和获取的最前沿，但它们充当将数据平台集成为一个整体的有凝聚力的结构。
开发框架：提供可重用的组件和指南，提供常见的功能，确保与平台服务的顺利集成。为DevOps管道提供标准模板。减少样板代码，促进新小组成员的入职，并简化数据摄取和转换管道的开发。
技术元数据收集：用于收集和分析数据平台组件状态的一致方法，例如数据管道的执行状态和版本、数据对象、可用性、系统参数等。启用不同部分之间的依赖关系跟踪例如，用于触发数据重新处理。
性能指标：监控平台的健康指标，例如CPU使用率、网络活动和系统故障。这有利于事后分析和性能优化。
事件处理和通知：为异步、事件驱动的数据处理奠定基础。实现平台环境可观察性、复杂事件处理、基于事件的调度以及通知消息的系统范围分发。
探索环境：为数据专业技术人员提供直观的自助服务工作区，用于处理数据发现和分析、产品原型设计和机器学习模型开发。
日志记录：用于内部流程日志记录和分析的内聚框架，支持主动系统监控和警报生成。
DevOps：CI/CD、可编写脚本的基础设施和自助服务配置的统一方法。
数据目录：集中技术和业务元数据，提供有关数据格式、质量、沿袭、所有权、数据产品SLA和SLO、数据质量属性、常见统计数据、数据分类、保留和归档要求等的广泛详情信息。促进数据产品发现和采样。
数据保护：与身份和访问管理集成，防止没有经过授权的数据访问。监督安全策略、加密技术和标记。
数据质量和数据治理：用于数据分析、保留、合规性和质量相关警报的综合框架。
主数据和参考数据管理：确保跨域数据标准化和协调。监督企业范围的参考数据。
本体和知识图：建立标准化的组织业务术语，阐明各种概念和实体之间错综复杂的关系。集成推理引擎，促进高级数据检索并跨域连接数据。促进属性的声明性验证、上下文和概念的映射以及策略规则的简化解析。
审计和监控：用于平台健康检查、合规性审计、日志分析、警报生成、合规性访问审计、事后日志分析和活动跟踪的统一系统。
DataOps：简化数据生命周期，包括备份和数据归档、异常检测和数据流监控
数据平台是大规模构建数据产品的强大工具。然而，创建最先进平台的旅程并不是特别需要立即使用最先进的工具和系统。与此类似，人们不需要一辆高性能跑车来日常购物。拥抱增量增长战略，同时始终牢记最终目标，可能是构建强大而高效的平台的关键。
确定要实施的初始服务取决于您组织的当前优先事项。例如，在金融服务和制药等监管合规性至关重要的行业，主要重点可能是加强数据治理服务。然而，对其他企业来说，这可能不是一个紧迫的问题。挑战在于辨别路线图、查明具有重大潜在影响的领域，并根据投资回报(ROI)不断调整决策。由于组织目标会跟着时间的推移而发生明显的变化，因此将平台开发锚定在普遍认可的根本原则（例如渐进式架构和关注点分离）中变得至关重要。
同样重要的是平台发展中的人性化因素。监控平台的采用并确保其在组织内的有效利用至关重要。必须与用户建立持续的反馈循环，以确保平台根据他们的需求和期望持续不断的发展。毕竟，如果仍未得到充分的利用，即使是最先进的平台也会变得多余。第一先考虑用户体验并提供全面的培训可以弥补这一差距。
从传统的孤立IT运营到与领域无关的服务和数据产品导向的转变最初可能看起来令人畏惧。因此，将组织变革管理深思熟虑地整合到数据平台的增长轨迹中是必不可少的。
一家成熟的金融服务企业必须努力维护市场诚信。其重要任务之一是对可能暗示内幕交易的可疑交易活动进行细致调查。这通常涉及观察重大市场新闻公开之前执行的交易。
公司的交易平台：这个历史悠远长久的系统是用Cobol编写的，在IBM大型机上运行。由于过渡到新平台的成本高昂，该公司继续维护它。交易从该平台提取，从EBCDIC转换为ASCII，然后以CSV文件形式保存在公司数据中心内的指定位置。
外部新闻聚合器：该服务使订户能够及时访问精选的公共信息，包括新闻稿、季度收益报告和各种新闻提要。能够最终靠FTP站点以JSON文件形式获取最新更新。
如果交易符合特定标准，则对其进行标记：它们是在新闻发布前的预定时间范围内执行的，并且它们的方向（买入或卖出）与新闻的基调相对应。
现有的基础设施难以有效地处理从内部交易系统和外部新闻来源收集的大量数据。
他们传统的基于规则的方法常常无法准确地查明内幕交易的情况。未解决这个问题，人们正在不断努力整合机器学习模型。这些模型旨在使用历史数据预测交易，并将其与新出现的新闻并列，以确保警报系统更加精确。
虽然Azure和GCP提供了强大的解决方案，但我们将概述使用AWS服务的数据平台的基本设计，以满足金融公司的需求。
AWSS3是一种高度可扩展的存储解决方案，适合存储大量交易数据和新闻源。存储设计具有三个不同的区域：
登陆区域：此临时区域与本地应用程序接口。它充当新执行的交易批次的初始下降点。每当此处上传新文件时，都会触发Lambda函数，向EventBridge发送通知消息。
准备好的数据：这里保留转换后的贸易数据、处理后的材料事件和警报，并将数据存储在高效的Parquet文件中。
Kubernetes服务：此服务中的容器化应用程序与新闻聚合器的sFTP站点进行交互。他们下载最新的数据块并将其放置在原始数据区域中以供后续处理。
使用AWSGlue（一种在Spark上运行的完全托管的ETL服务），原始贸易数据和新闻将转换为合规性报告。结合机器学习模型，Glue能够准确的通过某些交易的模式和时间将其标记为潜在可疑交易。
AWSAthena是一种无服务器解决方案，充当PowerBI报告工具的后端。它可使用标准SQL快速分析S3中的数据，以此来实现动态、快速的报告生成。
数据目录：GlueCatalog是主要的技术元数据目录。对于与业务相关的元数据，Collibra数据目录无缝集成。
AWSIdentityandAccessManagement：指定谁或什么可以访问AWS中的服务和资源，集中管理细粒度权限，并分析访问权限以细化整个数据平台的权限。
AWSStepFunctions：该服务管理数据提取和转换过程中的多个操作流。它能够准确的通过时间表或在收到特定通知事件时工作。
Lambda函数：这些函数管理目录中新数据工件的注册。它们还处理数据管道的状态报告，并对错误或不一致发出警报。
DynamoDB：存储操作元数据和系统参数至关重要。DynamoDB就是用于此目的，提供快速访问和可靠的存储。
ElasticSearch和Grafana：这些工具共同提供强大的日志分析功能，Grafana通过操作仪表板促进可视化。