如何评估组织的数据平台

公司和组织生成数据,并越来越多地使用这些数据来生成其他值。虽然传统上这是工商管理分析师的任务,但今天的数据在组织的各个方面和部门中都发挥着重要作用。为了使公司能够实现这一变革,需要一种高效的长期数据架构。在这里,我们将讨论构建此类数据架构需要解决的许多方面和技术挑战。

本文的动机来自于观察到数据平台经常被简化为数据库组件,这是整个数据生命周期的过度简化。我们希望说明公司中基本的长期数据策略所需的功能量。

什么是数据平台?

数据平台是一种允许您摄取,处理,存储,访问,分析和呈现数据的服务。这些被认为是我们称之为数据平台的定义特征。该平台可以分解为以下部分:

  • 数据仓库:摄取,处理,存储,访问。
  • 商业智能:分析和呈现。
  • 数据科学:统计学和人工智能(一种特殊的分析形式)。

虽然存储和处理数据是数据平台的核心,但它并不止于此。为了更好地了解整体数据管理任务,我们编制了一份有关整个数据工程和分析生命周期的17个标准的列表。

  1. 数据架构(基础架构,扩展,数据库)
  2. 导入接口
  3. 数据转换(ETL)
  4. 性能
  5. 过程自动化
  6. 监控
  7. 数据历史化
  8. 数据版本控制
  9. 代理密钥管理
  10. 分析/报告
  11. 数据科学工作区
  12. 外部访问/ API
  13. 可用性
  14. 多用户开发过程
  15. 平台文档
  16. 文档
  17. 安全
  18. 成本

在以下部分中,我们将简要介绍这些标准,但不会过多介绍技术细节。

1.数据架构

核心数据架构是数据平台架构中最重要的方面之一,但到目前为止还不是唯一的一个。目标是找到合适的存储和数据库解决方案以满足您的要求。有三种基本选项可供选择,对以下所有其他主题产生影响:

关系型数据库

非常成熟的数据库系统,具有大量内置智能,可高效处理大型数据集。这些系统具有最具表现力的分析工具,但在维护方面往往更为复杂。如今,这些系统也可作为分布式系统使用,并且可以处理极大的数据集。例如PostgreSQL与Citus或Greenplum集群解决方案,MariaDB / MySQL与Galera集群,Amazon Redshift,Oracle,MSSQL,......

NoSQL样式分片数据库

这些系统牺牲了关系数据库的一些经典特性,以便在其他领域获得更多功能。这些系统本身提供的分析能力要低得多,但更易于管理,具有高可用性和易于备份。它们旨在处理极大的数据集。有人试图模仿关系数据库世界中可用的SQL的分析能力,并使用顶层工具(Impala,Hive)。如果您有大量数据或流媒体或实时数据的特定要求,您应该查看这些专业数据系统。例如Cassandra,Hadoop Ecosystem,Elasicsearch,Druid,MongoDB,Kudu,InfluxDB,Kafka,neo4j和Dgraph。

基于文件的系统

可以仅根据文件设计数据策略。像Parquet文件标准这样的文件结构使您能够使用非常便宜的存储来存储分布在许多存储节点或Amazon S3等云对象存储上的非常大的数据集。主要优点是数据存储系统足以响应数据访问请求。上述两个系统需要在额外的计算节点上运行服务以响应数据查询。使用像Apache Drill这样的解决方案,您可以查询具有与SQL相同的舒适度的镶木地板文件。

在寻找支持所选数据架构的硬件架构时,桌面上会提供一些基本选项。

  1. 您可以依靠主要云供应商提供的服务来尝试构建您的平台。在AWS,Azure或Google Cloud等云平台上,您可以将一系列相当简单的服务连接在一起,以创建涵盖我们的标准列表的数据平台。这可能在小规模上看起来简单而便宜,但是当你向外扩展并且需要定制时,结果会变得非常复杂和昂贵。
  2. 相比之下,存在基于自运行硬件的平台,包括云虚拟机和单独的软件栈。在这里,您可以获得最大的灵活性,但还需要通过创建自己的代码和自定义解决方案来回答列表中的许多条件。
  3. 作为最后一类,我们将提到更完整和专用的独立云数据平台,如Repods,Snowflake,Panoply或Qubole(免责声明:作者来自Repods平台)。这些平台开箱即用地处理我们列表中的或多或少的标准。

