百度上怎么制作自己的网站,网络架构师证书怎么考,前端app开发流程,郑州app下载前言#xff1a;学习大数据技术#xff0c;知道会用已经够了#xff0c;但是要想走得更远#xff0c;应该了解它发展的来龙去脉#xff0c;为何会有新的技术/工具的出现#xff0c;相比老的技术有什么样的进步。 1、传统数据处理系统存在的问题 随着信息时代互联网技术爆… 前言学习大数据技术知道会用已经够了但是要想走得更远应该了解它发展的来龙去脉为何会有新的技术/工具的出现相比老的技术有什么样的进步。 1、传统数据处理系统存在的问题 随着信息时代互联网技术爆炸式的发展人们对于网络的依赖程度日渐加深在业务中需要处理的数据量快速增加逐渐飙升到了一个惊人的数量级。并且数据产生的速度随着采集与处理技术的更新仍在加快。 数据量从兆字节(MB)、吉字节 (GB) 的级别到现在的太字节 (TB)、柏 字 节 (PB) 级别数据量的变化促使数据管理系统 (DBMS) 和数据仓库 (Data Warehouse,DW) 系统也在悄然地变化着。传统应用的数据系统架构设计时应用直接访问数据库系统。当用户访问量增加时数据库无法支撑日益增长的用户请求的负载从而导致数据库服务器无法及时响应用户于数据修改的请求时就需要增加多个工作处理层并发执行数据库又将再次成为响应请求的瓶颈。一个解决办法是对数据库进行分区 (Horizontal Partitioning)。分区的方式通常以 Hash 值作为 key 。这样就需要应用程序端知道如何去寻找每个key 所在的分区。 但即便如此问题仍然会随着用户请求的增加接踵而来。当之前的分区无法满足负载时 就需要增加更多分区这时就需要对数据库进行reshard 。resharding 的工作非常耗时而痛苦因 为需要协调很多工作例如数据的迁移、更新客户端访问的分区地址更新应用程序代码。如果系统本身还提供了在线访问服务对运维的要求就更高。这种情况下就可能导致数据写到错误的分区因此必须要编写脚本来自动完成且需要充分的测试。 由此可见在数据层和应用中增加了缓冲隔离数据量的日渐增多仍然迫使传统数据仓库的开发者一次又一次挖掘系统试图在各个方面寻找一点可提升的性能。架构变得越来越复杂 增加了队列、分区、复制、重分区脚本 (Resharding Scripts)。应用程序还需要了解数据库的 schema, 并能访问到正确的分区。问题在于数据库对于分区是不了解的无法帮助你应对分 区、复制与分布式查询。 最严重的问题是系统并没有对人为错误进行工程设计仅靠备份是不能治本的。归根结底 系统还需要限制因为人为错误导致的破坏。然而数据永不止步传统架构的性能被压榨至极 限检索数据的延迟和频繁的硬件错误问题逐渐使用户不可接受在传统架构上进行继续挖掘被证明是“挤牙膏”。帮助处理海量数据的新技术和新架构开发被提上日程以求得让企业在现代竞争中占得先机。越来越多的开发者参与到新技术与新架构的研究探讨中结论与成果逐渐丰硕。人们发现当系统的用户访问量持续增加时就需要考虑读写分离技术 (Master-Slave)和分库分表技术。常见读写分离技术架构如上图所示。 现在数据处理系统的架构变得越来越复杂了相比传统的数据库 一次数据处理的过程增加了队列、分区、复制等处理逻辑。应用程序不仅仅需要了解数据的存储位置还需要了解数据库的存储格式、数据组织结构 (schema) 等信息才能访问到正确的数据。 随着技术的不断发展商业现实也发生了变化。除了要求同一时间内可以处理的数据量提 升现代商业要求更快做出的决定更有价值。现在Kafka、Storm、Trident、Samza、Spark、 Flink 、Parquet 、Avro 、Cloud providers 等新技术成为了工程师和企业广泛采用的流行语。基于新技术不少企业开发了自己的数据处理方式现代基于Hadoop 的 Map/Reduce 管 道 ( 使 用 Kafka,Avro 和数据仓库等现代二进制格式即 Amazon Redshift,用于临时查询)采用了 如图所示。 这个方式虽然看起来有其非常好的优势但它仍然是一种传统的批处理方式具有所有已知的缺点主要原因是客户端的数据在批处理花费大量时间完成之前的数据处理时新的数据已经进入而导致数据过时。 基于传统系统出现的上述问题和无数人对于新技术的渴求与探讨“大数据”的概念被适时 的提出研究与设计大数据系统成为了新的风潮。我们要学习的大数据系统架构设计理论正是为了解决在处理海量数据时出现的种种问题并让系统在一定的度量属性下可以接受成为构造大数据系统的良好范式。 2、大数据处理系统架构分析 2.1 大数据处理系统面临挑战 当今大数据的到来已经成为现实生活中无法逃避的挑战。每当我们要做出决策的时候 大数据就无处不在。大数据术语广泛地出现也使得人们渐渐明白了它的重要性。大数据渐渐向人们展现了它为学术、工业和政府带来的巨大机遇。与此同时大数据也向参与的各方提出了巨大的挑战。那么主要挑战表现在以下三点。 1如何利用信息技术等手段处理非结构化和半结构化数据 大数据中结构化数据只占15%左右其余的85%都是非结构化的数据它们大量存在于社交网络、互联网和电子商务等领域。另一方面也许有90%的数据来自开源数据其余的被存储在数据库中。大数据的不确定性表现在高维、多变和强随机性等方面。股票交易数据流是不确定性大数据的一个典型例子。 大数据催生了大量研究问题。非结构化和半结构化数据的个体表现、 一般性特征和基本原理尚不清晰这些都需要通过包括数学、经济学、社会学、计算机科学和管理科学在内的多学科交叉来研究和讨论。给定一种半结构化或非结构化数据比如图像如何把它转换成多维数据表、面向对象的数据模型或者直接基于图像的数据模型。值得注意的是大数据每一种表示形式都仅为数据本身的一个侧面表现并非全貌。 如果把通过数据挖掘提取“粗糙知识”的过程称为“一次挖掘”过程那么将粗糙知识与被 化后主观知识包括具体的经验、常识、本能、情境知识和用户偏好相结合而产生“智能 知识”过程就叫作“二次挖掘”。从“一次挖掘”到“二次挖掘”,就类似于事物由“量”到 “质”的飞跃。 由于大数据所具有的半结构化和非结构化特点基于大数据的数据挖掘所产生的结构化的 “粗糙知识”(潜在模式)也伴有一些新的特征。这些结构化的粗糙知识可以被主观知识加工处 理并转化生成半结构化和非结构化的智能知识。寻求“智能知识”反映了大数据研究的核心 价值。 2如何探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模 这一问题的突破是实现大数据知识发现的前提和关键。从长远角度来看依照大数据的个体复杂性和随机性所带来的挑战将促使大数据数学结构的形成从而促使大数据统一理论日趋 完备。从短期而言学术界鼓励发展一种一般性的结构化数据和半结构化、非结构化数据之间 的转换原则以支持大数据的交叉工业应用。管理科学尤其是基于最优化的理论将在大数据 知识发现的一般性方法和规律性的研究中发挥重要的作用。 大数据的复杂形式导致许多对“粗糙知识”的度量和评估相关的研究问题。已知的最优 化、数据包络分析、期望理论、管理科学中的效用理论可以被应用到研究如何将主观知识 融合到数据挖掘产生的粗糙知识的“二次挖掘”过程中。这里人机交互将起到至关重要的 作用。 3数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响 由于大数据本身的复杂性这一问题无疑是一个重要的科研课题对传统的数据挖掘理论和技术提出了新的挑战。在大数据环境下管理决策面临着两个“异构性”问题“数据异构性” 和“决策异构性”。传统的管理决策模式取决于对业务知识的学习和日益积累的实践经验而管 理决策又是以数据分析为基础的。 大数据已经改变了传统的管理决策结构的模式。研究大数据对管理决策结构的影响会成为一个公开的科研问题。除此之外决策结构的变化要求人们去探讨如何为支持更高层次的决策 而去做“二次挖掘”。无论大数据带来了哪种数据异构性大数据中的“粗糙知识”仍可被看作 “一次挖掘”的范畴。通过寻找“二次挖掘”产生的“智能知识”来作为数据异构性和决策异构性 之间的桥梁是十分必要的。探索大数据环境下决策结构是如何被改变的相当于研究如何将决 策者的主观知识参与到决策的过程中。 大数据是一种具有隐藏法则的人造自然寻找大数据的科学模式将带来对研究大数据之美 的一般性方法的探究尽管这样的探索十分困难但是如果我们找到了将非结构化、半结构化 数据转换成结构化数据的方法已知的数据挖掘方法将成为大数据挖掘的工具。 2.2 大数据处理系统架构特征 Storm 之父Nathan Marz 在《大数据系统构建可扩展实时数据系统构建原理与最佳实践》 一书中提出了他认为大数据系统应该具有的属性。 1鲁棒性和容错性(Robust and Fault-tolerant ) 对大规模分布式系统来说机器是不可靠的可能会宕机但是系统需要是健壮、行为正确的即使是遇到机器错误。除了机器错误人更可能会犯错误。在软件开发中难免会有一些Bug, 系统必须对有Bug 的程序写入的错误数据有足够的适应能力所以比机器容错性更加重要的容错性是人为操作容错性。对于大规模的分布式系统来说人和机器的错误每天都可能会发生如何应对人和机器的错误让系统能够从错误中快速恢复尤其重要。 2低延迟读取和更新能力 (Low Latency Reads and Updates) 许多应用程序要求数据系统拥有几毫秒到几百毫秒的低延迟读取和更新能力。有的应用程序允许几个小时的延迟更新但是只要有低延迟读取与更新的需求系统就应该在保证鲁棒性的前提下实现。 3横向扩容 (Scalable) 当数据量/负载增大时可扩展性的系统通过增加更多的机器资源来维持性能。也就是常说的系统需要线性可扩展通常采用scale out(通过增加机器的个数)而不是 scale up (通过增 强机器的性能)。 4通用性(General) 系统需要支持绝大多数应用程序包括金融领域、社交网络、电子商务数据分析等。 5延展性(Extensible) 在新的功能需求出现时系统需要能够将新功能添加到系统中。同时系统的大规模迁移 能力是设计者需要考虑的因素之一这也是可延展性的体现。 6即席查询能力 (Allows Ad Hoc Queries) 用户在使用系统时应当可以按照自己的要求进行即席查询(Ad过系统多样化数据处理产生更高的应用价值。 7最少维护能力(Minimal Maintenance) 系统需要在大多数时间下保持平稳运行。使用机制简单的组件和算法让系统底层拥有低复 杂度是减少系统维护次数的重要途径。Marz 认为大数据系统设计不能再基于传统架构的增量 更新设计要通过减少复杂性以减少发生错误的几率、避免繁重操作。 8可调试性 (Debuggable) 系统在运行中产生的每一个值需要有可用途径进行追踪并且要能够明确这些值是如何 产生的。 3、大数据技术发展简史 3.1、大数据技术的起源大数据的三驾马车 大数据最早是起源于google。大家都知道google主要是提供网页检索服务而这项服务依赖两个能力网页的收集索引的构建。有了这两个能力我们才能通过检索服务搜索到互联网上的网页。这些网页和索引都需要大量的存储和计算能力。为了提高这两个能力谷歌发表了三篇重要的论文。 2003年分布式文件系统GFS。 2004年大数据分布式计算框架MapReduce。 2006年NoSql数据库系统BigTable。 这三篇论文奠定了大数据技术的基础也就是我们经常说的大数据得三驾马车。一个是文件系统一个是计算框架一个是数据库系统当时Google发表的论文让业界沸腾从此开启了大数据时代。在那之前大多数公司其实还是聚焦在单机上在思考如何提升单机的性能寻找更贵更好的服务器。而 Google 的思路是部署一个大规模的服务器集群通过分布式的方式将海量数据存储在这个集群上然后利用集群上的所有机器进行数据计算。 这样Google 其实不需要买很多很贵的服务器它只要把这些普通的机器组织到一起就能够进行大规模的计算了。 3.2、Hadoop的诞生分布式数据存储和计算的框架 Lucene开源项目创始人Doug Cutting正在开发开源搜索引擎Nutch阅读了Google的论文后根据论文原理实现了类似GFS和MapReduce的功能。3年后也就是2006年Doug Cutting将这些大数据相关的功能从Nutch中分离了出来然后启动了一个独立的项目专门开发和维护大数据技术这就是后来赫赫有名的Hadoop主要包括 Hadoop 分布式文件系统 HDFS 和大数据计算引擎 MapReduce。 大家看Hadoop的源码就会发现这个用纯Java实现的软件没有什么特别之处诞生它给社会带来了巨大的影响甚至带动了一场深刻的科技革命推动了人工智能的发展和进步。 Hadoop发布以后Yahoo开始使用起来2007年百度和阿里也开始使用Hadoop进行大数据存储和计算。2008年Hadoop成为Apache顶级项目。 3.3、Yahoo的Pig 2006年Yahoo觉得用MapReduce进行大数据编程太麻烦了于是开发了Pig脚本语言类似SQL语法Pig经过编译后生成MapReduce程序在Hadoop上运行大大优化了MapReduce的使用难度。 3.4、Facebook的HiveHadoop数据仓库工具 2007年编写Pig虽然比MapReduce编程简单但是还是要学习。于是Facebook发布了Hive支持使用SQL语法进行大数据计算写个Select语句进行数据查询Hive会将SQL语句转化成 MapReduce计算程序。这样熟悉数据库的数据分析师和工程师便可以无门槛地使用大数据进行数据分析和处理了Hive出现后大大降低了Hadoop的使用难度迅速得到开发者和企业的追捧。 众多Hadoop产品开始出现包括专门将关系数据库中的数据导入导出到 Hadoop 平台的 Sqoop针对大规模日志进行分布式收集、聚合和传输的 FlumeMapReduce 工作流调度引擎 Oozie 等。 Hive是基于Hadoop的一个数据仓库工具用来进行数据提取、转化、加载这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。hive数据仓库工具能将结构化的数据文件映射为一张数据库表并提供SQL查询功能能将SQL语句转变成MapReduce任务来执行。Hive的优点是学习成本低可以通过类似SQL语句实现快速MapReduce统计使MapReduce变得更加简单而不必开发专门的MapReduce应用程序。hive十分适合对数据仓库进行统计分析。 3.5、Powerset的HBASENoSQL列式数据库 2007年Powerset的工作人员通过google的论文开发出了BigTable的java版本即HBASE。2008年HBASE贡献给了Apache。 3.6、Yarn的诞生大数据资源调度框架 Hadoop 早期MapReduce 既是一个执行引擎又是一个资源调度框架服务器集群的资源调度管理由 MapReduce 自己完成。但是这样不利于资源复用也使得 MapReduce 非常臃肿。于是一个新项目启动了将 MapReduce 执行引擎和资源调度分离开来这就是 Yarn大数据资源调度框架。 3.7、Spark的诞生批处理计算引擎 2012 年UC 伯克利 AMP 实验室开发的 Spark 开始崭露头角马铁博士发现使用 MapReduce 进行机器学习计算的时候性能非常差因为机器学习算法通常需要进行很多次的迭代计算而 MapReduce 每执行一次 Map 和 Reduce 计算都需要重新启动一次作业带来大量的无谓消耗影响执行效率。 MapReduce 主要使用磁盘作为存储介质而 2012 年的时候内存已经突破容量和成本限制成为数据运行过程中主要的存储介质。Spark 一经推出立即受到业界的追捧并逐步替代MapReduce 在企业应用中的地位。 3.8、大数据批处理和流处理 1批处理大数据离线计算 像 MapReduce、Spark 这类计算框架处理的业务场景都被称作批处理计算通常按天或者固定时间段进行一次计算计算的数据是历史数据也称为大数据离线计算。 2流处理大数据实时计算 还有一种场景需要对实时产生的大量数据进行即时计算例如人脸识别这类计算称为大数据流计算对应的有Storm、Flink、Spark Streaming 等流计算框架来满足此类大数据应用的场景这类计算也称为大数据实时计算。 3.9. NoSQL NoSQL 曾经在 2011 年左右非常火爆涌现出 HBase、Cassandra 等许多优秀的产品其中 HBase 是从 Hadoop 中分离出来的、基于 HDFS 的 NoSQL 系统。 4、 OLTP和OLTP区别 1OLTP 联机事务处理 为了保证对业务的快速响应和支持针对产品和业务功能有一个直接的数据库与之进行交互。 OLTPOnLine Transaction Processsing 联机事务处理是与功能、业务强相关的事务查询系统要保证高并发场景下低时延的查询和处理效率因此对CPU的性能要求较高。直接存储与功能和业务直接相关的地方就叫数据库一般是服务端开发的同事来负责。 如上提到数据库主要为在线业务服务。如果是分析场景需要查询数据涉及到从业务数据库取数据就意味着会影响业务数据库对业务的支持。量小还好量大或者查询比较复杂服务端的同事就会担心影响到线上业务或者把业务数据库查“崩”了影响线上业务因此非常nice地拒绝你的需求。所以企业在经过初期的市场验证阶段后会开始寻求从数据中找到下一步发展的方向直接从业务数据库获取数据限制颇多因此这时候就需要搭建数据仓库体系了。 2OLAPOnLine Analytical Processing联机分析处理 数据仓库是独立于业务数据库之外的一套数据存储体系OLAPOnLine Analytical Processing联机分析处理是数据仓库系统的主要应用能够支持复杂的分析操作与数据库需要直接直接线上业务不同数据仓库侧重于分析决策提供直观的数据查询结果。当然数据仓库也是可以支持线上业务的下面会提到。 数据上报时就可以将偏分析场景的数据只往数据仓库存如用户加购行为、收藏音乐歌单行为之前存在业务数据库的一些数据也可以逐步移向数据仓库进行存储尽量让业务数据库将主要精力花在业务应用支持上而数据仓库则将精力主要投入到分析场景中为运营决策者提供快速的数据导出和查询等分析应用。 前面提到的数据仓库在一些场景下也是可以支持业务应用的比如电商场景下常见的根据用户行为做商品推荐。用户的行为数据存进数仓后进行实时计算然后将算法模型计算出的推荐结果发给业务端做展示。 3数据库和数据仓库区别 数据库是OLTP联机事务处理应用的场景其存储的主要是与业务直接相关的数据强调准确、低时延、高并发如果没有特别强调基本上数据库里只会去存储与业务相关的数据。 数据仓库OLAP联机分析处理是数据仓库系统的主要应用其支持的对象只要是面向分析场景的应用提供结构化的、主题化的数据提供给运营做业务反馈和辅助决策用同时有些场景下也可以由数据仓库对业务进行支持。 参考链接1. 什么是OLTP、OLAP、数据库和数据仓库 - 知乎
