海量数据处理技术可以做什么

大数据是指无法在一定时间内用常规软件工具对其内容进行抓取、管理和处理的数据集合。大数据技术，是指从各种各样类型的数据中，快速获得有价值信息的能力。适用于大数据的技术，包括大规模并行处理（MPP）数据库，数据挖掘电网，分布式文件系统，分布式数据库，云计算平台，互联网，和可扩展的存储系统。 　　大数据有四个基本特征：一、数据体量巨大（Vomule），二、数据类型多样（Variety），三、处理速度快（Velocity），四、价值密度低（Value）。 　　在大数据的领域现在已经出现了非常多的新技术，这些新技术将会是大数据收集、存储、处理和呈现最强有力的工具。大数据处理一般有以下几种关键性技术：大数据采集、大数据预处理、大数据存储及管理、大数据分析及挖掘、大数据展现和应用（大数据检索、大数据可视化、大数据应用、大数据安全等）。 　　大数据处理之一：采集。大数据的采集是指利用多个数据库来接收发自客户端（Web、App或者传感器形式等）的数据，并且用户可以通过这些数据库来进行简单的查询和处理工作。比如，电商会使用传统的关系型数据库MySQL和Oracle等来存储每一笔事务数据，除此之外，Redis和MongoDB这样的NoSQL数据库也常用于数据的采集。 　　在大数据的采集过程中，其主要特点和挑战是并发数高，因为同时有可能会有成千上万的用户来进行访问和操作，比如火车票售票网站和淘宝，它们并发的访问量在峰值时达到上百万，所以需要在采集端部署大量数据库才能支撑。并且如何在这些数据库之间进行负载均衡和分片的确是需要深入的思考和设计。 　　大数据处理之二：导入和预处理。虽然采集端本身会有很多数据库，但是如果要对这些海量数据进行有效的分析，还是应该将这些来自前端的数据导入到一个集中的大型分布式数据库，或者分布式存储集群，并且可以在导入基础上做一些简单的清洗和预处理工作。也有一些用户会在导入时使用来自Twitter的Storm来对数据进行流式计算，来满足部分业务的实时计算需求。 　　导入与预处理过程的特点和挑战主要是导入的数据量大，每秒钟的导入量经常会达到百兆，甚至千兆级别。 　　大数据处理之三：统计和分析。统计与分析主要利用分布式数据库，或者分布式计算集群来对存储于其内的海量数据进行普通的分析和分类汇总等，以满足大多数常见的分析需求，在这方面，一些实时性需求会用到EMC的GreenPlum、Oracle的Exadata，以及基于MySQL的列式存储Infobright等，而一些批处理，或者基于半结构化数据的需求可以使用Hadoop。 　　统计与分析这部分的主要特点和挑战是分析涉及的数据量大，其对系统资源，特别是I/O会有极大的占用。 　　大数据处理之四：挖掘。与前面统计和分析过程不同的是，数据挖掘一般没有什么预先设定好的主题，主要是在现有数据上面进行基于各种算法的计算，从而起到预测（Predict）的效果，从而实现一些高级别数据分析的需求。比较典型算法有用于聚类的Kmeans、用于统计学习的SVM和用于分类的NaiveBayes，主要使用的工具有Hadoop的Mahout等。该过程的特点和挑战主要是用于挖掘的算法很复杂，并且计算涉及的数据量和计算量都很大，常用数据挖掘算法都以单线程为主。 　　整个大数据处理的普遍流程至少应该满足这四个方面的步骤，才能算得上是一个比较完整的大数据处理。 　　大数据的处理方式大致分为数据流处理方式和批量数据处理方式两种。数据流处理的方式适合用于对实时性要求比较高的场合中。并不需要等待所有的数据都有了之后再进行处理，而是有一点数据就处理一点，更多地要求机器的处理器有较快速的性能以及拥有比较大的主存储器容量，对辅助存储器的要求反而不高。批量数据处理方式是对整个要处理的数据进行切割划分成小的数据块，之后对其进行处理。重点在于把大化小——把划分的小块数据形成小任务，分别单独进行处理，并且形成小任务的过程中不是进行数据传输之后计算，而是将计算方法（通常是计算函数——映射并简化）作用到这些数据块最终得到结果。 　　当前，对大数据的处理分析正成为新一代信息技术融合应用的节点。移动互联网、物联网、社交网络、数字家庭、电子商务等是新一代信息技术的应用形态，这些应用不断产生大数据。通过对不同来源数据的管理、处理、分析与优化，将结果反馈到上述应用中，将创造出巨大的经济和社会价值。大数据也是信息产业持续高速增长的新引擎。面对大数据市场的新技术、新产品、新业态会不断涌现。在硬件与集成设备领域，大数据将对芯片、存储产业产生重要影响，还将催生一体化数据存储处理服务器、内存计算等市场。在软件与服务领域，大数据将引发数据快速处理分析、数据挖掘技术和软件产品的发展。大数据利用将成为提高核心竞争力的关键因素。各行各业的决策正在从“业务驱动”转变为“数据驱动”。对大数据的分析可以使零售商实时掌握市场动态并迅速做出应对；可以为商家制定更加精准有效的营销策略提供决策支持；可以帮助企业为消费者提供更加及时和个性化的服务；在医疗领域，可提高诊断准确性和药物有效性；在公共事业领域，大数据也开始发挥促进经济发展、维护社会稳定等方面的重要作用。大数据时代科学研究的方法手段将发生重大改变。例如，抽样调查是社会科学的基本研究方法。在大数据时代，可通过实时监测，跟踪研究对象在互联网上产生的海量行为数据，进行挖掘分析，揭示出规律性的东西，提出研究结论和对策。 　　目前大数据在医疗卫生领域有广为所知的应用，公共卫生部门可以通过覆盖全国的患者电子病历数据库进行全面疫情监测。5千万条美国人最频繁检索的词条被用来对冬季流感进行更及时准确的预测。学术界整合出2003年H5N1禽流感感染风险地图，研究发行此次H7N9人类病例区域。社交网络为许多慢性病患者提供了临床症状交流和诊治经验分享平台，医生借此可获得院外临床效果统计数据。基于对人体基因的大数据分析，可以实现对症下药的个性化治疗。 　　在医药研发方面，大数据的战略意义在于对各方面医疗卫生数据进行专业化处理，对患者甚至大众的行为和情绪的细节化测量成为可能，挖掘其症状特点、行为习惯和喜好等，找到更符合其特点或症状的药品和服务，并针对性的调整和优化。在医药研究开发部门或公司的新药研发阶段，能够通过大数据技术分析来自互联网上的公众疾病药品需求趋势，确定更为有效率的投入产品比，合理配置有限研发资源。除研发成本外，医药公司能够优化物流信息平台及管理，更快地获取回报，一般新药从研发到推向市场的时间大约为13年，使用数据分析预测则能帮助医药研发部门或企业提早将新药推向市场。 　　在疾病诊治方面，可通过健康云平台对每个居民进行智能采集健康数据，居民可以随时查阅，了解自身健康程度。同时，提供专业的在线专家咨询系统，由专家对居民健康程度做出诊断，提醒可能发生的健康问题，避免高危病人转为慢性病患者，避免慢性病患者病情恶化，减轻个人和医保负担，实现疾病科学管理。对于医疗卫生机构，通过对远程监控系统产生数据的分析，医院可以减少病人住院时间，减少急诊量，实现提高家庭护理比例和门诊医生预约量的目标。武汉协和医院目前也已经与市区八家社区卫生服务中心建立远程遥控联系，并将在未来提供“从医院到家”的服务。在医疗卫生机构，通过实时处理管理系统产生的数据，连同历史数据，利用大数据技术分析就诊资源的使用情况，实现机构科学管理，提高医疗卫生服务水平和效率，引导医疗卫生资源科学规划和配置。大数据还能提升医疗价值，形成个性化医疗，比如基于基因科学的医疗模式。 　　在公共卫生管理方面，大数据可以连续整合和分析公共卫生数据，提高疾病预报和预警能力，防止疫情爆发。公共卫生部门则可以通过覆盖区域的卫生综合管理信息平台和居民信息数据库，快速监测传染病，进行全面疫情监测，并通过集成疾病监测和响应程序，进行快速响应，这些都将减少医疗索赔支出、降低传染病感染率。通过提供准确和及时的公众健康咨询，将会大幅提高公众健康风险意识，同时也将降低传染病感染风险。 　　在居民健康管理方面，居民电子健康档案是大数据在居民健康管理方面的重要数据基础，大数据技术可以促进个体化健康事务管理服务，改变现代营养学和信息化管理技术的模式，更全面深入地从社会、心理、环境、营养、运动的角度来对每个人进行全面的健康保障服务，帮助、指导人们成功有效地维护自身健康。另外，大数据可以对患者健康信息集成整合，在线远程为诊断和治疗提供更好的数据证据，通过挖掘数据对居民健康进行智能化监测，通过移动设备定位数据对居民健康影响因素进行分析等等，进一步提升居民健康管理水平。 　　在健康危险因素分析方面，互联网、物联网、医疗卫生信息系统及相关信息系统等普遍使用，可以系统全面地收集健康危险因素数据，包括环境因素（利用GIS系统采集大气、土壤、水文等数据），生物因素（包括致病性微生物、细菌、病毒、真菌等的监测数据），经济社会因素（分析经济收入、营养条件、人口迁徙、城镇化、教育就业等因素数据），个人行为和心理因素，医疗卫生服务因素，以及人类生物遗传因素等，利用大数据技术对健康危险因素进行比对关联分析，针对不同区域、人群进行评估和遴选健康相关危险因素及制作健康监测评估图谱和知识库也成为可能，提出居民健康干预的有限领域和有针对性的干预计划，促进居民健康水平的提高。 答案来源于网络

数据挖掘和机器学习的区别和联系，周志华有一篇很好的论述《机器学习和 数据挖掘》可以帮助大家理解。 数据挖掘受到很多学科领域的影响，其中数据库、机器学习、统计学无疑影响 最大。简言之，对数据挖掘而言，数据库提供数据管理技术，机器学习和统计学 提供数据分析技术。 由于统计学往往醉心于理论的优美而忽视实际的效用，因此，统计学界提供的 很多技术通常都要在机器学习界进一步研究，变成有效的机器学习算法之后才能 再进入数据挖掘领域。从这个意义上说，统计学主要是通过机器学习来对数据挖 掘发挥影响，而机器学习和数据库则是数据挖掘的两大支撑技术。 从数据分析的角度来看，绝大多数数据挖掘技术都来自机器学习领域，但机器 学习研究往往并不把海量数据作为处理对象，因此，数据挖掘要对算法进行改造， 使得算法性能和空间占用达到实用的地步。同时，数据挖掘还有自身独特的内容， 即关联分析。 而模式识别和机器学习的关系是什么呢，传统的模式识别的方法一般分为两种： 统计方法和句法方法。句法分析一般是不可学习的，而统计分析则是发展了不少机 器学习的方法。也就是说，机器学习同样是给模式识别提供了数据分析技术。 至于，数据挖掘和模式识别，那么从其概念上来区分吧，数据挖掘重在发现知识， 模式识别重在认识事物。 机器学习的目的是建模隐藏的数据结构，然后做识别、预测、分类等。因此，机器 学习是方法，模式识别是目的。 总结一下吧。只要跟决策有关系的都能叫 AI(人工智能)，所以说 PR（模式识别）、 DM（数据挖掘）、IR（信息检索） 属于 AI 的具 体应用应该没有问题。 研究的东西则 不太一样， ML(机器学习) 强调自我完善的过程。 Anyway，这些学科都是相通的。