2.表现

这个标准通常是平台选择中的一个重要影响者。性能主要受您选择的数据库子系统的影响。根据经验,您的性能要求越高,您的数据库系统选择就越专业化。我们不想详细介绍,而是专注于数据平台中鲜为人知的主题。

3.导入接口

我们将导入接口分为三个不同的部分。

  1. 文件 - 仍然是最常见的数据形式。
  2. 网络服务 - 网上有大量相关数据。
  3. 数据库 - 尽管在许多组织中,大量数据存储在传统数据库中,但在大多数情况下,直接数据库访问不会暴露给Internet,因此无法用于云数据平台。Web服务可以放置在内部部署数据库和云服务之间,以处理安全性方面和访问控制。另一种方法是在安全跳转主机上使用ssh-tunneling 。
  4. 实时流 - 由消息传递路由器(说WAMP,MQTT,AMQP,......)提供的实时数据流,今天使用不多,但随着物联网的兴起,它们将变得更加重要。

4.数据转换ETL

导入数据平台的数据通常必须经过一些数据转换才能用于分析。此过程传统上称为ETL(提取,转换,加载)。这些过程通常从原始数据创建表,分配数据类型,过滤值,连接现有数据,创建派生列/行,并将各种自定义逻辑应用于原始数据。创建和管理ETL过程有时称为数据工程,是任何数据环境中最耗时的任务。在大多数情况下,这项任务占人类总体努力的80%。较大的数据仓库可以包含数千个具有不同阶段和依赖关系以及处理顺序的ETL过程。

5.过程自动化

如果您之间有许多源,目标和数据转换过程,那么您也有许多依赖关系,并且具有一定的运行计划逻辑。流程的自动化是每个数据仓库的一部分,并且涉及很多复杂性。有专门的工具(Apache Airflow,Automate,Control-M,Luigi,......)来处理流程的调度。

流程自动化还要求您管理要处理的数据块的选择,即在增量加载方案中,每次执行流程都需要逐步选择特定的源数据块以传递给目标。这种“数据范围管理”通常由元数据驱动的方法实现,即,存在专用的元数据表,其跟踪每个块的过程状态,并且可以被查询以协调所有块的处理。

6.监测

较大的数据仓库系统可以轻松地包含数百个表,其中有数百个自动ETL过程来管理数据流。在运行时出现的错误几乎是不可避免的,其中许多错误必须通过人工干预来处理。有了这么多的复杂性,你肯定需要一种方法来监控平台上发生的事情。

7.数据历史化

管理更长的数据历史的需求是每个数据仓库工作的核心。事实上,数据仓库任务本身可以概括为将单独的数据块合并为同质数据历史的任务。数据是随着时间的推移自然生成的,因此需要使用新数据增加现有数据库存。为了稳健地管理数据历史,通常使用“数据历史化”。从技术上讲,使用专用时间范围列跟踪表格中的时间范围。这与数据版本控制不同,因为历史记录涉及实际生命时间戳,而版本控制通常涉及技术插入时间戳(参见下面的部分)。

8.数据版本控制

通过版本化数据,您可以随时跟踪数据更正,以便以后恢复旧分析。版本控制允许您对现有数据应用非破坏性更正。在比较版本控制功能时,您必须考虑创建版本的难易程度以及恢复或查询版本的难易程度。版本控制可以在系统的不同级别上处理:

  • 在存储子系统上创建版本快照(类似于备份)。
  • 底层数据库系统可能支持版本跟踪。
  • 版本控制可能由数据仓库系统处理。
  • 版本控制可以作为用户空间中的自定义转换逻辑实现。

9.代理密钥管理

数据仓库用于合并来自许多源的数据,这些源具有相应对象的不同标识符。这要求我们为导入的对象创建新的键范围,并在连续导入中保持它们。这些新密钥称为代理密钥,以有效的方式创建和维护这些密钥并非易事。

10.分析/报告

