网站策划布局长沙seo外包优化

网站策划布局,长沙seo外包优化,网站开发双语,可以做网站素材的服装一#xff1a;百亿级 海量存储数据服务的业务背景 很多公司的业务数据规模庞大#xff0c;在百亿级以上#xff0c; 而且通过多年的业务积累和业务迭代#xff0c;各个业务线错综复杂#xff0c;接口调用杂乱无章#xff0c;如同密密麻麻的蛛网#xff0c;形成了难以理清…一百亿级 海量存储数据服务的业务背景很多公司的业务数据规模庞大在百亿级以上 而且通过多年的业务积累和业务迭代各个业务线错综复杂接口调用杂乱无章如同密密麻麻的蛛网形成了难以理清的API Call蜘蛛网。API 调用蜘蛛网 如图 所示这种API 调用蜘蛛网的特点是第一各个业务线互相依赖。A向B要数据B向C请求接口C向A需求服务循环往复令人目不暇接。第二各自为政独立发展。各业务线各有财产各自为营宛如诸侯割据拥兵自重。各自一滩、烟囱化非常严重。第三无休止的跑腿成本、无休止的会议沟通成本沟通和协调成本让人望而生畏。如何降低成本降本增效 迫切需要进行各个业务线的资源的整合、数据的整合、形成统一的海量数据服务这里成为为 数智枢纽(Data Intelligence Hub)服务/ 或者百亿级 数据中心服务 通过 统一的 数智枢纽(Data Intelligence Hub)服务 将这错综复杂的蜘蛛网变成简明的直线班车。数智枢纽(Data Intelligence Hub)服务 / 或者百亿级 数据中心服务 如下图 所示数智枢纽(Data Intelligence Hub)服务/ 或者百亿级 数据中心服务带来的几个优势第一将省去不必要的接口调用。业务穿插不再混乱减少无休止的会议沟通解决数据难以获取、速度缓慢的问题。第二统一数据中心将大大节省产品和开发人员的时间提升整体工作效率。各个业务线在新的系统下将协同作战资源高效利用真正实现事半功倍。第三进行统一的高可用优化、高并发优化确保稳如泰山快如闪电。总而言之数智枢纽(Data Intelligence Hub)服务 的出现将从根本上改变我们的统一数据存储和数据访问的工作方式实现资源整合和效率提升。最终实现了 稳如泰山快如闪电大气磅礴节约成本清晰明了。二架构设计与模块介绍先看一下整体架构整个数智枢纽(Data Intelligence Hub)服务 核心主要分为数据统一接入层数据统一查询层元数据管理索引建立平台监控在线与离线数据存储层先看一下整体架构图如下图下面将分别对其进行介绍。三数据统一查询层的业务梳理一般来说数据统一查询层大同小异可以总结出以下几大常见的数据查询类型Key-Value查询最简单的kv查询并发量可能很高速度要求快。比如风控。Key-Map查询定向输出比如常见的通过文章id获取文章详情数据kv查询升级版。MultiKey-Map批量查询比如常见的推荐Feed流展示Key-Map查询升级版。C-List多维查询查询指定多个条件进行数据过滤条件可能很灵活分页输出满足条件的数据。这是非常常见的比如筛选指定标签或打分的商品进行推荐、获取指定用户过去某段时间买过的商品等等。G-Count统计分析查询数仓统计分析型需求。如数据分组后的数据统计。G-Top统计排行查询根据某些维度分组展示排行。如数据分组后的最高Top10帖子。四海量数据存储层的技术选型解决海量数据的存储并且能够实现海量数据的秒级查询, 首先要进行海量数据存储层的技术选型.一般来说有两种HBaseMongoDBMongodb用于存储非结构化数据尤其擅长存储json格式的数据或者是一些很难建索引的文本数据,。Mongodb 存储的量大概在10亿级别再往上性能就下降了除非另外分库。Hbase是架构在hdfs上的列式存储擅长rowkey的快速查询但不擅长模糊匹配查询其实是前模糊或全模糊Hbase的优势是存储的量可以达到百亿甚至以上比mongodb的存储量大多了。在于写入的速度上hbase由于只维护一个主键写入的速度要比mongodb这种要维护所有索引的数据库快多了。在于服务器的数量上hbase占用两台机器能完成的事情mongodb要占用更多的机器每台机器按一年20000的费用几百台下来就是一笔很大的费用。总之MongoDB更擅长存储需要在线访问的NOSQL文档并且通过索引更善于做查询存储能力弱。Hbase更偏向非关系型数据库扩展储存能力强。所以现在很多公司都选用HBASE而 不选用Mongodb因为一旦数据量过大再去改结构很复杂。五数据统一查询层的架构设计Hbase是典型的nosql是一种构建在HDFS之上的分布式、面向列的存储系统在需要的时候可以进行实时的大规模数据集的读写操作前面讲到Hbase是架构在hdfs上的列式存储擅长rowkey的快速查询但不擅长模糊匹配查询其实是前模糊或全模糊注意Hbase 不擅长模糊匹配查询。如何实现 数据统一查询层这个时候我们就是用elasticsearch架构在hbase之上数据统一查询层的架构是elasticsearch hbase结合海量的数据存储使用hbase数据的即席查询快速检索使用elasticsearch最终通过elasticsearchhbase就可以做到海量数据的复杂查询elasticsearchhbase 的基本原理很简单将Elasticsearch的DOC ID和Hbase的rowkey相关联。在数据接入的时候通过构建统一的、全局唯一 ID 既当做Elasticsearch的DOC ID 也当做Hbase的rowkey。在统一数据服务构建ID然后先写入 hbase再发送kafka 消息 异步写入ES。将源数据根据业务特点划分为索引数据和原始数据索引数据指需要被检索的字段存储在Elasticsearch集群中原始数据指不需要被ES检索的字段包括某些超长的文本数据等存储在Hbase集群中。当然在操作之前我们还要考虑一批数据在elasticsearch中构建索引的时候针对每一个字段要分析是否存储和是否构建索引这个就需要根据元数据进行有效的控制。实际查询的过程是先ES根据条件查询到分页数据或者是list里面封装的是那个所有实体类、然后遍历通过遍历到的id去查hbase之后就可以封装Dto然后返回List将HBase的rowkey设定为ES的文档ID搜索时根据业务条件先从ES里面全文检索出相对应的文档从而获取出文档ID即拿到了rowkey再从HBase里面抽取数据。elasticsearchhbase 的优点1.发挥了Elasticsearch的全文检索的优势能够快速根据关键字检索出相关度最高的结果2.同时减少了Elasticsearch的存储压力这种场景下不需要存储检索无关的内容甚至可以禁用_source节约一半的存储空间同时提升最少30%的写入速度3.避免了Elasticsearch大数据量下查询返回慢的问题大数据量下Hbase的抽取速度明显优于Elasticsearch4.各取所长发挥两个组件各自的优势。好像ES天生跟HBase是一家人HBase支持动态列ES也支持动态列这使得两者结合在一起很融洽。而ES强大的索引功能正好是HBase所不具备的如果只是将业务索引字段存入ES中体量其实并不大甚至很多情况下业务索引字段60%以上都是Term类型根本不需要分词。总之 ES天生 就是hbase 的外置索引elasticsearchhbase 的 缺点1、两个组件之间存在时效不一致的问题相对而言Elasticsearch的入库速度肯定是要快于Hbase的这是需要业务容忍一定的时效性对业务的要求会比较高。2、同时管理两个组件增加了管理成本显而易见同时维护两套组件的成本肯定是更大的。 当然既然是百亿级数据这点维护人员还是要有的。六数据统一接入服务介绍数据统一接入服务在springboot中通过HBase-Client API进行了二次轻封装支持在线RESTFUL服务接口和离线SDK包两种主要方式对外提供服务。为了提升吞吐量数据统一接入服务可以兼容HBase原生API和HBase BulkLoad大批量数据写入。当然数据统一接入服务需要做很多工作比如统一id的生成权限管理负载均衡失败恢复动态扩缩容数据接口监控等等。在数据统一接入服务中为了适应不同的数据源和业务需求主要涉及三种接入模式定时拉取REST实时推送消息队列MQ推送。以下是对这三种模式的详细介绍1. 定时拉取定时任务 系统按照预设的时间间隔定时从数据源拉取数据。数据同步 适用于数据变化不频繁、实时性要求不高的场景如批量数据同步和周期性报告生成。任务调度 使用调度器如Quartz来管理和执行定时任务。定时拉取实现方式大致如下配置定时任务 设置任务调度器的时间间隔和拉取频率。数据拉取 编写数据拉取逻辑通过API、数据库查询等方式从数据源获取数据。数据处理 对拉取的数据进行清洗、转换和存储。日志和监控 记录拉取过程的日志监控任务执行情况。2. REST实时推送实时推送 数据源在数据产生或变化时立即通过REST API推送数据到接入服务。事件驱动 适用于数据变化频繁、实时性要求高的场景如实时监控和即时通知。API接口 提供统一的REST API接口供数据源调用进行数据推送。REST实时推送的实现方式主要如下定义API接口 设计和实现数据接收的REST API。数据接收 编写接收数据的逻辑处理并存储推送的数据。数据验证 对接收的数据进行验证确保数据完整性和正确性。响应处理 返回接收结果处理异常情况。3. MQ异步推送消息队列 使用消息队列如RabbitMQ、Kafka进行数据推送保证数据传输的可靠性和可扩展性。异步处理 适用于高并发、大数据量的接入场景。解耦设计 生产者和消费者解耦提升系统的灵活性和可维护性。MQ异步推送的实现方式主要如下配置消息队列 设置消息队列服务器和相关配置。消息生产者 数据源作为消息生产者将数据发送到消息队列。消息消费者 接入服务作为消息消费者从消息队列中获取并处理数据。数据处理 对获取的数据进行清洗、转换和存储。这三种接入模式各有优劣选择合适的模式需要根据具体的业务需求和场景进行评估定时拉取适用于数据变化不频繁、实时性要求不高的场景实施简单、易于管理。REST实时推送适用于数据变化频繁、实时性要求高的场景适合事件驱动的系统设计。MQ推送适用于高并发、大数据量的场景通过异步处理和解耦设计提升系统的扩展性和可靠性。综合使用这三种模式可以构建一个高效、灵活、可扩展的数据统一接入服务。七元数据管理服务的架构设计元数据管理服务 主要就是对接我们上文业务梳理模块归纳的各种业务需求都由此模块提供服务。顾名思义元数据管理服务 提供两个方面的元数据管理无论是存储策略元数据还是查询策略元数据主要用于为用户配置策略或用户自己配置策略最终基于策略生成策略ID。虽然 HBase和ES一样也是No-Schema模型是可以动态创建字段的但是元数据管理服务 还是 为其HBase和ES做一个显示的 Schema管理同时去动态控制哪些字段要建索引。无论是存储策略元数据还是查询策略元数据主要是对ElasticSearch和HBase的meta data/表结构的一些抽象/封装然后在创建 hbase Table /ES document 结构的时候或者读取 hbase Table /ES document 的时候进行动态映射 。另外在查询ES的时候会通过动态模板将用户请求转化为ElasticSearch DSL语句而后对ES进行查询直接返回数据或是获取到rowkey进而查询HBase进行结果返回。通过元数据管理中心我们可以判断出用户所需字段是否被索引字段覆盖是否有必要二次查询HBase返回结果。而这整个查询过程用户并不会感知他们只需要一个PolicyID即可。当然我们也在不断普及用户如何通过后台自己配置生成策略。合作较多的业务方甚至可以自己在测试环境配置好一切完成数据的自助获取工作。而我们需要做的只是一键同步测试环境的策略到线上环境并通知他们线上已可用。通过元数据管理服务的架构设计可以快速的配置各种数据查询接口整个过程5~10分钟一个新的接口就诞生了。其次由于ES抗压能力并不是太强这里可以引入redis 缓存策略接口也会根据业务需求决定是否开启 redis 缓存。事实上大部分接口是可以接受短时间内数据缓存的。当然像简单KV、Key-Map 这种是直接走HBase的并不需要缓存。为啥 因为Hbase的吞吐量很高总之由于ES的DSL功能丰富通过元数据管理服务的策略配置可以动态支持分词查询、分桶查询、多表联合查询、TopN、聚合查询等多种复合查询等等。通过元数据管理服务 维护一套元数据方便我们做一些简单的页面指标监控并对ES和HBase有一个总的控制如建表删表等。其次可以在数据接入的时候我们会通过元数据中心判断数据是否符合表和索引的规则在数据输出的时候我们控制哪些策略需要走缓存哪些策略不需要走HBase等等。八. HBase 和 ES 的数据一致性架构HBase 和 ES 的数据一致性有两种方案HBase WAL ESHBase Kafka ES方式一HBase WAL ES 实现数据一致性Hbase在底层是以K-V类型存储的。每条数据的每个属性都会保存一条记录由于HDFS不支持随机写操作所以当修改属性时不会修改记录而是插入一条新的记录每条记录除了包含数据的属性外还包含一个[时间戳(TimeStamp)表示数据更新时的时间一个数据类型(Type)表示数据时修改还是删除或者是插入等。如row key为row_key1的这条数据初始情况下在底层实际上存储了三条记录分别记录了这条数据的name、city、phone属性当要修改数据的phone属性时则再插入一条记录表示新的phone属性根据时间戳判断最新的那条记录有效。预写日志WALWAL(Write-Ahead Log)预写日志是一个保险机制。当向Hbase写入一条数据时Hbase首先会将数据写入WAL然后再把数据放入内存中Memstore而不会立即落盘。当查询时也是先在内存中查询如果内存中没有查询到才会在磁盘中进行查询。当Memstore中的数据达到一定的量时才刷写flush到最终存储的HFile内。而如果在这个过程中服务器宕机或者断电了那么数据就丢失了。但是有了WAL机制在Hbase将数据写入Memstore前就先写入了WAL这样当发生故障后就可以通过WAL将丢失的数据恢复回来。WAL是一个环状的滚动日志结构这种结构写入效果最高而且可以保证空间不会持续变大。WAL的检查间隔由hbase.regionserver.logroll.period定义默认值为1小时。检查的内容是把当前WAL中的操作跟实际持久化到HDFS上的操作比较看哪些操作已经被持久化了被持久化的操作就会被移动到.oldlogs文件夹内这个文件夹也是在HDFS上的。一个WAL实例包含有多个WAL文件。WAL文件的最大数量通过hbase.regionserver.maxlogs默认是32参数来定义。WAL是默认开启的也可以选择关闭或延迟异步同步写入WAL。HBase WAL ES 实现数据一致性 实现步骤设置 HBase 的 WAL 日志位置 在 HBase 的配置文件 hbase-site.xml 中配置 WAL 日志路径。xml复制代码propertynamehbase.regionserver.hlog.dir/namevalue/hbase/wal/value/property编写 WAL 日志解析服务 编写一个独立的服务定期读取 WAL 日志文件解析其中的写操作并同步到 Elasticsearch。同步到 Elasticsearch 在解析服务中将提取的数据变更信息写入到 Elasticsearch。HBase WAL ES 实现数据一致性 方案的问题WAL层不太好控制和监控ES消费WAL的存在效率问题总之WAL层数据一致性不好维护。方式二HBase kafka ES 实现数据一致性HBase kafka ES 实现数据一致性 方案如下图数据接入层在数据写完HBase之后即对外响应Success并异步将数据推至Kafak队列中等待ES去二次消费写入ES失败则对外抛出异常这里首先要保证的是写入HBase要么成功要么失败。在ES消费层我们是可以动态指定消费线程数量的。当Kafka Lag堆积超过一定阈值阈值可进行Group级调节和监控会进行警报并动态调整消费线程数。由于使用了异步架构只保证数据最终一致性。当数据写入HBase成功之后会对写Kafka和写ES进行链路追踪任何一个环节一旦写入失败即将Failed Key写入黑名单Redis存储。对于进入黑名单的数据我们会起定时调度线程去扫描这些Key并进行自动回补索引。回补方式是到HBase中拿最新的数据再次写入队列中去。如果此时又失败会把这些Key放入终极死亡名单Redis存储并通过定时调度线程去扫描这个死亡名单如果有尸体则报警此时人力介入。方便大家理解简单画了一下这个流程见下图九hbase集群间数据同步replication先看一下整体架构图咱们有两个hbase集群 如下图一个是 在线计算一个负责离线计算两个集群之间需要数据复制。HBase 提供了内置的复制机制可以在不同的 HBase 集群之间同步数据。这种机制称为 HBase Replication它允许将数据从一个 HBase 集群复制到另一个 HBase 集群通常用于数据备份、灾难恢复、多数据中心部署等场景。Replication复制指的是持续的将同一份数据拷贝到多个地方进行存储是各种存储系统中常见而又重要的一个概念可以指数据库中主库和从库的复制也可以指分布式集群中多个集群之间的复制还可以指分布式系统中多个副本之间的复制。它的难点在于数据通常是不断变化的需要持续的将变化也反映到多个数据拷贝上并保证这些拷贝是完全一致的。HBase 的复制机制基于 WALWrite-Ahead Log。当数据写入到主集群Master Cluster时写操作首先被记录到 WAL 中然后这些 WAL 日志被传输到从集群Slave Cluster从集群再根据这些日志进行数据重放从而实现数据同步。通常来说数据复制到多个拷贝上有如下好处多个备份提高了数据的可靠性通过主从数据库/主备集群之间的复制来分离OLTP和OLAP请求提高可用性即使在单副本挂掉的情况下依然可以有其他副本来提供读写服务可扩展通过增加副本来服务更多的读写请求跨地域数据中心之间的复制Client通过读写最近的数据中心来降低请求延迟HBase中的Replication指的是主备集群间的复制用于将主集群的写入记录复制到备集群。HBase目前共支持3种Replication异步Replication串行Replication同步Replication本文介绍的是第一种异步Replication。首先看下官方的一张图需要声明的是HBase的replication是以Column Family为单位的每个Column Family都可以设置是否进行replication。上图中一个Master对应了3个SlaveMaster上每个RegionServer都有一份HLog在开启Replication的情况下每个RegionServer都会开启一个线程用于读取该RegionServer上的HLog并且发送到各个SlaveZookeeper用于保存当前已经发送的HLog的位置。Master与Slave之间采用异步通信的方式保障Master上的性能不会受到Slave的影响。用Zookeeper保存已经发送HLog的位置主要考虑在Slave复制过程中如果出现问题后重新建立复制可以找到上次复制的位置。HBase Replication步骤HBase Client向Master写入数据对应RegionServer写完HLog后返回Client请求同时replication线程轮询HLog发现有新的数据发送给SlaveSlave处理完数据后返回给MasterMaster收到Slave的返回信息在Zookeeper中标记已经发送到Slave的HLog位置注在进行replication时Master与Slave的配置并不一定相同比如Master上可以有3台RegionServerSlave上并不一定是3台Slave上的RegionServer数量可以不一样数据如何分布这个HBase内部会处理。十 平台监控模块介绍平台监控模块主要包括基础平台的监控 应用平台监控。基础平台的监控 包括 Hadoop集群、HBase集群的监控外加K8S平台监控。应用平台监控 包括数据 配置/ 数据统一接入 / 数据统一存储 /数据统一服务 的监控。