转自：思否 话说当下技术圈的朋友，一起聚个会聊个天，如果不会点大数据的知识，感觉都融入不了圈子，为了以后聚会时让你有聊有料，接下来就跟随我的讲述，一起与大数据混个脸熟吧，不过在“撩”大数据之前，还是先揭秘一下研发这些年我们都经历了啥？ 缘起：应用系统架构的从 0 到 1 揭秘：研发这些年我们都经历了啥？ 大道至简。生活在技术圈里，大家静下来想想，无论一个应用系统多庞大、多复杂，无非也就是由一个漂亮的网站门面 + 一个丑陋的管理模块 + 一个闷头干活的定时任务三大板块组成。 我们负责的应用系统当然也不例外，起初设计的时候三大模块绑在一起（All in one），线上跑一个 Tomcat 轻松就搞定，可谓是像极了一个大泥球。 衍化至繁。由于网站模块、管理平台、定时任务三大模块绑定在一起，开发协作会比较麻烦，时不时会有代码合并冲突出现；线上应用升级时，也会导致其它模块暂时不能使用，例如如果修改了一个定时任务的配置，可能会导致网站、管理平台的服务暂时不能用。面对诸多的不便，就不得不对 All in one 的大泥球系统进行拆解。 随着产品需求的快速迭代，网站 WEB 功能逐渐增多，我们起初设计时雄心勃勃（All in one 的单体架构），以为直接按模块设计叠加实现就好了，谁成想系统越发显得臃肿（想想也是走弯路啦！）。所以不得不改变实现思路，让模块服务下沉，分布式思想若现——让原来网站 WEB 一个系统做的事，变成由子系统分担去完成。 应用架构的演变，服务模块化拆分，随之而来的就是业务日志、业务数据散落在各处。随着业务的推广，业务量逐日增多，沉淀的数据日益庞大，在业务层面、运维层面上的很多问题，逐渐开始暴露。 在业务层面上，面对监管机构的监管，整合提取散落在各地的海量数据稍显困难；海量数据散落，想做个统计分析报表也非常不易。在运维层面上，由于缺少统一的日志归档，想基于日志做快速分析也比较困难；如果想从散落在各模块的日志中，进行调用链路的分析也是相当费劲。 面对上述问题，此时一个硕大的红色问号出现在我们面前，到底该如何解决？ 面对结构化的业务数据，不妨先考虑采用国内比较成熟的开源数据库中间件 Sharding-JDBC、MyCat 看是否能够解决业务问题；面对日志数据，可以考虑采用 ELK 等开源组件。如果以上方案或者能尝试的方式都无法帮我们解决，尝试搬出大数据吧。 那到底什么时候需要用大数据呢？大数据到底能帮我们解决什么问题呢？注意，前方高能预警，门外汉“撩”大数据的正确姿势即将开启。 邂逅：一起撬开大数据之门 槽点：门外汉“撩”大数据的正确姿势 与大数据的邂逅，源于两个头痛的问题。第一个问题是海量数据的存储，如何解决？第二个问题是海量数据的计算，如何解决？ 面对这两个头痛的问题，不得不提及谷歌的“三驾马车”（分布式文件系统 GFS、MapReduce 和 BigTable），谷歌“三驾马车”的出现，奠定了大数据发展的基石，毫不夸张地说，没有谷歌的“三驾马车”就没有大数据，所以接下来很有必要逐一认识。 大家都知道，谷歌搜索引擎每天要抓取数以亿计的网页，那么抓取的海量数据该怎么存储？ 谷歌痛则思变，重磅推出分布式文件系统 GFS。面对谷歌推出的分布式文件系统 GFS 架构，如 PPT 中示意，参与角色着实很简单，主要分为 GFS Master（主服务器）、GFS Chunkserver（块存储服务器）、GFS Client（客户端）。 不过对于首次接触这个的你，可能还是一脸懵 ，大家心莫慌，接下来容我抽象一下。 GFS Master 我们姑且认为是古代的皇上，统筹全局，运筹帷幄。主要负责掌控管理所有文件系统的元数据，包括文件和块的命名空间、从文件到块的映射、每个块所在的节点位置。说白了，就是要维护哪个文件存在哪些文件服务器上的元数据信息，并且定期通过心跳机制与每一个 GFS Chunkserver 通信，向其发送指令并收集其状态。 GFS Chunkserver 可以认为是宰相，因为宰相肚子里面能撑船，能够海纳百川。主要提供数据块的存储服务，以文件的形式存储于 Chunkserver 上。 GFS Client 可以认为是使者，对外提供一套类似传统文件系统的 API 接口，对内主要通过与皇帝通信来获取元数据，然后直接和宰相交互，来进行所有的数据操作。 为了让大家对 GFS 背后的读写流程有更多认识，献上两首歌谣。 到这里，大家应该对分布式文件系统 GFS 不再陌生，以后在饭桌上讨论该话题时，也能与朋友交涉两嗓子啦。 不过这还只是了解了海量数据怎么存储，那如何从海量数据存储中，快速计算出我们想要的结果呢？ 面对海量数据的计算，谷歌再次创新，推出了 MapReduce 编程模型及实现。 MapReduce 主要是采取分而治之的思想，通俗地讲，主要是将一个大规模的问题，分成多个小规模的问题，把多个小规模问题解决，然后再合并小规模问题的结果，就能够解决大规模的问题。 也有人说 MapReduce 就像光头强的锯子和锤子，世界上的万事万物都可以先锯几下，然后再锤几下，就能轻松搞定，至于锯子怎么锯，锤子怎么锤，那就是个人的手艺了。 这么解释不免显得枯燥乏味，我们不妨换种方式，走进生活真实感受 MapReduce。 斗地主估计大家都玩过，每次开玩之前，都会统计一副牌的张数到底够不够，最快的步骤莫过于：分几份给大家一起数，最后大家把数累加，算总张数，接着就可以愉快地玩耍啦... ...这不就是分而治之的思想吗？！不得不说架构思想来源于人们的生活！ 再举个不太贴切的例子来感受MapReduce 背后的运转流程，估计很多人掰过玉米，每当玉米成熟的季节，地主家就开始忙碌起来。 首先地主将一亩地的玉米分给处于空闲状态的长工来处理；专门负责掰玉米的长工领取任务，开始掰玉米操作（Map 操作），并把掰好的玉米放到在麻袋里（缓冲区），麻袋装不下时，会被装到木桶中（溢写），木桶被划分为蓝色的生玉米木桶、红色的熟玉米木桶（分区），地主通知二当家来“收”属于自己的那部分玉米，二当家收到地主的通知后，就到相应的长工那儿“拿回”属于自己的那部分玉米（Fetch 操作），二当家对收取的玉米进行处理（Reduce 操作），并把处理后的结果放入粮仓。 一个不太贴切的生活体验 + 一张画得不太对的丑图 = 苦涩难懂的技术，也不知道这样解释，你了解了多少？不过如果以后再谈大数据，知道 MapReduce 这个词的存在，那这次的分享就算成功（哈哈）。 MapReduce 解决了海量数据的计算问题，可谓是力作，但谷歌新的业务需求一直在不断出现。众所周知，谷歌要存储爬取的海量网页，由于网页会不断更新，所以要不断地针对同一个 URL 进行爬取，那么就需要能够存储一个 URL 不同时期的多个版本的网页内容。谷歌面临很多诸如此类的业务场景，面对此类头痛的需求，该怎么办？ 谷歌重磅打造了一款类似以“URL + contents + time stamp”为 key，以“html 网页内容”为值的存储系统，于是就有了 BigTable 这个键值系统的存在（本文不展开详述）。 至此，两个头痛的问题就算解决了。面对海量数据存储难题，谷歌推出了分布式文件系统 GFS、结构化存储系统 BigTable；面对海量数据的计算难题，谷歌推出了 MapReduce。 不过静下来想想，GFS 也好、MapReduce 也罢，无非都是秉承了大道至简、一人掌权、其它人办事、人多力量大的设计理念。另外画龙画虎难画骨，建议闲暇之余也多些思考：为什么架构要这么设计？架构设计的目标到底是如何体现的？ 基于谷歌的“三驾马车”，出现了一大堆开源的轮子，不得不说谷歌的“三驾马车”开启了大数据时代。了解了谷歌的“三驾马车”的设计理念后，再去看这些开源的轮子，应该会比较好上手。 好了，门外汉“撩”大数据就聊到这儿吧，希望通过上文的分享能够了解几个关键词：大道至简、衍化至繁、谷歌三驾马车（GFS、MapReduce、BigTable）、痛则思变、开源轮子。 白头：番外篇 扯淡：不妨换一种态度 本文至此也即将接近尾声，最后是番外篇~ 首先，借用日本剑道学习心诀“守、破、离”，希望我们一起做一个精进的人。 最后，在有限的时间内要多学习，不要停下学习的脚步，在了解和使用已经有的成熟技术之时，更要多思考，开创适合自己工作场景的解决方案。 文章来源：宜信技术学院 & 宜信支付结算团队技术分享第6期-宜信支付结算部支付研发团队高级工程师许赛赛《揭秘：“撩”大数据的正确姿势》 分享者：宜信支付结算部支付研发团队高级工程师许赛赛 原文首发于公号-野指针

支付宝的线上系统极其复杂，每一笔交易背后是数亿行代码、成百上千个系统， 经过无数的链路，再加上海量线上实时交易，谁也无法预测下一秒是否会出现什么样 的问题。如何消除人们的焦虑呢？这时就轮到技术风险团队登场了。 技术风险工作就是使用技术手段，把各种软件、硬件、人为引入的可能出现业务 受损的的风险降到最低。在支付宝，它服务于从基础设施到上层应用的所有系统，从 写第一行代码到最终上线的整个研发流程。 目前，技术风险工作主要由 SRE 来承接，日常的工作包括变更风险防御、快速 应急、红蓝攻防、资金安全等，同时像双 11 大促，春节红包等高并发高性能的场景 是技术风险工作的大考。 SRE 是 Site Risk Engineering 的缩写，主要工作是围绕线上风险问题，研发 技术架构和解决方案，去解决各种各样的风险问题。 变更指的是代码上线到实际生产环境的过程，我们需要围绕变更建立各种技术手 段，减少变更导致的故障，研发变更相应的平台。据统计，80% 的系统生产故障都 来自于代码变更，因此无论怎么重视也不为过。支付宝建立了一系列制度保证系统内 的任何变更都符合可监控、可灰度、可回滚的“三板斧”要求。 而一旦线上真的出现了问题，就涉及到应急机制了。支付宝有一套完善的线上应 急流程，包括怎么快速定位问题，以及一个数据智能化的监控系统，可以迅速从线上 海量业务中找出风险异常点。一旦发现任何问题就发出告警通知相应的同学，进行相 应的流程进行解决。 平时没有故障的时候做什么呢？就是开头提到的红蓝攻防了。蓝军从第三方角度 发掘各类脆弱点，并通过红蓝军技术攻防演练，不断验证防御系统的可靠性。每年的 大演练时刻，都会进行全公司的动员，两边排兵布阵，攻守异常激烈。 在“期末考试”中，每支红军在被攻击后，花费多长时间发现故障，又用了多 长时间恢复等都会被视作评定指标，而结果会根据“无损”攻防体系相匹配的度量平 台，对攻防结果进行排名。 去年“期末考试”冠军得主是红一支付宝军，支付宝资深技术专家兼军长李铮提 到，去年 12 月 21 日的红蓝大军颁奖仪式上，第一名获得了一副金算盘，以及关公 铜像一年所有权，而今年还给最后一名准备了特别“奖品”——一副烂算盘，“真的 是很烂的算盘，也就淘宝上才能买到。” 除此之外，资金安全是专门保护支付宝里的资金的系统，在海量线上资金处理 时，要保证一分钱资金都不出问题，需要的是海量数据计算和风险挖掘能力。

“程序设计 = 算法 + 数据结构”是瑞士计算机科学家Niklaus Wirth于1976年出版的一本书的书名，很快就成了在计算机工作者之间流传的一句名言。斗转星移，尽管新技术方法不断涌现，这句名言依然焕发着无限的生命力，它借助面向对象知识的普及，使数据结构技术更加完善和易于使用。由此，也说明了数据结构在计算机学科中的地位和不可替代的独特作用。 然而，在可视化程序设计的今天，借助于集成开发环境我们可以很方便、快捷地开发部署应用程序，程序设计似乎不再只是计算机专业的人员的专利，很多人以为，只要掌握了几种开发工具就可以成为编程高手了，其实这是一个误区。纵然，我们可以很熟练地掌握一门程序设计语言、熟练地运用各种IDE开发应用程序，但是我们写出的代码是否是优良的。我们的设计是否合理。代码执行是否是高效的。代码风格是否是有美感的。更甚的说我们所写出代码的是否是艺术。 在长达几年的时间内，我总是陷在了一个误区里面：即认为工程能力和算法能力是不相干的两回事，我们似乎可以很轻松地完成一个工程项目，至少我在做一些MIS系统的时候一直都是这么认为的，甚至觉得根本不需要所谓的算法或数据结构。当时一直想不通的是为什么Google、百度这样牛的公司却对ACMer们如此青睐，对于这种招聘的标准感到疑惑不解。为什么他们不在技术（多线程、网络编程、分布式系统等）上做要求，却偏偏只关注这么一小块的算法设计。 我曾经反复地告诉自己“程序设计 = 算法 + 数据结构”在70年代提出是受限于计算机硬件，当时的内存不足、计算能力不强，程序需要设计足够精巧细致。再看当前主流的计算机配置，比70年代的大型机运算能力还要强大，我们好像完全不用担心算法设计的问题。报着这样的想法，我向来都不太重视算法，而且工程中对算法的需求并不多。 只是有一天，我突然发现我只是片面地关注其中一个方面，硬件能力是提升了，但同时人们所面对的信息、数据、运算任务的规模也是极大的膨胀了，而且膨胀的规模比硬件本身运算能力提升的规模还要大很多。算法和数据结构不仅没有贬值，反而比之前那个时代显得更为重要。试想，在互联网迅猛发展的今天，一个中等规模的企业每天所产生的数据量能达到GB级甚至TB级。要处理这样的海量数据不是说单纯的硬件运算能力上来就解决了的，设计优良的算法和数据结构设计能够在1分钟之内完成任务，而一个糟糕的设计则可能需要1个小时的运行。 一般认为，一个数据结构是由数据元素依据某种逻辑联系组织起来的，这种对数据元素间逻辑关系的描述称为数据结构。许多大型系统的构造经验表明，系统实现的困难程度和系统构造的质量都严重的依赖于是否选择了最优的数据结构。许多时候，确定了数据结构后，算法就容易得到了。当然，有些情况下事情也会反过来，我们根据特定算法来选择数据结构与之适应。算法则可以理解为有基本运算及规定的运算顺序所构成的完整的解题步骤，或者看成按照要求设计好的有限的确切的计算序列，并且这样的步骤和序列可以解决一类问题。 总的来说，数据结构和算法并不是一门教你编程的课，它们可以脱离任何的计算机程序设计语言，而只需要从抽象意义上去概括描述。说的简单一点，数据结构是一门告诉你数据在计算机里如何组织的课程，而算法是一门告诉你数据在计算机里如何运算的课程，前者是结构学、后者是数学。程序设计就像盖房子，数据结构是砖、瓦，而算法则是设计图纸。你若想盖房子首先必须要有原材料（数据结构），但这些原材料并不能自动地盖起你想要的房子，你必须按照设计图纸（算法）一砖一瓦地去砌，这样你才能拥有你想要的房子。数据结构是程序设计这座大厦的基础，没有基础，无论设计有多么高明，这座大厦不可能建造起来。算法则是程序设计之灵魂，它是程序设计的思想所在，没有灵魂没有思想那不叫程序，只是一堆杂乱无章的符号而已。在程序设计中，数据结构就像物质，而算法则是意识，这在哲学上可以理解为：意识是依赖与物质而存在的，物质是由意识而发展的。双方相互依赖，缺一不可。 当然最经典的数据结构是有限的，包括线性表、栈、队列、串、数组、二叉树、树、图、查找表等，而算法则是琳琅满目的，多种多样的。就好像数据结构是人体的各种组织、器官，算法则是人的思想。你可以用自己的思想去支配你的身体各个可以运动的器官随意运动。如果你想吃苹果，你可以削皮吃，可以带皮吃，只要你愿意，甚至你可以不洗就吃。但无论如何，你的器官还是你的器官，就那么几样，目的只有一个就是吃苹果，而方式却是随心所欲的。这就是算法的灵活性、不固定性。因此可以这样说：数据结构是死的，而算法是活的。 我花了四年时间才走出这个误区，值得庆幸的是不算太晚，而我的梦想是要做一名优秀的架构师，缺乏数据结构和算法的深厚功底，很难设计出高水平的具有专业水准的架构和应用，数据结构和算法则是我实现梦想最坚实的基石。现在，也正是我需要开始沉淀的时刻。程序设计这项伟大的工程，教授于我的将不仅仅是技术这么简单，我期待它能给我以更深的思考与感悟，激发我对生命的热爱，对理想的执着，对卓越的追求。

