完整的大数据云计算.技术图谱

https://zhimap.com/mmap/30f4a40a01be44b6b07fbc11dc585264

Advertisements

MVP与精益创业

2014年,财富杂志发表了一篇文章,他们对101家失败的创业公司进行了“验尸”,其中42%的创业公司的失败是因为他们的产品缺乏与之相对应的市场 (product market fit)。创业公司烧了几个月的钱做了一款市场上并不需要的产品。那么是不是说明了大部分的创业者都是空想家?如何正确的聚焦在帮用户更容易的凿“洞”,而不是错误的聚焦在工具上? 那么应该如何使用最少的成本跟相对短的时间来验证产品的有效性? 我第一次接触MVP这个概念是因为工作关系,后来是通过Eric Ries的《精益创业》这本书。MVP=Minimum Viable Product,意思是最轻量级的可行性产品。实质上是指利用最少的资源来得到最大的回报,这里的回报指的是经验证的认知 (learning)。  MVP往往用来测试idea的product market fit,你的解决方案是不是有人愿意买单。我们的假设是,如果证实了MVP解决了用户与商业问题,那么团队将开始在此基础上build成熟的产品。但是,首先你的产品要通过“安全检验“。 MVP并不意味着先设计车轮,而是利用最少的资源来设计代步工具,是否根本的解决了用户的交通问题。下图解释的再清楚不过了,随处可见的一张图。 不同的观点来了。其实,MVP不一定需要是一个产品,只要是可以被用户想象的,就可以拿来去验证假设。并且,测试产品是否具有product market fit只是其中的一个目的,所有的一起都是为了获得经验证的认知。 硅谷有一个杯子蛋糕“cupcake theory”的理论,说的是当我们想要卖一种蛋糕时,要先使用较少的原料跟时间来做出同种口味跟外型的cupcake,为了就是收集用户对它的口味跟外型喜好相关的数据。 开发MVP产品之前,最重要的任务就是团队要想清楚需要验证的假设 (Hypothesis)是什么?如何定义是成功的实验 (Success Metrics)?数据上面如何表现才能算是成功?这个是我所认为的产品开发之前的最最重要的部分,没有之一,因为这一方法会让你理清思路,否则产品开发无异于在搭建空中楼阁。 一个没有被仔细思考定义过的假设还不如没有假设。 Hypothesis格式我就不在这里张贴了,网上可以找得到。 好了,举几个利用MVP来验证假设的例子。 人工最小化可行产品(Wizard of OzMVP) Wizard of Oz?绿野仙踪?这种测试指的是由一名产品团队人员代替系统,向用户做出反馈。 Zappo的创始人Nick为了证实人们有网上购买鞋子需求的想法,在一开始先到当地的专柜去拍鞋子的照片放到网上,如果有人下了单,他就跑去店里购买。这样,他一开始并没有仓储的压力,也不需要投入成本去搭建一个真正的电商平台。在这个过程中,Nick可以观察到真实的用户在购买当中出现的问题。在用户看来,只要产品能工作,他们并不在意其背后是否是通过纯人工的方式在运作。Zappos 最终成为了一家很成功的电商,2009年它被Amazon 以12亿美元的价格收购。 当年亚马逊搞出Echo也是使用了这个方法去了解用户会问什么样的问题和期望得到答案的速度。当用户问出任意一个问题,躲在另一个房间的程序员就会立即在Google上搜索出相应的答案,以不同的速度发送给用户。被测试的用户还以为是软件做出的反应。在研发团队了解了用户的相关行为以后,立刻决定投入到下一个阶段的产品开发中。 登录页(Landing Pages) Landing Page是用户看到的第一个页面。Buffer在最早期制作了一个登录页,但是与很多公司不同的是,创始人Joel并没有只关注于注册转化率这些数字,而是在用户提交了email以后,立即开始了与用户的进一步沟通,目的在于了解产品是否真正的解决了用户的问题,如何更好的改进产品。因此,他将登录页当作是一种从用户那里获得认知的手段,learning才是第一生产力。 还有很多其他的方法我就不一一的介绍了。 MVP是一个不断被重复的过程。 那么,即使知道MVP理论,为什么还会有那么多的初创公司失败?实际上,这些初创公司可能并没有了解MVP的精髓。MVP并不意味着是砍掉了一半功能的产品,就如我们前面提到的,它根本就不一定是一个可使用的产品。现实中的产品MVP已经会经历很多次的试错。“敏捷开发”与“精益创业”都离不开了快速试错与获得新的认知。 上图中出现了三个概念:value – 价值;benefit – 利益; feature – 功能。 最成功的MVP是问自己如何验证我的value proposition (价值定位),我的产品的价值定位是否符合了用户的价值定位?而不是简单的问自己我应该build什么功能,只是丢一堆工具给用户。 写在最后 毫无疑问,为了一个合理的最小化可行产品你要付出很多努力,最小化可行产品能提供的不仅仅是解决方案,更重要的是它能暴露出的问题。你来决定什么是最小的,用户来决定什么是可行的! [...]

