1、调整心态。社会的发展很快，大数据作为一个新的产业，对人们的生活已经产生了很多的影响，我们应该调整好心态，随时准备挑战新的变化。
2、个人用途。建立一个大数据项目，可以从自己实践开始，比如通过大数据找到一个女朋友等等。
3、坚持学习。大数据的发展和应用日新月异，要走出去，增长见识，不断的学习，这样才能跟上时代的脚步。
4、市场导向。大数据项目其实与用户有关，商业性的应用以及市场的导向有关，要选择一个重点的方向，找准定位。
5、客户来源。目前的大数据可以供商用，比如像一些中小型的需求，我们也要找到这些企业客户，让我们的成功体现价值。
6、快速更新。大数据的发展，是根据企业的需求来开发的，开发的需求不断的更迭，也需要我们快速的更新大数据产品。
如何搭建大数据分析平台？
一般的大数据平台从平台搭建到数据分析大概包括以下几个步骤：
Linux系统安装。分布式计算平台或组件安装。
数据导入。数据分析。一般包括两个阶段：数据预处理和数据建模分析。数据预处理是为后面的建模分析做准备，主要工作时从海量数据中提取可用特征，建立大宽表。
数据建模分析是针对预处理提取的特征或数据建模，得到想要的结果。结果可视化及输出API。可视化一般式对结果或部分原始数据做展示。一般有两种情况，行数据展示，和列查找展示。
搭建大数据分析平台到思迈特软件Smartbi看看，在Excel中对数据进行二次加工，告别依赖于IT人员处理的困境；数据有错误也不怕，能够对缺失、不规范的数据进行二次加工，并能将这些数据入库；不受限制的分析思路，按您的想法加工数据；将本地数据和线上数据结合起来分析。
数据分析平台靠不靠谱，来试试Smartbi,思迈特软件Smartbi经过多年持续自主研发，凝聚大量商业智能最佳实践经验，整合了各行业的数据分析和决策支持的功能需求。满足最终用户在企业级报表、数据可视化分析、自助探索分析、数据挖掘建模、AI智能分析等大数据分析需求。
思迈特软件Smartbi个人用户全功能模块长期免费试用
马上免费体验:Smartbi一站式大数据分析平台
零基础如何学习大数据
一、兴趣建立
兴趣是可以让一个人持续关注一个事物的核心动力,而且兴趣也是可以培养出来的。如果你把写程序单纯作为赚钱手段，久而久之疲劳感会越来越强。大数据的应用非常广泛，比如：人工智能！找到自己的兴趣点，去发掘大数据在其中起到的神奇作用，这是最简单的兴趣共鸣。当一个人通过自己的努力获得的成就感就是最大的兴趣，在空闲的时候也可以到一些大数据论坛转转（比如：云和数据），你会发现一群程序员在一起除了技术交流外，还有属于程序员的幽默和八卦。
二、脚踏实地、切忌浮躁
俗话说：一口吃不成胖子，但现实的社会中人人都想一口吃成胖子。浮躁成为了当代人的一个符号，尤其是1/2线城市中承受着快节奏、大压力的人们，还有我们这些对大数据行业充满希望的学生。面对诱惑不论是企业、客户、政府、学校、还是培训机构都笼罩在浮躁之气当中，我们要做好自己。
作为学生不忘初心，就是脚踏实地的好好学习。熟练掌握大数据技术才是你学习阶段最该关系的事。不要每天活在幻想中，幻想毕业后的高薪工作、幻想自己变成技术大牛，这一切都是建立在你的大数据技术成熟的前提下。
三、行动非心动
很多想学习或转行大数据的朋友，从2017年大数据开始火爆的时刻开始观望直到现在还未能决定。然而那些和你一起关注大数据并行动学习大数据的学员，已经拿着15-20K的高薪在生活和工作了。心动不如行动，大数据的路上人越来越多。等，只会失去这个时代少有的机会。
四、学操结合，项目跟进
大数据是一项未来社会和企业都无法避开的技术，几乎全行业都需要大数据技术的支持，包括传统企业及人工智能等新兴行业。大数据到底学什么？其实大数据的方向有很多，而当前企业对大数据人才的需求主要集中在大数据开发。说到开发相信大家第一时间想到的就是编程。
到底要如何学习编程才能更快的掌握呢？1、读源码 2、原理剖析 3、抄代码 4、运行 5、默写代码 6、项目跟进。这样学习的好处是什么呢？读源码和原理剖析不用解释，抄代码是为了让你亲手操作一遍加强记忆，运行结果分析可以更快更牢固掌握知识点，然后默写一遍总结自己掌握情况。
最重要的是项目跟进，将教会你所掌握的编程技术在实际应用中如何使用，也就是你在未来工作中的工作如何进行。在面试及工作中项目经验都将直接决定你的薪资和发展，云和数据大数据培训班采用真实企业大数据项目进行对学生实训，以提高学生的竞争力，这是其他培训机构少有的。
五、工具的使用
工欲善其事必先利其器。开发工作包含各种各样的活动，需求收集分析、建立用例模型、建立分析设计模型、编程实现、调试程序、自动化测试、持续集成等等，没有工具帮忙可以说是寸步难行。工具可以提高开发效率，使软件的质量更高BUG更少。
六、为什么要学习大数据
今天大数据技术已经广泛应用于生活、工作及城市规划中，大数据人才需求量不断增长，而大数据人才产出不足造成大数据人才严重短缺，未来的人工智能、云计算、物联网都与大数据息息相关不可分割，大数据人才需求量将爆发式增长。所以，从就业前景，发展方向等多方面来看，学大数据无疑是最佳选择。
大数据平台是什么？什么时候需要大数据平台？如何建立大数据平台？
1、大数据平台目前业界也没有统一的定义，但一般情况下，使用了Hadoop、Spark、Storm、Flink等这些分布式的实时或者离线计算框架，建立计算集群，并在上面运行各种计算任务，这就是通常理解上的大数据平台。
2、至于一家企业什么时候需要大数据平台，这取决于这么几方面：
业务需求：业务需求引导是必须的，不能光为了建平台而建平台，建立平台的最终目的是为了服务业务，让业务发展的更好。企业内大数据平台一般是信息管理部门、IT部门承建并承接一些数据需求，业务部门其实不关心你是不是用大数据平台还是用Oracle数据库计算出来的，那么这怎么评估呢？其实主要还是数据量，比如业务部门是不是偶尔会提“去年全年的XX怎么样？”、“去年全年的销售按照渠道、产品类别几个维度进行细分”、“需要用户行为数据、订单数据结合来做用户画像”、“需要给用户打标签”、“设备传感器的数据都有了，需要做实时的故障预测”等等，在承接各种业务需求的时候，是不是偶尔会出现任务运行很久的情况？会不会出现有些需求根本难以实现，因为计算量太大的问题？这就说明，业务上已经有大数据的诉求了，技术上并没有满足。
说到业务需求，企业内的信息管理部门也要注意，自己不能光承担需求，更重要的是要深入业务，理解业务，本部门对技术了解，如果对业务也多了解一下，就能够利用技术优势做到“想业务部门所未想”，实现比业务部门能提出更好的需求，并且能用大数据技术实现这个需求，这时候，信息管理部门的价值就更突出了，在企业内就再也不是一个承接需求或者背锅的部门了。
数据量与计算量：涉及到数据量的评估，也包括2方面：
现有的情况：现在有多少数据？都存储在哪里？业务部门提的各种指标需求，每天需要多长时间计算完成？每天什么时候完成昨天经营情况的数据更新？
增长的情况：每天、每周、每个月的数据增量有多少？按照这个增速，现有的配置还能满足多长时间的需求？
以上2个方面需要综合评估，现有数据量较多或者增长较快，那就需要做大数据平台的打算了。
先进性：本企业在技术上的布局是否需要一定前瞻性？需要早在数据量不太大的时候就进行技术探索？亦或是未来会上马新项目，新项目会产生大量数据。
公有云与私有云的选择：如果企业对公有云比较接受，其实可以考虑直接数据上公有云，公有云在国内主要就是阿里云、腾讯云、百度云等，其中阿里云的技术最为成熟，此外还有亚马逊的AWS等，但这里说的是搭建自己的大数据平台，就不深入展开了。
3、如何搭建大数据平台
建设一个大数据平台不是一朝一夕能完成的，不是下载安装几个开源组件那么简单。
涉及到：
技术层面：如何进行系统架构设计？集群资源如何评估？需要哪些组件？Hadoop、Spark、Tez、Storm、Flink，这些组件有什么区别？它们之间如何有机的组合起来？
团队层面：现有的技术团队配比如何？有没有人力搭建并且运维这个平台？有没有能力运营好这个平台？
对于非常重视主营业务的传统企业，信息技术部门的团队规模一般比较有限，建设一个大数据平台的成本是很高的，这个成本不仅是经济成本，还包括人才投入的成本、时间消耗的成本等等，如何能快速满足企业的大数据平台需求。这时候就可以考虑直接采购商用的大数据平台。
商用的大数据平台，市场上也有很多可以选择，比如星环、华为，此外还有袋鼠云数栈。
数栈的目标是通过产品化的方式，帮助企业构建数据共享能力中心。数栈不仅仅是一个大数据平台，同时附加各类数据处理工具，包括：
开发套件：一站式大数据开发平台，帮助企业快速完全数据中台搭建
数据质量: 对过程数据和结果数据进行质量校验，帮助企业及时发现数据质量问题
数据地图: 可视化的数据资产中心，帮助企业全盘掌控数据资产情况和数据的来源去向
数据模型: 使企业数据标准化，模型化，帮助企业实现数据管理规范化
数据API: 快速生成数据API、统一管理API服务，帮助企业提高数据开放效率
主要特点有：
1.一站式。一站式数据开发产品体系，满足企业建设数据中台过程中的多样复杂需求。
2.兼容性强。支持对接多种计算引擎，兼容离线&实时任务开发。
3.开箱即用。基于Web的图形化操作界面，开箱即用，快速上手。
4.性价比高。满足中小企业数据中台建设需求，降低企业投入成本。
有了数栈，企业搭建数据平台就不再是什么问题，核心需求也就会从搭建数据平台转为满足更多的业务诉求，实现真正的企业数据共享能力中心
如何培养大数据思维
在大数据时代，我们的思维认知很容易受到各类媒体的冲击。下面分享几点关于在大数据时代下如何进行思维提升的思考。
第一，我们尤其要培养开放性思维，提升思想的包容性，警惕认知偏差。认知偏差往往源于人们只看到经过某种筛选而产生的结果，而没有意识到筛选的过程，因此忽略了被筛选掉的关键信息。比如，“幸存者偏差”就是众多认知偏差之一，因为失败案例被忽略导致人们盲目乐观。
第二，我们要摈弃样本思维，建立全局思维。我们每天被海量信息包围，从这些信息中找到有效信息就成为一种必备技能。大数据精准信息投放导致我们都深陷信息壁垒之中，只有敢于打破壁垒，确保信息的多样性和整体性，这样才能帮助我们更接近事实真相。
第三，我们要从感性思维切换到理性思维。大数据意味着庞杂的信息，这些信息作为实证材料时刻影响着影响我们的观念。相近的和相反的例证导致我们在截然不同的结论之间摇摆不定，迷惑不已。因此，我们只有认真分析不同信息来源背后隐藏的动机并系统梳理其内在联系和发展脉络，才能实现从感性思维到理性思维的转变，摆脱信息表象的困扰
如何打造优秀的大数据团队
如何打造优秀的大数据团队
对于企业来说,要建设自己的大数据平台,需要的不只是技术解决方案,更重要的是组建一支优秀的数据团队。那么,数据团队有哪些成员组成?他们的工作方式是什么?采用怎样的组织架构来开展工作?
1. 数据团队成员这里只讨论数据团队中核心成员的角色和他们的工作职责。1)基础平台团队主要负责搭建稳定、可靠的大数据存储和计算平台。核心成员包括:数据开发工程师负责Hadoop、Spark、Hbase和Storm等系统的搭建、调优、维护和升级等工作,保证平台的稳定。数据平台架构师负责大数据底层平台整体架构设计、技术路线规划等工作,确保系统能支持业务不断发展过程中对数据存储和计算的高要求。运维工程师负责大数据平台的日常运维工作2)数据平台团队主要负责数据的清洗、加工、分类和管理等工作,构建企业的数据中心,为上层数据应用提供可靠的数据。数据开发工程师负责数据清洗、加工、分类等开发工作,并能响应数据分析师对数据提取的需求。数据挖掘工程师负责从数据中挖掘出有价值的数据,把这些数据录入到数据中心,为各类应用提供高质量、有深度的数据。数据仓库架构师负责数据仓库整体架构设计和数据业务规划工作。3)数据分析团队主要负责为改善产品体验设计和商业决策提供数据支持。业务分析师主要负责深入业务线,制定业务指标,反馈业务问题,为业务发展提供决策支持。建模分析师主要负责数据建模,基于业务规律和数据探索构建数据模型,提升数据利用效率和价值。2. 数据团队的工作方式数据团队的工作可以分成两大部分,一部分是建设数据存储和计算平台,另一部分是基于数据平台提供数据产品和数据服务。平台的建设者包括三种人群:基础平台团队对hadoop、spark、storm等各类大数据技术都非常熟悉,负责搭建稳定、可靠的大数据存储和计算平台。数据平台团队主要负责各类业务数据进行清洗、加工、分类以及挖掘分析,然后把数据有组织地存储到数据平台当中,形成公司的数据中心,需要团队具有强大的数据建模和数据管理能力。数据产品经理团队主要是分析挖掘用户需求,构建数据产品为开发者、分析师和业务人员提供数据可视化展示。平台的使用者也可以包括三种人群:数据分析团队通过分析挖掘数据,为改善产品体验设计和商业决策提供数据支持。运营、市场和管理层可以通过数据分析师获得有建设性的分析报告或结论,也可以直接访问数据产品获得他们感兴趣的数据,方便利用数据做决策。数据应用团队利用数据平台团队提供的数据开展推荐、个性化广告等工作。3. 数据分析团队的组织架构在整个大数据平台体系中的团队:基础平台、数据平台、数据应用和数据产品经理团队都可以保持独立的运作,只有数据分析团队的组织架构争议比较大。数据分析团队一方面要对业务比较敏感,另一方面又需要与数据平台技术团队有深度融合,以便能获得他们感兴趣的数据以及在数据平台上尝试实验复杂建模的可能。从他们的工作方式可以看出,数据分析团队是衔接技术和业务的中间团队,这样的团队组织架构比较灵活多变:1)外包公司自身不设立数据分析部门,将数据分析业务外包给第三方公司,当前电信行业,金融行业中很多数据分析类业务都是交给外包公司完成的。优势: 很多情况下,可以降低公司的资金成本和时间成本;许多公司内部缺乏相关的知识与管理经验,外包给专业的团队有助于公司数据价值的体现 。劣势:一方面外包人员的流动和合作变数,对数据的保密性没有保证;另外一方面,外包团队对需求的响应会比较慢,处理的问题相对通用传统,对公司业务认知不如内部员工深入,创新较低。2)分散式每个产品部门独立成立数据分析团队,负责响应自己产品的数据需求,为业务发展提供决策支持。优势:数据分析团队与开发团队、设计团队以及策划团队具有共同的目标,团队整体归属感强,绩效考核与产品发展直接挂钩,有利于业务的发展。劣势:在业务规模比较小的情况下,数据分析师比较少,交流的空间也比较小。因为身边的同事都不是该领域的人才,无法进行学习交流,所以成长空间会比较小,分析师的流失也会比较严重,最终陷入招募新人——成长受限——离职——招募新人的恶性循环。另一方面,每个产品团队都零星地招募几个分析师,整体来看给员工的感觉是公司并不是特别重视数据化运营的文化,对数据的认同感会被削弱,不利于公司建立数据分析平台体系。3)集中式数据分析团队与产品团队、运营团队各自独立,团队的负责人具有直接向分管数据的副总裁或CEO直接汇报的权限,团队负责响应各业务部门的数据需求。优势:分析团队具有充分的自主权,可以专心建设好公司级别的数据平台体系,研究数据最具有价值的那些问题,有权平衡业务短期需求和平台长期需求直接的关系。另一方面,这种自上而下建立起来组织架构,可以向全体员工传达数据在公司的重要位置,有利于建立数据化运营的文化。劣势:产品业务团队会觉得他们对数据的掌控权比较弱,一些业务数据需求得不到快速响应,认为分析团队的反应太慢无法满足业务发展的需要。随着业务发展越来越大,产品团队会自己招募分析师来响应数据需求,逐渐替代分析团队的工作,这样势必会导致分析团队的工作被边缘化。4)嵌入式数据分析团队同样独立于产品团队存在,但只保留部分资深数据专家,负责招聘、培训数据分析师,然后把这些人派遣到各产品团队内部,来响应各类业务数据需求。优势:团队的灵活性比较好,可以根据公司各业务线的发展情况合理调配人力资源,重点发展的项目投入优秀的人才,一些需要关闭的项目人才可以转移到其他项目中去。劣势:分析师被嵌入到产品团队内部,受产品团队主管的领导,从而失去了自主权,导致沦落为二等公民。人事关系在公司数据分析团队中,却要被业务团队主管考核,但业务团队主管并不关心他们的职业发展,导致分析师的职业发展受到限制。那么,到底采取哪一种组织架构比较合适呢?可以根据公司数据化运营进展的深度灵活采取一种或几种方式。除了外包模式,其他组织架构我都经历过,简单来说,早期采用分散式、中期采用集中式、后期采用分散式或嵌入式以及两则并存。早期:公司对数据体系的投入一般是比较谨慎的,因为要全面建设数据体系需要投入大量的人力和财力,公司不太可能还没有看清楚局势的情况下投入那么多资源。所以,往往都是让每个产品团队自己配置分析师,能解决日常的业务问题就行。杭研院早期的网易云阅读、印像派等项目中就是采用的这种分散的模式。中期:随着业务的发展、公司对数据的认识有所提高并且重视程度不断加大,就开始愿意投入资源来构建公司级别的数据体系。这个阶段采用集中式有利于快速构建数据分析平台,为公司各个产品团队提供最基础的数据分析体系,能在未来应对业务的快速发展。杭研院花了两年时间完成了这个阶段的主要工作,并在网易云音乐和易信产品发展阶段起到了至关重要的作用。后期:一旦公司级别的数据分析平台构建完成,消除了早期分散模式中分析师缺少底层平台支持的窘境,他们能够在分析平台上自助完成大量的数据分析工作。而且经历过集中式阶段的洗礼,公司上上下下对数据的认识都有了很大的提高。此时,在回到分散模式时,原先的很多弊端已基本消除,此外,采用嵌入模式也是可以的。目前杭研院在网易云音乐、网易云课堂、考拉海购等几个产品中就是分散式和嵌入式并存的架构。总之,没有最好的组织架构,只有适合自己的组织架构。
大数据规划的五个步骤
大数据规划的五个步骤
数据分析的未来将朝着更为普及化、更为实时的数据分析去迈进，也就是说“针对正确的人，在正确的时间，获得正确的信息”，从这个意义来说，它已经超越了技术本身，是更为接近业务层面的实时分析。
对于一个成功企业来说，数据整合能力、分析能力和行动能力不可或缺。如果不具备完善的数据整合、分析和行动能力的企业迟早面临被淘汰的风险。在经营环境发生巨变的情况下，任何企业都必须在大数据规划上做好准备，这样才能抢先竞争对手发现市场新的趋势。
三种能力
我们建议企业和政府机构进行数据整合能力、分析能力和行动能力的建设。对于任何公司的管理层来说，要充分认识到数据的重要性，在管理层充分认识到数据的重要性之后，内部要有足够的人员和能力去整合、搭建和完善数据管理基础架构。有了海量数据之后，数据分析师能够对其进行分析和挖掘，使其产生理想的价值。
数据分析能力通过一定的方法论可以获得。这个方法论从宏观的角度来看，是通过数据整合探索出有效的业务价值，进而精确地协助制定商业策略或服务提升的策略，有效地采取正确的行动，来协助业务和服务质量的增长，或是解决业务已知、不确定或发现未知的问题。
另外，数据要实现普及化，不仅掌握在管理层手中，在数据安全和权限管理的机制下，企业或单位的每一个人都要了解自己的业务具体发生了什么，为何发生，预测将要发生什么情况，从而更快、更好地做出决策，最终达到智慧型的管理，通过一些主动式的事件，产生正确的行动，如业务增长的价值措施和办法，来精确有效地提升业务的增长。
五个步骤
如今大数据已经远远超出了IT的范畴，也就是说所有部门都在大数据运用的范畴中。
大数据规划有五个步骤，首先从业务驱动的角度，相关部门选择要解决和产生的业务场景。针对需求处理和采取整合这些场景需要的大数据。当然选择的重点是怎么使信息快速产生价值。场景因需求不同而包罗万象：例如企业在精确营销方面提升业务增长，对于其客户在购买哪些产品前的黄金路径统计分析等等。
其次，直接产生的价值需要与已有的客户关系管理、客户交易等数据进行结合和关联，从而为企业产生总体的关键价值效益。例如，哪些用户在购买前确实通过上述统计总结的黄金路径，而这些用户和该企业的历史关系为何，以提供企业下一步精确行动的优先顺序等等。
第三，整个企业要建立大数据分析的支持体系、分析的文化、分析数据的人才，彻底形成企业对大数据的综合管理、探索、共识。大数据能力的建设是企业或政府单位内上下及跨部门就如何提供更加智慧型服务和产品给用户的议题。
第四，随着大数据探索范围的扩大，企业要建立大数据的标准，统一数据格式、采集方法、使用方式，设定一个共享的愿景和目的，然后按照阶段化的目标去实现愿景。例如，有关数据的存储和处理长期围绕在关系型的结构数据中，提供更加智慧型服务和产品是需要结合过去难以处理分析的数据，如文本、图像等等。数据内容快速演变，因此对数据的标准、格式、采集、工具、方法等的治理能力必须与时俱进。
第五，最终建成企业或政府单位内的“统一数据架构”，从各类所需的多元的结构化数据源建立整合能力（采集、存储、粗加工）。在此基础上，建设数据探索和分析能力（从整合出来的海量数据里快速探索出价值），之后如何有效、实时、精确地与已有的业务数据结合，产生精确的业务行动能力（进行更深度的利用和提供更智慧型的服务），从而达到“针对正确的人，在正确的时间，正确的方式，提供正确的信息”的目标。
如何建立一个完整可用的安全大数据平台
“
要建立一个大数据系统，我们需要从数据流的源头跟踪到最后有价值的输出，并在现有的Hadoop和大数据生态圈内根据实际需求挑选并整合各部分合适的组件来构建一个能够支撑多种查询和分析功能的系统平台。这其中既包括了对数据存储的选择，也涵盖了数据线上和线下处理分离等方面的思考和权衡。此外，没有任何一个引入大数据解决方案的商业应用在生产环境上承担的起安全隐患。
1
计算框架篇
大数据的价值
只有在能指导人们做出有价值的决定时，数据才能体现其自身的价值。因此，大数据技术要服务于实际的用途，才是有意义的。一般来说，大数据可以从以下三个方面指导人们做出有价值的决定：
报表生成（比如根据用户历史点击行为的跟踪和综合分析、 应用程序活跃程度和用户粘性计算等）；
诊断分析（例如分析为何用户粘性下降、根据日志分析系统为何性能下降、垃圾邮件以及病毒的特征检测等）；
决策（例如个性化新闻阅读或歌曲推荐、预测增加哪些功能能增加用户粘性、帮助广告主进行广告精准投放、设定垃圾邮件和病毒拦截策略等）。
图 1
进一步来看，大数据技术从以下三个方面解决了传统技术难以达成的目标（如图1）：
在历史数据上的低延迟（交互式）查询，目标是加快决策过程和时间， 例如分析一个站点为何变缓慢并尝试修复它；
在实时数据上的低延迟查询，目的是帮助用户和应用程序在实时数据上做出决策， 例如实时检测并阻拦病毒蠕虫（一个病毒蠕虫可以在1.3秒内攻击1百万台主机）；
更加精细高级的数据处理算法，这可以帮助用户做出“更好”的决策， 例如图数据处理、异常点检测、趋势分析及其他机器学习算法。
蛋糕模式
从将数据转换成价值的角度来说，在Hadoop生态圈十年蓬勃成长的过程中，YARN和Spark这二者可以算得上是里程碑事件。Yarn的出现使得集群资源管理和数据处理流水线分离，大大革新并推动了大数据应用层面各种框架的发展（SQL on Hadoop框架, 流数据，图数据，机器学习）。
它使得用户不再受到MapReduce开发模式的约束，而是可以创建种类更为丰富的分布式应用程序，并让各类应用程序运行在统一的架构上，消除了为其他框架维护独有资源的开销。就好比一个多层蛋糕，下面两层是HDFS和Yarn, 而MapReduce就只是蛋糕上层的一根蜡烛而已，在蛋糕上还能插各式各样的蜡烛。
在这一架构体系中，总体数据处理分析作业分三块（图2），在HBase上做交互式查询（Apache Phoenix, Cloudera Impala等）， 在历史数据集上编写MapReduce程序抑或利用Hive等做批处理业务， 另外对于实时流数据分析Apache Storm则会是一种标准选择方案。
虽然Yarn的出现极大地丰富了Hadoop生态圈的应用场景，但仍存有两个显而易见的挑战：一是在一个平台上需要维护三个开发堆栈；二是在不同框架内很难共享数据，比如很难在一个框架内对流数据做交互式查询。这也意味着我们需要一个更为统一和支持更好抽象的计算框架的出现。
图 2
一统江湖
Spark的出现使得批处理任务，交互式查询，实时流数据处理被整合到一个统一的框架内（图3），同时Spark和现有的开源生态系统也能够很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。 通过启用内存分布数据集，优化迭代工作负载， 用户能够更简单地操作数据，并在此基础上开发更为精细的算法，如机器学习和图算法等。
有三个最主要的原因促使Spark目前成为了时下最火的大数据开源社区（拥有超过来自200多个公司的800多个contributors）：
Spark可以扩展部署到超过8000节点并处理PB级别的数据，同时也提供了很多不错的工具供应用开发者进行管理和部署；
Spark提供了一个交互式shell供开发者可以用Scala或者Python即时性试验不同的功能；
Spark提供了很多内置函数使得开发者能够比较容易地写出低耦合的并且能够并发执行的代码，这样开发人员就更能集中精力地为用户提供更多的业务功能而不是花费时间在优化并行化代码之上。
当然Spark也和当年的MapReduce一样不是万灵药，比如对实时性要求很高的流数据处理上Apache Storm还是被作为主流选择， 因为Spark Streaming实际上是microbatch（将一个流数据按时间片切成batch,每个batch提交一个job）而不是事件触发实时系统，所以虽然支持者们认为microbatch在系统延时性上贡献并不多，但在生产环境中和Apache Storm相比还不是特别能满足对低延时要求很高的应用场景。
比如在实践过程中， 如果统计每条消息的平均处理时间，很容易达到毫秒级别，但一旦统计类似service assurance（确保某条消息在毫秒基本能被处理完成）的指标， 系统的瓶颈有时还是不能避免。
但同时我们不能不注意到，在许多用例当中，与流数据的交互以及和静态数据集的结合是很有必要的, 例如我们需要在静态数据集上进行分类器的模型计算，并在已有分类器模型的基础上，对实时进入系统的流数据进行交互计算来判定类别。
由于Spark的系统设计对各类工作（批处理、流处理以及交互式工作）进行了一个共有抽象，并且生态圈内延伸出了许多丰富的库（MLlib机器学习库、SQL语言API、GraphX）, 使得用户可以在每一批流数据上进行灵活的Spark相关操作，在开发上提供了许多便利。
Spark的成熟使得Hadoop生态圈在短短一年之间发生了翻天覆地的变化， Cloudera和Hortonworks纷纷加入了Spark阵营，而Hadoop项目群中除了Yarn之外已经没有项目是必须的了（虽然Mesos已在一些场合替代了Yarn）, 因为就连HDFS，Spark都可以不依赖。但很多时候我们仍然需要像Impala这样的依赖分布式文件系统的MPP解决方案并利用Hive管理文件到表的映射，因此Hadoop传统生态圈依然有很强的生命力。
另外在这里简要对比一下交互式分析任务中各类SQL on Hadoop框架，因为这也是我们在实际项目实施中经常遇到的问题。我们主要将注意力集中在Spark SQL, Impala和Hive on Tez上, 其中Spark SQL是三者之中历史最短的，论文发表在15年的SIGMOD会议上， 原文对比了数据仓库上不同类型的查询在Shark（Spark最早对SQL接口提供的支持）、Spark SQL和Impala上的性能比较。
也就是说， 虽然Spark SQL在Shark的基础上利用Catalyst optimizer在代码生成上做了很多优化，但总体性能还是比不上Impala, 尤其是当做join操作的时候， Impala可以利用“predicate pushdown”更早对表进行选择操作从而提高性能。
不过Spark SQL的Catalyst optimizer一直在持续优化中，相信未来会有更多更好的进展。Cloudera的Benchmark评测中Impala一直比其他SQL on Hadoop框架性能更加优越，但同时Hortonworks评测则指出虽然单个数据仓库查询Impala可以在很短的时间内完成，但是一旦并发多个查询Hive on Tez的优势就展示出来。另外Hive on Tez在SQL表达能力也要比Impala更强（主要是因为Impala的嵌套存储模型导致的）， 因此根据不同的场景选取不同的解决方案是很有必要的。
图 3
各领风骚抑或代有才人出？
近一年比较吸引人眼球的Apache Flink（与Spark一样已有5年历史，前身已经是柏林理工大学一个研究性项目，被其拥趸推崇为继MapReduce, Yarn，Spark之后第四代大数据分析处理框架）。 与Spark相反，Flink是一个真正的实时流数据处理系统，它将批处理看作是流数据的特例，同Spark一样它也在尝试建立一个统一的平台运行批量，流数据，交互式作业以及机器学习，图算法等应用。
Flink有一些设计思路是明显区别于Spark的，一个典型的例子是内存管理，Flink从一开始就坚持自己精确的控制内存使用并且直接操作二进制数据，而Spark一直到1.5版本都还是试用java的内存管理来做数据缓存，这也导致了Spark很容易遭受OOM以及JVM GC带来的性能损失。
但是从另外一个角度来说, Spark中的RDD在运行时被存成java objects的设计模式也大大降低了用户编程设计门槛， 同时随着Tungsten项目的引入，Spark现在也逐渐转向自身的内存管理， 具体表现为Spark生态圈内从传统的围绕RDD（分布式java对象集合）为核心的开发逐渐转向以DataFrame(分布式行对象集合)为核心。
总的来说，这两个生态圈目前都在互相学习，Flink的设计基因更为超前一些，但Spark社区活跃度大很多，发展到目前毫无疑问是更为成熟的选择，比如对数据源的支持（HBase, Cassandra, Parquet, JSON, ORC）更为丰富以及更为统一简洁的计算表示。另一方面，Apache Flink作为一个由欧洲大陆发起的项目，目前已经拥有来自北美、欧洲以及亚洲的许多贡献者，这是否能够一改欧洲在开源世界中一贯的被动角色，我们将在未来拭目以待。
2
NoSQL数据库篇
NoSQL数据库在主流选择上依旧集中在MongoDB, HBase和Cassandra这三者之间。在所有的NoSQL选择中，用C 编写的MongoDB几乎应该是开发者最快也最易部署的选择。MongoDB是一个面向文档的数据库，每个文档／记录／数据（包括爬取的网页数据及其他大型对象如视频等）是以一种BSON（Binary JSON）的二进制数据格式存储, 这使得MongoDB并不需要事先定义任何模式, 也就是模式自由（可以把完全不同结构的记录放在同一个数据库里）。
MongoDB对于完全索引的支持在应用上是很方便的，同时也具备一般NoSQL分布式数据库中可扩展，支持复制和故障恢复等功能。 MongoDB一般应用于高度伸缩性的缓存及大尺寸的JSON数据存储业务中，但不能执行“JOIN”操作，而且数据占用空间也比较大，最被用户诟病的就是由于MongoDB提供的是数据库级锁粒度导致在一些情况下建索引操作会引发整个数据库阻塞。一般来说，MongoDB完全可以满足一些快速迭代的中小型项目的需求。
下面来主要谈谈Cassandra和HBase之间的比较选择。Cassandra和HBase有着截然不同的基因血统。HBase和其底层依赖的系统架构源自于著名的Google FileSystem（发表于2003年）和Google BigTable设计（发表于2006年）， 其克服了HDFS注重吞吐量却牺牲I/O的缺点，提供了一个存储中间层使得用户或者应用程序可以随机读写数据。
具体来说，HBase的更新和删除操作实际上是先发生在内存MemStore中， 当MemStore满了以后会Flush到StoreFile, 之后当StoreFile文件数量增长到一定阈值后会触发Compact合并操作，因此HBase的更新操作其实是不断追加的操作，而最终所有更新和删除数据的持久化操作都是在之后Compact过程中进行的。
这使得应用程序在向内存MemStore写入数据后，所做的修改马上就能得到反映，用户读到的数据绝不会是陈旧的数据，保证了I/O高性能和数据完全一致性； 另一方面来说， HBase基于Hadoop生态系统的基因就已经决定了他自身的高度可扩展性、容错性。
在数据模型上，Cassandra和HBase类似实现了一个key-value提供面向列式存储服务，其系统设计参考了 Amazon Dynamo (发表于2007年) 分布式哈希（DHT）的P2P结构（实际上大部分Cassandra的初始工作都是由两位从Amazon的Dynamo组跳槽到Facebook的工程师完成)，同样具有很高的可扩展性和容错性等特点。
除此之外， 相对HBase的主从结构，Cassandra去中心化的P2P结构能够更简单地部署和维护，比如增加一台机器只需告知Cassandra系统新节点在哪，剩下的交给系统完成就行了。同时，Cassandra对多数据中心的支持也更好，如果需要在多个数据中心进行数据迁移Cassandra会是一个更优的选择。
Eric Brewer教授提出的经典CAP理论认为任何基于网络的数据共享系统，最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素。实际分布式系统的设计过程往往都是在一致性与可用性上进行取舍，相比于HBase数据完全一致性的系统设计，Cassandra选择了在优先考虑数据可用性的基础上让用户自己根据应用程序需求决定系统一致性级别。
比如：用户可以配置QUONUM参数来决定系统需要几个节点返回数据才能向客户端做出响应，ONE指只要有一个节点返回数据就可以对客户端做出响应，ALL指等于数据复制份数的所有节点都返回结果才能向客户端做出响应，对于数据一致性要求不是特别高的可以选择ONE，它是最快的一种方式。
从基因和发展历史上来说，HBase更适合用做数据仓库和大规模数据处理与分析（比如对网页数据建立索引）， 而Cassandra则更适合用作实时事务和交互式查询服务。Cassandra在国外市场占有比例和发展要远比国内红火， 在不少权威测评网站上排名都已经超过了HBase。目前Apache Cassandra的商业化版本主要由软件公司DataStax进行开发和销售推广。另外还有一些NoSQL分布式数据库如Riak, CouchDB也都在各自支持的厂商推动下取得了不错的发展。
虽然我们也考虑到了HBase在实际应用中的不便之处比如对二级索引的支持程度不够（只支持通过单个行键访问，通过行键的范围查询，全表扫描），不过在明略的大数据基础平台上，目前整合的是依然是HBase。
理由也很简单，HBase出身就与Hadoop的生态系统紧密集成，其能够很容易与其他SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）进行整合，而不需要重新部署一套分布式数据库系统，而且可以很方便地将同样的数据内容在同一个生态系统中根据不同框架需要来变换存储格式（比如存储成Hive表或者Parquet格式）。
我们在很多项目中都有需要用到多种SQL on Hadoop框架，来应对不同应用场景的情况，也体会到了在同一生态系统下部署多种框架的简便性。 但同时我们也遇到了一些问题， 因为HBase项目本身与HDFS和Zookeeper系统分别是由不同开源团队进行维护的，所以在系统整合时我们需要先对HBase所依赖的其他模块进行设置再对HBase进行配置，在一定程度上降低了系统维护的友好性。
目前我们也已经在考虑将Cassandra应用到一些新的客户项目中，因为很多企业级的应用都需要将线上线下数据库进行分离，HBase更适合存储离线处理的结果和数据仓库，而更适合用作实时事务和并发交互性能更好的Cassandra作为线上服务数据库会是一种很好的选择。
3
大数据安全篇
随着越来越多各式各样的数据被存储在大数据系统中，任何对企业级数据的破坏都是灾难性的，从侵犯隐私到监管违规，甚至会造成公司品牌的破坏并最终影响到股东收益。给大数据系统提供全面且有效的安全解决方案的需求已经十分迫切：
大数据系统存储着许多重要且敏感的数据，这些数据是企业长久以来的财富
与大数据系统互动的外部系统是动态变化的，这会给系统引入新的安全隐患
在一个企业的内部，不同Business Units会用不同的方式与大数据系统进行交互，比如线上的系统会实时给集群推送数据、数据科学家团队则需要分析存储在数据仓库内的历史数据、运维团队则会需要对大数据系统拥有管理权限。
因此为了保护公司业务、客户、财务和名誉免于被侵害，大数据系统运维团队必须将系统安全高度提高到和其他遗留系统一样的级别。同时大数据系统并不意味着引入大的安全隐患，通过精细完整的设计，仍然能够把一些传统的系统安全解决方案对接到最新的大数据集群系统中。
一般来说，一个完整的企业级安全框架包括五个部分：
Administration: 大数据集群系统的集中式管理，设定全局一致的安全策略
Authentication: 对用户和系统的认证
Authorization：授权个人用户和组对数据的访问权限
Audit：维护数据访问的日志记录
Data Protection：数据脱敏和加密以达到保护数据的目的
系统管理员要能够提供覆盖以上五个部分的企业级安全基础设施，否则任何一环的缺失都可能给整个系统引入安全性风险。
在大数据系统安全集中式管理平台这块，由Hortonworks推出的开源项目Apache Ranger就可以十分全面地为用户提供Hadoop生态圈的集中安全策略的管理，并解决授权(Authorization)和审计(Audit)。例如，运维管理员可以轻松地为个人用户和组对文件、数据等的访问策略，然后审计对数据源的访问。
与Ranger提供相似功能的还有Cloudera推出的Apache Sentry项目，相比较而言Ranger的功能会更全面一些。
而在认证（Authentication）方面, 一种普遍采用的解决方案是将基于Kerberos的认证方案对接到企业内部的LDAP环境中， Kerberos也是唯一为Hadoop全面实施的验证技术。
另外值得一提的是Apache Knox Gateway项目，与Ranger提高集群内部组件以及用户互相访问的安全不同，Knox提供的是Hadoop集群与外界的唯一交互接口，也就是说所有与集群交互的REST API都通过Knox处理。这样，Knox就给大数据系统提供了一个很好的基于边缘的安全（perimeter-based security）。
基于以上提到的五个安全指标和Hadoop生态圈安全相关的开源项目， 已经足已证明基于Hadoop的大数据平台我们是能够构建一个集中、一致、全面且有效的安全解决方案。
我市再ITjob管网上面找的