在开始谈我对架构本质的理解之前，先谈谈对今天技术沙龙主题的个人见解，千万级规模的网站感觉数量级是非常大的，对这个数量级我们战略上 要重 视 它 ， 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级？现在很流行的优步(Uber)，从媒体公布的信息看，它每天接单量平均在百万左右， 假如每天有10个小时的服务时间，平均QPS只有30左右。对于一个后台服务器，单机的平均QPS可以到达800-1000，单独看写的业务量很简单 。为什么我们又不能说轻视它？第一，我们看它的数据存储，每天一百万的话，一年数据量的规模是多少？其次，刚才说的订单量，每一个订单要推送给附近的司机、司机要并发抢单，后面业务场景的访问量往往是前者的上百倍，轻松就超过上亿级别了。 今天我想从架构的本质谈起之后，希望大家理解在做一些建构设计的时候，它的出发点以及它解决的问题是什么。 架构，刚开始的解释是我从知乎上看到的。什么是架构？有人讲， 说架构并不是一 个很 悬 乎的 东西 ， 实际 上就是一个架子 ， 放一些 业务 和算法，跟我们的生活中的晾衣架很像。更抽象一点，说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻，强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力？我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一，你必须要有抽象的能力，抽象的能力最基本就是去重，去重在整个架构中体现在方方面面，从定义一个函数，到定义一个类，到提供的一个服务，以及模板，背后都是要去重提高可复用率。 第二， 分类能力。做软件需要做对象的解耦，要定义对象的属性和方法，做分布式系统的时候要做服务的拆分和模块化，要定义服务的接口和规范。 第三， 算法（性能），它的价值体现在提升系统的性能，所有性能的提升，最终都会落到CPU，内存，IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子，在分布式系统我们会做 MySQL分 库 分表，我们要从不同的库和表中读取数据，这样的抽象最直观就是使用模板，因为绝大多数SQL语义是相同的，除了路由到哪个库哪个表，如果不使用Proxy中间件，模板就是性价比最高的方法。 第二看一下加速网络的CDN，它是做速度方面的性能提升，刚才我们也提到从CPU、内存、IO、网络四个方面来考虑，CDN本质上一个是做网络智能调度优化，另一个是多级缓存优化。 第三个看一下服务化，刚才已经提到了，各个大网站转型过程中一定会做服务化，其实它就是做抽象和做服务的拆分。第四个看一下消息队列，本质上还是做分类，只不过不是两个边际清晰的类，而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构，到一定量级的系统整个架构都会变成三层，客户端包括WEB、安卓和IOS，这里就不说了。接着还都会有一个接口层， 有三个主要作用： 第一个作用，要做 安全隔离，因为前端节点都是直接和用户交互，需要防范各种恶意攻击； 第二个还充当着一个 流量控制的作用，大家知道，在2014年春节的时候，微信红包，每分钟8亿多次的请求，其实真正到它后台的请求量，只有十万左右的数量级（这里的数据可能不准），剩余的流量在接口层就被挡住了； 第三，我们看对 PC 端和移 动 端的需求不一样的，所以我们可以进行拆分。接口层之后是后台，可以看到微博后台有三大块： 一个是 平台服 务， 第二， 搜索， 第三， 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门，做的就是 数据存储和读 取，对搜索来说做的是 数据的 检 索，对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说，第一代架构，基本上能支撑到用户到 百万 级别，到第二代架构基本能支撑到 千万 级别都没什么问题，当业务规模到 亿级别时，需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构，有几个地方是非常难的，首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的，同时线上业务又不能停， 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我，说他在内部推行服务化的时候，把一个模块服务化做完了，其他部门就是不接。我建议在做服务化的时候，首先更多是偏向业务的梳理，同时要找准一个很好的切入点，既有架构和服务化上的提升，业务方也要有收益，比如提升性能或者降低维护成本同时升级过程要平滑，建议开始从原子化服务切入，比如基础的用户服务， 基础的短消息服务，基础的推送服务。 第二，就是可 以做无状 态 服 务，后面会详细讲，还有数据量大了后需要做数据Sharding，后面会将。 第三代 架构 要解决的 问题，就是用户量和业务趋于稳步增加（相对爆发期的指数级增长），更多考虑技术框架的稳定性， 提升系统整体的性能，降低成本，还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战，PV是在10亿级别，QPS在百万，数据量在千亿级别。我们可用性，就是SLA要求4个9，接口响应最多不能超过150毫秒，线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢？那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务，每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样，就是数据量，bigger and bigger，用户体验是faster and faster，业务是more and more。互联网业务更多是产品体验驱动， 技 术 在 产 品 体验上最有效的贡献 ， 就是你的性能 越来越好 。 每次降低加载一个页面的时间，都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度，横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分，第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分，会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下， 接口层有feed、用户关系、通讯接口；服务层，SOA里有基层服务、原子服务和组合服务，在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务，组合服务由几个原子服务和自己的业务逻辑构建而成 ，资源层负责海量数据的存储（后面例子会详细讲）。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题，由众多的技术组件共同构建而成 。在接口层，微博使用JERSY框架，帮助你做参数的解析，参数的验证，序列化和反序列化；资源层，主要是缓存、DB相关的各类组件，比如Cache组件和对象库组件。监 控平台和服 务 治理 ， 完成系统服务的像素级监控，对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个，首先是系统架构三个利器： 一个， 我 们 RPC 服 务组 件 （这里不讲了）， 第二个，我们 消息中 间 件 。消息中间件起的作用：可以把两个模块之间的交互异步化，其次可以把不均匀请求流量输出为匀速的输出流量，所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理，它是 代码级灰度发布以及 保障系统降级的利器。 第二个 ， 无状态 ， 接口 层 最重要的就是无状 态。我们在电商网站购物，在这个过程中很多情况下是有状态的，比如我浏览了哪些商品，为什么大家又常说接口层是无状态的，其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物，选了几件商品，到了哪一步，接口无状态后，状态要么放在缓存中，要么放在数据库中， 其 实 它并不是没有状 态 ， 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个， 数据 层 比服 务层 更需要 设计，这是一条非常重要的经验。对于服务层来说，可以拿PHP写，明天你可以拿JAVA来写，但是如果你的数据结构开始设计不合理，将来数据结构的改变会花费你数倍的代价，老的数据格式向新的数据格式迁移会让你痛不欲生，既有工作量上的，又有数据迁移跨越的时间周期，有一些甚至需要半年以上。 第四，物理结构与逻辑结构的映射，上一张图看到两个维度切成十二个区间，每个区间代表一个技术领域，这个可以看做我们的逻辑结构。另外，不论后台还是应用层的开发团队，一般都会分几个垂直的业务组加上一个基础技术架构组，这就是从物理组织架构到逻辑的技术架构的完美的映射，精细化团队分工，有利于提高沟通协作的效率 。 第五， www .sanhao.com 的访问过程，我们这个架构图里没有涉及到的，举个例子，比如当你在浏览器输入www.sanhao网址的时候，这个请求在接口层之前发生了什么？首先会查看你本机DNS以及DNS服务，查找域名对应的IP地址，然后发送HTTP请求过去。这个请求首先会到前端的VIP地址（公网服务IP地址），VIP之后还要经过负载均衡器（Nginx服务器），之后才到你的应用接口层。在接口层之前发生了这么多事，可能有用户报一个问题的时候，你通过在接口层查日志根本发现不了问题，原因就是问题可能发生在到达接口层之前了。 第六，我们说分布式系统，它最终的瓶颈会落在哪里呢？前端时间有一个网友跟我讨论的时候，说他们的系统遇到了一个瓶颈， 查遍了CPU，内存，网络，存储，都没有问题。我说你再查一遍，因为最终你不论用上千台服务器还是上万台服务器，最终系统出瓶颈的一定会落在某一台机（可能是叶子节点也可能是核心的节点），一定落在CPU、内存、存储和网络上，最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候，经常很少做业务分析，技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例，像前三页占了97%，在做缓存设计的时候，我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 ， 越细致越好 。举了一个例子，大家都会用电商，电商在双十一会做全国范围内的活动，他们做设计的时候也会考虑场景的，一个就是购物车，我曾经跟相关开发讨论过，购物车是在双十一之前用户的访问量非常大，就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了，但是他会频繁的浏览购物车。针对这个场景，活动之前重点设计优化购物车的写场景， 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢？最右边的是Feed，就是微博所有关注的人，他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展，除了跟时间序相关的微博还有非时间序的微博，就是会有广告的要求，增加一些广告，还有粉丝头条，就是拿钱买的，热门微博，都会插在其中。分发控制，就是说和一些推荐相关的，我推荐一些相关的好友的微博，我推荐一些你可能没有读过的微博，我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博，实际会起多个并行的程序来读取，最后同步做统一的聚合。这里稍微分享一下， 从SNS社交领域来看，国内现在做的比较好的三个信息流： 微博 是 基于弱关系的媒体信息流 ； 朋友圈是基于 强 关系的信息流 ； 另外一个做的比 较 好的就是今日 头 条 ， 它并不是基于关系来构建信息流 ， 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合，体现在很多很多的产品之中，除了SNS，电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页，它的信息流基本由几部分组成：第一，打广告的；第二个，做一些推荐，热门的商品，其次，才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 ， 但是到后期会 发现 ， 你的 这 个流 如何做控制分发 ， 非常复杂， 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析，那么技术上怎么解决高并发，高性能的问题？微博访问量很大的时候，底层存储是用MySQL数据库，当然也会有其他的。对于查询请求量大的时候，大家知道一定有缓存，可以复用可重用的计算结果。可以看到，发一条微博，我有很多粉丝，他们都会来看我发的内容，所以 微博是最适合使用 缓 存 的系统，微博的读写比例基本在几十比一。微博使用了 双 层缓 存，上面是L1，每个L1上都是一组（包含4-6台机器），左边的框相当于一个机房，右边又是一个机房。在这个系统中L1缓存所起的作用是什么？ 首先，L1 缓 存增加整个系 统 的 QPS， 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景，只有一篇博文，但是它的访问量无限增长，其实我们不需要影响L2缓存，因为它的内容存储的量小，但它就是访问量大。这种场景下，你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景，就是L2级缓存发生作用，比如我有一千万个用户，去访问的是一百万个用户的微博 ，这个时候，他不只是说你的吞吐量和访问带宽，就是你要缓存的博文的内容也很多了，这个时候你要考虑缓存的容量， 第二 级缓 存更多的是从容量上来 规划，保证请求以较小的比例 穿透到 后端的 数据 库 中 ，根据你的用户模型你可以估出来，到底有百分之多少的请求不能穿透到DB， 评估这个容量之后，才能更好的评估DB需要多少库，需要承担多大的访问的压力。另外，我们看双机房的话，左边一个，右边一个。 两个机房是互 为 主 备 ， 或者互 为热备 。如果两个用户在不同地域，他们访问两个不同机房的时候，假设用户从IDC1过来，因为就近原理，他会访问L1，没有的话才会跑到Master，当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问，也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ，两个机房都有全量的用户数据，同时在线提供服务，但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢？CDN是典型的多级缓存。CDN在国内各个地区做了很多节点，比如在杭州市部署一个节点时，在机房里肯定不止一台机器，那么对于一个地区来说，只有几台服务器到源站回源，其他节点都到这几台服务器回源即可，这么看CDN至少也有两级。Local Cache+ 分布式 缓 存，这也是常见的一种策略。有一种场景，分布式缓存并不适用， 比如 单 点 资 源 的爆发性峰值流量，这个时候使用Local Cache + 分布式缓存，Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量，长尾的流量仍然访问分布式缓存，这样的Hybrid缓存架构通过复用众多的应用服务器节点，降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构，微博的博文主要存在MySQL中。首先来看内容表，这个比较简单，每条内容一个索引，每天建一张表，其次看索引表，一共建了两级索引。首先想象一下用户场景，大部分用户刷微博的时候，看的是他关注所有人的微博，然后按时间来排序。仔细分析发现在这个场景下， 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户，取他们的前条微博ID，然后聚合排序。我们在做哈希（分库分表）的时候，同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的，今天的热点新闻，明天就没热度了，数据的冷热非常明显，这种场景就需要按照时间维度做分表，首先冷热数据做了分离（可以对冷热数据采用不同的存储方案来降低成本），其次， 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分，那么这个用户所有数据都在一张表里，这张表就是无限增长的，时间长了查询会越来越慢。二级索引，是我们里面一个比较特殊的场景，就是我要快速找到这个人所要发布的某一时段的微博时，通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统，当系统到千万级以后的时候，越来越庞杂，所解决的问题更偏向稳定性，性能和监控。刚才说用户只要有一个请求过来，你可以依赖你的服务RPC1、RPC2，你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点，就是说一个请求从用户过来之后，在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候，这些日志落在不同的机器上，你也不知道问题到底出在哪儿，各个服务之间互相隔离，互相之间没有建立关联。所以导致排查问题基本没有任何手段，就是出了问题没法儿解决。 我们要解决的问题，我们刚才说日志互相隔离，我们就要把它建立联系。建立联系我们就有一个请求ID，然后结合RPC框架， 服务治理功能。假设请求从客户端过来，其中包含一个ID 101，到服务A时仍然带有ID 101，然后调用RPC1的时候也会标识这是101 ，所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个，你做的时候，你不能说每个地方都加，对业务系统来说需要一个框架来完成这个工作， 这 个框架要 对业务 系 统 是最低侵入原 则 ， 用 JAVA 的 话 就可以用 AOP，要做到零侵入的原则，就是对所有相关的中间件打点，从接口层组件（HTTP Client、HTTP Server）至到服务层组件（RPC Client、RPC Server），还有数据访问中间件的，这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志？服务化以后，每个服务可以用不同的开发语言， 考虑多种开发语言的兼容性 ， 内部定 义标 准化的日志 是唯一且有效的办法。最后，如何构建基于GPS导航的路况监控？我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题， 如果 单一用 户发现问题 后 ， 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么，但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控，每辆车有GPS定位，我想看北京哪儿拥堵的时候，怎么做？ 第一个 ， 你肯定要知道每个 车 在什么位置，它走到哪儿了。其实可以说每个车上只要有一个标识，加上每一次流动的信息，就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警，我们怎么能了解道路的流量状况和负载，并及时报警。我们要定义这条街道多宽多高，单位时间可以通行多少辆车，这就是道路的容量。有了道路容量，再有道路的实时流量，我们就可以基于实习路况做预警？ 对应于 分布式系 统 的话如何构建？ 第一 ， 你要 定义 每个服 务节 点它的 SLA A 是多少 ？SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义，相当于定义系统的容量。 第二个 ， 统计 线 上 动态 的流量，你要知道服务的平均QPS、最低QPS和最大QPS，有了流量和容量，就可以对系统做全面的监控和报警。 刚才讲的是理论，实际情况肯定比这个复杂。微博在春节的时候做许多活动，必须保障系统稳定，理论上你只要定义容量和流量就可以。但实际远远不行，为什么？有技术的因素，有人为的因素，因为不同的开发定义的流量和容量指标有主观性，很难全局量化标准，所以真正流量来了以后，你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施：第一，最简单的就是有降 级 的 预 案，流量超过系统容量后，先把哪些功能砍掉，需要有明确的优先级 。第二个， 线上全链路压测，就是把现在的流量放大到我们平常流量的五倍甚至十倍（比如下线一半的服务器，缩容而不是扩容），看看系统瓶颈最先发生在哪里。我们之前有一些例子，推测系统数据库会先出现瓶颈，但是实测发现是前端的程序先遇到瓶颈。第三，搭建在线 Docker 集群 ， 所有业务共享备用的 Docker集群资源，这样可以极大的避免每个业务都预留资源，但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升，这里以Java语言为例，首先， 一定要 理解 JAVA；第二步，JAVA完了以后，一定要 理 解 JVM；其次，还要 理解 操作系统；再次还是要了解一下 Design Pattern，这将告诉你怎么把过去的经验抽象沉淀供将来借鉴；还要学习 TCP/IP、 分布式系 统、数据结构和算法。