交互文件命名规则

文件夹的整理方法 一般用一个大的文件夹作为一个项目最原始的管理,还是拿千寻租房的项目来打比方。首先大的文件夹取名为该项目的名字“千寻租房”。首先阁主先针对有多个版本需要管理,并且UI和UX都需要进行接触的工作内容进行说明。文件整理方式如下图。 一般一个项目会涉及到以下几个内容的整理: 01 Wireframe即low-fi(低保真效果图)文件的地址; 02 Visual Flow是Hi-fi(高保真效果图)地址; 03 UI Kits是图片资源输出的地址(比如说icon); 04 Documents并不是产品文档,而是APP里面需要的一些文档,比方说《服务条款》等; 05 App icon即APP的icon在各个平台上需要的尺寸图和它的源文件,尺寸常备1024x1024px,512x512px,167x167px,152x152px,120x120px,80x80px,58x58px(可以参考相关iOS规范); 06 Video Templates是有视频文件的情况下放置视频; 07 AppStoreScreenShot专门为screenshot(即用来简介APP功能的页面,需要上传到各个APP的发布平台)进行准备的,因为安卓平台实在太多了,有时候每个平台规定的尺寸还不太一样,所以专门为它怎被一个文件夹; 08 Lauch Card因为在UI层面上需要耗费的时间比较多,一般在改版的时候放在比较靠后的需求,所以也可以单列出来。 而作为设计师,接触最多的就是01,02,03,所以讲他们三个放在最前面,这也是给文件夹进行编序的原因,所以看到从01到08,序列号是按照它们使用的频率和重要程度来进行排序的。 为什么不将03进行版本的区分?因为同一个APP,从1.0改版的2.0的时候,icon可能延续了部分1.0版本的内容,所以部分是公用的,如果再在上面进行分类,反而程序员进行查找的时候要去翻多个子文件夹,反而不太方便。设计师只要告诉程序员所用图片的名字,程序员可以直接根据单个的icon路径,直接在里面进行提取。当然这也只是其中的一种解决方案。 每个版本又可以进行功能块进行子文件夹的分类,比方说上图中的这一部分。 Archive是用来放历史文件的,对于设计师来说历史文件是不能丢的,说不准哪一天老板就说“还是改回第一版吧~”你懂得~ 以上是针对工作内容综合性比较强的同学进行设计的文件整理方式。倘若有的同学工作内容比较集中,比方做单做UI或者单做UX的,那么文件的整理方式也可以进行如下进行整理。因为内容比较单一,所以只需要进行版本号进行区分也行。 文件夹的命名方式是“项目名+版本号”。比方说1.0版本的千寻租房项目,那么命名就是“千寻租房1.0”,如果有平级的2.0版本,就在它平行的下面再建一个文件夹叫“千寻租房2.0”。那么无论找什么版本的文件都一目了然。 Sketch文件的命名以及它的图层的整理 1. Sketch的命名规则 Sketch的命名如上图可以看出,“项目名字功能块版本号_修改日期”,比方说在5月5日做的千寻租房1.0版本的首页,那么它的命名就是“千寻租房_index_1.0_0505”。加上日期是为了方便别人和自己查看哪个是最新的版本,有时候在查找历史文件时也能起到帮忙回忆的作用。

作为UX设计师,你需要知道的52个专业术语

