加入收藏 | 设为首页 |

cc漫画-微软:谈谈大数据架构

海外新闻 时间: 浏览:284 次

这篇文章转自微软官方技能文档,比较详细的介绍了大数据架构。文章中有很多是微软的技能特性,这些关于咱们来说,或许无关紧要,重要的是学习其理论,在咱们做大数据方面的规划时,有很强的参考价值。

关于技能才能不杰出的团队,选用云厂商的一些技能建立大数据渠道,是一个可取的计划。

继续共享cc漫画-微软:谈谈大数据架构互联网研制技能干货,欢迎重视我。

大数据架构

大数据架构规划用来处理对传统数据库体系而言太大或太杂乱的数据的引进、处理和剖析。 安排进入大数据范畴的门槛各不相同,详细取决于用户的权限及其东西的功用。 对某些安排来说,大数据或许意味着数百个 GB 的数据,而对另一些安排来说,大数据则意味着数百个 TB 的数据。 跟着处理大数据集的东西的开展,大数据的寓意也在不断地改变。 慢慢地,这个术语更多的是指经过高档剖析从数据集获取的价值,而不是严厉地指数据的巨细,尽管这种情况下的数据往往是很大的。

多年来,数据格局一直在变。 数据的功用和预期功用一直在变。 存储本钱在大幅下降,而数据的搜集手法则在增多。 一些数据会瞬间呈现,需求不断地进行搜集和调查。 另一些数据呈现速度较慢,但却是很大型的区块,一般是以数十年的历史数据的方法呈现。 你面临的或许是高档剖析问题,也或许是需求机器学习的问题。 这些都是大数据架构寻求处理的难题。

大数据处理计划一般触及一个或多个以下类型的作业负荷:

  • 静态大数据源的批处理。
  • 移动中的大数据的实时处理。
  • 大数据的交互式阅读。
  • 猜测剖析和机器学习。

需求处理以下难题时,可以考虑运用大数据架构:

  • 存储和处理对传统数据库而言数量太大的数据。
  • 转化非结构化数据以进行剖析和陈述。
  • 实时或许以较低的推迟捕获、处理和剖析无限的数据流。

大数据架构的组件

下图显现了组成大数据架构的逻辑组件。 单个处理计划或许不会包含此图中的每个项目。