怎么没人讨论啊?  阿里云客服解答一下也可以啊.. ------------------------- 引用第2楼ace_php_faq于2014-11-18 15:56发表的  : 海量数据处理，odps 吗？ 你是针对第一种情况吗? 不过我压根没怎么看懂阿里云这个产品. 你已经用过了? 能否说说第一种情况使用时的该产品架构运作过程? ------------------------- 回 6楼(千鸟) 的帖子 以陌陌的附近的留言功能为例. 海量留言. 我用数据库来存放,然后再通过坐标获取附近XX公里内的所有用户留言内容. 内存即使用KEY_VALUE存取, 还得按条件获取(如附近XX公里内的所有留言), 还得按时间排序出来. KEY VALUE直接搞不定. 即使用了RDS数据库, 搜索起来方便了, 但是海量动态数据, 筛选和排序并返回给用户.(当然还有增加), 肯定非常吃力吧. 所以我觉得你说的太简单了点了吧...这两个东西压根就不适合当针对那个需求的架构. ------------------------- Re:回 7楼(huangjinshe) 的帖子 引用第8楼啊里新人于2014-11-20 15:24发表的 回 7楼(huangjinshe) 的帖子 : 你的业务场景之前没考虑过，想这种高大上的产品不应该有一个人来做， 而且关于数据存储，阿里只是一个服务空间，你怎么存储是作为一个技术应该考虑的。 另外视频转码的事儿，你说的什么cpu就不清楚了，不是搞那一块的。 谁说一个人做? 也是一个团队做呀. 阿里只是服务空间?  现在的阿里远远已经不但是服务空间, 而是一个综合平台. 通过提供强大的技术和服务让用户使用更好的解决方案. 所以我才想和大家一起讨论在阿里云如何集成阿里云的产品来实现这些. ------------------------- 回 10楼(啊里新人) 的帖子 确实, 必须调用支持Intel Quicksync的CPU才能发挥好的性能. ------------------------- 回 12楼(啊里新人) 的帖子 这话说的好像别的服务器不是透明的一样? ------------------------- 引用第13楼千鸟于2014-11-21 20:51发表的  : 阿里云只负责提供基础服务，具体的核心业务应该是应用层考虑的 阿里云马上就推出编码业务了. 你不想不意味着阿里云不整. 况且我说的也不是非基础服务. 只剩下另一个问题了. ------------------------- Re:回 14楼(huangjinshe) 的帖子 引用第16楼啊里新人于2014-11-24 10:10发表的 回 14楼(huangjinshe) 的帖子 : 。。。。这里貌似只有阿里，我也就说ecs咋回事儿了。再说了别家的也不叫ecs吧。。。 你太敏感了 我说的是哪家服务器不是透明的? 跟ECS没啥关系啊.... 你也真是的....答非所问啊...

X-Engine是阿里云数据库产品事业部自研的联机事务处理OLTP（On-Line Transaction Processing）数据库存储引擎。作为自研数据库POLARDB的存储引擎之一，已经广泛应用在阿里集团内部诸多业务系统中，包括交易历史库、钉钉历史库等核心应用，大幅缩减了业务成本，同时也作为双十一大促的关键数据库技术，挺过了数百倍平时流量的冲击。 为什么设计一个新的存储引擎 X-Engine的诞生是为了应对阿里内部业务的挑战，早在2010年，阿里内部就大规模部署了MySQL数据库，但是业务量的逐年爆炸式增长，数据库面临着极大的挑战： 极高的并发事务处理能力（尤其是双十一的流量突发式暴增）。 超大规模的数据存储。 这两个问题虽然可以通过扩展数据库节点的分布式方案解决，但是堆机器不是一个高效的手段，我们更想用技术的手段将数据库性价比提升到极致，实现以少量资源换取性能大幅提高的目的。 传统数据库架构的性能已经被仔细的研究过，数据库领域的泰斗，图灵奖得主Michael Stonebreaker就此写过一篇论文 《OLTP Through the Looking Glass, and What We Found There》 ，指出传统关系型数据库，仅有不到10%的时间是在做真正有效的数据处理工作，剩下的时间都浪费在其它工作上，例如加锁等待、缓冲管理、日志同步等。 造成这种现象的原因是因为近年来我们所依赖的硬件体系发生了巨大的变化，例如多核（众核）CPU、新的处理器架构（Cache/NUMA）、各种异构计算设备（GPU/FPGA）等，而架构在这些硬件之上的数据库软件却没有太大的改变，例如使用B-Tree索引的固定大小的数据页（Page）、使用ARIES算法的事务处理与数据恢复机制、基于独立锁管理器的并发控制等，这些都是为了慢速磁盘而设计，很难发挥出现有硬件体系应有的性能。 基于以上原因，阿里开发了适合当前硬件体系的存储引擎，即X-Engine。 X-Engine架构 全新架构的X-Engine存储引擎不仅可以无缝对接兼容MySQL（得益于MySQL Pluginable Storage Engine特性），同时X-Engine使用分层存储架构。 因为目标是面向大规模的海量数据存储，提供高并发事务处理能力和降低存储成本，在大部分大数据量场景下，数据被访问的机会是不均等的，访问频繁的热数据实际上占比很少，X-Engine根据数据访问频度的不同将数据划分为多个层次，针对每个层次数据的访问特点，设计对应的存储结构，写入合适的存储设备。 X-Engine使用了LSM-Tree作为分层存储的架构基础，并进行了重新设计： 热数据层和数据更新使用内存存储，通过内存数据库技术（Lock-Free index structure/append only）提高事务处理的性能。 流水线事务处理机制，把事务处理的几个阶段并行起来，极大提升了吞吐。 访问频度低的数据逐渐淘汰或是合并到持久化的存储层次中，并结合多层次的存储设备（NVM/SSD/HDD）进行存储。 对性能影响比较大的Compaction过程做了大量优化： 拆分数据存储粒度，利用数据更新热点较为集中的特征，尽可能的在合并过程中复用数据。 精细化控制LSM的形状，减少I/O和计算代价，有效缓解了合并过程中的空间增大。 同时使用更细粒度的访问控制和缓存机制，优化读的性能。 技术特点 利用FPGA硬件加速Compaction过程，使得系统上限进一步提升。这个技术属首次将硬件加速技术应用到在线事务处理数据库存储引擎中，相关论文 《FPGA-Accelerated Compactions for LSM-based Key Value Store》 已经被2020年的顶级会议FAST'20接收。 通过数据复用技术减少数据合并代价，同时减少缓存淘汰带来的性能抖动。 使用多事务处理队列和流水线处理技术，减少线程上下文切换代价，并计算每个阶段任务量配比，使整个流水线充分流转，极大提升事务处理性能。相对于其他类似架构的存储引擎（例如RocksDB），X-Engine的事务处理性能有10倍以上提升。 X-Engine使用的Copy-on-write技术，避免原地更新数据页，从而对只读数据页面进行编码压缩，相对于传统存储引擎（例如InnoDB），使用X-Engine可以将存储空间降低至10%~50%。 Bloom Filter快速判定数据是否存在，Surf Filter判断范围数据是否存在，Row Cache缓存热点行，加速读取性能。 LSM基本逻辑 LSM的本质是所有写入操作直接以追加的方式写入内存。每次写到一定程度，即冻结为一层（Level），并写入持久化存储。所有写入的行，都以主键（Key）排序好后存放，无论是在内存中，还是持久化存储中。在内存中即为一个排序的内存数据结构（Skiplist、B-Tree、etc），在持久化存储也作为一个只读的全排序持久化存储结构。 普通的存储系统若要支持事务处理，需要加入一个时间维度，为每个事务构造出一个不受并发干扰的独立视域。例如存储引擎会对每个事务定序并赋予一个全局单调递增的事务版本号（SN），每个事务中的记录会存储这个SN以判断独立事务之间的可见性，从而实现事务的隔离机制。 如果LSM存储结构持续写入，不做其他的动作，那么最终会成为如下结构。 这种结构对于写入是非常友好的，只要追加到最新的内存表中即完成，为实现故障恢复，只需记录Redo Log，因为新数据不会覆盖旧版本，追加记录会形成天然的多版本结构。 但是如此累积，冻结的持久化层次越来越多，会对查询会产生不利的影响。例如对同一个key，不同事务提交产生的多版本记录会散落在各个层次中；不同的key也会散落在不同层次中。读操作需要查找各个层并合并才能得到最终结果。 因此LSM引入了Compaction操作解决这个问题，Compaction操作有2种作用： 控制LSM层次形状 一般的LSM形状都是层次越低，数据量越大（倍数关系），目的是为了提升读性能。 通常存储系统的数据访问都有局部性，大量的访问都集中在少部分数据上，这也是缓存系统能有效工作的基本前提。在LSM存储结构中，如果把访问频率高的数据尽可能放在较高的层次上，存放在快速存储设备中（例如NVM、DRAM），而把访问频率低的数据放在较低层次中，存放在廉价慢速存储设备中。这就是X-Engine的冷热分层概念。 合并数据 Compaction操作不断的把相邻层次的数据合并，并写入更低层次。合并的过程实际上是把要合并的相邻两层或多层的数据读出来，按key排序，相同的key如果有多个版本，只保留新的版本（比当前正在执行的活跃事务中最小版本号新），丢掉旧版本数据，然后写入新的层，这个操作非常耗费资源。 合并数据除了考虑冷热分层以外，还需要考虑其他维度，例如数据的更新频率，大量的多版本数据在查询的时候会浪费更多的I/O和CPU，因此需要优先进行合并以减少记录的版本数量。X-Engine综合考虑了各种策略形成自己的Compaction调度机制。 高度优化的LSM X-Engine的memory tables使用了无锁跳表（Locked-free SkipList），并发读写的性能较高。在持久化层如何实现高效，就需要讨论每层的细微结构。 数据组织 X-Engine的每层都划分成固定大小的Extent，存放每个层次中的数据的一个连续片段（Key Range）。为了快速定位Extent，为每层Extents建立了一套索引（Meta Index），所有这些索引，加上所有的memory tables（active/immutable）一起组成了一个元数据树（Metadata Tree），root节点为Metadata Snapshot，这个树结构类似于B-Tree。 X-Engine中除了当前的正在写入的active memory tables以外，其他结构都是只读的，不会被修改。给定某个时间点，例如LSN=1000，上图中的Metadata Snapshot 1引用到的结构即包含了LSN=1000时的所有的数据的快照，因此这个结构被称为Snapshot。 即便是Metadata结构本身，也是一旦生成就不会被修改。所有的读请求都是以Snapshot为入口，这是X-Engine实现Snapshot级别隔离的基础。前文说过随着数据写入，累积数据越多，会执行Compaction操作、冻结memory tables等，这些操作都是用Copy-on-write实现，即每次都将修改产生的结果写入新的Extent，然后生成新的Meta Index结构，最终生成新的Metadata Snapshot。 例如执行一次Compaction操作会生成新的Metadata Snapshot，如下图所示。 可以看到Metadata Snapshot 2相对于Metadata Snapshot 1并没有太多的变化，仅仅修改了发生变更的一些叶子节点和索引节点。 事务处理 得益于LSM的轻量化写机制，写入操作固然是其明显的优势，但是事务处理不只是把更新的数据写入系统那么简单，还要保证ACID（原子性、一致性、隔离性、持久性），涉及到一整套复杂的流程。X-Engine将整个事务处理过程分为两个阶段： 读写阶段 校验事务的冲突（写写冲突、读写冲突），判断事务是否可以执行、回滚重试或者等锁。如果事务冲突校验通过，则把修改的所有数据写入Transaction Buffer。 提交阶段 写WAL、写内存表，以及提交并返回用户结果，这里面既有I/O操作（写日志、返回消息），也有CPU操作（拷贝日志、写内存表）。 为了提高事务处理吞吐，系统内会有大量事务并发执行，单个I/O操作比较昂贵，大部分存储引擎会倾向于聚集一批事务一起提交，称为Group Commit，能够合并I/O操作。但是一组事务提交的过程中，还是有大量等待过程的，例如写入日志到磁盘过程中，除了等待落盘无所事事。 X-Engine为了进一步提升事务处理的吞吐，使用流水线技术，把提交阶段分为4个独立的更精细的阶段： 拷贝日志到缓冲区（Log Buffer） 日志落盘（Log Flush） 写内存表（Write memory table） 提交返回（Commit） 事务到了提交阶段，可以自由选择执行流水线中任意一个阶段，只要流水线任务的大小划分得当，就能充分并行起来，流水线处于接近满载状态。另外这里利用的是事务处理的线程，而非后台线程，每个线程在执行的时候，选择流水线中的一个阶段执行任务，或者空闲后处理其他请求，没有等待，也无需切换，充分利用了每个线程的能力。 读操作 LSM处理多版本数据的方式是新版本数据记录会追加在老版本数据后面，从物理上看，一条记录不同的版本可能存放在不同的层，在查询的时候需要找到合适的版本（根据事务隔离级别定义的可见性规则），一般查询都是查找最新的数据，总是由最高的层次往低层次找。 对于单条记录的查找而言，一旦找到便可以终止，如果记录在比较高的层次，例如memory tables，很快便可以返回；如果记录已经落入了很低的层次，那就得逐层查找，也许Bloom Filter可以跳过某些层次加快这个旅程，但毕竟还是有很多的I/O操作。X-Engine针对单记录查询引入了Row Cache，在所有持久化的层次的数据之上做了一个缓存，在memory tables中没有命中的单行查询，在Row Cache之中也会被捕获。Row Cache需要保证缓存了所有持久化层次中最新版本的记录，而这个记录是可能发生变化的，例如每次flush将只读的memory tables写入持久化层次时，就需要恰当的更新Row Cache中的缓存记录，这个操作比较微妙，需要精心的设计。 对于范围扫描而言，因为没法确定一个范围的key在哪个层次中有数据，只能扫描所有的层次做合并之后才能返回最终的结果。X-Engine采用了一系列的手段，例如SuRF（SIGMOD'18 best paper）提供range scan filter减少扫描层数、异步I/O与预取。 读操作中最核心的是缓存设计，Row Cache负责单行查询，Block Cache负责Row Cache的漏网之鱼，也用来进行范围扫描。由于LSM的Compaction操作会一次更新大量的Data Block，导致Block Cache中大量数据短时间内失效，导致性能的急剧抖动，因此X-Engine做了很多的优化： 减少Compaction的粒度。 减少Compaction过程中改动的数据。 Compaction过程中针对已有的缓存数据做定点更新。 Compaction Compaction操作是比较重要的，需要把相邻层次交叉的Key Range数据读取合并，然后写到新的位置。这是为前面简单的写入操作付出的代价。X-Engine为优化这个操作重新设计了存储结构。 如前文所述，X-Engine将每一层的数据划分为固定大小的Extent，一个Extent相当于一个小而完整的排序字符串表（SSTable），存储了一个层次中的一个连续片段，连续片段又进一步划分为一个个连续的更小的片段Data Block，相当于传统数据库中的Page，只不过Data Block是只读而且不定长的。 回看并对比Metadata Snapshot 1和Metadata Snapshot 2，可以发现Extent的设计意图。每次修改只需要修改少部分有交叠的数据，以及涉及到的Meta Index节点。两个Metadata Snapshot结构实际上共用了大量的数据结构，这被称为数据复用技术（Data Reuse），而Extent大小正是影响数据复用率的关键，Extent作为一个完整的被复用的物理结构，需要尽可能的小，这样与其他Extent数据交叉点会变少，但又不能非常小，否则需要索引过多，管理成本太大。 X-Engine中Compaction的数据复用是非常彻底的，假设选取两个相邻层次（Level1, Level2）中的交叉的Key Range所涵盖的Extents进行合并，合并算法会逐行进行扫描，只要发现任意的物理结构（包括Data Block和Extent）与其他层中的数据没有交叠，则可以进行复用。只不过Extent的复用可以修改Meta Index，而Data Block的复用只能拷贝，即便如此也可以节省大量的CPU。 一个典型的数据复用在Compaction中的过程可以参考下图。 可以看出数据复用的过程是在逐行迭代的过程中完成的，不过这种精细的数据复用带来另一个副作用，即数据的碎片化，所以在实际操作的过程中也需要根据实际情况进行分析。 数据复用不仅给Compaction操作本身带来好处，降低操作过程中的I/O与CPU消耗，更对系统的综合性能产生一系列的影响。例如c、Compaction过程中数据不用完全重写，大大降低了写入时空间的增大；大部分数据保持原样，数据缓存不会因为数据更新而失效，减少合并过程中因缓存失效带来的读性能抖动。 实际上，优化Compaction的过程只是X-Engine工作的一部分，更重要的是优化Compaction调度的策略，选什么样的Extent、定义compaction任务的粒度、执行的优先级等，都会对整个系统性能产生影响，可惜并不存在什么完美的策略，X-Engine积累了一些经验，定义了很多规则，而探索更合理的调度策略是未来一个重要方向。 适用场景 请参见X-Engine最佳实践。 如何使用X-Engine 请参见使用X-Engine引擎。 后续发展 作为MySQL的存储引擎，持续地提升MySQL系统的兼容能力是一个重要目标，后续会根据需求的迫切程度逐步加强原本取消的一些功能，例如外键，以及对一些数据结构、索引类型的支持。 X-Engine作为存储引擎，核心的价值还在于性价比，持续提升性能降低成本，是一个长期的根本目标，X-Engine还在Compaction调度、缓存管理与优化、数据压缩、事务处理等方向上进行深层次的探索。 X-Engine不仅仅局限为一个单机的数据库存储引擎，未来还将作为自研分布式数据库POLARDB分布式版本的核心，提供企业级数据库服务。