“注意用户做什么,而不是他们说什么。” ——雅各布 尼尔森 《作为UX设计师你需要知道的52个专业术语》是给设计者的一个有意义的补充,我将用通俗的语言把这些专业术语按字母顺序列出,并加以解释。 52个专业术语 3次点击法则 如果用户点击三次仍无法访问他们想要的页面,他们将离开网站。 5秒测试 一个5秒测试包括向用户展示应用程序或网站界面5秒钟,然后用户回想他们刚才看到的内容。这是一个评价关键视觉效果,以及判断用户的关注点是否符合预期影响的好方法。 二八法则 由帕累托原则(Pareto principle)引出 ,适用于任何网站,网页app或软件环境,即80%的结果是由20%的功能和特征所承担。 A / B测试 A / B测试说的是你将两个不同版本的线上内容提供给用户,来观察他们更倾向于哪一个。 视频传送门:What A-B Testing is_腾讯视频 可访问性 可访问性是指一个网站或app是否可以被轻松使用和理解,以及该网站/app对残疾人或其他人群的特殊需要是否考虑完善,比如通过配色设计使色盲者也能轻松阅读。 视频传送门:Everyone is different!_腾讯视频 主动倾听 这是一种采访技巧,即采访者通过认真倾听和及时的做出一些反应,来使交流更好地进行下去。 数据分析 数据分析可以有效地提供你的网站/app的流量信息,它告诉你流量从何而来,以及用户主要在哪里停留。它为了解你的网站/app是否可行提供了一个很好的视角。 视频传送门:What Web Analytics Is_腾讯视频 卡片分类法 卡片分类是一种帮助设计或评估站点信息架构的方法。在一个卡片分类会话中,参与者按自己的理解将细目分成不同的组,也可能需要给这些组贴上一定的标签。你可以使用卡片,纸张或在线卡片分类工具来进行卡片分类。 视频传送门:Card sorting_腾讯视频 点击流分析 点击流分析是指在网站分析中收集和分析用户会去访问哪些页面,以及以什么顺序去访问等这类数据的过程。访问者在网站访问的路径称为点击流。 视频传送门:Hadoop Tutorial_腾讯视频 竞争者分析 这是对当前和潜在竞争对手的优势和劣势的一种评估。 使用情境分析 使用情境分析涉及收集和分析以下信息:目标用户、任务、支持其目标的工具、产品使用的物理环境、技术约束及其他会影响用户体验的因素。 情境分析的数据可以通过访谈、研讨、调查、站点访问、 小组(焦点)座谈 、 观察性研究和情境调查来收集。 转换率 转化率是指在线完成目标交易的访问者的所占比。在电子商务中,转化营销是指将网站访问者转化为付费客户的行为。提高转化率的过程称为转化率优化。 日记分析 [...]

大数据独角兽Palantir之核心技术探秘

