网站没有做适配 怎么办十个免费域名

当前位置： 首页 > news >正文

网站没有做适配 怎么办,十个免费域名,wordpress 手机无菜单,哪里公司建设网站好目录 大数据处理系统架构特征Lambda架构Lambda架构介绍Lambda架构实现Lambda架构优缺点Lambda架构与其他架构模式对比 Kappa架构Kappa架构介绍Kappa架构实现Kappa架构优缺点 常见Kappa架构变形#xff08;Kappa、混合分析系统#xff09;Kappa架构混合分析系统的Kappa架构 La… 目录 大数据处理系统架构特征Lambda架构Lambda架构介绍Lambda架构实现Lambda架构优缺点Lambda架构与其他架构模式对比 Kappa架构Kappa架构介绍Kappa架构实现Kappa架构优缺点 常见Kappa架构变形Kappa、混合分析系统Kappa架构混合分析系统的Kappa架构 Lambda与Kappa架构对比Lambda与Kappa架构选型案例分析术语 大数据处理系统架构特征 鲁棒性和容错性 低延迟读取和更新能力 横向扩容 通用性 延展性 即席查询能力 最少维护能力 可调试性 Lambda架构 Lambda架构由 Storm 的作者 Nathan Marz提出 其设计目的在于提供一个能满足大数据系统关键特性的架构包括高容错、低延迟、可扩展等。 其整合 离线计算 与 实时计算融合不可变性、读写分离和复杂性隔离等原则 可集成 Hadoop、Kafka、Spark、Storm等各类大数据组件。 Lambda 是用于同时处理 离线 和 实时数据的可容错的可扩展的分布式系统。 它具备强鲁棒性提供低延迟和持续更新。 Lambda架构介绍 (1) 批处理层 (Batch Layer): 存储数据集 Batch Layer在数据集上预先计算查询函数并构建查询所对应的 View。Batch Layer可以很好地处理离线数据但有很多场景数据是不断实时生成且需要实时查询处理对于这种情况 Speed Layer更为适合。(2) 加速层 (Speed Layer): Batch Layer处理的是全体数据集而 Speed Layer处理的是最近的增量数据流。 Speed Layer 为了效率在接收到新的数据后会不断更新 Real-time View, 而Batch Layer 是根据全体离线数据集直接得到 Batch View。(3) 服务层 (Serving Layer): Serving Layer 用于合并Batch View 和 Real-time View中的结果数据集到最终数据集。 Lambda架构实现 在这种Lambda架构实现中 Hadoop (HDFS) 用于存储主数据集 Spark(或Storm) 可构成速度层 (Speed Layer), HBase ( 或 Cassandra) 作为服务层由Hive创建可查询的视图。 Lambda架构优缺点 优点 (1) 容错性好。 Lambda 架构为大数据系统提供了更友好的容错能力一旦发生错误我们可以修复算法或从头开始重新计算视图。(2) 查询灵活度高。批处理层允许针对任何数据进行临时查询。(3) 易伸缩。所有的批处理层、加速层和服务层都很容易扩展。因为它们都是完全分布式的系统我们可以通过增加新机器来轻松地扩大规模。(4) 易扩展。添加视图是容易的只是给主数据集添加几个新的函数。 缺点 (1) 全场景覆盖带来的编码开销。(2) 针对具体场景重新离线训练一遍益处不大。(3) 重新部署和迁移成本很高。 Lambda架构与其他架构模式对比 事件溯源 - 数据集的存储存储所有数据支持根据历史数据 重新计算 恢复正确状态容错性CQRS - 读写分离通过流、批处理进行写通过view进行读 Kappa架构 数据系统数据查询 数据的特性When时间点、What不可变、CRUD变成CR添加和读取 数据的存储数据不可变、存储所有数据 Kappa架构介绍 Kappa架构由 Jay Kreps提出不同于Lambda 同时计算流计算和批计算并合并视图 Kappa只会通过 流计算 一条的数据链路计算并产生视图。 Kappa 同样采用了重新处理事件的原则对于历史数据分析类的需求 Kappa要求数据的长期存储能够以有序日志流的方式重新流入流计算引擎重新产生历史数据的视图。 本质上是通过改进 Lambda架构中的 Speed Layer, 使它既能够进行实时数据处理同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据。
Kappa架构实现 #mermaid-svg-6sFticAeFb4bMP7r {font-family:“trebuchet ms”,verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-6sFticAeFb4bMP7r .error-icon{fill:#552222;}#mermaid-svg-6sFticAeFb4bMP7r .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-6sFticAeFb4bMP7r .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-6sFticAeFb4bMP7r .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-6sFticAeFb4bMP7r .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-6sFticAeFb4bMP7r .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-6sFticAeFb4bMP7r .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-6sFticAeFb4bMP7r .marker{fill:#333333;stroke:#333333;}#mermaid-svg-6sFticAeFb4bMP7r .marker.cross{stroke:#333333;}#mermaid-svg-6sFticAeFb4bMP7r svg{font-family:“trebuchet ms”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-6sFticAeFb4bMP7r .label{font-family:“trebuchet ms”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-6sFticAeFb4bMP7r .cluster-label text{fill:#333;}#mermaid-svg-6sFticAeFb4bMP7r .cluster-label span{color:#333;}#mermaid-svg-6sFticAeFb4bMP7r .label text,#mermaid-svg-6sFticAeFb4bMP7r span{fill:#333;color:#333;}#mermaid-svg-6sFticAeFb4bMP7r .node rect,#mermaid-svg-6sFticAeFb4bMP7r .node circle,#mermaid-svg-6sFticAeFb4bMP7r .node ellipse,#mermaid-svg-6sFticAeFb4bMP7r .node polygon,#mermaid-svg-6sFticAeFb4bMP7r .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-6sFticAeFb4bMP7r .node .label{text-align:center;}#mermaid-svg-6sFticAeFb4bMP7r .node.clickable{cursor:pointer;}#mermaid-svg-6sFticAeFb4bMP7r .arrowheadPath{fill:#333333;}#mermaid-svg-6sFticAeFb4bMP7r .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-6sFticAeFb4bMP7r .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-6sFticAeFb4bMP7r .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-6sFticAeFb4bMP7r .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-6sFticAeFb4bMP7r .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-6sFticAeFb4bMP7r .cluster text{fill:#333;}#mermaid-svg-6sFticAeFb4bMP7r .cluster span{color:#333;}#mermaid-svg-6sFticAeFb4bMP7r div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:“trebuchet ms”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-6sFticAeFb4bMP7r :root{–mermaid-font-family:“trebuchet ms”,verdana,arial,sans-serif;} 实时数据处理 历史数据处理将log offset设置为0启动新实例从头处理历史数据 新数据视图处理过的数据已经赶上了旧视图 Kafka 根据历史数据区间 设置数据日志保留期 Instance1 流式计算实例 实时视图 Instance2 新的流式计算实例 新视图 切换为新视图 Kappa架构优缺点 优点 在于将实时和离线代码 统一 起来方便维护而且统一了数据口径的问题避免了 Lambda架构中与离线 数据合并 的问题查询历史数据的时候只需要重放存储的历史数据即可。 缺点 (1) 消息中间件缓存的数据量和回溯数据有性能瓶颈。通常算法需要过去180天的数据如果都存在消息中间件无疑有非常大的压力。同时一次性回溯订正180天级别的数据对实时计算的资源消耗也非常大。(2) 在实时数据处理时遇到大量不同的实时流进行关联时非常依赖实时计算系统的能力很可能因为数据流先后顺序问题导致数据丢失。(3) Kappa 在抛弃了离线数据处理模块的时候同时抛弃了离线计算更加稳定可靠的特点。Lambda 虽然保证了离线计算的稳定性但双系统的维护成本高且两套代码带来后期运维困难。 对于以上Kappa框架存在的几个问题目前也存在一些解决方案 对于消息队列缓存数据性能的问题 Kappa框架 提出使用HDFS来存储中间数据。针对 Kappa 框架展示层能力不足的问题也有人提出了 混合分析系统 的解决方案。 常见Kappa架构变形Kappa、混合分析系统 Kappa架构 Kappa是 Uber提出流式数据处理架构 它的核心思想是让流计算框架 直接读 HDFS里的数据仓库数据 一并实现实时计算和历史数据 backfll 计算不需要为 backfll 作业长期保存日志或者把数据拷贝回消息队列。 Kappa 将数据任务分为 无状态任务和 时间窗口任务。 Uber开发了 Apache hudi 框架 来存储数据仓库数据 hudi 支持更新、删除已有parquet数据 也支持增量消费数据更新部分 从而系统性解决了问题2存储的问题。 图19-11是完整的Uber大数据处理平台其中Hadoop→ Spark →用户查询 的流程涵盖了Kappa数据处理架构。 将不同来源的数据通过 Kafka 导入到Hadoop 中 通过HDFS来存储中间数据 再通过 spark对数据进行分析处理 最后交由上层业务进行查询。 混合分析系统的Kappa架构 Lambda和 Kappa架构都还有展示层的困难点结果视图如何支持热点数据查询分析 一个解决方案是在 Kappa基础上衍生数据分析流程。 如图19-12所示在基于使用 Kafka Flink 构 建 Kappa 流计算数据架构 针对Kappa架构分析能力不足的问题 再利用 Kafka对接组合 Elastic-Search 实时分析引擎部分弥补其数据分析能力。 但是 ElasticSearch 也只适合对合理数源数量级的热点数据进行索引无法覆盖所有批处理相关的分析需求 这种混合架构某种意义上属于 Kappa和 Lambda间的折中方案。
Lambda与Kappa架构对比 Lambda架构 批处理Hadoop - Hbase流处理Spark、Storm - Redis Kappa架构 Kafka作为消息中间件将数据保持在消息队列中流式计算Flink其作为新兴的流处理框架以数据并行和流水线方式执行任意流数据程序且同时支持批处理和流处理。 SparkFlink微批处理流处理无界流批处理有界流 Lambda与Kappa架构选型 考虑因素详细说明业务需求 与技术需求- 用户需要根据自己的业务需求来选择架构- 如果业务对于 Hadoop、Spark、Strom 等关键技术有强制性依赖选择 Lambda 架构可能较为合适- 如果处理数据偏好于流式计算又依赖Flink 计算引擎那么选择 Kappa架构可能更为合适。复杂度- 频繁修改 Lambda 架构需要反复修改两套代码则显然不如 Kappa架构简单方便。- 同时支持批处理和流式计算或者希望用一份代码进行数据处理那么可以选择Kappa 架构。- 实时处理和离线处理的结果不能统一比如某些机器学习的预测模型需要先通过离线批处理得到训练模型再交由实时流式处理进行验证测试那么这种情况下批处理层和流处理层不能进行合并因此应该选择Lambda架构。开发维护成本- Lambda架构需要有一定程度的开发维护成本包括两套系统的开发、部署、测试、维护适合有足够经济、技术和人力资源的开发者。- 而Kappa 架构只需要维护一套系统适合不希望在开发维护上投入过多成本的开发者。历史数据处理能力- 频繁接触海量数据集进行分析比如过往十年内的地区降水数据等这种数据适合批处理系统进行分析应该选择Lambda架构。- 如果始终使用小规模数据集流处理系统完全可以使用则应该选择 Kappa架构。 案例分析 术语 即席查询(Ad Hoc) 即席查询Ad Hoc是用户根据自己的需求灵活的选择查询条件系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的而即席查询是由用户自定义查询条件的。 AD-HOC 以单独的SQL语句的形式执行的查询就是即席查询比如说在C#程序里嵌入的SQL语句或者在SSMS里的新建查询窗口自己键入的SQL代码就是即席查询。 而将SQL代码放入存储过程里面以存储过程或者函数或者触发器来执行的查询就不是即席查询即席当场就是当场去查询。 即席查询是指那些用户在使用系统时根据自己当时的需求定义的查询。即席查询生成的方式很多最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是将数据仓库中的维度表和事实表映射到语义层用户可以通过语义层选择表建立表间的关联最终生成SQL语句。即席查询与通常查询从SQL语句上来说并没有本质的差别。它们之间的差别在于通常的查询在系统设计和实施时是已知的所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询使这些查询的效率很高。而即席查询是用户在使用时临时生产的是一种松散类型的命令/查询其值取决于某个变量每次执行命令时结果都不同这取决于变量的值。它不能预先确定通常属于动态编程SQL查询。临时查询是短期的并且是在运行时创建的。系统无法预先优化这些查询所以即席查询也是评估数据仓库的一个重要指标。 即席查询的位置通常是在关系型的数据仓库中即在EDW或者ROLAP中。多维数据库有自己的存储方式对即席查询和通常查询没有区别。在一个数据仓库系统中即席查询使用的越多对数据仓库的要求就越高对数据模型的对称性的要求也越高。对称性的数据模型对所有的查询都是相同的这也是维度建模的一个优点。 资料来源 Ad Hoc Query https://www.techopedia.com/definition/30581/ad-hoc-query-sql-programming What is an Ad Hoc Query? https://www.wisegeek.com/what-is-an-ad-hoc-query.htm