数据平台的目的是准备用于分析的原始数据并将该数据存储更长的时间。分析可以以多种方式进行。

有许多工具被称为商业智能工具(BI工具),仅涉及创建分析和美观/人类可读数据可视化。为了准备可供使用的数据块进行演示,数据平台提供了从较大的数据库中创建数据提取和聚合的功能。

通过智能查询数据存储来回答特定的业务问题需要大量熟练掌握分析查询语言。BI工具旨在通过提供点击和点击界面来回答基本问题,例如“每月在线商店的访问者数量”或“X区域的收入总和”,从而简化这些任务。这些工具还使用户能够以易于使用的方式可视化信息图形。在几乎所有情况下,高级用户仍然希望能够绕过这些工具并进行自己的查询。BI工具的常用示例有Tabelau,Qlik,Looker,Chartio,Superset等等。

11.数据科学

如今,培训机器学习模型是数据平台必须服务的新要求。使用Python或R以及各种专用库(如NumPy,Pandas,Scikit-learn,TensorFlow,PyTorch或甚至更专业的库进行自然语言处理或图像识别)实现更复杂的方法。

由于这些任务的计算要求很高,因此除了现有的分析硬件之外,还需要额外的计算硬件。虽然这为您提供了大量可供选择的工具,但您再次面临托管和管理计算资源以支持非常苛刻的机器学习工作的挑战。

12.外部访问/ API

平台中收集的所有数据都可用于不同目的。这里考虑的可能渠道是:

  • 用于直接分析或通过BI工具的SQL访问。
  • API访问(REST请求)作为网站或应用程序的服务。
  • 通过推送通知或电子邮件为最终用户或管理员提供的通知。
  • 文件导出以进一步处理或向其他方传送数据。

13.可用性

平台的可用性在很大程度上取决于目标受众。可用性是一个非常广泛和主观的类别,并考虑诸如在平台中创建和管理对象(用户,数据仓库,表格,转换,报告等)是多么容易。通常,在用户获得的控制级别和简单性水平之间存在折衷。在这里,我们必须区分平台提供的功能和平台内用户生成的内容。在大多数情况下,用户生成的内容需要使用代码,因为数据工程和分析的整个主题本质上是复杂的并且需要大量的表达性。

14.多用户工作流程

此类别评估对用户交互以及工作和数据共享的支持。此方面涉及用户操作,协作工作,共享和角色分配的实时更新。还有一种讨论和评论平台的方法。

15.平台内文件

数据平台用于在更长的时间段内为许多参与用户实现许多自定义复杂性。

这需要正确记录用户提供的内容。在这里,我们评估平台如何支持此任务。当然,文档总是可以在平台之外准备,但这意味着信息分歧的风险。外部文档很快就会过时,因此很快就会失去用户的信任。

16.文件

所有平台都需要用户具备一定的熟练程度。数据工程不是偶然的任务。因此,专业使用平台需要有关平台功能详细信息的正确文档。

17.安全

数据平台安全性可以分为存储安全性(静态数据),交互(传输中的数据)和访问控制。

18.成本结构

我们确定了数据平台的三个主要成本驱动因素:

  • 许可证
  • 基础设施(硬件)
  • 员工
  • 今天,大多数软件栈可以使用开源和/或免费软件以高质量实现。许可软件或服务通常需要较少的维护工作和较低级别的系统知识。

云提供商可以按使用付费使用计算硬件。这基本上适用于存储基础架构。

要估算硬件成本,您需要考虑基础架构以涵盖以下组件:

  • 数据库
  • 数据转换
  • Analytics(分析)
  • 数据科学
  • 自动化
  • 监控
  • 托管内容

尽管数据库通常是最大的组件,但它并不是唯一的组件。

结论

不应将数据平台简化为底层核心数据库,而应将其视为需要平衡的服务生态系统。

上面的列表提供了一个基本切入点,用于评估数据平台是否适合作为组织的长期可管理数据平台,其主要目的是为更重要的统计和预测聚合更长的数据历史。如果您的目标是在更短的时间内解决非常具体的数据相关问题,则此列表仅适用于部分。

发表评论
留言与评论(共有 0 条评论)
   
验证码:

相关文章

推荐文章

'); })();