1.Palantir源起:B2B大数据和企业级Google。 Palantir(中文名帕兰提尔,源于《指环王》中可穿越时空、洞悉世间一切的水晶球Palantír)被誉为硅谷最神秘的大数据独角兽企业,短短几年内跻身百亿俱乐部,成为全球最高估值排名第四的初创公司。它的主要客户只在美剧和好莱坞里出现,如美国联邦调查局(FBI)、美国中央情报局(CIA)、美国国家安全局(NSA)、美国军队和各级反恐机构,当然还有如JPMorgan这样的华尔街金融大鳄等等。 关于Palantir的传奇故事很多,CIA通过他家的大数据技术追踪到本拉登;创始人Alex Karp师从德国的Jürgen Habermas(研究西方马克思主义)获得哲学博士,热衷中国气功和太极;帮多家银行揭露旁氏骗局挽回数十亿损失,帮助摩根大通解决欺诈交易和黑客攻击问题,每年节约数亿美元; 公司创始人和投资人(号称“硅谷黑帮”)由海军陆战队员随时保护以防不测;产品只卖美国及其盟友国;与棱镜门有说不清楚的关系等…这些花边新闻不是本文的关注点,本文重点从大数据技术角度来揭密Palantir的B2B大数据王国。 如果说谷歌是互联网大数据的霸主(确实如此,我在前文《从Tensorflow看谷歌的云端人工智能战略》有详细解读),那么Palantir的目标就是做未来企业级大数据霸主,这家公司的愿景就是做企业和政府领域的Google。为什么这样讲?从技术角度来分析,这是大数据发展的必然趋势,互联网上的数据多半是UGC用户产生内容,或是如电商平台这种某细分领域的独立生态数据,而真正的大数据金矿还在众多大型企业和政府机构的服务器集群中沉睡。 比如一个国家的情报部门和各部、各局信息中心,无不是掌握着成千上万关键领域的大数据,包括各种业务数据、监控数据、DNA样本、语音视频图片、地图时空数据等(当然前提是信息化程度及其发达,就像我们的税务系统一样,而不是房产登记系统),面对如此海量、多源、异构而且高关联性、复杂性、动态性大数据,如果没有快速的大数据分析技术和工具支持,那只能是望数兴叹。 而Palantir的大数据技术和产品就是专门针对大型企业和政府机构需求而生(与互联网公司的大数据技术有较大不同),其官方主页上的自我定位也很准确:“Palantir’s mission is to solve the most important problems for the world’s most important institutions.”。企业级大数据玩家当然政府和金融是最具数权(信息权利)的两个领域,所以Palantir研发的平台级大数据产品只有两个版本:Palantir Gotham(服务政府及军队客户)和Palantir Metropolis(服务金融、法律及其它客户)。 如果说谷歌、亚马逊、Facebook等互联网巨头是B2C大数据,那么Palantir就是B2B大数据,多数企业和政府机构对大数据的应用还处于起步和探索阶段,互联网下或关键领域内网、专网中结合私有云技术的B2B大数据分析是大数据时代发展的必然,而且应用潜力和价值更为巨大,谷歌旗下DeepMind公司开始跟大型医院和卫生部门合作就是最好的注解,互联网巨头以其已有的大数据技术优势,其业务触角正在向传统行业延伸。 图1. Palantir官方主页的服务宗旨 2.Palantir产品技术体系:军事、金融和警务大数据案例分析 网上有个段子,虽然真假不能确认,但却能从中看出Palantir的发迹史:“美国911之后,CIA等部门忙于调查各种线索。 Stanford的几个教授以公开的海量信息为输入,利用大数据处理技术建立关于人物关系的网络,最后锁定了一批疑似人,并迅速将结果发布出去,使得CIA等部门大为震惊,因为教授们的结果与CIA花人力物力大量侦查和审讯的结果很近似,让CIA们误以为教授们有牵连,迅速飞到Stanford找教授们问话。从此,“人脑+电脑“来分析复杂问题并辅助反恐成为可能”,Palantir正是在这一大背景下诞生和发迹的。目前Palantir有两大核心产品,Palantir Gotham和Palantir Metropolis,前者主要服务于国防安全和政府管理领域,后者主要服务于金融领域。 两大产品体系下辖十多种解决方案,如反欺诈(Anti Fraud)、网络安全(Cyber Security)、国防安全(Defense)、内部威胁(Insider Threat)、危机应对(Crisis Response)、保险分析(Insurance Analytics)、案例管理(Case Management)、疾病控制(Disease Response)、智能化决策(Intelligence)等。两个产品线的核心技术是服务客户整理、分析、利用不同来源的结构化和非结构化数据,创造一种人脑智能和计算机智能的共生分析环境及工具,人脑和大数据分析互补,提升客户的智慧和洞察力,从而解决大数据环境下的复杂问题决策。 Palantir在大数据江湖上最传奇的战绩,一是帮多家银行追回纳斯达克前主席麦道夫庞氏骗局的数十亿美金,二是帮助奥巴马政府追捕到本拉登。下面我们以军事、金融、警务三个方面的案例来对其产品的技术体系和服务内容进行初步探索和分析: (1)以军事国防解决方案为例。其核心目标是将多个军事情报领域的海量数据进行融合和关联分析,转化为可操作的决策指挥能力,多情报领域数据的集成和融合是要解决的关键问题,包括非结构化和结构化数据流,如链接图,电子表格,电话,文档,网络数据,传感器数据,甚至动态视频、图像等。 Palantir提供了一个基于全量多模态数据融合和协同挖掘分析的大数据支撑框架,可以对在地理、空间上分散的人、装备、环境、事件等进行大规模实时关联和因果分析,以指导复杂战场环境下的军事行动。这些大数据技术已被美国军方广泛运用于战场态势分析和预测,如定位伊拉克战场可能存在的炸弹或地雷位置,帮助美军在巴格达规划一条被袭概率最小的路径,或者分析亚丁湾海盗活动的热点区域。 这些分析整合了美军等多方原本孤立的数据源(如军事情报部门和陆海空、海军陆战队等组织机构的数据),通过Palantir的Nexus等技术,无缝整合同步数据和进行分析模型协同,包括各类数据模型、安全模型和本体对象的管理,其全量数据分析和知识管理能跟踪每一个数据和模型的读,写和编辑、保存,以积累战场空间的决策知识。基于通用的大数据融合分析平台,使指挥人员和调度人员能在单一系统内解决所有问题,包括敌人的活动情报分析(情报报告,事件行为等),关联分析(背景、跟踪、时空、反应等)和预判决策等功能。 下面几个图(图2-4)是Palantir 为美国军队提供的软件功能界面,从其中的功能和数据元素我们可以看出Palantir 的大数据分析技术已经深入美国核心情报军事机构,帮助其实现作战打击链的全局决策支持,从分析情报、打击目标,再将军事行动中获得的新情报与现有大数据进行融合更新,极大提高了情报分析和指挥决策能力。 图2. 国防部和海军的一个联席分析功能界面,对其舰船、飞机、情报文本和相关战场环境资源做了融合和关联,在统一视图里面进行管控,技术实现上把上述资源映射为各类事件、实体、对象及其关系。 图3. 阿富汗战场的融合分析功能界面,对各个区域的各类事件(武装袭击、爆炸、绑架等)进行了大规模关联分析,通过大规模数据可视化钻取和查询,可以找出事件之间的因果关系链。 图4. 战场空间感知态势图,战场环境下各类资源和事件总体态势分析 (2)以金融欺诈解决方案为例。Palantir凭借其为政府服务的影响力,在2010年摩根大通成为它的首批非政府客户。后来Palantir帮多家银行追回纳斯达克前主席麦道夫庞氏骗局的数十亿美金,名声大振,其出色的大数据技术获得华尔街金融大鳄们的认可,目前许多银行、保险、对冲基金,包括美国证券交易委员会都在使用Palantir的产品和技术。 反欺诈是金融领域的一项关键业务,信用评级、风险管理、关联交易、洗钱、逃税等都涉及此项分析内容。而金融是信息化程度极高的行业,拥有海量的相关数据。Palantir的Metropolis平台可将许多孤立的金融环境数据汇集到统一分析系统,通过时间序列以及关联分析、频繁项分析和知识图谱、社交网络等机器学习技术挖掘出有价值的信息。下面图5-6是Palantir金融版功能界面。 图5. Palantir金融版Metropolis平台功能界面图 [...]