回到今天看互联网、计算机与智能技术的发展，我认为第一个真正被验证过的就 是搜索，互联网的发展拉动了搜索技术的发展。搜索是第一个实现算力、数据规模化 的软件，它依然满足冯诺依曼架构的设想。其实，搜索最开始被提出来的时候就是为 了解决海量数据的计算效率问题，最早由雅虎发明，后来 Google 通过 PageRank 算法做了改良，以更好的体验创造了巨大的市场。正是因为在互联网广告领域发现了 巨大的市场需求，才使得源源不断技术投入到搜索领域。正是因为对于搜索技术的沉 淀，使得算力和数据的规模化问题得以更好地解决，也就形成了云计算和大数据。 传统思路无法思考新技术的估值问题，对于创新的技术，很难对它形成正确的估值，因为技术迭代速度非常快。比如当蒸汽机出现之后，很快又出现了铁路、轮船， 因此对蒸汽机进行估值时，很难想象后面会出现多大的市场，对世界和社会形成多大 的改变，这就是创新的力量。所以说只有技术创新才是在创造新的财富，因为它增加 了产能，再通过资本的投入不断扩大规模。因此，在研究技术的变化、迭代时，很难 想象一个新技术出来之后会创造怎样的新需求，所以难以通过一套成熟的方法评估一 项新技术未来的潜力空间。 今天，如果想要在企业的竞争中具有更好的竞争力，需要从资源角度去思考对每 项新技术的看法。比如在工业时代，其实出现了一次自然资源的大发现，英国最早使 用木材作为生产生活的主要燃料，后来因为木材减少才开始使用煤炭，但直到蒸汽机 发明之后，煤炭才被大量开采出来。工业革命诞生在英国还有一个很重要的原因是英 国的煤炭比较多并且方便开采，离海岸线近，比较容易运输。在古代中国，煤矿主要 在内陆，而经济最发达的地方在长三角，在没有铁路、轮船的情况下，将煤炭运输到 沿海地区的成本很高，所以煤炭没有成为古代中国经济发展的重要材料。当蒸汽机出 现之后，煤炭成为了重要的战略资源。同样的事情也发生在石油出现之后，美国克利 夫兰因为附近的油田从小城镇发展成为一个工业化城市，也正是在这里洛克菲勒拿到 了第一桶金。电力发展上也一样，1886 年，美国决定在尼亚加拉瀑布上建设一个水 电站，输送十万马力的电能到距离 26 英里外的布法罗市。瀑布在电力发明之前，只 能被当做壮观的自然景观，而当电力系统发明之后，就会发现瀑布的水落差是非常重 要的自然资源，而谁占有了这样的资源，谁就拥有了巨大的财富。对于自然资源的垄 断或攫取，能够让企业或者国家在竞争上处于优势位置，因此有必要从自然资源的角 度重新看待新技术的发展。当一项新技术出现之后，创新实际上是需要讲究市场规模 的。而对于时代的改变来说，创新的规模才是最关键、最本质的事情。 回到计算机的发展，最开始的电子管还会发光发热，存在巨大的能耗问题。后来 发明了晶体管，硅就成为了一种新的自然资源，而这种材料在地球上到处都是，使得 新造晶体管比维修电子管更加便宜，这就导致了商业模式的重构。由此可见，自然资 源会决定很多事情。 对于计算机、AI 的发展而言，算力和数据都是重要的生产资料。算力涉及到晶 体管、存储网络等，而数据则需要当做一个新的自然资源重新思考。在信息时代，计 算机的发展就是出现了各种各样的数据库，通过计算机取代了许多需要人工的填表工 作。而在智能时代，一些低门槛、低复杂度的事情都可以被计算机自动完成。回过头 来看，计算机在信息时代对算力和数据利用的规模都比较小，PC 时代所使用的算力 和数据可能仅仅来源于自身，但在智能时代的软件操作，利用的可能是云计算海量的 数据和算力。因此，今天新的软件才能解决不一样的问题，它对效率的提升会是信息 时代的无数倍。云计算有效地完成了算力的规模化，数据的规模化曾经期望通过大数 据来完成，但目前大数据并没有得到充分应用，各行各业依然在处理小数据。今天我 们谈论机器智能到底应该设计成什么样的软件，其实应该看这个智能软件到底消耗多 少算力和数据，从规模上来判断。如果一个智能软件没有消耗非常多的算力与数据， 很难想象它能够提升非常高的产能。 要实现数据的规模化，其实最重要的就是 IoT。今天，通过大量的 IoT 设备，会 源源不断地采集海量的数据，数据规模远远大于人工填表时代所产生的数据规模。人 工填表采集的数据依然认为是信息时代采集的数据，而 IoT 设备采集的数据则是满足 智能时代所需数据规模的基础。数据要想成为自然资源，规模很重要。 对于数据的成本而言，AI 的成本高是因为数据成本非常高。算力成本通过晶体 管、集成电路、云计算已经有效地实现了规模经济，可以在实现路径中逐渐收敛，并 且符合摩尔定律。而数据成本依旧非常高，这主要有几点原因：第一，对很多 AI 算 法而言，数据打标的成本非常高，往往需要人工参与，因此整个学界和产业界都在思 考如何让机器自动打标签，进而有效降低数据成本。第二，IoT 设备以及全链路数据 采集的成本过高。IoT 设备不生产数据，而是采集数据，通过 3G/4G/5G 的发展降 低了设备数据采集链路的成本。数据采集之后，还需要考虑如何存储和加工，需要综 合考量成本，也需要和上层的应用软件形成互动，所以人工数据治理也浪费了大量时 间。只要需要人工参与，效率一定不高，成本也会上升。因此，学术界和产业界也在 思考如何让机器自动进行数据治理，解决数据的质量问题。当这些全部完成之后，才能让数据成为在智能时代能够被有效使用的自然资源。

在PaaS层中一个复杂的通用应用就是大数据平台。大数据是如何一步一步融入云计算的呢?首先我们来看一下大数据里面的数据，就分三种类型，一种叫结构化的数据，一种叫非结构化的数据，还有一种叫半结构化的数据。 大数据拥抱云计算 在PaaS层中一个复杂的通用应用就是大数据平台。大数据是如何一步一步融入云计算的呢? 1 数据不大也包含智慧 一开始这个大数据并不大。原来才有多少数据?现在大家都去看电子书，上网看新闻了，在我们80后小时候，信息量没有那么大，也就看看书、看看报，一个星期的报纸加起来才有多少字?如果你不在一个大城市，一个普通的学校的图书馆加起来也没几个书架，是后来随着信息化的到来，信息才会越来越多。 首先我们来看一下大数据里面的数据，就分三种类型，一种叫结构化的数据，一种叫非结构化的数据，还有一种叫半结构化的数据。 结构化的数据：即有固定格式和有限长度的数据。例如填的表格就是结构化的数据，国籍：中华人民共和国，民族：汉，性别：男，这都叫结构化数据。 非结构化的数据：现在非结构化的数据越来越多，就是不定长、无固定格式的数据，例如网页，有时候非常长，有时候几句话就没了;例如语音，视频都是非结构化的数据。 半结构化数据：是一些XML或者HTML的格式的，不从事技术的可能不了解，但也没有关系。 其实数据本身不是有用的，必须要经过一定的处理。例如你每天跑步带个手环收集的也是数据，网上这么多网页也是数据，我们称为Data。数据本身没有什么用处，但数据里面包含一个很重要的东西，叫做信息(Information)。 数据十分杂乱，经过梳理和清洗，才能够称为信息。信息会包含很多规律，我们需要从信息中将规律总结出来，称为知识(Knowledge)，而知识改变命运。信息是很多的，但有人看到了信息相当于白看，但有人就从信息中看到了电商的未来，有人看到了直播的未来，所以人家就牛了。如果你没有从信息中提取出知识，天天看朋友圈也只能在互联网滚滚大潮中做个看客。 所以数据的应用分这四个步骤：数据、信息、知识、智慧。 最终的阶段是很多商家都想要的。你看我收集了这么多的数据，能不能基于这些数据来帮我做下一步的决策，改善我的产品。例如让用户看视频的时候旁边弹出广告，正好是他想买的东西;再如让用户听音乐时，另外推荐一些他非常想听的其他音乐。 用户在我的应用或者网站上随便点点鼠标，输入文字对我来说都是数据，我就是要将其中某些东西提取出来、指导实践、形成智慧，让用户陷入到我的应用里面不可自拔，上了我的网就不想离开，手不停地点、不停地买。 很多人说双十一我都想断网了，我老婆在上面不断地买买买，买了A又推荐B，老婆大人说，“哎呀，B也是我喜欢的啊，老公我要买”。你说这个程序怎么这么牛，这么有智慧，比我还了解我老婆，这件事情是怎么做到的呢? 2 数据如何升华为智慧 数据的处理分几个步骤，完成了才最后会有智慧。 第一个步骤叫数据的收集。首先得有数据，数据的收集有两个方式： 第一个方式是拿，专业点的说法叫抓取或者爬取。例如搜索引擎就是这么做的：它把网上的所有的信息都下载到它的数据中心，然后你一搜才能搜出来。比如你去搜索的时候，结果会是一个列表，这个列表为什么会在搜索引擎的公司里面?就是因为他把数据都拿下来了，但是你一点链接，点出来这个网站就不在搜索引擎它们公司了。比如说新浪有个新闻，你拿百度搜出来，你不点的时候，那一页在百度数据中心，一点出来的网页就是在新浪的数据中心了。 第二个方式是推送，有很多终端可以帮我收集数据。比如说小米手环，可以将你每天跑步的数据，心跳的数据，睡眠的数据都上传到数据中心里面。 第二个步骤是数据的传输。一般会通过队列方式进行，因为数据量实在是太大了，数据必须经过处理才会有用。可系统处理不过来，只好排好队，慢慢处理。 第三个步骤是数据的存储。现在数据就是金钱，掌握了数据就相当于掌握了钱。要不然网站怎么知道你想买什么?就是因为它有你历史的交易的数据，这个信息可不能给别人，十分宝贵，所以需要存储下来。 第四个步骤是数据的处理和分析。上面存储的数据是原始数据，原始数据多是杂乱无章的，有很多垃圾数据在里面，因而需要清洗和过滤，得到一些高质量的数据。对于高质量的数据，就可以进行分析，从而对数据进行分类，或者发现数据之间的相互关系，得到知识。 比如盛传的沃尔玛超市的啤酒和尿布的故事，就是通过对人们的购买数据进行分析，发现了男人一般买尿布的时候，会同时购买啤酒，这样就发现了啤酒和尿布之间的相互关系，获得知识，然后应用到实践中，将啤酒和尿布的柜台弄的很近，就获得了智慧。 第五个步骤是对于数据的检索和挖掘。检索就是搜索，所谓外事不决问Google，内事不决问百度。内外两大搜索引擎都是将分析后的数据放入搜索引擎，因此人们想寻找信息的时候，一搜就有了。 另外就是挖掘，仅仅搜索出来已经不能满足人们的要求了，还需要从信息中挖掘出相互的关系。比如财经搜索，当搜索某个公司股票的时候，该公司的高管是不是也应该被挖掘出来呢?如果仅仅搜索出这个公司的股票发现涨的特别好，于是你就去买了，其实其高管发了一个声明，对股票十分不利，第二天就跌了，这不坑害广大股民么?所以通过各种算法挖掘数据中的关系，形成知识库，十分重要。 3 大数据时代，众人拾柴火焰高 当数据量很小时，很少的几台机器就能解决。慢慢的，当数据量越来越大，最牛的服务器都解决不了问题时，怎么办呢?这时就要聚合多台机器的力量，大家齐心协力一起把这个事搞定，众人拾柴火焰高。 对于数据的收集：就IoT来讲，外面部署这成千上万的检测设备，将大量的温度、湿度、监控、电力等数据统统收集上来;就互联网网页的搜索引擎来讲，需要将整个互联网所有的网页都下载下来。这显然一台机器做不到，需要多台机器组成网络爬虫系统，每台机器下载一部分，同时工作，才能在有限的时间内，将海量的网页下载完毕。 对于数据的传输：一个内存里面的队列肯定会被大量的数据挤爆掉，于是就产生了基于硬盘的分布式队列，这样队列可以多台机器同时传输，随你数据量多大，只要我的队列足够多，管道足够粗，就能够撑得住。 对于数据的存储：一台机器的文件系统肯定是放不下的，所以需要一个很大的分布 式文件系统来做这件事情，把多台机器的硬盘打成一块大的文件系统。 对于数据的分析：可能需要对大量的数据做分解、统计、汇总，一台机器肯定搞不定，处理到猴年马月也分析不完。于是就有分布式计算的方法，将大量的数据分成小份，每台机器处理一小份，多台机器并行处理，很快就能算完。例如著名的Terasort对1个TB的数据排序，相当于1000G，如果单机处理，怎么也要几个小时，但并行处理209秒就完成了。 所以说什么叫做大数据?说白了就是一台机器干不完，大家一起干。可是随着数据量越来越大，很多不大的公司都需要处理相当多的数据，这些小公司没有这么多机器可怎么办呢? 4 大数据需要云计算，云计算需要大数据 说到这里，大家想起云计算了吧。当想要干这些活时，需要很多的机器一块做，真的是想什么时候要就什么时候要，想要多少就要多少。 例如大数据分析公司的财务情况，可能一周分析一次，如果要把这一百台机器或者一千台机器都在那放着，一周用一次非常浪费。那能不能需要计算的时候，把这一千台机器拿出来;不算的时候，让这一千台机器去干别的事情? 谁能做这个事儿呢?只有云计算，可以为大数据的运算提供资源层的灵活性。而云计算也会部署大数据放到它的PaaS平台上，作为一个非常非常重要的通用应用。因为大数据平台能够使得多台机器一起干一个事儿，这个东西不是一般人能开发出来的，也不是一般人玩得转的，怎么也得雇个几十上百号人才能把这个玩起来。 所以说就像数据库一样，其实还是需要有一帮专业的人来玩这个东西。现在公有云上基本上都会有大数据的解决方案了，一个小公司需要大数据平台的时候，不需要采购一千台机器，只要到公有云上一点，这一千台机器都出来了，并且上面已经部署好了的大数据平台，只要把数据放进去算就可以了。 云计算需要大数据，大数据需要云计算，二者就这样结合了。 人工智能拥抱大数据 机器什么时候才能懂人心 虽说有了大数据，人的欲望却不能够满足。虽说在大数据平台里面有搜索引擎这个东西，想要什么东西一搜就出来了。但也存在这样的情况：我想要的东西不会搜，表达不出来，搜索出来的又不是我想要的。 例如音乐软件推荐了一首歌，这首歌我没听过，当然不知道名字，也没法搜。但是软件推荐给我，我的确喜欢，这就是搜索做不到的事情。当人们使用这种应用时，会发现机器知道我想要什么，而不是说当我想要时，去机器里面搜索。这个机器真像我的朋友一样懂我，这就有点人工智能的意思了。 人们很早就在想这个事情了。最早的时候，人们想象，要是有一堵墙，墙后面是个机器，我给它说话，它就给我回应。如果我感觉不出它那边是人还是机器，那它就真的是一个人工智能的东西了。 让机器学会推理 怎么才能做到这一点呢?人们就想：我首先要告诉计算机人类的推理的能力。你看人重要的是什么?人和动物的区别在什么?就是能推理。要是把我这个推理的能力告诉机器，让机器根据你的提问，推理出相应的回答，这样多好? 其实目前人们慢慢地让机器能够做到一些推理了，例如证明数学公式。这是一个非常让人惊喜的一个过程，机器竟然能够证明数学公式。但慢慢又发现其实这个结果也没有那么令人惊喜。因为大家发现了一个问题：数学公式非常严谨，推理过程也非常严谨，而且数学公式很容易拿机器来进行表达，程序也相对容易表达。 教给机器知识 因此，仅仅告诉机器严格的推理是不够的，还要告诉机器一些知识。但告诉机器知识这个事情，一般人可能就做不来了。可能专家可以，比如语言领域的专家或者财经领域的专家。 语言领域和财经领域知识能不能表示成像数学公式一样稍微严格点呢?例如语言专家可能会总结出主谓宾定状补这些语法规则，主语后面一定是谓语，谓语后面一定是宾语，将这些总结出来，并严格表达出来不就行了吗?后来发现这个不行，太难总结了，语言表达千变万化。 人工智能这个阶段叫做专家系统。专家系统不易成功，一方面是知识比较难总结，另一方面总结出来的知识难以交给计算机。因为你自己还迷迷糊糊，觉得似乎有规律，就是说不出来，又怎么能够通过编程教给计算机呢? 算了，教不会你自己学吧 于是人们想到：机器是和人完全不一样的物种，干脆让机器自己学习好了。

