运营商大规模数据集群治理的实践指南

写在开头的话

Q:  军哥,你们运营商行业的大规模集群,都有啥特点啊?

A:  我们集群主要是承载B域、信令和互联网日志等去标识化数据,简单的说,有三个特点:

1)集群规模较大:数千节点规模,近百PB数据量,日新增处理数据百TB以上;

2)组织干系人多:数据平台开发运维过程涉及到数百人以上的不同团队组织协同;

3)数据合规要求高:数据租户服务涉及到数据安全、用户隐私保护的合规要求高。

Q:  好吧,听起来,要搞定这样的集群,有难度呀!那何时要关注集群的治理呢?

A:  好问题!一般来说,当数据质量问题、数据交付及时性、数据安全问题需要耗费极高的应对成本,或者说,当你经常会碰到以下类似的问题时,就该考虑做系统化的集群治理工作了。

Q:  看起来,集群治理好像需要做很多配套的工作,实际上会有多大的产出效果呢?

A:  说出来,你可能不太信,就拿针对某集群治理的效果为例:在处理数据量翻倍的情况下,集群资源负载降低30%以上,综合计算节省数百台节点,每年节省投入上千万元;减少垃圾数据、测试数据、中间数据、过程数据,占总存储15%以上;核心产品模型运行时长,缩短30%-80%。一、集群治理的定位

Q:  我以前听说过数据治理,你这里说大规模数据集群的治理,有什么具体差异吗?

A:  好问题!不过要搞清楚这块,得先了解一下我们数据资产管理体系建设的实施路径——主要分三个子工程,同步开展实施推进:

  • 工程一:搭建核心业务数据治理框架,包括基础平台的建设、治理规范的制定,元数据管理、数据血缘和数据质量工具开发和应用实践,构建上层数据产品体系和数据能力开放平台,让数据多用活用,形成符合公司业务和组织协作特点的治理文化。
  • 工程二:实现全域数据计算集群的深度治理,完成全域数据治理元数据的自动化采集、存储和分析,构建数据能力开放平台多租户专项治理机制,沉淀数据治理中台能力,基于大数据集群底层核心组件(如YARN、HDFS)的深入洞察,孵化出数据集群治理的应用。
  • 工程三:完善治理机制体制建设,构建数据资产管理体系,并利用该系统的运营逐步重塑优化业务流程,实现可支撑全业务流程的成本评估机制,让数据价值持续攀升。

回到你刚才的提问,数据治理基本上可以理解为工程一的核心目标;大规模集群的治理对应工程二,它需要长期支撑工程一的具体建设任务,并为数据资产管理体系的运营夯实基础。

二、集群治理的背景 

Q:  你刚才说的好像很有道理,但是我还是不太明白,为何不是在数据治理工程中扩展一个子任务去做,而是要另起炉灶,搞一个新的大工程来做数据集群的专项治理?

A:  好问题!恭喜你!你快要触摸到数据集群治理问题的核心了。我们不妨再捋一下数据集群治理的背景,主要是遇到的历史部分集群无序建设的种种问题:

这些问题可进一步分为几类,简单分析完你就自然明白了:

1)管理类:集群接口机权限管控、数据表不合理创建和删除、垃圾数据表过多问题。这类问题,可以通过数据治理工程进行持续改进,但是解决时间周期以年为单位。

2)集群类:集群整体加工慢、稳定性欠佳、队列资源争抢、资源得不到合理分配的问题。这类问题,基本上要集群底层视角进行深入分析,在业务层做数据治理几乎无解。

3)洞察类:冗余计算浪费资源问题、智能实时预警、完整血缘和数据价值分析问题。这类问题只能通过大数据技术手段对Hadoop底层核心组件做深入洞察来解决。

三、集群治理的目标

Q:  听你这么说,针对大规模数据集群的治理工程还是很有必要的!