大多数大数据架构都包含下列组件中的一些或悉数:

  • 数据源。 一切大数据处理计划一开始都有一个或多个数据源。 示例包含:
  • 应用程序数据存储,例如联系数据库。
  • 应用程序生成的静态文件,例如 Web 服务器日志文件。
  • 实时数据源,例如 IoT 设备。
  • 数据存储。 用于批处理操作的数据一般存储在分布式文件存储中,该存储可以包容很多各种格局的大型文件。 这类存储一般称为 Data Lake。 用于完结此存储的选项包含 Azure Data Lake Store 和 Azure 存cc漫画-微软:谈谈大数据架构储中的 blob 容器。
  • 批处理。 由于数据集很大,因而大数据处理计划一般有必要运用长期运转的批处理作业来处理数据文件,以便挑选、聚合和预备用于剖析的数据。 这些作业一般触及读取源文件、对它们进行处理,以及将输出写入到新文件。 选项包含在 Azure Data Lake Analytics 中运转 U-SQL 作业,在 HDInsight Hadoop 群集中运用 Hive、Pig 或自定义 Map/Reduce 作业cc漫画-微软:谈谈大数据架构,或许在 HDInsight Spark 群集中运用 Java、Scala 或 Python 程序。
  • 实时音讯引进。 假如处理计划包含实时源,则架构有必要包含一种办法来捕获并存储进行流处理的实时音讯。 这可以是一个简略的数据存储,将在其间将传入音讯放置在一个文件夹中以进行处理。 不过,许多处理计划都需求一个音讯引进存储来充任音讯缓冲区,以及支撑横向扩展处理、牢靠传递和其他音讯行列语义。 此部分的流式处理架构一般称为流缓冲。 选项包含 Azure 事情中心、Azure IoT 中心和 Kafka。
  • 流处理。 捕获实时音讯后,处理计划有必要经过挑选、聚合以及预备用于剖析的数据来处理音讯。 然后,会将处理后的流数据写入到输出接纳器。 Azure 流剖析依据不断运转的 SQL 查询供给保管流处理服务,这些查询对无限的流进行操作。 还可以在 HDInsight 群集中运用开源 Apache 流式处理技能,例如 Storm 和 Spark 流式处理。
  • 剖析数据存储。 许多大数据处理计划会先预备用于剖析的数据,然后以结构化格局供给已处理的数据供剖析东西查询。 如大多数传统事务智能 (BI) 处理计划中所见,用来为这些查询供给服务的剖析数据存储可以是 Kimball 款式的联系数据仓库。 或许,数据也可以经过低推迟 NoSQL 技能(如 HBase)或 Interactive Hive 数据库中呈现,该数据库供给分布式数据存储中数据文件的元数据笼统。 Azure SQL 数据仓库为大规模、依据云的数据仓库供给保管服务。 HDInsight 支撑交互式 Hive、HBase 和 Spark SQL,也可以运用这些技能来供给用于剖析的数据。
  • 剖析和陈述。 大多数大数据处理计划的意图是经过剖析和陈述供给对数据的见地。 若要运用户可以对数据进行剖析,架构可以包含一个数据建模层,例如 Azure Analysis Services 中的多维 OLAP 多维数据集或表格数据模型。 它还可以运用 Microsoft Power BI 或 Microsoft Excel 中的建模和可视化技能支撑自助式 BI。 剖析和陈述还可以选用适用于数据科学家或数据剖析人员的交互式数据阅读方法。 关于这些计划,许多 Azure 服务都支撑剖析笔记本(例如 Jupyter),这答应这些用户经过 Python 或 R 运用其现有技能。关于大规模数据阅读,可以运用 Microsoft R Server,可以独立运用,也可以将其与 Spark 一同运用。
  • 事务流程。 大多数大数据处理计划都包含重复的数据处理操作(封装在作业流中),这些操刁难源数据进行转化、在多个源和接纳器之间移动数据、将已处理的数据加载到剖析数据存储中,或许直接将成果推送到报表或仪表板。 若要主动履行这些作业流,可以运用比如 Azure 数据工厂或 Apache Oozie 和 Sqoop 的事务流程技能。

Lambda 架构

运用极大型数据集时,运转客户端所需的查询类型或许需求很长期。 这些查询无法实时履行,并且一般需求 MapReduce之类的算法跨整个数据集进行并行操作。 然后,成果会与原始数据分隔存储,用于查询。

此办法的一个缺陷是会形成推迟 — 假如处理需求数小时,则查询回来的成果或许是数小时之前的数据的成果。 最好是可以获取一些实时成果(或许精确性稍欠),然后将这些成果与批处理剖析成果结合在一同。

lambda 架构首先由 Nathan Marz 提出,经过创立两个数据流途径来处理此问题。 一切进入体系的数据都经过这两个途径:

  • 批处理层(冷途径)以原始方法存储一切传入数据,对数据进行批处理。 该处理的成果作为批处理视图存储。
  • 速度层(热途径)可实时剖析数据。 规划此层是为了下降小时光推迟,但价值是精确性也会下降。

批处理层将成果馈送到服务层中,后者会编制批处理视图的索引,以便进步查询功率。 速度层会依据最新数据运用增量更新来更新服务层。

流入热途径的数据受速度层提出的推迟要求束缚,因而可以赶快处理。 一般情况下,这需求献身必定程度的精确性,以便数据赶快安排妥当。 例如,在运用某个 IoT 计划时,需求经过很多的温度传感器发送遥测数据。 可以运用速度层来处理传入数据的滑动时刻窗口。

另一方面,流入冷途径中的数据不受这些相同的低推迟要求束缚。 这样可以跨大型数据集进行高精度核算,这样的核算或许很耗时。