分布式计算开源框架Hadoop入门实践(一

来源:https://www.evget.com/article/2017/4/28/26165.html 标签:数据分析 大数据 Hadoop 概述:Hadoop是Apache开源组织的一个分布式计算开源框架,在很多大型网站上都已经得到了应用,如亚马逊、Facebook和Yahoo等等。对于我来说,最近的一个使用点就是服务集成平台的日志分析。服务集成平台的日志量将会很大,而这也正好符合了分布式计算的适用场景(日志分析和索引建立就是两大应用场景)。 在SIP项目设计的过程中,对于它庞大的日志在开始时就考虑使用任务分解的多线程处理模式来分析统计,在我从前写的文章《Tiger Concurrent Practice —日志分析并行分解设计与实现》中有所提到。但是由于统计的内容暂时还是十分简单,所以就采用Memcache作为计数器,结合MySQL就完成了访问控制以及统计的工作。然而未来,对于海量日志分析的工作,还是需要有所准备。现在最火的技术词汇莫过于“云计算”,在Open API日益盛行的今天,互联网应用的数据将会越来越有价值,如何去分析这些数据,挖掘其内在价值,就需要分布式计算来支撑海量数据的分析工作。 回过头来看,早先那种多线程,多任务分解的日志分析设计,其实是分布式计算的一个单机版缩略,如何将这种单机的工作进行分拆,变成协同工作的集群,其实就是分布式计算框架设计所涉及的。在去年参加BEA大会的时候,BEA和VMWare合作采用虚拟机来构建集群,无非就是希望使得计算机硬件能够类似于应用程序中资源池的资源,使用者无需关心资源的分配情况,从而最大化了硬件资源的使用价值。分布式计算也是如此,具体的计算任务交由哪一台机器执行,执行后由谁来汇总,这都由分布式框架的Master来抉择,而使用者只需简单地将待分析内容提供给分布式计算系统作为输入,就可以得到分布式计算后的结果。 Hadoop是Apache开源组织的一个分布式计算开源框架,在很多大型网站上都已经得到了应用,如亚马逊、Facebook和Yahoo等等。对于我来说,最近的一个使用点就是服务集成平台的日志分析。服务集成平台的日志量将会很大,而这也正好符合了分布式计算的适用场景(日志分析和索引建立就是两大应用场景)。 当前没有正式确定使用,所以也是自己业余摸索,后续所写的相关内容,都是一个新手的学习过程,难免会有一些错误,只是希望记录下来可以分享给更多志同道合的朋友。 什么是Hadoop? 搞什么东西之前,第一步是要知道What(是什么),然后是Why(为什么),最后才是How(怎么做)。但很多开发的朋友在做了多年项目以后,都习惯是先How,然后What,最后才是Why,这样只会让自己变得浮躁,同时往往会将技术误用于不适合的场景。 Hadoop框架中最核心的设计就是:MapReduce和HDFS。MapReduce的思想是由Google的一篇论文所提及而被广为流传的,简单的一句话解释MapReduce就是“任务的分解与结果的汇总”。HDFS是Hadoop分布式文件系统(Hadoop Distributed File System)的缩写,为分布式计算存储提供了底层支持。 MapReduce从它名字上来看就大致可以看出个缘由,两个动词Map和Reduce,“Map(展开)”就是将一个任务分解成为多个任务,“Reduce”就是将分解后多任务处理的结果汇总起来,得出最后的分析结果。这不是什么新思想,其实在前面提到的多线程,多任务的设计就可以找到这种思想的影子。不论是现实社会,还是在程序设计中,一项工作往往可以被拆分成为多个任务,任务之间的关系可以分为两种:一种是不相关的任务,可以并行执行;另一种是任务之间有相互的依赖,先后顺序不能够颠倒,这类任务是无法并行处理的。回到大学时期,教授上课时让大家去分析关键路径,无非就是找最省时的任务分解执行方式。在分布式系统中,机器集群就可以看作硬件资源池,将并行的任务拆分,然后交由每一个空闲机器资源去处理,能够极大地提高计算效率,同时这种资源无关性,对于计算集群的扩展无疑提供了最好的设计保证。(其实我一直认为Hadoop的卡通图标不应该是一个小象,应该是蚂蚁,分布式计算就好比蚂蚁吃大象,廉价的机器群可以匹敌任何高性能的计算机,纵向扩展的曲线始终敌不过横向扩展的斜线)。任务分解处理以后,那就需要将处理以后的结果再汇总起来,这就是Reduce要做的工作。 上图就是MapReduce大致的结构图,在Map前还可能会对输入的数据有Split(分割)的过程,保证任务并行效率,在Map之后还会有Shuffle(混合)的过程,对于提高Reduce的效率以及减小数据传输的压力有很大的帮助。后面会具体提及这些部分的细节。 HDFS是分布式计算的存储基石,Hadoop的分布式文件系统和其他分布式文件系统有很多类似的特质。分布式文件系统基本的几个特点: 对于整个集群有单一的命名空间。 数据一致性。适合一次写入多次读取的模型,客户端在文件没有被成功创建之前无法看到文件存在。 文件会被分割成多个文件块,每个文件块被分配存储到数据节点上,而且根据配置会由复制文件块来保证数据的安全性。 上图中展现了整个HDFS三个重要角色:NameNode、DataNode和Client。NameNode可以看作是分布式文件系统中的管理者,主要负责管理文件系统的命名空间、集群配置信息和存储块的复制等。NameNode会将文件系统的Meta-data存储在内存中,这些信息主要包括了文件信息、每一个文件对应的文件块的信息和每一个文件块在DataNode的信息等。DataNode是文件存储的基本单元,它将Block存储在本地文件系统中,保存了Block的Meta-data,同时周期性地将所有存在的Block信息发送给NameNode。Client就是需要获取分布式文件系统文件的应用程序。这里通过三个操作来说明他们之间的交互关系。 文件写入: Client向NameNode发起文件写入的请求。 NameNode根据文件大小和文件块配置情况,返回给Client它所管理部分DataNode的信息。 Client将文件划分为多个Block,根据DataNode的地址信息,按顺序写入到每一个DataNode块中。 文件读取: Client向NameNode发起文件读取的请求。 NameNode返回文件存储的DataNode的信息。 Client读取文件信息。 文件Block复制: NameNode发现部分文件的Block不符合最小复制数或者部分DataNode失效。 通知DataNode相互复制Block。 DataNode开始直接相互复制。 最后再说一下HDFS的几个设计特点(对于框架设计值得借鉴): Block的放置:默认不配置。一个Block会有三份备份,一份放在NameNode指定的DataNode,另一份放在与指定DataNode非同一Rack上的DataNode,最后一份放在与指定DataNode同一Rack上的DataNode上。备份无非就是为了数据安全,考虑同一Rack的失败情况以及不同Rack之间数据拷贝性能问题就采用这种配置方式。 心跳检测DataNode的健康状况,如果发现问题就采取数据备份的方式来保证数据的安全性。 数据复制(场景为DataNode失败、需要平衡DataNode的存储利用率和需要平衡DataNode数据交互压力等情况):这里先说一下,使用HDFS的balancer命令,可以配置一个Threshold来平衡每一个DataNode磁盘利用率。例如设置了Threshold为10%,那么执行balancer命令的时候,首先统计所有DataNode的磁盘利用率的均值,然后判断如果某一个DataNode的磁盘利用率超过这个均值Threshold以上,那么将会把这个DataNode的block转移到磁盘利用率低的DataNode,这对于新节点的加入来说十分有用。 数据交验:采用CRC32作数据交验。在文件Block写入的时候除了写入数据还会写入交验信息,在读取的时候需要交验后再读入。 NameNode是单点:如果失败的话,任务处理信息将会纪录在本地文件系统和远端的文件系统中。 数据管道性的写入:当客户端要写入文件到DataNode上,首先客户端读取一个Block然后写到第一个DataNode上,然后由第一个DataNode传递到备份的DataNode上,一直到所有需要写入这个Block的NataNode都成功写入,客户端才会继续开始写下一个Block。 安全模式:在分布式文件系统启动的时候,开始的时候会有安全模式,当分布式文件系统处于安全模式的情况下,文件系统中的内容不允许修改也不允许删除,直到安全模式结束。安全模式主要是为了系统启动的时候检查各个DataNode上数据块的有效性,同时根据策略必要的复制或者删除部分数据块。运行期通过命令也可以进入安全模式。在实践过程中,系统启动的时候去修改和删除文件也会有安全模式不允许修改的出错提示,只需要等待一会儿即可。 下面综合MapReduce和HDFS来看Hadoop的结构: 在Hadoop的系统中,会有一台Master,主要负责NameNode的工作以及JobTracker的工作。JobTracker的主要职责就是启动、跟踪和调度各个Slave的任务执行。还会有多台Slave,每一台Slave通常具有DataNode的功能并负责TaskTracker的工作。TaskTracker根据应用要求来结合本地数据执行Map任务以及Reduce任务。 说到这里,就要提到分布式计算最重要的一个设计点:Moving Computation is Cheaper than Moving Data。就是在分布式处理中,移动数据的代价总是高于转移计算的代价。简单来说就是分而治之的工作,需要将数据也分而存储,本地任务处理本地数据然后归总,这样才会保证分布式计算的高效性。 [...]