A:是的,“大规模”带来的问题,肯定不止上面这几类,实际上会远超你的想象,传统的数据治理工具(如元数据、数据质量、数据血缘分析)可能就不灵了,必须要根据集群规模、数据仓库新型技术方案选型以及业务流程进行重构,才可能得到预期的治理效果。再强调一句,大规模数据是长在集群之上,而集群里面的很多关键组件不是传统的商业关系型数据库,而是开源社区的通用版本,其可维护性、稳定性和功能局限性等方面都存在较大的挑战,性能这块也需要深入到源码层进行重构调优处理,你得做好准备。

所以,我们做大规模集群治理的核心目标聚焦在①确保集群稳定,充分保障集群资源算力;②以效果为导向,有效驱动平台数据治理1

充分保障集群资源算力

毫无疑问,在大规模集群计算环境,保障集群资源算力是首要任务。如果这一块稍有闪失,数据采集、数据存储、数据加工、数据建模分析、数据测试、数据稽核、数据迁移、数据同步、数据计算、数据作业重跑等流程可能都要崩溃,因为这些环节背后都涉及到大量的数据作业任务调度执行,其成功与否取决于分布式系统组件整体的通信、资源的申请、以及任务实例的执行结果,因此除了足够的物理资源池之外,还需要特别保障集群Master进程类服务的性能表现和稳定性。2

有效驱动平台数据治理

开展集群治理的工作,最重要的目标就是有效支撑数据治理工程的建设。

数据治理是一个系统工程,通常是按照类似下面的框架做:

其关键是组织、流程、平台工具、评价考核机制的全面协同。

首先是从数据采集加工流程中梳理出数据治理体系最需关注的各环节建设内容和目标:

然后构建元数据管理、数据质量稽核、数据血缘分析、数据地图等工具集:

  • 元数据管理:数据库表、模型脚本等元数据信息庞大复杂,可通过全文检索功能迅速查找和关键字匹配的权限范围内的元数据信息,为海量数据分析提供更快、更正确的查询处理、更好的数据质量、更易使用的操作接口等。
  • 数据血缘分析:元数据管理重要应用之一,展示表、视图、过程之间的关系,表和指标间的关系。采用NET模式或FLOW模式进行信息呈现。血缘关系的数据来源支持通过解析数据加工SQL脚本、存储过程注释的方式;可支持通过ETL流程自动生成的方式,亦可支持通过配置表的方式。
  • 数据地图:元数据信息的全景视图,描述所有元数据对象的血缘关系,所处层级覆盖范围由ODS->DWA->DWD->DM层,全面呈现了数据仓库中数据之间的关系。

如果你的数据集群规模不大,比如百节点以内,有非常完备的治理组织架构,按照传统的工具流程和方法论去做数据治理,一般问题不大。但是,如果是在运营商大规模集群环境,随着业务的发展,遇到新的问题时,光靠一些老套路是行不通的,或者说整体治理成本是极大的。在这样的大规模集群环境下,数据治理的本质其实就是:解决人与人的对抗、人与机器的对抗、人与工具的对抗、人与数的对抗问题。实践经验发现,只是靠堆人的方式,或者只在数据治理文化层面强调人机数的全面协同,要做好大规模集群的数据治理是不太现实的。更务实的做法是基于公司业务和组织架构特点,不断驱动和协同优化,还要借助大数据技术手段,精益推动数据集群侧的持续治理,形成数据治理+集群治理+资产管理的整体协同效应。

简而言之,集群治理支撑数据治理,数据治理驱动数据资产管理。数据中心的资产包括数据、程序、流程、服务及资源5大类,通过集群治理和资产的有效管理,对于促进数据价值持续发现、数据能力持续开放、数据的持续变现有巨大的促进作用,从而逐步推动数据治理体系向资产管理体系演进。四、集群治理的实施路径

Q:  军哥,说了半天,你好像还没有告诉我,到底如何开展集群的治理工作呀?

A:  不急,只要你明白了集群治理的定位、背景、目标,其实搞大规模数据集群的治理工作就没有那么难,按照以下8个步骤做就行:

第一步:理清大规模数据集群的现状和治理需求点

第二步:明确治理的组织架构、方法论、技术框架