成为一名合格的开发工程师不是一件简单的事情，需要掌握从开发到调试到优化等一系列能力，这些能力中的每一项掌握起来都需要足够的努力和经验。而要成为一名合格的机器学习算法工程师（以下简称算法工程师）更是难上加难，因为在掌握工程师的通用技能以外，还需要掌握一张不算小的机器学习算法知识网络。 下面我们就将成为一名合格的算法工程师所需的技能进行拆分，一起来看一下究竟需要掌握哪些技能才能算是一名合格的算法工程师。 1.基础开发能力 所谓算法工程师，首先需要是一名工程师，那么就要掌握所有开发工程师都需要掌握的一些能力。 有些同学对于这一点存在一些误解，认为所谓算法工程师就只需要思考和设计算法，不用在乎这些算法如何实现，而且会有人帮你来实现你想出来的算法方案。这种思想是错误的，在大多数企业的大多数职位中，算法工程师需要负责从算法设计到算法实现再到算法上线这一个全流程的工作。 笔者曾经见过一些企业实行过算法设计与算法实现相分离的组织架构，但是在这种架构下，说不清楚谁该为算法效果负责，算法设计者和算法开发者都有一肚子的苦水，具体原因不在本文的讨论范畴中，但希望大家记住的是，基础的开发技能是所有算法工程师都需要掌握的。 2.概率和统计基础 概率和统计可以说是机器学习领域的基石之一，从某个角度来看，机器学习可以看做是建立在概率思维之上的一种对不确定世界的系统性思考和认知方式。学会用概率的视角看待问题，用概率的语言描述问题，是深入理解和熟练运用机器学习技术的最重要基础之一。 概率论内容很多，但都是以具体的一个个分布为具体表现载体体现出来的，所以学好常用的概率分布及其各种性质对于学好概率非常重要。 对于离散数据，伯努利分布、二项分布、多项分布、Beta分布、狄里克莱分布以及泊松分布都是需要理解掌握的内容； 对于离线数据，高斯分布和指数分布族是比较重要的分布。这些分布贯穿着机器学习的各种模型之中，也存在于互联网和真实世界的各种数据之中，理解了数据的分布，才能知道该对它们做什么样的处理。 此外，假设检验的相关理论也需要掌握。在这个所谓的大数据时代，最能骗人的大概就是数据了，掌握了假设检验和置信区间等相关理论，才能具备分辨数据结论真伪的能力。例如两组数据是否真的存在差异，上线一个策略之后指标是否真的有提升等等。这种问题在实际工作中非常常见，不掌握相关能力的话相当于就是大数据时代的睁眼瞎。 在统计方面，一些常用的参数估计方法也需要掌握，典型的如最大似然估计、最大后验估计、EM算法等。这些理论和最优化理论一样，都是可以应用于所有模型的理论，是基础中的基础。 3.机器学习理论 虽然现在开箱即用的开源工具包越来越多，但并不意味着算法工程师就可以忽略机器学习基础理论的学习和掌握。这样做主要有两方面的意义： 掌握理论才能对各种工具、技巧灵活应用，而不是只会照搬套用。只有在这个基础上才能够真正具备搭建一套机器学习系统的能力，并对其进行持续优化。否则只能算是机器学习搬砖工人，算不得合格的工程师。出了问题也不会解决，更谈不上对系统做优化。 学习机器学习的基础理论的目的不仅仅是学会如何构建机器学习系统，更重要的是，这些基础理论里面体现的是一套思想和思维模式，其内涵包括概率性思维、矩阵化思维、最优化思维等多个子领域，这一套思维模式对于在当今这个大数据时代做数据的处理、分析和建模是非常有帮助的。如果你脑子里没有这套思维，面对大数据环境还在用老一套非概率的、标量式的思维去思考问题，那么思考的效率和深度都会非常受限。 机器学习的理论内涵和外延非常之广，绝非一篇文章可以穷尽，所以在这里我列举了一些比较核心，同时对于实际工作比较有帮助的内容进行介绍，大家可在掌握了这些基础内容之后，再不断探索学习。 4.开发语言和开发工具 掌握了足够的理论知识，还需要足够的工具来将这些理论落地，这部分我们介绍一些常用的语言和工具。 5.架构设计 最后我们花一些篇幅来谈一下机器学习系统的架构设计。 所谓机器学习系统的架构，指的是一套能够支持机器学习训练、预测、服务稳定高效运行的整体系统以及他们之间的关系。 在业务规模和复杂度发展到一定程度的时候，机器学习一定会走向系统化、平台化这个方向。这个时候就需要根据业务特点以及机器学习本身的特点来设计一套整体架构，这里面包括上游数据仓库和数据流的架构设计，以及模型训练的架构，还有线上服务的架构等等。这一套架构的学习就不像前面的内容那么简单了，没有太多现成教材可以学习，更多的是在大量实践的基础上进行抽象总结，对当前系统不断进行演化和改进。但这无疑是算法工程师职业道路上最值得为之奋斗的工作。在这里能给的建议就是多实践，多总结，多抽象，多迭代。 6.机器学习算法工程师领域现状 现在可以说是机器学习算法工程师最好的时代，各行各业对这类人才的需求都非常旺盛。典型的包括以下一些细分行业： 推荐系统。推荐系统解决的是海量数据场景下信息高效匹配分发的问题，在这个过程中，无论是候选集召回，还是结果排序，以及用户画像等等方面，机器学习都起着重要的作用。 广告系统。广告系统和推荐系统有很多类似的地方，但也有着很显著的差异，需要在考虑平台和用户之外同时考虑广告主的利益，两方变成了三方，使得一些问题变复杂了很多。它在对机器学习的利用方面也和推荐类似。 搜索系统。搜索系统的很多基础建设和上层排序方面都大量使用了机器学习技术，而且在很多网站和App中，搜索都是非常重要的流量入口，机器学习对搜索系统的优化会直接影响到整个网站的效率。 风控系统。风控，尤其是互联网金融风控是近年来兴起的机器学习的又一重要战场。不夸张地说，运用机器学习的能力可以很大程度上决定一家互联网金融企业的风控能力，而风控能力本身又是这些企业业务保障的核心竞争力，这其中的关系大家可以感受一下。 但是所谓“工资越高，责任越大”，企业对于算法工程师的要求也在逐渐提高。整体来说，一名高级别的算法工程师应该能够处理“数据获取数据分析模型训练调优模型上线”这一完整流程，并对流程中的各种环节做不断优化。一名工程师入门时可能会从上面流程中的某一个环节做起，不断扩大自己的能力范围。 除了上面列出的领域以外，还有很多传统行业也在不断挖掘机器学习解决传统问题的能力，行业的未来可谓潜力巨大。

