首页 文章 精选 留言 我的

精选列表

搜索[AI生态系]，共10000篇文章
优秀的个人博客,低调大师

浪潮成为OpenStack成员 推动开放云生态系统构建

继刚刚宣布与阿里云达成战略合作之后，浪潮于28日正式宣布加入国际云计算权威组织——OpenStack基金会，成为全球最有活力的开源云平台管理项目的重要成员。浪潮作为中国领先的云计算整体解决方案供应商，此次加入OpenStack后，将会更有效的帮助中国企业和云服务商构建起先进的云计算基础架构，推动云计算在中国的应用落地。同时，基于在云计算技术层面的深厚储备，浪潮的加入也将推动OpenStack标准的完善。 OpenStack作为Rackspace 和 NASA 共同开发的云计算平台，通过开放的社区直接把用户引入到云计算创新过程中，其首要任务是简化云的部署过程并为其带来良好的可扩展性。OpenStack 采用“以用户为中心”的社会化研发方式，对全球云计算的发展模式产生了深远的影响，使得用户不再受制于平台，而是可以方便、灵活的将数据在各种开源云计算平台间迁移。随着云计算应用越来越广泛，越来越多的企业乐于使用那些不是以单一厂商主导的云计算基础设施，开源软件项目可以帮助他们摆脱对某类产品的依赖和被锁定，无论从开放性、灵活性还是成本上，开源软件都是一个非常好的选择。OpenStack成立之后，其确立的“开放”核心价值理念，促进了社区的蓬勃发展，而随着厂商的不断加入、社会化研发模式的成熟、精英团队的领导、灵活的架构设计，使得OpenStack成为了全球最有活力的开源项目，有第三方机构评价，OpenStack有望成为“云时代的Linux”。据统计，OpenStack推出至今，已经在全球56个国家的电信、金融、IT、医疗、教育、政府等领域取得广泛应用。 目前，OpenStack组织吸引了超过190家公司和2000个开发者的加入，IBM、HP、AT&T、RedHat、SUSE、Canonical、Cisco、 Dell、VMware等都是其重要成员。OpenStack基金会是该组织的核心管理机构，对于成员准入审核有着严格的标准，会综合考量申请者的技术积累及研发能力，要求必须能够具有反哺OpenStack社区的能力。浪潮作为中国领先的云计算供应商，已形成涵盖IAAS、PAAS、SAAS三个层面的云计算整体解决方案服务能力，能够在主机、通用服务器、海量存储、云操作系统等为客户打造领先的云基础架构和解决方案，其解决方案已经广泛应用于政务、工商、水利、交通、金融等十余个行业。 浪潮云产品部总经理王峰表示：“深厚的技术积累和丰富的行业应用经验，是浪潮成为OpenStack基金会成员的重要原因，浪潮将在这一开放平台贡献自己的力量。”据王峰介绍，浪潮加入OpenStack基金会后，将致力于推动云操作系统标准的完善，OpenStack将为浪潮提供社区开放资源，为云海OS下一代产品提供技术支持；浪潮云海OS产品将在未来兼容OpenStack标准，并且分享云海OS部分代码。云操作系统被称作云数据中心的“中枢神经”，OpenStack被看作是国际上最权威的云操作系统标准。 浪潮一直在积极参与云操作系统领域国际国内标准的制定。除参与OpenStack等国际云操作系统标准的应用和推广，浪潮还积极推动国内云操作系统相关规范和标准的制定。近日浪潮参与制定了公安部牵头起草的《云操作系统安全检验要求》规范，并成为首批认证成员，目前这一规范正在积极申请成为国家标准。 随着开源社区越来越成为云计算发展的重要推动力，越来越多的企业已经意识到开源社区对未来云计算发展的重要性，开始以自己的方式影响和参与社区的发展。浪潮、华胜天成等国内企业成为OpenStack基金会成员，积极参与国际开源云计算标准的制定和落地，将有助于中国IT企业在云计算这新一轮的产业竞争中占据主动，确保全球云计算应用环境中“中国声音”的存在。 本文作者：佚名 来源：51CTO
2017-08-01
优秀的个人博客,低调大师