第三步:构建针对大数据集群的智能运维技术平台

第四步:实现YARN作业&HDFS画像、小文件洞察

第五步:实现NN RPC画像、关键Master服务预警

第六步:实现冗余计算挖掘,以目录维度评估冗余度

第七步:重构数据血缘、元数据、数据资产管理应用

第八步:智能分析集群用户行为画像,检测预测异常

下文中将对以上八个步骤进行具体解读。五、集群治理的案例实践第一步:理清大规模数据集群的现状和治理需求点

  • 现状:Hadoop集群的计算能力已达到数千节点,平台部分集群初期由外部厂商进行建设,为了支撑业务快速上线,并没有统一规划,无序建设引发的问题逐渐暴露出来,权限混乱、计算能力下降、资源冗余计算、资源浪费等问题频发,针对该部分集群的稳定性和资源利用优化治理工作挑战巨大。
  • 需求点:数据治理项目实施的整体难点主要集中在运营商多源头数据质量持续改进、日万亿级大规模数据加工处理、数据平台资源弹性交付与产品化快速响应支撑能力、数据能力开放平台租户高效运营、数据平台智能运维体系建设、数据安全合规保障等六个方面。其中跟集群本身治理特别相关的是:集群智能运维平台搭建、Hadoop组件洞察应用、冗余计算挖掘、集群用户行为智能分析、数据血缘与元数据管理系统重构等五个方面。

第二步:明确治理的组织架构、方法论、技术框架治理组织架构

  • 集群治理组:负责集群治理平台应用和优化评测工具研发、治理方案的制定、组织治理周例会和专项优化虚拟小组联合讨论会、定期跟踪巡检治理效果,像牵引器一样驱动大家协同完成工作。
  • 数据治理组:除了负责数据质量和常规治理工作以外,还要配合集群治理组的方案,评估涉及到业务数据域基础模型采集加工过程中的改进优化需求点,然后负责具体实施,当然还包括相关产品支撑模型的重构、融合模型的整合优化工作。
  • 租户运营组:配合数据治理组、数据建模组和集群治理组完成租户场景集群治理专项方案的实施。
  • 平台维护组:配合产品应用部、数据治理组、租户运营组、数据建模组、集群治理组完成集群治理专项优化方案的实施。
  • 数据建模组:配合数据治理组、集群治理组完成集群治理平台AI类模型的开发。
  • 产品应用部:配合数据治理组和集群治理组完成集群治理专项优化方案的实施。

治理方法论

这里的核心就是建立自下而上、自发协同、精益推进式的数据治理文化。

治理技术框架

Q: 这个技术框架理解起来太抽象了,要解决的问题可以再解释一下吗?

A: 其实没有那么难以理解,主要是公司业务高速发展过程中数据业务需求越来越复杂,所需算力也越来越大,进一步导致某些集群的规模越来越大,承载的产品也越来越多,部分集群面临资源负载过高、资源抢占严重、RPC请求负载过高等问题;存储系统也面临空文件、垃圾文件、小文件过多,平均文件大小过小、文件数持续增长等问题,存储系统稳定性面临很大隐患;作业又面临执行耗时过长、耗资源大、数据倾斜严重等问题,直接导致数据加工异常率过高、数据具备时间有延迟风险、产品交付面临风险。基于以上面临的各种困境构建巡山大数据集群治理平台,以资源、存储、作业三大角度,从资源画像、作业画像、存储画像、冗余计算挖掘、数据血缘画像、RPC画像六大维度,几十个小维度进行集群交叉治理并协同各相关组织进行全域治理,使集群全面向良性健康方向发展。第三步:构建针对大数据集群的智能运维技术平台

Q:  军哥,搞大规模数据集群的治理怎么扯到智能运维平台上面去了呢?必须要建这个平台吗?

A:  好问题!前面说过,集群治理的首要目标就是充分保证集群资源算力,实际上就是要保障集群关键服务运行和数据作业资源调度的稳定性,以及相对不错的性能表现。

