前言
本文隶属于专栏《大数据理论体系》，该专栏为笔者原创，引用请注明泉源，不足和错误之处请在评论区帮忙指出，谢谢！
本专栏目录结构和参考文献请见大数据理论体系
姊妹篇
《分布式数据模型详解：OldSQL =＞ NoSQL =＞ NewSQL》
《分布式盘算模型详解：MapReduce、数据流、P2P、RPC、Agent》
《大数据存储架构详解：数据仓库、数据集市、数据湖、数据网格、湖仓一体》
《大数据处置惩罚架构详解：Lambda架构、Kappa架构、流批一体、Dataflow模型、及时数仓》
《及时数仓详解》
思维导图
Lambda 架构
Lambda 的由来
我们通常认为这个希腊字母与这一模式相关联是由于数据来自两个地方。
批量数据和快速的流式数据代表Lambda符号的弯曲部分，然后通过服务层(线段与曲线部分合并)合并，如上图所示。
WHAT
Lambda架构（Lambda Architecture）是由Twitter工程师南森·马茨（Nathan Marz）提出的大数据处置惩罚架构。
它的目的是构建一个通用的、健壮的大数据系统，能够同时满意及时查询和历史数据批处置惩罚的需求。
随着大数据的鼓起，越来越多的公司开始面临海量数据的处置惩罚问题。传统的批处置惩罚系统无法满意及时数据处置惩罚的需求，而简单的流式处置惩罚系统又无法举行复杂的历史数据分析。这就必要一种混淆架构，能够兼顾及时性和复杂分析。Lambda架构应运而生。
关于 Lambda 架构的详情请参考我的博客——《什么是Lambda架构？》
构成
Lambda 架构总共由三层系统构成：批处置惩罚层（Batch Layer），速率处置惩罚层（Speed Layer），以及用于响应查询的服务层（Serving Layer）。
在 Lambda 架构中，每层都有自己所肩负的任务。
批处置惩罚层
批处置惩罚层存储管理主数据集（不可变的数据集）和预先批处置惩罚盘算好的视图。
批处置惩罚层利用可处置惩罚大量数据的分布式处置惩罚系统预先盘算效果。
它通过处置惩罚所有的已有历史数据来实现数据的正确性。
这意味着它是基于完备的数据集来重新盘算的，能够修复任何错误，然后更新现有的数据视图。
输出通常存储在只读数据库中，更新则完全取代现有的预先盘算好的视图。
速率处置惩罚层
速率处置惩罚层会及时处置惩罚新来的大数据。
速率层通过提供最新数据的及时视图来最小化延伸。
速率层所生成的数据视图可能不如批处置惩罚层最终生成的视图那样正确或完备，但它们几乎在收到数据后立即可用。
而当同样的数据在批处置惩罚层处置惩罚完成后，在速率层的数据就可以被替代掉了。
本质上，速率层补充了批处置惩罚层所导致的数据视图滞后。
比如说，批处置惩罚层的每个任务都必要 1 个小时才气完成，而在这 1 个小时里，我们是无法获取批处置惩罚层中最新任务给出的数据视图的。
而速率层由于能够及时处置惩罚数据给出效果，就补充了这 1 个小时的滞后。
服务层
所有在批处置惩罚层和速率层处置惩罚完的效果都输出存储在服务层中，服务层通过返回预先盘算的数据视图或从速率层处置惩罚构建好数据视图来响应查询。
Kappa 架构
Kappa架构是对Lambda架构的改进和优化，由Jay Kreps于2014年首次提出。
随着流式盘算系统的发展，Lambda架构存在的一些问题渐渐显现出来：
- 系统复杂度高：必要同时开发和维护批处置惩罚系统和流式系统。
- 通过日志重播实现低延伸查询，会导致数据冗余。
- 及时视图和批处置惩罚视图存在延伸不划一的问题。
为了办理这些问题，Jay Kreps提出了Kappa架构。Kappa架构去除了Lambda架构的批处置惩罚层，直接通过流式处置惩罚系统实现整个流程。
关于 Kappa 架构的详情请参考我的博客——《什么是Kappa架构？》
构成
Kappa架构主要包含两个层:
- 流式处置惩罚层：通过流式处置惩罚系统接收所有数据，并举行及时盘算，更新存储中的效果视图。
- 服务层：对外提供查询服务，直接基于流式处置惩罚层更新的效果视图举行查询返回。
Kappa架构镌汰了系统复杂度，避免了数据冗余和数据不划一的问题。但必要流式处置惩罚系统能够包管Exactly-once语义，以包管流式盘算的精确性。而且，去除批处置惩罚系统后，对历史数据的复杂盘算会更加困难。
以 Apache Kafka 为例来讲述整个Kappa架构的过程
- 部署 Apache Kafka，并设置数据日志的保留期（Retention Period）。这里的保留期指的是你希望能够重新处置惩罚的历史数据的时间区间。比方，如果你希望重新处置惩罚最多一年的历史数据，那就可以把 Apache Kafka 中的保留期设置为 365 天。如果你希望能够处置惩罚所有的历史数据，那就可以把 Apache Kafka 中的保留期设置为“永久（Forever）”。
- 如果我们必要改进现有的逻辑算法，那就表示我们必要对历史数据举行重新处置惩罚。我们必要做的就是重新启动一个 Apache Kafka 作业实例（Instance）。这个作业实例将重头开始，重新盘算保留好的历史数据，并将效果输出到一个新的数据视图中。我们知道 Apache Kafka 的底层是利用 Log Offset 来判断现在已经处置惩罚到哪个数据块了，以是只必要将 Log Offset 设置为 0，新的作业实例就会重头开始处置惩罚历史数据。
- 当这个新的数据视图处置惩罚过的数据进度赶上了旧的数据视图时，我们的应用便可以切换到从新的数据视图中读取。
- 制止旧版本的作业实例，并删除旧的数据视图。
与 Lambda 架构不同的是，Kappa 架构去掉了批处置惩罚层这一体系结构，而只保留了速率层。 你只必要在业务逻辑改变又大概是代码更改的时间举行数据的重新处置惩罚。
当然了，也可以在上面讲到的步调中做一些优化。 比方不实行第 4 步，也就是不删除旧的数据视图。这样的好处是当你发现代码逻辑出错时可以及时回滚（Roll Back）到上一个版本的数据视图中去。又大概是你想在服务层提供 A/B 测试，保留多个数据视图版本将有助于你举行 A/B 测试。
Lambda 架构 vs Kappa 架构
Lambda架构和Kappa架构的区别可以通过下表举行对比阐明:
对比项Lambda架构Kappa架构构成批处置惩罚层
速率层
服务层流式处置惩罚层
服务层数据处置惩罚方式批处置惩罚系统处置惩罚历史数据
流式系统处置惩罚及时数据仅用流式系统处置惩罚全部数据系统复杂度较高，必要开发和维护两个系统较低，只必要一个流式系统延伸划一性存在，及时视图和批处置惩罚视图有延伸差异更好，没有批处置惩罚系统数据冗余存在，必要重播日志到及时系统较少，无需重播日志历史数据处置惩罚批处置惩罚系统可举行复杂历史分析相对复杂，只有流式系统 总结来说:
Lambda架构通过批处置惩罚层和速率层的组合，兼顾了低延伸和复杂分析，但系统较复杂，存在数据冗余和延伸不划一问题。
Kappa架构只通过流式系统实现所有处置惩罚，简化了架构，但历史数据分析相对复杂，必要流式系统包管精确一次语义。
两者都有各自的优缺点，必要根据详细场景举行技能选型和计划权衡。
Kappa 架构变种
Kappa-S
Kappa-S架构是在Kappa架构的基础上举行的优化和改进。
Kappa架构通过单个流式处置惩罚系统实现低延伸的及时盘算以及历史数据的处置惩罚。
但原始的Kappa架构依然存在一些问题:
- 历史数据的处置惩罚还是相对复杂，不如Lambda架构中的批处置惩罚系统。
- 单个流式系统必要承担全部数据的处置惩罚，面临较大的压力。
- 流式系统必要包管精确一次语义，实现较为复杂。
为了办理这些问题，Jay Kreps等人提出了Kappa-S架构。该架构在Kappa架构的基础上，引入了Stream-Serving层。
Kappa-S架构包含以下组件:
- Stream层:及时流式处置惩罚层。
- Serving层:查询服务层。
- Stream-Serving层:用来预盘算并服务历史数据的查询，减轻Stream负载。
通过引入Stream-Serving层针对历史数据举行预盘算，Kappa-S架构减轻了流式处置惩罚的压力，使历史数据的查询和分析更加简单，同时也避免了流式系统必要提供精确一次语义的复杂性。可以看作是Kappa架构和Lambda架构的折中方案。
Kappa-Lambda
Kappa-Lambda架构是在Kappa架构的基础上，引入了Lambda架构中的批处置惩罚层组件，形成的一种混淆架构。
Kappa-Lambda架构包含以下组件:
- Stream层:及时流式处置惩罚层。
- Serving层:查询服务层。
- Batch层:批处置惩罚层，用于复杂的历史数据分析。
- Speed层:速率层，用于低延伸的及时盘算。
其工作流程如下:
- Stream层接收及时数据，举行及时盘算。
- Speed层从Stream层获取及时效果，举行低延伸的及时分析。
- Serving层查询时，及时部分从Speed层获取，历史部分从Batch层获取。
- Batch层定期从Stream层获取数据，举行复杂的历史数据分析和处置惩罚。
可以看出，Kappa-Lambda架构相比Kappa架构，引入了批处置惩罚层组件，以便举行复杂的历史数据分析。同时保留了Speed层，举行低延伸的及时盘算。
这种计划兼顾了Kappa架构的简单性，以及Lambda架构在复杂分析上的优势。既能及时处置惩罚，也能举行复杂的批处置惩罚。
Kappa-DB
Kappa-DB架构是在Kappa架构的基础上，通过引入数据库组件，实现流式数据到数据库的持久化保存，形成的一种架构计划。
Kappa-DB架构通常包含以下组件:
- Stream层:及时流式处置惩罚层。
- Serving层:查询服务层。
- Database:数据库层，用于存储流式处置惩罚的效果数据。
其工作流程如下:
- Stream层接收及时数据，举行及时处置惩罚。
- Stream层将处置惩罚效果写入数据库举行持久化存储。
- Serving层接收查询请求，从数据库中读取数据，举行盘算后返回效果。
- 定期举行归档或聚合，避免数据库数据过多。
引入数据库组件的长处包括:
- 通过数据库持久化存储，避免数据丢失。
- 简化历史数据查询，数据库可以举行索引优化。
- 可以通过归档低落存储成本。
- 可以重用数据库的盘算能力，镌汰流盘算开销。
必要注意数据库写入成为系统瓶颈的问题，通常要控制写入数据库的频率，举行归档优化等。
总体上，Kappa-DB架构通过融合流式处置惩罚和数据库，实现了数据的持久化存储，同时也继承了Kappa架构的长处。
Kappa 系列架构对比
架构范例构成长处缺点Kappa流式处置惩罚层
服务层简单，划一性好历史处置惩罚复杂Kappa-S流式处置惩罚层
服务层
预盘算层减轻流量压力
历史处置惩罚简单额外一层复杂度Kappa-Lambda流式处置惩罚层
服务层
速率层
批处置惩罚层兼顾及时和批处置惩罚架构比较复杂Kappa-DB流式处置惩罚层
服务层
数据库层数据持久化
利用DB盘算DB成为瓶颈 综合来看:
- Kappa架构简单但历史处置惩罚复杂
- Kappa-S通过预盘算层减轻及时流量压力，但增加了系统复杂度
- Kappa-Lambda引入批处置惩罚能力，但架构非常复杂
- Kappa-DB利用数据库实现持久化，但可能面临DB瓶颈
必要根据详细业务需求，均衡及时处置惩罚、历史处置惩罚、划一性、范畴等方面的需求，选择适合的架构。
流批一体
流批一体(Unified Batch and Streaming Processing)是指将流式处置惩罚和批处置惩罚统一在一个运行时框架中，举行一体化的处置惩罚。
在流批一体架构中，及时数据流和历史数据批量处置惩罚可以利用同一组数据处置惩罚工具和技能，比方Apache Spark、Apache Flink等。流批一体架构可以将及时数据和历史数据举行统一的处置惩罚和分析，以简化数据处置惩罚的复杂性和提高数据处置惩罚的效率。
在流批一体架构中，及时数据流和历史数据批量处置惩罚可以利用同一套数据处置惩罚代码。这意味着，数据处置惩罚职员可以利用同一种编程语言、框架和工具来处置惩罚及时数据和历史数据。这样可以镌汰数据处置惩罚职员的学习和利用成本，并提高数据处置惩罚的效率和精度。
流批一体架构还可以将及时数据和历史数据存储在同一套数据存储系统中，比方Apache HBase、Apache Cassandra等。这样可以简化数据存储的管理和维护，并提高数据的可用性和可靠性。
总之，流批一体是一种将流数据处置惩罚和批数据处置惩罚整合在一起的数据处置惩罚架构，它可以简化数据处置惩罚的复杂性和提高数据处置惩罚的效率。流批一体架构可以在及时数据处置惩罚和历史数据批量处置惩罚之间实现无缝切换，以满意不同的数据处置惩罚需求。
诞生配景
流批一体的诞生主要有以下配景:
- Lambda架构的复杂性问题：Lambda架构必要同时开发和维护批处置惩罚系统和流式处置惩罚系统，系统复杂，开发和运维困难。
- 及时盘算和历史盘算的需求融合：越来越多的应用同时必要及时数据处置惩罚和历史数据分析，必要一个统一的框架。
- 流式处置惩罚系统的发展成熟：流式处置惩罚系统的盘算模型和性能已经发展成熟，可以用于替代传统的批处置惩罚任务。
- 微批流式处置惩罚技能的出现：Spark Streaming等系统采用微批流式处置惩罚，简化了流式处置惩罚的事故时间管理。
- 云原生技能的鼓起：Kubernetes等技能为流批一体提供了更好的资源调理和技能支撑。
综上，流批一体可以看作是对Lambda架构的简化，也是及时处置惩罚和批处置惩罚融合的产物，以应对及时数据和历史数据双需求的场景。
Dataflow 模型
DataFlow 模型是一种用于形貌数据处置惩罚流程的盘算模型，它形貌了数据从源头到目的地的活动过程，并指定了数据处置惩罚的方式和顺序。
DataFlow 模型常用于并行盘算和数据流处置惩罚范畴，比方流处置惩罚框架 Apache Flink 就是基于 DataFlow 模型实现的。
在 DataFlow 模型中，数据被视为活动的实体，数据处置惩罚被视为一系列的数据转换操纵。数据可以从一个或多个输入源中流入数据处置惩罚系统，颠末一系列的处置惩罚操纵，最终输出到一个或多个输出目的地中。在数据处置惩罚的过程中，数据可以被分割成多个数据块，这些数据块可以并行处置惩罚，以提高数据处置惩罚的效率。
DataFlow 模型中的数据处置惩罚操纵通常被形貌为有向图中的节点，数据活动则被形貌为有向边。每个节点可以实行一些特定的数据处置惩罚操纵，比方数据过滤、数据转换、数据聚合等。节点之间的边表示数据的活动方向和数据处置惩罚顺序。在 DataFlow 模型中，数据处置惩罚操纵可以被组合成复杂的数据处置惩罚流程，以实现不同的数据处置惩罚需求。
总之，DataFlow 模型是一种用于形貌数据处置惩罚流程的盘算模型，它形貌了数据从源头到目的地的活动过程，并指定了数据处置惩罚的方式和顺序。DataFlow 模型常用于并行盘算和数据流处置惩罚范畴，比方流处置惩罚框架 Apache Flink 就是基于 DataFlow 模型实现的。
关于 Dataflow 模型的更多细节请参考我的博客——《DataFlow 模型是什么？》
诞生配景
Dataflow模型的主要诞生配景:
- 大数据时代的数据规模爆炸，必要并行盘算能力
- 流式盘算和批处置惩罚的需求融合
- MapReduce模型的局限性：MapReduce模型对迭代盘算和DAG支持不友好，而Dataflow模型通过Operator图更适合表达复杂的数据处置惩罚流程。
- 分布式资源管理与集群调理技能的进步：YARN、Mesos、Kubernetes等技能为Dataflow模型提供了更好的运行时支撑。
- 内存盘算的发展：Spark等内存盘算框架更适合Dataflow模型。
综上，Dataflow模型是对MapReduce模型的重要发展和延伸，可以更好地处置惩罚迭代、流式、DAG等复杂数据处置惩罚任务，在大数据时代得到广泛应用。
关于 MapReduce 模型请参考我的博客——《MapReduce 编程模型到底是怎样的？》
Dataflow 模型全流程
DataFlow 模型的全流程可以分为以下几个步调：
- 数据源输入：数据源可以是各种范例的数据，比方文件、数据库、消息队列等。在 DataFlow 模型中，数据源被视为数据处置惩罚流程的出发点，数据从数据源中流入数据处置惩罚系统。
- 数据切割：在 DataFlow 模型中，数据可以被分割成多个数据块，这些数据块可以并行处置惩罚，以提高数据处置惩罚的效率。数据切割可以根据数据的大小、时间戳、键值等方式举行，以便更好地实现数据并行处置惩罚。
- 数据转换：在 DataFlow 模型中，数据可以颠末一系列的数据转换操纵，比方数据清洗、数据过滤、数据聚合等。数据转换操纵被形貌为有向图中的节点，每个节点可以实行一些特定的数据处置惩罚操纵，节点之间的边表示数据的活动方向和数据处置惩罚顺序。
- 数据聚合：在 DataFlow 模型中，数据可以颠末多个数据转换操纵后被聚合起来，以便更好地实现数据分析和挖掘。
- 数据输出：在 DataFlow 模型中，数据输出可以是各种范例的数据目的地，比方文件、数据库、消息队列等。数据输出被视为数据处置惩罚流程的终点，数据从数据处置惩罚系统中输出到数据目的地中。
在 DataFlow 模型中，数据处置惩罚操纵可以被组合成复杂的数据处置惩罚流程，以实现不同的数据处置惩罚需求。数据处置惩罚流程可以利用各种数据处置惩罚框架和工具来实现，比方 Apache Flink、Apache Beam、Apache Kafka 等。
Dataflow 模型怎样包管数据的正确性和划一性
DataFlow 模型可以通过以下方式来包管数据的正确性和划一性：
- 数据校验：在数据流入数据处置惩罚系统之前，可以举行数据校验，比方数据格式、数据范例、数据范围等。这可以包管数据的正确性和完备性。
- 数据清洗：在数据处置惩罚过程中，可以举行数据清洗，比方去除重复数据、填充缺失数据等。这可以包管数据的划一性和正确性。
- 事务处置惩罚：在数据处置惩罚过程中，可以利用事务机制来确保数据的划一性。比方，如果一个节点的数据处置惩罚失败，整个数据处置惩罚流程可以回滚到之前的状态，以包管数据的划一性。
- 数据分区：在数据处置惩罚过程中，可以将数据分成多个数据块，每个数据块可以并行处置惩罚。这可以提高数据处置惩罚的效率，同时也可以避免数据竞争和数据辩论，以包管数据的划一性。
- 数据重试：在数据处置惩罚过程中，如果某个节点处置惩罚失败，可以举行数据重试，直到数据处置惩罚乐成。这可以包管数据的完备性和正确性。
及时数仓
及时数仓是一种现代化的数据仓库，具有大数据规模的小数据语义和性能。它可以处置惩罚及时数据、最新数据和历史数据，并且能够跨数据域举行相关性分析。及时数仓具有更快的数据到达和查询速率，可以在集成且安全的平台上完成所有功能。
及时数仓的优势包括更快的决策、数据民主化、个性化的客户体验、提高业务敏捷性息争锁新的业务用例。然而，及时数仓也面临着ETL性能和复杂及时盘算场景等挑战。
典型的及时数仓架构包括数据收集层、数据存储层、及时盘算层和及时应用层。数据收集层负责接收和传输数据，数据存储层用于及时数据存储，及时盘算层用于及时盘算和分析，及时应用层用于数据分析和挖掘。
及时数仓可以应用于及时OLAP分析、及时数据看板、及时业务监控和及时数据接口服务等场景。其技能实现通常包括消息总线、及时存储、流处置惩罚和分析以及应用层。
常用的及时数仓技能包括Apache Kafka、Apache Druid、Apache Spark、Hadoop、TiDB等，详细选择取决于需求和偏好。
关于及时数仓的更多细节请参考我的博客——《及时数仓详解》
诞生配景
及时数仓的主要诞生配景有:
- 对及时数据分析需求的增长：越来越多的企业希望能够立即分析操纵数据，以便及时做出决策。
- 传统数仓延伸大的问题：传统的数仓以批量方式定期更新，无法满意对及时数据的分析必要。
- 流式盘算技能的发展：大数据技能使得流式数据的采集、传输和盘算成为可能。
- 内存盘算的进步：Spark等内存盘算技能使得内存级的交互式分析成为可能。
- 对用户体验的提高要求：用户希望立即获取分析看法，不能等待传统数仓的延伸。
- 云盘算技能的进步：云盘算提供了及时数仓弹性扩展的能力。
架构
及时数仓通常具有四个组件：数据收集层、数据存储层、及时盘算层和及时应用层。这些组件协同工作，以便在事故发生后立即或短时间内支持事故数据的处置惩罚和分析。所有数据处置惩罚阶段（数据摄取、丰富、分析、基于 AI/ML 的分析）都是连续的，具有最小延伸，并且能够实现及时报告和即席分析。
一个比较典型的及时数仓架构如下所示：
- 数据收集层：第三方服务和协同系统通过 Apache Kafka/Apache Nifi 之类的消息总线传输数据到及时数仓；第三方数据源通过调用及时数仓的 API；物联网系统通过直接毗连并推送数据的方法传输数据
- 数据存储层：利用 Apache Kudu/Apache Druid/Amazon Redshift 来举行及时数据存储
- 及时盘算层：利用 Apache Spark/Amazon Kinesis/Hadoop 来举行及时盘算和分析
- 及时应用层：利用 AI 和机器学习技能对数据举行分析和挖掘，利用 SQL Server/Oracle BI 来支持查询、报告和即席查询；利用 Apache Impala 来支持及时报告和告警。
对比
架构范例构成长处缺点Lambda架构批处置惩罚层
速率层
服务层兼顾低延伸和复杂分析系统复杂,数据冗余Kappa架构流式处置惩罚层
服务层系统简单,划一性好历史处置惩罚相对复杂流批一体统一运行时框架处置惩罚简化,效率高及时性打扣头Dataflow模型数据源、转换操纵、数据汇聚机动性强,可扩展性好必要办理划一性等问题及时数仓收集层
存储层
盘算层
应用层及时分析,低延伸基础设施要求高
总结
本文详细介绍了几种主要的大数据处置惩罚架构:
- Lambda架构：组合批处置惩罚层和速率层，兼顾低延伸和复杂分析，但系统较复杂，存在数据冗余和延伸不划一问题。Lambda架构的批处置惩罚层可以基于Hadoop、Spark等技能来实现，速率层可以基于Storm、Flink等流式处置惩罚系统来实现。服务层必要实现查询接口，可以利用REST API。Lambda架构适合大数据场景，但维护批处置惩罚层和速率层的重复开发较为贫苦。
- Kappa架构：仅通过流式处置惩罚实现所有处置惩罚，简化了架构，但历史数据分析相对复杂。Kappa架构还有几种变种，如Kappa-S、Kappa-Lambda、Kappa-DB。Kappa架构中的流式处置惩罚层可以基于Flink、Spark Streaming等来实现，必要实现Exactly-once语义。服务层同样必要查询接口。Kappa架构简单高效，但对及时流有较高要求，历史数据处置惩罚不如Lambda架构方便。
- 流批一体：将流式处置惩罚和批处置惩罚统一在一个运行时框架中，可以简化处置惩罚，提高效率。流批一体必要统一运行时框架，如Flink、Spark等，可以通过DataStream和DataSet在流式处置惩罚和批处置惩罚之间无缝切换。盘算模型也必要统一，如Dataflow模型。流批一体简化系统，但及时性不如纯流式处置惩罚。
- Dataflow模型：将数据处置惩罚视为数据流经转换操纵的流程，可以表达复杂的数据处置惩罚流程。Dataflow模型通常用有向图表达，并基于并行运行时框架实现，如Flink。必要办理数据划一性、容错等问题。Dataflow模型可以机动表示复杂处置惩罚流程。
- 及时数仓：通过流式处置惩罚实现对及时数据的快速存储和盘算分析，满意了对及时分析的需求。及时数仓中的消息总线可以用Kafka实现，存储系统可以利用HBase、Druid等，盘算利用Spark Streaming、Flink。及时数仓可以快速分析数据并及时更新，但对基础设施要求较高。
总的来说，大数据处置惩罚架构的发展趋势是及时性加强、处置惩罚统一简化、满意复杂分析需求。必要根据详细业务场景需求选择合适的架构方案。未来可能是基于流式处置惩罚的架构为主，同时引入批处置惩罚能力举行复杂分析。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