博通谈物联网战略：“垂直分工”与生态系统

垂直分工，是半导体行业的一个术语，指Fabless（IC设计公司）、Foundry（芯片代工）之间分工合作的模式。 博通是一家典型的“垂直分工”Fabless，其芯片由台积电代工。实际上这家半导体巨头并不局限于芯片制造，在芯片到产品的过程，这种早期的基因也深深影响着。甚至在早期的物联网领域，博通依然恪守着“垂直分工”的合作模式。 博通是已知最早公开推出物联网支持的芯片厂商（之一），它的WICED平台早在2011年就已发布。 WICED，是一个专门针对物联网连接技术的解决方案。据了解，WICED包括三个系列：针对Wi-Fi的WICED Wi-Fi芯片、针对蓝牙(BLE)的WICED Smart芯片以及快速构建原型的开发套件WICED Sense。博通市场无线连接事业部产品营销总监David Liu表示：“通过采用不同的WICED技术，
2017-09-12
优秀的个人博客,低调大师

静态之殇 GIN实时防护体系打造安全生态系统

据统计，互联网每天新增URL上万亿、新增网站数百万，而其中大部分URL、域名存在的时间不超过24小时，高达22%的URL指向不安全内容，甚至是恶意攻击网站。作为传统WEB安全防护的标配，”URL安全列表“和”网站信誉评级“显得越来越力不从心，更要命的是还有许多“白名单“网站被挂马，直接打击了用户对网站信誉评级的信任。 面对日益严峻的威胁以及恶意攻击技术，WEB安全亟需新的技术来应对不断变化的趋势。日前，Blue Coat提出的Global Intelligence Network（GIN全球智能网络）让我们看到了新的思路。GIN是Blue Coat全部资源和技术的智能有机整合，通过全球感知、实时分享以及层次化合理安全架构和主动恶意网络监控等手段，GIN可以有效应对互联网层出不穷的恶意威胁。GIN旨在打造一个全球化的安全防护体系，通过层次化架构设计，逐级过滤威胁，减少误报率，其最终目的在于降低恶意威胁、提高企业工作效率，降低客户的安全投入成本。 全球感知 实时分享 据悉，Blue Coat在全球范围拥有超过15000家企业用户，其中有80%的全球500强企业，还有全球12家大型运营商中的8家，在家庭消费群体中，Blue Coat提供免费的K9应用，为家庭用户做好安全防护和家长控制，概括来说，涵盖了企业、运营商和家庭消费者等。全球化的用户覆盖为GIN提供了全方位的网络安全监测数据，使之拥有了感知全球各地网络威胁的能力。无论攻击威胁来自于哪个地方，GIN能够在第一时间感知监测到，并通过GIN复杂、智能的手段进行分析，这就是GIN的“全球感知”能力。 从产品架构层面讲，GIN已经把Blue Coat所有的产品都整合在一起，使用Blue Coat产品构建的用户安全体系架构，可以通过GIN建立各种联系，实现威胁情报实时共享等。比如，对于未知URL，GIN可以在800ms左右反馈给用户一个分析结果；平均每5分钟，GIN全球安全数据库就进行一次同步更新。 全球化的用户基础造就了Blue Coat广泛的语言认知能力，在GIN全球化智能网络中，每天有超过12万亿的web请求，Blue Coat的语言认知能力也起着巨大的作用，比如在大陆中文的网站居多，在欧洲不同的国家有不同的语言，任何语言类型的网站都有可能被用户访问，GIN要对这些网站进行识别，目前，GIN已经涵盖了全球的主要语言，有55种之多。 层次化合理架构 王跃霖认为通过合理的顶层安全架构设计，能够帮助用户降低投资成本，同时减少安全系统误报，并最终有效的提升企业的工作效率。GIN层次化的安全架构设计，采取层层过滤，逐步缩小检测范围，集中精力打击真正未知威胁的办法，对于占大多数的已知URL，GIN在第一层级就可以及时、快速的过滤和防护；如果网页中含有下载链接等，在第二层级GIN将对这些链接内容进行病毒扫描，再次过滤掉一部分恶意攻击；经过这两层的过滤，最后剩下的未知URL才会进入更严格的”沙箱“处理。 沙箱的处理性能是业界难题之一， 单纯的提高沙箱的性能潜力总是有限的。如果沙箱能够做到有针对性，也可以显著提高整个安全系统的执行效率。GIN层次化防御体系层层过滤掉初、中级威胁，让沙箱有针对性的集中处理高级未知威胁，不但能够消除大量的假告警带来的额外运营成本，还能有效提升企业的网络安全系统效率。 王跃霖分享了一例GIN层次化防御体系的成功案例，某全球财富50强企业采用了Blue Coat的GIN解决方案，统计数据显示，90天的时间里该企业总共有超过631亿次的web请求，其中1.773亿次是有问题的，此外，有将近2万个文件的下载是不安全的，而这些威胁都被GIN系统过滤掉了，本案中GIN的威胁阻止能力超过了99.9%。 逆向思维——抛开表象、直追根本、紧盯恶意网络 大量数据已经表明，传统WEB安全产品存储的静态URL列表与每天增长的海量URL相比根本就不是一个量级，静态的URL安全列表已经无法应对当下的安全威胁。对待web安全防护，王跃霖透露GIN采用了“抛开表象、直追根本、紧盯恶意网络”的“逆向思维”。 据悉，全球有很多黑客（组织）控制的恶意网络，由于旧”肉鸡”的脱离与新”肉鸡”的加入，这些恶意网络结构会不断的变动，Blue Coat安全实验室会定期追踪这些恶意网络及其结构变动，并通过全球网络进行威胁情报分享，不管用户访问的URL是什么，只要是有URL指向这些恶意网络，GIN立马切断这种链接，及时阻止黑客的不轨行为。这就是GIN的抛开表象、直追根本，紧盯恶意网络的逆向思维。 GIN——全球客户服务智能化 王跃霖解释Global Intelligence Network实际上是针对Blue Coat全球客户服务的智能化概念，GIN除了200多个自动化工具以外，还有人工分析。通过GIN高度智能化的分析能力，Blue Coat有效的服务于全球客户。未来，GIN还会通过技术创新、新产品收购等方式，不断的发展壮大，更好的服务于Blue Coat全球客户。 原文发布时间为：2015-09-28 本文来自云栖社区合作伙伴至顶网，了解相关信息可以关注至顶网。
2017-08-31
优秀的个人博客,低调大师