这里的稳定性和性能就是IT运维领域的事情,从业界发展来看,主要经历了四个阶段:

1)运维1.0,主要关注网管软件和ITSM工单系统,讲究业务协同和运维流程化。

2)运维2.0,主要关注CMDB和SOP标准运维,一般都会强调自动化工具在运维场景的应用,重点解决一些靠堆人方式解不了的问题。

3)运维3.0,主要关注DevOps、微服务、容器化的融合,比如基于容器云的DevOps一体化平台,打通项目管理、需求、研发、测试、上线、变更处理全流程。

4)运维4.0,主要关注AIOps,实现智能化的健康可用性分析、资源占用预测统计、异常检测、故障预警、智能扩缩容、日志根因分析应用等,其实就是用大数据的技术手段来搞定AIOps模型数据的采集、存储和分析处理。

一般来说,企业IT建设的头几年,会逐步上线CMDB、ITSM、Job自动化作业、SOP等子系统,然后开始考虑DevOps、容器云、AIOps等方向的建设。对于大规模数据集群来说,我们必须先构建好这个基础的智能运维技术平台。

总体架构

ITSM:IT流程服务管理系统,支持跨部门业务工作协同;CMDB:配置管理平台,IT资产应用统一配置化动态管理;Job:自动化作业平台,运维场景的作业批量自动化调度执行;SOP:标准运维平台,可视化拖拽模板化的运维流程定义和调度执行;DevOps: 开发运维一体化平台,公司平台级开发运维一体化管理模式;大数据集群治理平台应用:基于Hadoop内核组件深度分析,实现各类运维数据综合采集和统一整合,基于运维业务场景构建智能调度模型,提升平台数据处理作业性能,有效节省集群资源占用,实现平台集群资源利用率最大化。Monitor统一监控:先支持基础设施和平台集群监控应用,然后完成数据治理及上层产品层对接,逐步形成更全面的端到端统一监控平台。

数据生产监测可视化大屏

具体实施过程中,前期需重点关注平台优化和跨部门业务协同子系统的运营成效。

第四步:实现YARN作业&HDFS画像、小文件洞察

以底层技术为核心,从资源、存储、计算三大维度进行联合治理,深度监控各业务资源队列使用状态、存储系统文件分布、作业运行事件和配置,建立可视化工具体系,驱动日常优化和运营。

  • 从资源角度,对线上集群的资源队列状态进行秒级数据采集,包含队列最大容量、队列配置容量、队列已使用容量多维度的数据采集,实时监控不同业务线、不同周期资源使用状态,以达到动态调整资源规划、加工周期保障产线加工正常进行。
  • 从计算角度,通过采集全域作业信息,解析出数十项核心指标和千个作业配置,计算出作业耗时TOP、耗内存TOP、耗CPU TOP、数据倾斜TOP、高IO TOP以及从不同业务、不同周期、不同账户洞察待优化作业,针对不同异常类型给出相应优化方案,降低作业资源负载、降低输出文件数、提升输出文件大小,从而减低整个集群资源负载和提升存储系统稳定性。
  • 从存储角度,采集分布式存储系统的元数据镜像和元数据操作日志,洞察分布式存储系统文件数趋势、文件分布统计、平均文件大小趋势统计、空文件分布、垃圾文件分布。

技术实现方案

第五步:实现NN RPC画像、关键Master服务预警

大数据集群有很多关键服务,这些服务的健康异常状态,需要重点监控,且尽可能做到实时处理效果,这样在故障发生后可以组合多种监控和日志信息,从多个维度交叉定位问题,提升解决问题效率。技术实现方案

第六步:实现冗余计算挖掘,以目录维度评估冗余度

冗余计算意味着同一份数据被多个加工流程加工,主要是由于前期为了支撑业务快速上线、没有统一规划、无序建设过程中所引发的问题,在运营商海量数据背景下,数据重复加工意味着对内存、CPU、存储容量、IO、文件数量、RPC负载有着全面且巨大的影响,在全域数十万加工作业中如何全面且精准定位冗余计算成为不小的挑战,基于此持续优化线上加工流程更是一个缓慢的过程,需要详细梳理业务需求,制定数据标准,明确数据口径。