热途径和冷途径终究在剖析客户端应用程序处会集。 假如需求实时显现时刻性要求高但精确性要求或许不高的数据,客户端会从热途径获取成果。 不然,客户端会从冷途径挑选成果来显现时刻性要求不高但精确性要求高的数据。 换言之,一开始可以运用时限相对较短的热途径的数据作为成果,稍后再运用冷途径的精确性较高的数据对成果进行更新。

存储在批处理层的原始数据是不可变的。 传入数据一直追加到现有数据上,不掩盖曾经的数据。 对特定基准的值进行更改时,所做的更改会作为带时刻戳的新事情记载来存储。 这样就可以挑选历史记载中恣意时刻点的已搜集数据从头进行核算。 依据开始的原始数据从头核算批处理视图这一功用很重要,由于这样就可以跟着体系的开展不断创立新视图。

Kappa 架构

Lambda 架构的一个缺陷是杂乱。 处理逻辑显现在冷途径和热途径两个不同的方位,并且运用不同的结构。 这样会导致核算逻辑重复,并且两个途径的架构办理起来也很杂乱。

Kappa 架构由 Jay Kreps 提出,用于代替 cc漫画-微软:谈谈大数据架构Lambda 架构。 它具有与 lambda 体系结构相同的根本方针,但有一个重要差异:一切数据流经一个途径,运用一个流处理体系。

某些方面与 Lambda 架构的批处理层有些相似,那就是,事情数据不可变,并且全都可以搜集,而不是只能搜集一部分。 数据作为事情流引进到能容错的分布式一致日志中。 这些事情按顺序排列。一个事情的当时状况只在追加新事情的情况下更改。 与 Lambda 架构的速度层相似,一切事情处理均在输入流的基础上进行,作为实时视图保存。

如需从头核算整个数据集(相当于 Lambda 中批处理层履行的操作),只需重播该流即可,一般可运用并行方法及时完结核算。

物联网 (IoT)

从有用视点来看,物联网 (IoT) 包含衔接到 Internet 的任何设备, 其间包含电脑、移动电话、智能表、智能调温器、智能致冷器、联网轿车、植入式心脏监测仪,以及任何其他可以衔接到 Internet 并可发送或接纳数据的设备。 衔接的设备数日积月累,从其搜集的数据量也是如此。 一般情况下,此类数据是在遭到严厉束缚且有时分推迟很严重的环境中搜集的。 别的一些情况下,数据是在低推迟环境中经过数千乃至数百万台设备发送的,这就要求可以快速引进数据并对其进行相应的处理。 因而,为了应对这些束缚和特别要求,需求正确地进行规划。

事情驱动的架构是 IoT 处理计划的中心环节。 下列图表显现 IoT 或许呈现的逻辑架构。 此图表着重架构的事情流式传输组件。

云网关运用牢靠、低推迟的音讯传递体系在云鸿沟引进设备事情。

设备或许会直接将事情发送到云网关,或经过现场网关发送。 现场网关是一种专用设备或软件,一般与接纳事情并将事情转接到云网关的设备坐落同一方位。 现场网关也可预处理原始设备事情,履行过滤、聚合或协议转化等功用。

引进后,事情将经过一个或多个流处理器,此处理器可将数据路由到存储等方位,也可履行剖析和其他处理。

下面是一些常见的处理类型。 (此列表并未包含一切类型。)

  • 将事情数据写入冷存储,用于存档或批处理剖析。
  • 热途径剖析,实时(或近乎实时)剖析事情流,以检测反常,辨认翻滚时刻范围内的形式,或许在流中呈现特别情况时触发警报。
  • 处理设备中特别类型的非遥测音讯,例如告诉和警报。
  • 机器学习。

具有灰色暗影的框表明 IoT 体系的组件,尽管这些组件与事情流式传输没有直接联系,但为了完好起见,仍在此处提出。

  • 设备注册表是预配设备的数据库,包含设备 ID 和常见的设备元数据,如方位信息。
  • 预配 API 是一种常见的外部接口,用于预配和注册新设备。
  • 某些 IoT 处理计划可使指令和操控音讯发送到设备。

转自:https://github.com/MicrosoftDocs/architecture-center.zh-cn/blob/live/docs/data-guide/big-data/index.md