从0到1构建数据生态系列(二)：拆解架构蓝图

一、结合业务需求拆解架构图 先把上一章已经讲过的架构图再贴一次： 整体架构说明 从架构图中可以看出，在我们整个数据架构中，需要做的事情很多。随着数据的流向，从下到上，主要分三层： 第一层是数据收集层，负责基础数据的收集工作； 第二层是数据存储与处理层，负责数据存储、对数据进行深度处理、转换及价值的挖掘等； 最上层是应用层，基于下面的数据处理，进行价值转换；还有贯穿整个过程的监控以及任务调度相关的工作。 第一层中，主要有四个数据来源：用户行为埋点上报数据、服务日志的数据、后端的业务数据、互联网的公开数据。 第二层中，我们主要的核心框架是Hadoop的核心生态，基于HDFS的存储(本质上hive的存储也是基于HDFS)，以及基于Spark部分实时处理的需求场景，主要是平台级的架构。当然，至于说具体的处理以及数据的加工、挖掘详细数据业务，后续其它章节再详述。 第三层中，我们直接面向的是业务方。一方面是数据生态中最基础最常见的的数据智能商业化分析，我们以excel封装成邮件日报周报的形式提供。另一方面是平台化的BI系统，以及高度自助性的数据自助查询系统。 在深度挖掘方面，推荐是一个大方向，基于数据的当代搜索也是数据生态的重要组成部分，同时还有业务画像、用户画像(绝对核心价值所在)等。除了以上这些，还有一些基于数据的推送服务、榜单数据、精准营销系统等，都是数据进一步有效应用，以及数据化价值的直接体现。 收回话题，在时间、人力有限，并且基础是0的前提下，事情解决的顺序就显得尤为重要了。 当前的业务需求 想要使用数据，前提是有数据。所以，我们第一个需要解决的问题是数据源，核心的驱动价值因素是我们的业务需求。 我们第一个业务需求就是从数据上洞察产品的运营效果，电商的各种数据运营需求，指导内容数据化运营、电商数据化运营以及通过数据改进产品。 跟业务强相关的基础数据是产品的业务数据库，这个是现成的，只要打通数据流通即可。与用户行为强相关的则是最直接的用户行为埋点上报数据，以及用户使用服务，在应用服务中留下的访问LOG。 基于服务日志LOG解析数据，一方面如果需要从服务LOG中清洗出有用数据，前提是服务中已经有意识的进行相关信息的LOG落地，这一点，很遗憾，当时并没有这个前瞻性。其次，从服务LOG中清洗数据的代价略高，且信息量有限。所以，在这个阶段中，我们并没有打算直接从服务LOG中清洗数据，因为在服务LOG中埋入数据收集点位，也是一个巨大的改造工程，但效果并不一定好。 我们将最快限度地打通业务数据库与数据中心的通道，然后以最快速度的对业务方提供可参考性的数据化日报。打通行为数据到数据应用的链路，结合用户行为数据，进一步优化数据化运营体系，以及为产品优化迭代提供数据支撑。构造最基础的数据中心平台，打通数据收集到数据分析应用的链路，为业务方、决策层提供数据化运营决策方案，为产品迭代提供最真实的数据反馈支撑。 这是我们数据部门第一个战略目标，像深度挖掘、推荐系统这些在这时通通不要想太多，饭需要一口一口的吃！ 之所以需要拆分阶段目标，依然是投入与产出比的问题！ 当有一个大目标时，我们需要把目标进行拆分，进一步拆分为阶段可实施、成果可见的阶段性目标，在这里同样适用。 并且，记住，你的老板是不懂技术的，他才不会管你的平台又建设到什么程度，集群又搭建了多少台，他只会问，这都一两个月了，你们数据怎么还没有给公司带来价值啊？！(哈哈，有点黑BOSS的感觉了) 不过这肯定是现实，不同位置上的人关注的核心重点不一样。可能你需要关注整体的进度，而业务层只关心你的产出给他带来什么帮助。是的，拆解大目标有利于我们快速入手启动项目；成果阶段化，更具有鼓励性，成就感；最后就是阶段性目标的实现情况更容易量化你的效率。 从人力的需求评估角度上说，也是有道理的，只有随着你的体系一步一步完善，你才知道哪个环节真正的缺人，缺什么人，这点很关键。不过最本质的问题，还是投入与产出比。 我们在做任何一件事情的时候，都需要注意投入与产出的比例，在一定的时间段内、投入一定的精力、产出一定比例的成果。有这种价值观，处理事务才更有效率！ 二、如何做机器需求的评估 想要打通数据收集到数据分析业务的输出链路，那么你需要一个数据平台进行支撑，甚至后续你将持续开挖的数据核心价值，这些都是基于平台做的。 所以我们需要一个数据平台，而说到平台，则机器资源是绕不过去的一个问题。那么，如何去评估你的集群需要多少台机器呢？每个机器又是以一个什么样的角色存在的呢？ 在评估之前，你首先应清楚了解到平台上需要承载的业务，包括内部的处理业务以及对外暴露的数据业务。其次，你需要考虑后续的可扩展性，即后续数据量上涨的情况下，机器的横向扩展当然是没有问题的，但部分角色机器的资源需求是在纵向。 举个简单例子，Hadoop的datanode可以在横向上进行扩展，但是Namenode的资源需求则无法做到。 至于说如何进行机器资源评估，在了解自身业务需求的前提下，这里所说的业务需求，不单纯是业务范围，也意味着业务范围承载的数据量是什么情况。在了解自身数据量的情况下，多查找其他公司的案例，与其他同行多交流沟通，借鉴其它公司的数据量与集群规模，来评估自身所需要的机器资源。需要注意一点的是，对于电商行业，经常会出现节日性、活动性质的流量暴涨。 所以，你的机器资源一定是需要考虑这些实际场景负载的或对于这种场景，若你有其它的方案进行处理也OK。 三、使用Nginx做数据上报伪服务 上面说到第二个重点，那就是用户行为数据的上报。 了解数据上报以及埋点相关逻辑的朋友应该清楚，其实所谓的SDK，其本质也是一个接受数据上报的服务。直接往上报服务中丢数据，跟封装成工具SDK，本质的意义是一样的，我们需要提供一个对外的数据上报服务。上报什么数据，数据以什么格式上报，这个在下一章的“数据上报体系”部分详细阐述，这里只是对上报服务这块进行讲解。 那这意味着，我们需要为客户端或者H5的童鞋提供一个统一的上报服务接口，让他们在用户特定行为操作的时候。比如浏览了某个页面，操作了某个按钮等之类的操作，进行这种信息的收集统一上报。说白了，封装用户的行为数据，在适当时候调我们的接口，把用户的行为数据给我传过来。 那这看似就是一个后台服务，用于处理上报过来的数据。但是请注意，不管你是一个服务也好，伪服务也好，一般情况下绝不会直接把获取到的数据直接落地的，这是传统的思维路子。 要知道上报的业务流量是很大的，特别是你的点位足够丰满的情况下，在流量高峰期，你要是敢直接进行数据落地，它就敢直接把你的服务给搞死。一所以一般情况下，我们都会把数据丢给缓存，以解耦上报与落地两端的压力。 既然如此，在人力资源有限、项目时间有限的前提下，为何要花这么大的精力去维护一个服务呢？于是，有了伪服务设想。 我们直接使用Nginx对外伪装成一个Web服务，提供Restful API，但我们不对上报的内容做任何处理，直接落地成Nginx的日志，再通过Flume对日志进行监控，丢到Kafka中。这样我们就迅速地搭建起一个上报“服务”，提供给客户端童鞋以及H5的童鞋，制定好数据上报的规范，然后就可以坐等数据过来了。 关于数据的合理性校验、规范性校验、有效性校验、以及进一步的解析，我们都放到Spark Streaming这一层去做。其实当时也是调研过lua的，在Nginx这一层也是可以做到数据完整性以及有效性校验的，但为了不至于给Nginx端带来过大的负荷，我们把复杂的逻辑处理放到后端。 基于这种伪服务的设计，还有一个好处就是，即使后端链路出现故障，但我的原始数据是落到LOG中的，只要我进行数据的回溯，再通过LOG清洗出异常的部分就行了。这也是我们后续实时数据容错的核心依据所在，所以，重点推荐。 四、用Spark Streaming做实时数据清洗 紧接上面的上报，我们在后端一层使用Spark Streaming做数据校验、进一步清洗的。 如果业务对于实时性要求不高，我们完全是不必要做数据的实时链路，只需要周期性地把Nginx中的上报日志进行批量清洗入库即可。但是，一方面基于部分对实时性稍高(其实也不高，分钟级别)，例如电商活动期间对数据的实时监控；另一方面来说，实时性的数据上报链路是最终的目标，为了业务的时效性，迟早是需要做的。 由于我们需要在后端的处理环节中，对数据的有效性、规范性做校验，并且做进一步的属性解析，例如通过IP解析地理位置之类的，因此承载的业务逻辑还是蛮复杂的。 所以，我们打算引入一个实时处理框架来做这件事。关于实时框架这块，我想，熟悉的朋友都会想到两个：Storm与Spark Streaming。在这里跟大家分享我之前翻译过的一篇文章《Storm与Spark Streaming的对比》。（英文原文：http://xinhstechblog.blogspot.com/2014/06/storm-vs-spark-streaming-side-by-side.html） 数据处理模型、数据延迟性 虽然这两种框架都提供了系统的可扩展性和可容错性，但是它们的数据处理模型从根本上说是不一样的，处理模型则决定了它们的实时性。 Storm可以实现真正流式实时的处理数据，例如每次处理一条消息，这样延迟就可以控制在秒级以下，实时性很高。而Spark Streaming的本质还是批量处理，只是这个批量是微批量，在短的时间窗口内进行数据实时处理，通常延迟在秒级左右，实时性相对较弱。 数据保护、容错能力 在数据容错能力方面，SparkStreaming做的比Storm好一些，它的容错是通过状态记录去实现的。(译者注：熟悉spark的童鞋都知道，spark会将所有的处理过程状态都以log的形式记录下来，即血统，出现错误的时候，可以根据血统进行数据的恢复) 而Storm则不一样，Storm对每一条数据进行处理标记，从而进行跟踪数据的处理情况，它只能保证每条数据被处理一次，但实际情况是，在发生错误时，这条数据是被处理多次的。 这意味着，更新多次时可能会导致数据不正确。 而Spark的批处理特点，能够保证每个批处理的所有数据只处理一次，保证数据不会在恢复的时候错乱(批处理重新执行)。 Storm提供的Trident库虽然能够保证在数据容错时只被处理一次，但它很大程度上依赖于事务的状态更新，并且这个过程相对较慢，更甚者，这个过程是需要用户自己去实现。（译者注：Spark的数据安全性是毋庸置疑的，虽然当年Storm能够从多个开源实时处理框架中脱颖而出，ack/faild机制的功劳巨大，但是跟Spark比，数据容错能力还是差了一筹） 所以，如果你的业务场景对实时性要求比较高，同样对数据容错也有所要求，那么Storm将是一个很好的选择。当然，如果你希望对每次实时处理的过程进行掌控，那么Spark Streaming提供的状态记录会清楚地描述出数据处理的过程，并且数据的容错能力也很不错。 框架实现以及编程API 假如你想深入源码中研究，你需要清楚的是：Storm是由Clojure编写的，而Spark Streaming则是Scala。 Storm是由BackType和Twitter开发的，而Spark Streaming则是由UC Berkeley开发的。 在语言支持上，Storm提供了Java API，同时也支持多语言。（译者注：在多语言的支持上，虽然支持，但是通常除了Clojure、Java、Python等几种语言，其它语言进行开发还是很困难的，最常用应该是Java）Spark Streaming支持Scala、Java、Python等几种语言。 批处理框架集成 （译者注：这点是针对于Spark Streaming来说的） Spark Streaming一个很大的优势就是，它是基于Spark框架上做的，这样的话，熟悉Spark操作的人就能很轻松的像进行其它批处理操作一样，进行操作Spark Streaming。这意味着你不用进行额外的编写处理代码，更为便捷。 实际生产应用 Storm开源得比较早，自2011年起，推特就在使用Storm了，其后更多的公司使用它。而Spark Streaming是一个比较新的项目，在2013年的时候，仅仅被Sharethrough使用（据作者了解）。 Storm是Hortonworks Hadoop数据平台中的数据流式处理的解决方案，而Spark Streaming出现在MapR的分布式平台和Cloudera的企业数据平台中。 此外，Databricks公司还专门为Spark提供技术支持，当然，其中也包括了Spark Streaming。 最后在依赖框架来说，Storm可以在Mesos上运行, 而Spark Streaming可以在YARN和Mesos上运行。 Storm比Spark Streaming更有实际应用的优势，但Spark有专门的公司维护它并且提供技术支持，包括它与Yarn的结合等。 总结 其实Storm在处理领域上还是有一定的差异的，Storm比较擅长实时性较高的数据处理，而Spark Streaming则偏向于内存处理(注意严格来说内存处理跟流式处理并不是完全一样的)。 在数据安全性方面，不作过多的评论，数据安全Storm虽然没有Spark streaming强大，但从目前来看已经够用了，要知道很多业务数据在这种场合下是允许丢失部分数据的。 关键点在于资源的管理，虽然最近发布的Storm 0.10.0-beta号称在资源管理上已经做了不小的优化，但在个人看来还远远不够。Spark Streaming依赖于Spark的环境，而Spark在Hadoop2.0时代以后，资源管理方面得到了巨大的提升，这侧面的衍生了大量类似Yarn的组件。 虽然Storm也可以运行在Yarn上，但目前并没有一个很稳定可用于生产环境的开源版本。所以，在资源管理方面storm还有很长的一段路要走。 在两者的选择上，从当前实际应用看，Storm已经越来越多的生产实例了，而Spark Streaming更多还处于预研或者试用阶段。 相对来说，在流式处理上，Storm有着不可比拟的优势，而在大批量内存处理的方面，则是Spark Streaming占着不小的优势。 所以具体使用方面，一般情况下Storm足够了，而Spark Streaming的话，慎用，毕竟任何开源的稳定性以及其价值，都是需要时间来检验的。 总之，Storm与Spark Streaming最本质的区分在于，Storm是真正实时处理，而Spark Streaming的处理本质则是微批处理。所以Storm能够将实时业务达到毫秒级，而Spark Streaming虽然也能达到亚秒级，但对于效率的影响会比较大，所以一般会用于秒级的数据处理。 目前就我们自身的业务需求来说，对于实时性并没有高到毫秒级的要求。 并且，为了维护系统平台的统一性(统一的平台架构，统一的YARN资源管理，同一个垂直生态)，我们选择使用Spark Streaming作为我们数据清洗的入口。 使用Spark Streaming需要解决的一个问题就是，输出结果的高度碎片化。 正如上面所说，Spark Streaming其核心依然是Spark的路子，在微小的时间窗内，对微小批量的数据进行处理，达到类似实时的效果。 而其每一个批量处理之后都是以批量结果得以输出，于是，就会产生大量的碎片文件。 其实，解决这个问题也简单，那就是合并！进行周期性的文件合并，这点就不多说了。 既然说到了Spark Streaming，也就顺带着说一说Spark这个生态。 在很早以前，Hadoop、MapReduce经常会被人提到，但是随着Spark的兴起，已经越来越少人愿意使用MapReduce去批量处理数据了。 是的，Spark目前在Hadoop大生态中，已经形成一个比较完整的子生态: 包括与数据查询分析关联的Spark SQL； 实时处理领域的Spark Streaming； 正常内存处理可以替代MapReduce的离线批量； 还有集成大量机器学习包的MLlib； 以及还有什么图形处理的什么鬼(好吧，那个不是我擅长的)。 在效率至上的数据时代，MapReduce说抛弃就被抛弃了(哈哈，其实也没有这么严重，只是越来越多人弃用MapReduce，这肯定是事实)。 在体系支撑上，Spark依然成气候，数据的常规SQL分析，数据的内存处理、实时处理，以及数据的深度挖掘等，全部一起打包，好用的不得了，所以越来越得人心，也是木有办法的事。 关于IP地理位置解析，这里也可以分享一下。 IPIP.NET提供的IP库实在是值得推荐的，没钱的可以使用它提供的免费版，有钱的主可以考虑使用使用付费版。 免费版没有想象中那么不堪，只是它提供的服务没有这么多，更新的频次少点而已，大部分能解析到市一级，至于省份这一级，那是妥妥的没问题。 五、结语 本章主要阐述如何从局部入手，拆解架构图，进行阶段性的任务执行。其中，详细讲解了部分核心重点，包括架构图的拆解、机器资源的评估、Nginx的上报伪服务、以及基于Spark Streaming的数据清洗等。 但是个人认为，方法论远比现成的方案有用，授人以鱼不如授人以渔！更重要的是中间阐述一些问题的思考方式、价值观，诸如拆解整体规划的思考、扩展预留的思考、方案选择的对比衡量等。希望本文能对你有所启发。 作者介绍 黄崇远 毕业于哈工大，近6年大数据行业经验 ，目前于深圳一创业公司任职大数据主管，数据虫巢公众号及官网(www.mite8.com)创建者。 原文发布时间为：2017-05-10 本文来自云栖社区合作伙伴DBAplus
2017-05-16

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册