洞察冗余计算主要思路是解析全域数十万个作业并从每个作业千个配置项中解析出输入目录,每个作业会有多个输入目录,最多的有上百个甚至上千个,且目录中含有省份、账期、基站等各种分区类型,我们需要对目录进行通用化处理,以目录为维度统计对应的加工流程以及每个加工流程对应的作业实例,从每个作业实例中计算内存消耗、CPU消耗、存储消耗、IO负载、文件数增长、RPC负载以评估冗余计算带来的成本、优化后达到的效果、执行周期内对其他数据加工产生的影响,以精细化数据为基础协调各组织进行持续治理。技术实现方案

第七步:重构数据血缘、元数据、数据资产管理应用
面临挑战

在某集群长期的无序建设中,由于对数据缺少平台级的运营手段,比如缺少数据库、数据表以及数据列统一的信息维护平台和整体的物理视图,导致底层数据存在过多垃圾表,且缺少对底层数据的认知;

对元数据的变更无监控无跟踪,缺少全域加工数据血缘关系,不能追溯数据加工流向,导致故障发生后不能明确影响范围,数据成本与价值也难以衡量,在安全合规为第一红线的背景下,对敏感数据也没有效跟踪;

缺少数据资产管理,没有展示数据应有的支撑能力,造成组织架构内数据服务信息不对称。

基于以上痛点,着手重构了企业级全域元数据平台,提供全域物理视图、业务视图、元数据变更跟踪监控、全域数据血缘关系图等核心功能,物理视图提升对数据的认知,业务视图展示数据支撑能力,元数据变更跟踪实时了解产线环境异常修改,数据血缘可提供数据追溯、数据成本价值洞察、敏感数据流向。

元数据平台视图

元数据平台应用

全域数据血缘关系图技术实现方案

第八步:智能分析集群用户行为画像,检测预测异常

产线环境难免存在数据被误删除的情况,故障发生后,一般要通过较复杂的综合定位过程才能发现根因,此时产线加工可能受阻、数据具备时间延迟,进一步影响到产品质量和用户体验;由于此类故障从根本上难以彻底消除,为尽可能的降低负面影响,可建立用户行为异常操作智能检测机制,对不正常的用户操作及时预警,在一定程度上提前发现问题、规避故障。技术实现方案

根据产线环境千万级的作业信息,结合当下的资源状态进行特征抽取,建立实时的机器学习模型,对当前以及未来一段时间窗口的资源占用进行预测,将检测到的异常状态波动进行告警。

六、结语
在运营商大规模集群治理的实践过程中,有几点感悟:

1)领导的支持力度非常关键。公司领导对数据资产管理建设的价值认可,能够在核心数据质量持续优化过程中提供组织协调支持,有效推动集团和各省分公司配合改进,保障端到端质量优化效果。

2)数据治理文化建设是核心。建立专业的数据治理团队,优化数据资产管理组织架构,以自底向上的完整血缘分析、核心数据质量为入口,建立自下而上、自发协同、精益推进的数据治理文化。

3)数据资产管理架构和配套工具是基础。在业务发展过程中,逐步打造体系化的数据治理实施能力,安全合规标准规范先行,建立持续优化的治理体制。

4)数据能力开放平台是优势。通过面向外部租户自助建模平台的综合运营,可大幅提升内部数据治理工程跨组织的协同效率,数据用多了,自然会激发治理的原动力。

5)基础平台团队要拥抱并吃透开源技术。能够从大数据平台核心组件源码层进行重构与性能调优,充分保障集群的稳定性和算力要求,在大规模集群故障预测、异常检测、故障恢复、资源调度优化、跨集群协同计算等方向全面探索和应用AIOps技术解决难题

原文链接:https://mp.weixin.qq.com/s/C0eygTSdPhFKzHD1GcZk1A

