杏彩体育:谈谈如何搭建数据平台以及演进趋势

2024-04-29 05:21:35   来源:杏彩体育投注网 作者:杏彩体育投注网官网 1

  在当今时代,IT组织正在努力应对数据复杂性和规模呈指数级增长的问题,其特点是三个V:数量、速度和...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  确定要实施的初始服务取决于您组织的当前优先事项。例如,在金融服务和制药等监管合规性至关重要的行业,主要重点可能是加强数据治理服务。然而,对于其他企业来说,这可能不是一个紧迫的问题。挑战在于辨别路线图、查明具有重大潜在影响的领域,并根据投资回报(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是主要的技术元数据目录。对于与业务相关的元数。