在这个信息时代高速发展的情况下，很多人会对自己该往哪个方向发展感到迷茫，下面我就浅显的给大家介绍一下五大流行区域的发展前景。大数据的发展前景：当前大数据行业真的是人才稀缺吗?学了几年后，大数据行业会不会产能过剩?大数据行业最终需要什么样的人才?接下来就带你们看看分析结果：当前大数据行业真的是人才稀缺吗?对!未来人才缺口150万，数据分析人才最稀缺。先看大数据人才缺口有多大?根据LinkedIn(领英)发布的《2016年中国互联网最热职位人才报告》显示，研发工程师、产品经理、人力资源、市场营销、运营和数据分析是当下中国互联网行业需求最旺盛的六类人才职位。其中数据分析人才最为稀缺、供给指数最低。同时，数据分析人才跳槽速度也最快，平均跳槽速度为19.8个月。而清华大学计算机系教授武永卫去年透露了一组数据：未来3-5年，中国需要180万数据人才，但目前只有约30万人。大数据行业未来会产能过剩吗?提供大数据技术与应用服务的第三方公司面临调整，未来发展会趋集中关于“大数据概念是否被过度炒作”的讨论，其实2013年的夏季达沃斯就有过。彼时支持“炒作”观点的现场观众达54.5%。对此，持反对意见的北京大学光华管理学院副教授苏萌提出了三个理由：不同机构间的数据还未真正流动起来，目前还只是数据“孤岛”;完整的生态产业链还未形成，尽管通过行为数据分析已能够分辨出一个消费者的喜好，但从供应到购买的链条还没建成;数据分析人才仍然极度匮乏。4年之后，舆论热点已经逐渐从大数据转向人工智能，大数据行业也历经整合。近一年间，一些大数据公司相继出现裁员、业务大调整等情况，部分公司出现亏损。那都是什么公司面临危机呢?基于数据归属，涉及大数据业务的公司其实有两类：一类是自身拥有数据的甲方公司，如亚马逊、阿里巴巴等;另一类是整合数据资源，提供大数据技术与应用服务的第三方公司。目前行业整合出现盈利问题的公司多集中在第三方服务商。对此，LinkedIn(领英)中国技术副总裁王迪表示，第三方服务商提供的更多的是技术或平台，大数据更多还是让甲方公司获益。在王迪看来，大数据业务要产生规模效益，至少要具备三点：算法、计算平台以及数据本身。“第三方大数据创业公司在算法上有一技之长，而计算能力实际上已经匀化了，传统企业如果用好了，和大数据创业公司没有区别，甚至计算能力更强，而数据获取方面，很多数据在传统行业内部并没有共享出来，第三方大数据公司获取这些数据是比较困难的，最后可能谁有数据，谁产生的价值更高。”说白了，数据为王。在2013年，拿到千万级A轮融资的大数据企业不足10家，到2015年，拿到千万级以上A轮融资的企业已经超过30家。直到2016年互联网资本寒冬，大数据行业投资热度有所减退，大数据行业是否也存在产能过剩?王迪认为，目前的行业整合属于正常现象，“经过市场的优胜劣汰，第三方服务领域会出现一些做得比较好的公司，其他公司可能被淘汰或转型做一些垂直行业应用。从社会来看，总的需求量一定是增加的，而对于供给侧，经过行业自然的洗牌，最终会集中在几家优秀的行业公司。”需要什么样的大数据人才?今年3月份，教育部公布了第二批获准开设“数据科学与大数据技术”的高校名单，加上第一批获批的北京大学、对外经济贸易大学、中南大学，一共35所高校获批该专业。今年开始，部分院校将招收第一届大数据专业本科生。大数据人才培养涉及到两方面问题：交叉性学科的人才培养方案是否与市场需求相匹配;学科建设的周期与行业快速更新之间的差距怎样弥合。对于第一个问题，“电商热”时期开设的电子商务专业是一个可吸取经验的样本。2000年，教育部高教司批准了第一批高校开设电子商务本科专业。作为一个复合型专业，电子商务的本科教学涵盖了管理、技术、营销三方面的课程。电子商务领域人才需求量大，但企业却无法从电子商务专业中找到合适的人才，原因何在?职业规划专家姜萌认为，并不是某一个专业对应一个行业热点，而是一个专业集群对应一个行业热点。“比如电子商务专业，我们到电子商务公司里会发现，不是学电子商务的人在做这些工作，而是每个专业各司其职，比如计算机、设计、物流管理、营销、广告、金融等等。现在行业的复合型工作都是由一个专业集群来完成的，而不是一个人来复合一堆专业特点。”大数据专业的人才培养也同样走复合型路线，复旦大学大数据学院的招生简章显示，学院本科人才培养以统计学、计算机科学和数学为三大基础支撑性学科，以生物学、医学、环境科学、经济学、社会学、管理学等为应用拓展性学科，具备典型的交叉学科特征。LinkedIn(领英)中国技术副总裁王迪指出，“从企业应用的角度来看，大数据行业里从事相关职能的同学背景是各异的，大数据作为一个人才培养方向还在探索中，在这个阶段，高校尝试开设硕士课程是很好的实践，但开设一类的本科专业还为时过早。”另一方面，专业人才培养的周期较长，而行业热点不断更新轮替，中间产生的时间差使得新兴专业的志愿填报具备了一定风险。王迪认为，“从今天的产业实践上看，大数据领域依然是从现有专业中挑选人才，教育和市场发展总是有一定差距的，学生本科四年，加上硕士阶段已经是七年之后的事情了，产业已经演进了很多，而教学大纲并不会跟进得那么快。”因此，尽管大数据的应用前景毋庸置疑，但在人才培养层面，复合型人才培养方案会不会重走电子商务专业的老路?学校教育如何赶上行业发展速度?这些都是值得进一步商榷的问题。面对热门专业，志愿填报需要注意啥?了解了大数据行业、公司和大数据专业后，姜萌对于考生填报像大数据相关的热门专业，提出了几条建议：报考热的专业和就业热的专业并不一定是重合的，比如软件、计算机、金融，这些专业的就业率实际并没有那么高，地质勘探、石油、遥感等专业，虽然报考上是冷门，但行业需求大，就业率更高。选择热门专业，更需要考虑就业质量。专业就业好，是统计学意义，指的是平均收入水平高，比如金融专业的收入，比其他纯文科专业的平均收入较高，但落实到个体层面，就业情况就不一样了，尤其像金融专业是典型的名校高学历好就业，但对于考试成绩较低的同学来说，如果去一些普通院校、专科院校学习金融，最后就业情况可能还不如会计专业。志愿填报，除了专业，城市因素也很重要：如果想从事金融、互联网的工作，更适合去一线城市，如果是去三、四线城市的学生可以考虑应用面比较广的专业，就是各行各业都能用到的专业，比如会计专业，专科层次的会计和985层次的会计都有就业渠道。如果先选择报考城市，也可以针对所在城市的行业特点选择专业，比如沿海城市外贸相对发达，选择国际贸易、外语类专业就业情况更好，比如武汉有光谷，选择光电类专业更好就业。最终家长和考生更需要考虑个人与专业匹配的问题，金融、计算机等热门专业不是所有人都适合学，好专业不见得对所有个体都是好的。java的发展前景：由于Java的诸多优点，Java的发展前景十分广泛。比如，在我们中国的市场，Java无论在企业级应用，还是在面向大众的服务方面都取得了不少进展，在中国的电信、金融等关键性业务中发挥着举足轻重的作用。由于SUN、TBM、Oracle等国际厂商相继推出各种基于Java技术的应用服务器以及各种应用软件，推动了Java在金融、电信、制造等领域日益广泛的应用，如清华大学计算机系利用Java、XML和Web技术研制开发了多个软件平台，东方科技的TongWeb、中创的Inforweb等J2EE应用服务器。由此可见，在巨大市场需求下，企业对于Java人才的渴求已经是不争的事实。你问我火了这么多年的Java语言的发展前景怎么样？那来看看吧Java在WEB、移动设备以及云计算方面前景广阔，随着云计算以及移动领域的扩张，更多的企业在考虑将其应用部署在Java平台上。无论是本地主机，公共云，Java都是目前最适合的选择。;另外在Oracle的技术投资担保下，Java也是企业在云应用方面回避微软平台、在移动应用方面回避苹果公司的一个最佳选择。Java可以参与制作大部分网络应用程序系统，而且与如今流行的WWW浏览器结合很好，这一优点将促进Java的更大范围的推广。因为在未来的社会，信息将会传送的更加快速，这将推动程序向WEB程序方向发展，由于Java具有编写WEB程序的能力，并且Java与浏览器结合良好，这将使得Java前景充满光明的发展。Python的发展前景：Python程序员的发展前景是怎样的？随着Python的技术的流行， Python在为人们带来工作与生活上的便捷后，关注者们开始慢慢关心Python的发展前景与方向。从自身特性看Python发展Python自身强大的优势决定其不可限量的发展前景。Python作为一种通用语言，几乎可以用在任何领域和场合，角色几乎是无限的。Python具有简单、易学、免费、开源、可移植、可扩展、可嵌入、面向对象等优点，它的面向对象甚至比java和C#、.net更彻底。它是一种很灵活的语言，能帮你轻松完成编程工作。强大的类库支持，使编写文件处理、正则表达式，网络连接等程序变得相当容易。能运行在多种计算机平台和操作系统中，如各位unix，windows，MacOS,OS/2等等，并可作为一种原型开发语言，加快大型程序的开发速度。从企业应用来看Python发展Python被广泛的用在Web开发、运维自动化、测试自动化、数据挖掘等多个行业和领域。一项专业调查显示，75%的受访者将Python视为他们的主要开发语言，反之，其他25%受访者则将其视为辅助开发语言。将Python作为主要开发语言的开发者数量逐年递增，这表明Python正在成为越来越多开发者的开发语言选择。目前，国内不少大企业都已经使用Python如豆瓣、搜狐、金山、腾讯、盛大、网易、百度、阿里、淘宝、热酷、土豆、新浪、果壳等;国外的谷歌、NASA、YouTube、Facebook、工业光魔、红帽等都在应用Python完成各种各样的任务。从市场需求与薪资看Python发展Python得到越来越多公司的青睐，使得Python人才需求逐年增加，从市场整体需求来看，Python在招聘市场上的流行程度也是在逐步上升的，工资水平也是水涨船高。据统计Python平均薪资水平在12K，随着经验的提升，薪资也是逐年增长。学习Python的程序员，除去Python开发工程师、Python高级工程师、Python自动化测试外，也能够朝着Python游戏开发工程师、SEO工程师、Linux运维工程师等方向发展，发展方向较为多元化。随着Python的流行，带动的是它的普及以及市场需求量，所以现在学习Python是个不错的时机。区块链的发展前景：区块链开发 ? 155---0116---2665 ?可是区块链技术到底是什么，大多数人都是模糊没有概念。通俗来讲，如果我们把数据库假设成一本账本，读写数据库就可以看做一种记账的行为，区块链技术的原理就是在一段时间内找出记账最快最好的人，由这个人来记账，然后将账本的这一页信息发给整个系统里的其他所有人。区块链技术也称分布式账本（或账簿）技术，属于互联网数据库技术，由参与者共同完成数据库记录，特点是去中心化和公开透明。此外，在每个区块的信息写入并获得认可后，整个区块链数据库完整保存在互联网的节点中，难以被修改，因此数据库的安全性极高。人们普遍认为，区块链技术是实现数字产品（如货币和知识产权）快速、安全和透明地对等（P2P）转账或转让的重要手段。在以色列Zen Protocol公司，区块链应用软件开发专家阿希尔·曼宁介绍说，他们公司正在开发Zen区块链平台，其将用于支持金融产品在无中介的环境下自动和自由交易。通常，人们将钱存放在银行，依靠银行管理自己的资金。但是，在支配资金时往往会受到银行规定的限制，或在汇款时存在耗时长、费用高等问题。区块链技术平台将让人们首次拥有自己管理和支配钱财的能力，他相信去中心化金融管理体系具有广阔的市场，有望极大地改变传统的金融市场。2018年伊始这一轮区块链的热潮，主要起源于虚拟货币的炒作热情。站在风口，区块链技术被认为是继蒸汽机、电力、互联网之后，下一代颠覆性的核心技术。很多人不禁要问“区块链又和比特币又是什么关系？”记者查询了大量资料发现，比特币2009年被一位名叫中本聪的人提出，之后比特币这套去中心化的机制一直稳定运行，这引起很多人对这套历史上并不存在的运行机制强烈关注。于是人们把从比特币技术抽象提取出来的技术运用于其他领域，称之为区块链。这过程就好像人们先发明了面条，然后人们发现其背后面粉不仅可以做面条还可以做馒头、面包。比特币是面条，区块链是面粉。也就是说，区块链和比特币的关系即比特币算是区块链技术的一种应用，或者说一种使用了区块链技术的产品形态。而说到区块链不得不说的就是ICO，它是一种公开发行的初始数字货币。对于投资人来说，出于对市场信号的敏感和长期关注价值投资项目，目前炙手可热的区块链也成为诸多投资人关注的新兴项目之一。“区块链对于我们来说就是省去了中间环节，节约了交易成本，节省了交易时间，但是目前来看各方面环境还不够成熟，有待观望。”一位投资人这样说道。记者发现，在春节期间，不少互金圈的朋友熬夜到凌晨进入某个探讨区块链的微信群热聊，此群还吸引了不少知名人士，诸如明星加入，同时还有大咖在群里解读区块链的投资方式和未来发展等等。一时间，关于区块链的讨论群接二连三出现，也引发了各个行业对区块链的关注。出于对于区块链技术懵懂的状态，记者追问了身边的一些互金圈的朋友，为何如此痴迷区块链？多数朋友认为“区块链能赚钱，抱着试试看的心态，或许能像之前比特币一样从中获取收益。”显然，区块链技术具有广阔的应用潜力，但是在其逐步进入社会改善民众生活的过程中，也面临许多的问题，需要积极去寻求相应的对策，最终让其发挥出潜力。只有这样，10年或20年后人们才能真正享受区块链技术创造的美好环境。人工智能的发展前景：人工智能产业是智能产业发展的核心，是其他智能科技产品发展的基础，国内外的高科技公司以及风险投资机构纷纷布局人工智能产业链。科技部部长万钢3月10日表示，加快实施新一代人工智能科学基础的关键技术系统集成研发，使那些研发成果尽快能够进入到开放平台，在开放使用中再一次把它增强完善。万钢称，马上就要发布人工智能项目指南和细则，来突破基础前沿理论关键部分的技术。人工智能发展趋势据前瞻产业研究院《人工智能行业市场前瞻与投资战略规划分析报告》指出，2017年中国人工智能核心产业规模超过700亿元，随着国家规划的出台，各地人工智能相关建设将逐步启动，预计到2020年，中国人工智能核心产业规模将超过1600亿元，增长率达到26.2%。报告认为，从产业投资回报率分析，智能安防、智能驾驶等领域的快速发展都将刺激计算机视觉分析类产品的需求，使得计算机视觉领域具备投资价值；而随着中国软件集成水平和人们生活水平的提高，提供教育、医疗、娱乐等专业化服务的服务机器人和智能无人设备具备投资价值。人工智能现状当前，人工智能受到的关注度持续提升，大量的社会资本和智力、数据资源的汇集驱动人工智能技术研究不断向前推进。从发展层次来看，人工智能技术可分为计算智能、感知智能和认知智能。当前，计算智能和感知智能的关键技术已经取得较大突破，弱人工智能应用条件基本成熟。但是，认知智能的算法尚未突破，前景仍不明朗。今年，随着智力资源的不断汇集，人工智能核心技术的研究重点可能将从深度学习转为认知计算，即推动弱人工智能向强人工智能不断迈进。一方面，在人工智能核心技术方面，在百度等大型科技公司和北京大学、清华大学等重点院校的共同推动下，以实现强人工智能为目标的类脑智能有望率先突破。另一方面，在人工智能支撑技术方面，量子计算、类脑芯片等核心技术正处在从科学实验向产业化应用的转变期，以数据资源汇集为主要方向的物联网技术将更加成熟，这些技术的突破都将有力推动人工智能核心技术的不断演进。工业大数据2022 年我国工业大数据有望突破 1200 亿元， 复合增速 42%。 工业大数据是提升制造智能化水平，推动中国制造业转型升级的关键动力，具体包括企业信息化数据、工业物联网数据，以及外部跨界数据。其中，企业信息化和工业物联网中机器产生的海量时序数据是工业数据的主要来源。工业大数据不仅可以优化现有业务，实现提质增效，而且还有望推动企业业务定位和盈利模式发生重大改变，向个性化定制、智能化生产、网络化协同、服务化延伸等智能化场景转型。预计到 2022 年，中国工业大数据市场规模有望突破 1200亿元，年复合增速 42%。IT的未来是人工智能这是一个指数级增长的时代。过去几十年，信息技术的进步相当程度上归功于芯片上晶体管数目的指数级增加，及由此带来的计算力的极大提升。这就是所谓的摩尔定律。在互联网时代，互联的终端数也是超线性的增长，而网络的效力大致与联网终端数的平方成正比。今天，大数据时代产生的数据正在呈指数级增加。在指数级增长的时代，我们可能会高估技术的短期效应，而低估技术的长期效应。历史的经验告诉我们，技术的影响力可能会远远的超过我们的想象。未来的计算能力人工智能需要强大的计算能力。计算机的性能过去30年提高了一百万倍。随着摩尔定律逐渐趋于物理极限，未来几年，我们期待一些新的技术突破。先谈一下类脑计算。传统计算机系统，长于逻辑运算，不擅长模式识别与形象思维。构建模仿人脑的类脑计算机芯片，我们今天可以以极低的功耗，模拟100万个神经元，2亿5千万个神经突触。未来几年，我们会看到类脑计算机的进一步的发展与应用随着互联网的普及、传感器的泛在、大数据的涌现、电子商务的发展、信息社区的兴起，数据和知识在人类社会、物理空间和信息空间之间交叉融合、相互作用，人工智能发展所处信息环境和数据基础发展了巨大的变化。伴随着科学基础和实现载体取得新的突破，类脑计算、深度学习、强化学习等一系列的技术萌芽预示着内在动力的成长，人工智能的发展已进入一个新的阶段。发展发展前景好，代表你现在学习会比后来者起步快，占有更大的优势，当然，你也要明白兴趣是最好的老师，选择自己感兴趣的相信你学的会更加而牢固。记住，最重要的一点：方向最重要！！！希望大家多多关注. ，加微信zhanglindashuju 可以获取更多资料哦作者：失色的瞳孔链接：https://juejin.im/post/5b1a6531e51d45067e6fc24a来源：掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