Image placeholder
老付
未设置
  45人点赞

没有讨论,发表一下自己的看法吧

推荐文章
多云时代下大规模数据库管理,该怎么做?

中国经济的高速发展是世界各国人们有目共睹的,随着数字经济时代的到来,金融数据库的管理,也随之面对一系列的新技术与挑战。云计算一直以来被认为是极具颠覆性的技术力量,随着云计算的应用普及,越来越为企业重视

etcd 在超大规模数据场景下的性能优化

作者|阿里云智能事业部高级开发工程师 陈星宇(宇慕)划重点etcd优化背景问题分析优化方案展示实际优化效果本文被收录在5月9日cncf.io官方blog中,链接:https://www.cncf.io

美团大规模微服务通信框架及治理体系OCTO核心组件开源

微服务通信框架及治理平台OCTO作为美团基础架构设施的重要组成部分,目前已广泛应用于公司技术线,稳定承载上万应用、日均支撑千亿级的调用。业务基于OCTO提供的标准化技术方案,能够轻松实现服务注册/发现

中国进入5G普及时代!三大运营商5G套餐正式公布,每月128起,联通最壕套餐599

大数据文摘出品作者:曹培信、刘俊寰5G手机已经卖了一批了,三大运营商的5G套餐却姗姗来迟。原本定于10月1日发布5G套餐,之后又推迟了一个月,并且中国三大运营商在公布服务价格之前,已预先向1000万用

大神讲解微服务治理的技术演进和架构实践

摘要:随着业务的发展,规模扩大,服务越来越多,需要协调线上运行的各个服务,保障服务的SLA;基于服务调用的性能KPI数据进行容量管理,合理分配各服务的资源占用;对故障业务做服务降级、流量控制、流量迁移

超大规模商用 K8s 场景下,阿里巴巴如何动态解决容器资源的按需分配问题?

导读:资源利用率一直是很多平台管理和研发人员关心的话题。本文作者通过阿里巴巴容器平台团队在这一领域的工作实践,整理出了一套资源利用提升的方案,希望能够带给大家带来一些讨论和思考。引言不知道大家有没有过

强化学习在小桔车服用户运营中的实践

桔妹导读:小桔车服为滴滴旗下品牌,围绕车主及汽车生命周期,整合运营多项汽车服务,更加智能更加用心地为车主提供适合的一站式用车服务,致力于让每一个人拥有轻松车生活。本次分享的主题为强化学习在小桔车服用户

美团下一代服务治理系统 OCTO2.0 的探索与实践

本文根据美团基础架构部服务治理团队工程师郭继东在2019QCon(全球软件开发大会)上的演讲内容整理而成,主要阐述美团大规模治理体系结合ServiceMesh演进的探索实践,希望对从事此领域的同学有所

如何为数据集选择正确的聚类算法

应用聚类算法比选择最佳算法要容易得多。每种类型都有其优缺点,如果您想要一个整洁的集群结构,就必须认真考虑。数据聚类是安排正确的整个数据模型的重要步骤。为了进行分析,应根据共同点整理信息。主要的问题是,

亚马逊将公布超过最大会话和知识数据集,超400万字

4月1日,亚马逊宣布:他们计划向公众公开“TopicalChat”数据集,超410万单词21万句子的语料库将于2019年9月17日发布。该数据集是为参加AlexaPrizeSocialbotGrand

PB级数据实时查询,滴滴Elasticsearch多集群架构实践

Elasticsearch是基于Lucene实现的分布式搜索引擎,提供了海量数据实时检索和分析能力。Elastic 公司开源的一系列产品组成的ElasticStack,可以为日志服务、搜索引擎、系统监

influxDB集群模式实践

influxDB数据库以其优秀的时序数据存储和查询能力,在处理和分析类似资源监控等时序数据方面得到了广泛的应用。而influxDB自带的各种特殊函数如求平均值、标准差、随机取数据,使数据分析变得十分方

美团点评Kubernetes集群管理实践

背景作为国内领先的生活服务平台,美团点评很多业务都具有非常显著、规律的“高峰”和“低谷”特征。尤其遇到节假日或促销活动,流量还会在短时间内出现爆发式的增长。这对集群中心的资源弹性和可用性有非常高的要求

侵入式服务治理方案,读这一篇就够

尽管在程序执行效率上,Java不如C、C++,在开发效率、易用性以及学习难度上,Java又不如Ruby、Python、Go,但Java无疑是当今后端系统开发中使用最为广泛的语言。Java所累积的大量生

微服务治理与统计分析

转载本文需注明出处:微信公众号EAWorld,违者必究。引言:微服务架构下,服务拆得越细,服务的粒度越小,可组装性就越好;与之相对的服务之间的调用关系就会变复杂,为了保证服务更好的运行,需要对这些服务

数字化治理是城市数字化转型的主阵地

春常在,宜常来,月亮之城宜春迎来了大数据与AI盛开的春天。在日前举办的首届华为∙宜春城市大数据与人工智能高峰论坛上,宜春市人民政府市长王水平表示,宜春市抢抓以智能化、大数据为标志的世界第四次工业革命的

亿级海量数据的实时读写和复杂查询实践

摘要:本文分享了每日亿级增量数据的实时读写、复杂查询场景实践介绍,涉及MySQL分表分库策略、数据异构、TiDB使用和优化、微服务架构等内容。  作者:黄哲铿  黄哲铿,中通商业CTO,前1号店技术总

餐饮SaaS规模之战一触即发 客如云显制胜决心

记得上小学的时候腊月时节下起了夜雨,第二天清晨寒风凛冽中公路铺满了薄薄的冰层,外出行人即使再小心也不免滑倒。2018年对于创业者来说何尝不是一个下雨的冬天,宏观经济带来了凛冽寒风。国内民以食为天,去年

AWS计划扩大其在中国市场的业务规模

近日,AWS首席云计算企业顾问张侠表示,AWS希望在中国快速发展的云计算市场中占有更大的份额。  AWS首席云计算企业顾问张侠(Digitimes的AaronLee摄)AWS在全球云计算市场中占有40

史上规模最大的中文知识图谱以及估值两个亿的 AI 核心代码

——大声告诉我,怎样才能可以让你变得更强?——充钱——???——都什么玩意?还有啥子咧?——充更多钱执迷不悟,无可救药了。所以,正确答案应该是什么呢?答:是知识。反正,说这些就是为了切入「知识」这个话

万亿级消息背后: 小米消息队列的实践

目录业务背景架构与关键问题性能与资源优化平台化效率小米消息中间件的规划与愿景前文《消息队列价值思考》讲述了消息中间件在企业IT架构中的重要价值,本文将呈现这些价值在落地小米业务过程中的遇到的问题和实践

一篇文章看懂,存储虚拟化在不同用例中的实践与优势

存储虚拟化是一种对物理存储资源进行抽象的技术,使其看起来像是一个集中的资源。虚拟化掩盖了管理内存、网络、服务器和存储中资源的复杂性。存储虚拟化运行在多个存储设备上,使它们看起来就像一个单一的存储池。这

机器学习在高德用户反馈信息处理中的实践

1.背景作为国内领先的出行大数据公司,高德地图拥有众多的用户和合作厂商,这为高德带来了海量的出行数据,同时通过各个渠道,这些用户也在主动地为我们提供大量的反馈信息,这些信息是需要我们深入挖掘并作用于产

HDFS3.2升级在滴滴的实践

桔妹导读:Hadoop 3的第一个稳定版本在2017年底就已经发布了,有了很多重大的改进。在HDFS方面,支持了ErasureCoding、Morethan2NameNodes、Router-Base

已配置 4000+ 页面,携程前端组件化探索之“乐高”运营系统

一、前言 市场部活动组主要负责各种运营活动的相关开发,分为常规运营活动和定制运营活动。常规运营活动因为组件(模块)具有复用性,并且配置化需求非常多,因此我们建设了一个可视化页面搭建平台——乐高(leg