服务器和操作系统 1、主板的两个芯片分别是什么芯片，具备什么作用？ 北桥：离CPU近，负责CPU、内存、显卡之间的通信。 南桥：离CPU远，负责I/O总线之间的通信。 2、什么是域和域控制器？ 将网络中的计算机逻辑上组织到一起，进行集中管理，这种集中管理的环境称为域。 在域中，至少有一台域控制器，域控制器中保存着整个域的用户账号和安全数据，安装了活动目录的一台计算机为域控制器，域管理员可以控制每个域用户的行为。 3、现在有300台虚拟机在云上，你如何进行管理？ 1）设定堡垒机，使用统一账号登录，便于安全与登录的考量。 2）使用ansiable、puppet进行系统的统一调度与配置的统一管理。 3）建立简单的服务器的系统、配置、应用的cmdb信息管理。便于查阅每台服务器上的各种信息记录。 4、简述raid0 raid1 raid5 三种工作模式的工作原理及特点 磁盘冗余阵列（Redundant Arrays of Independent Disks，RAID），把硬盘整合成一个大磁盘，在大磁盘上再分区，存放数据、多块盘放在一起可以有冗余（备份）。 RAID整合方式有很多，常用的：0 1 5 10 RAID 0：可以是一块盘和N个盘组合 优点：读写快，是RAID中最好的 缺点：没有冗余，一块坏了数据就全没有了 RAID 1：只能2块盘，盘的大小可以不一样，以小的为准 10G+10G只有10G，另一个做备份。它有100%的冗余，缺点：浪费资源，成本高 RAID 5 ：3块盘，容量计算10*（n-1）,损失一块盘 特点：读写性能一般，读还好一点，写不好 总结： 冗余从好到坏：RAID1 RAID10 RAID 5 RAID0 性能从好到坏：RAID0 RAID10 RAID5 RAID1 成本从低到高：RAID0 RAID5 RAID1 RAID10 5、linux系统里，buffer和cache如何区分？ buffer和cache都是内存中的一块区域，当CPU需要写数据到磁盘时，由于磁盘速度比较慢，所以CPU先把数据存进buffer，然后CPU去执行其他任务，buffer中的数据会定期写入磁盘；当CPU需要从磁盘读入数据时，由于磁盘速度比较慢，可以把即将用到的数据提前存入cache，CPU直接从Cache中拿数据要快的多。 6、主机监控如何实现？ 数据中心可以用zabbix（也可以是nagios或其他）监控方案，zabbix图形界面丰富，也自带很多监控模板，特别是多个分区、多个网卡等自动发现并进行监控做得非常不错，不过需要在每台客户机（被监控端）安装zabbix agent。 如果在公有云上，可以使用云监控来监控主机的运行。 网络 7、主机与主机之间通讯的三要素有什么？ IP地址、子网掩码、IP路由 8、TCP和UDP都可以实现客户端/服务端通信，这两个协议有何区别？ TCP协议面向连接、可靠性高、适合传输大量数据；但是需要三次握手、数据补发等过程，耗时长、通信延迟大。 UDP协议面向非连接、可靠性低、适合传输少量数据；但是连接速度快、耗时短、延迟小。 9、简述TCP协议三次握手和四次分手以及数据传输过程 三次握手： （1）当主机A想同主机B建立连接，主机A会发送SYN给主机B，初始化序列号seq=x。主机A通过向主机B发送SYS报文段，实现从主机A到主机B的序列号同步，即确定seq中的x。 （2）主机B接收到报文后，同意与A建立连接，会发送SYN、ACK给主机A。初始化序列号seq=y，确认序号ack=x+1。主机B向主机A发送SYN报文的目的是实现从主机B到主机A的序列号同步，即确定seq中的y。 （3）主机A接收到主机B发送过来的报文后，会发送ACK给主机B，确认序号ack=y+1，建立连接完成，传输数据。 四次分手： （1）当主机A的应用程序通知TCP数据已经发送完毕时，TCP向主机B发送一个带有FIN附加标记的报文段，初始化序号seq=x。 （2）主机B收到这个FIN报文段，并不立即用FIN报文段回复主机A，而是想主机A发送一个确认序号ack=x+1，同时通知自己的应用程序，对方要求关闭连接（先发ack是防止主机A重复发送FIN报文）。 （3）主机B发送完ack确认报文后，主机B 的应用程序通知TCP我要关闭连接，TCP接到通知后会向主机A发送一个带有FIN附加标记的报文段，初始化序号seq=x，ack=x+1。 （4）主机A收到这个FIN报文段，向主机B发送一个ack确认报文，ack=y+1，表示连接彻底释放。 10、SNAT和DNAT的区别 SNAT:内部地址要访问公网上的服务时（如web访问），内部地址会主动发起连接，由路由器或者防火墙上的网关对内部地址做个地址转换，将内部地址的私有IP转换为公网的公有IP，网关的这个地址转换称为SNAT，主要用于内部共享IP访问外部。 DNAT:当内部需要提供对外服务时（如对外发布web网站），外部地址发起主动连接，由路由器或者防火墙上的网关接收这个连接，然后将连接转换到内部，此过程是由带有公网IP的网关替代内部服务来接收外部的连接，然后在内部做地址转换，此转换称为DNAT，主要用于内部服务对外发布。 数据库 11、叙述数据的强一致性和最终一致性 强一致性：在任何时刻所有的用户或者进程查询到的都是最近一次成功更新的数据。强一致性是程度最高一致性要求，也是最难实现的。关系型数据库更新操作就是这个案例。 最终一致性：和强一致性相对，在某一时刻用户或者进程查询到的数据可能都不同，但是最终成功更新的数据都会被所有用户或者进程查询到。当前主流的nosql数据库都是采用这种一致性策略。 12、MySQL的主从复制过程是同步的还是异步的？ 主从复制的过程是异步的复制过程，主库完成写操作并计入binlog日志中，从库再通过请求主库的binlog日志写入relay中继日志中，最后再执行中继日志的sql语句。 **13、MySQL主从复制的优点 ** 如果主服务器出现问题，可以快速切换到从服务器提供的服务； 可以在从服务器上执行查询操作，降低主服务器的访问压力； 可以在从服务器上执行备份，以避免备份期间影响主服务器的服务。 14、redis有哪些数据类型？ (一)String 最常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。 (二)hash 这里value存放的是结构化的对象，比较方便的就是操作其中的某个字段。做单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。 (三)list 使用List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。 (四)set 因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系统一般都是集群部署，使用JVM自带的Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。 另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。 (五)Zset Zset多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。另外，sorted set可以用来做延时任务。最后一个应用就是可以做范围查找。 15、叙述分布式数据库及其使用场景？ 分布式数据库应该是数据访问对应用透明，每个分片默认采用主备架构，提供灾备、恢复、监控、不停机扩容等整套解决方案，适用于TB或PB级的海量数据场景。 应用 16、Apache、Nginx、Lighttpd都有哪些特点？ Apache特点：1）几乎可以运行在所有的计算机平台上；2）支持最新的http/1.1协议；3）简单而且强有力的基于文件的配置（httpd.conf)；4）支持通用网关接口（cgi）；5）支持虚拟主机；6）支持http认证，7）集成perl；8）集成的代理服务器；9）可以通过web浏览器监视服务器的状态，可以自定义日志；10）支持服务器端包含命令（ssi）；11）支持安全socket层（ssl）；12）具有用户绘画过程的跟踪能力；13）支持fastcgi；14）支持java servlets Nginx特点：nginx是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP代理服务器，处理静态文件，索引文件以及自动索引，无缓存的反向代理加速，简单的负载均衡和容错，具有很高的稳定性，支持热部署。 Lighttpd特点：是一个具有非常低的内存开销，CPU占用率低，效能好，以及丰富的模块，Lighttpd是众多opensource轻量级的webserver中较为优秀的一个，支持fastcgi，cgi，auth，输出压缩，url重写，alias等重要功能。 17、LVS、NGINX、HAPROXY的优缺点？ LVS优点：具有很好的可伸缩性、可靠性、可管理性。抗负载能力强、对内存和CPU资源消耗比较低。工作在四层上，仅作分发，所以它几乎可以对所有的应用做负载均衡，且没有流量的产生，不会受到大流量的影响。 LVS缺点：软件不支持正则表达式处理，不能做动静分离，如果web应用比较庞大，LVS/DR+KEEPALIVED实施和管理比较复杂。相对而言，nginx和haproxy就简单得多。 nginx优点：工作在七层之上，可以针对http应用做一些分流的策略。比如针对域名、目录结构。它的正则规则比haproxy更为强大和灵活。对网络稳定性依赖非常小。理论上能PING就能进行负载均衡。配置和测试简单，可以承担高负载压力且稳定。nginx可以通过端口检测到服务器内部的故障。比如根据服务器处理网页返回的状态码、超时等。并且可以将返回错误的请求重新发送给另一个节点，同时nginx不仅仅是负载均衡器/反向代理软件。同时也是功能强大的web服务器，可以作为中层反向代理、静态网页和图片服务器使用。 nginx缺点：不支持URL检测，仅支持HTTP和EMAIL，对session的保持，cookie的引导能力相对欠缺。 Haproxy优点：支持虚拟主机、session的保持、cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。支持TCP协议的负载均衡；单纯从效率上讲比nginx更出色，且负载策略非常多。 aproxy缺点：扩展性能差；添加新功能很费劲，对不断扩展的新业务很难对付。 18、什么是中间件？什么是jdk？ 中间件介绍： 中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源 中间件位于客户机/ 服务器的操作系统之上，管理计算机资源和网络通讯 是连接两个独立应用程序或独立系统的软件。相连接的系统，即使它们具有不同的接口 但通过中间件相互之间仍能交换信息。执行中间件的一个关键途径是信息传递 通过中间件，应用程序可以工作于多平台或OS环境。 jdk：jdk是Java的开发工具包 它是一种用于构建在 Java 平台上发布的应用程序、applet 和组件的开发环境 19、日志收集、日志检索、日志展示的常用工具有哪些？ ELK或EFK。 Logstash：数据收集处理引擎。支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储以供后续使用。 Kibana：可视化化平台。它能够搜索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。 Elasticsearch：分布式搜索引擎。具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析，并能将这三者结合起来。Elasticsearch 基于 Lucene 开发，现在使用最广的开源搜索引擎之一，Wikipedia 、StackOverflow、Github 等都基于它来构建自己的搜索引擎。 Filebeat：轻量级数据收集引擎。基于原先 Logstash-fowarder 的源码改造出来。换句话说：Filebeat就是新版的 Logstash-fowarder，逐渐取代其位置。 20、什么是蓝绿发布和灰度发布？ 蓝绿：旧版本-新版本 灰度：新旧版本各占一定比例，比例可自定义 两种发布都通过devops流水线实现

Re【马甲问题】马甲账号清除公告 以前某社交公司查mj，就是用登陆浏览器比对。比对下登陆提交的浏览器地址，就全查出来了。 对于文本内容的比对感觉作用不大，我想过和别的组的尝试合并提交，只多出来200个提交。 ------------------------- Re【马甲问题】马甲账号清除公告 不过说句实在话，参加这么多竞赛过来，我还是第一次看到竞赛主办方用查mj的方式来抑制选手调参数过拟合训练数据集的。在最后一周更改测试集才是通用的做法吧。 我个人来说，同一策略线下验证集调好参数后，线上不会改参数超过两次，也是担心太过拟合，第二赛季就傻了。 ------------------------- Re【马甲问题】马甲账号清除公告 恩，看到规则了，话说第一季我觉得这样做可能比较好：训练集不变，然后测试集800个人随机抽样400个人作为平时的leadership排名，最后评测的时候用剩下400个人。这样刷小号也没意义了。 （突然想到回去后要跟我实验室的其他队伍说一声。。。以后LR调好W后别用我那个python脚本生成提交数据了。。。免得被当小号处理了omg ------------------------- 回22楼jiajiadidi的帖子 你不是改个参数几个队一起刷的话应该还好吧 我当初就觉得这样不好，后面多半要出乱子。浙大宣讲问主办方，现在这种情况，几条简单规则就能刷到6，我要是把这几条简单的规则告诉别人，那别人不都挤到前面，那赛季1不就没意义了？然后还有mj的问题。 宣讲的老师说，那你觉得现在极限是多少呢？是7么。mj这种问题都是小问题 后来算者说得好，规则确实能做得比较好，怎么结合规则做出更好的模型才是王道，模型不如规则只能说模型做的不够好。这个对我影响还蛮大的，也让我好好反思了一下。 我现在靠LR做到6.8，基本也没做规则了，而是想如何用以前淘宝有个做CTR预估的MLR的思路结合商品类目和用户定向做更好的结合规则的LR。 我把我python工程环境也发给同实验室的其他组了，在我基础上也有比我做的更高的，具体来说也没太问。 今天回贴，也是看到这种情况有所感想。 大家去刷规则，把推荐大赛做成overfitting大赛，这样对于自己的提高，或是解决这个实际问题，这样有意义么？我是觉得没有意义的。 跟我用同一体系方法的几个队，现在基本都做到6.9 6.8了，大家还是把精力更多放在了如何做更好的模型上。 想想最初学的PAC，一个模型如何叫好，train error低，并且train error近似于test error。这样我们才能声称自己的模型学习到了真正的target function f。而目前大家凭着test 来不断调整参数，就算把f1做到天上去，自己的模型只能说train error低了，大赛后也是毫无意义的。算法学到的那个function，也最多只能当作笑谈 看到有置顶，真是受宠若惊了。帖子里面说的MLR，是盖坤/靖世在阿里技术沙龙中分享的《海量数据下的非线性模型探索 》http://club.alibabatech.org/resource_detail.htm?topicId=106 。这个ppt非常好，我也学到不少。 顺便说说的是，在这个比赛中，我也确实学到不少。 以前我在做项目的时候，基本是对算法非常迷信的，关系好的豆瓣算法组的一个人批我机器学习理解不成熟，太喜欢炫技，我也左耳朵进右耳朵出。最近做某公司的推荐项目，我基本想都不想，就要上time SVD++做baseline，对数据也基本不做太多分析，对业务也是不屑一顾的，非常依赖feature selection算法以及高维非线性模型。 在以前kdd cup或者recsys等比赛中，也是直接上定制化的SVD，把所有数据建模在一个式子里跑SGD草草完事。 做阿里比赛最开始我也是没做太多数据分析，直接上的implicit feedback，sigmoid处理正负反馈，time SVD++以及各种复杂的处理方式。与其说是解决问题，不如是说炫技。当然结果也非常惨，只有4%。 后来才开始认真思考这个比赛的问题。品牌推荐和普通推荐到底有什么区别？打个比方，用户在一个月后会看自己以前有交互的电影的只有1%。而用户在一个月后会买自己以前有交互的品牌的却有20%。CF着力的是那没有交互行为的80%的品牌。除此外800用户，对用户的factor的估计，还是加入temporal dynamic稀释的，又能有多准呢？ 所以除了算者说的那些点外，光就这一点基本就可以判定CF在赛季1的不适合了。 这样的问题，只要好好想想就能想通的，可笑的是我第一二周还在所谓的“巧妙模型”上花费了大量的力气。这个让我反思了很久。 用我室友说我的，便是我太迷信算法了，瞧不起用excel写统计的，也瞧不起做简单数据分析然后跑简单模型的人。 这便是我在比赛中获得的教训，也是我和我同实验室的朋友在回家路上所总结的。 说实在，这个比赛我也没有太多精力参加，赛季二估计也只能每周花1天来做，毕竟实验室项目太多。所以估计最后也拿不到特别好的名次。但我觉得，这次比赛前几周给我带来的教训，便已经让我非常有收获了，至少我现在对于机器学习算法以及业务关系的理解，和比赛前已经有了很大的不同。 我现在是单挑，考虑到赛季2最近也找了一个队友，他貌似有两个小号。我也给他发短信让他回学校后赶快发邮件把这些号注销了并入我的队，毕竟也算占着前500的坑，注销了也让更多的队能进入前500。也希望其他队的朋友也再接再厉，在比赛中真正得到一些领悟和经验。愿大家都能做出更好的推荐，进一步加深对机器学习的理解 ^_^ 顺便给大家讲个竞赛的小段子开心开心=w= “阿里的比赛，有个学弟找我合了下数据，做到38名。他觉得很开心，就跟他导师说了。他导师说，才38名啊，做不到前3名就别参加竞赛丢他脸。听到这事我当时就呵呵了，you can you up，no can no bb。我导师就好多了，他要是知道我在做竞赛而不干活，不管几名肯定把我剁了。”