大数据与云计算

大数据与云计算笔记

数据仓库

数据仓库：

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

数据仓库特点：

1、数据仓库是面向主题的；操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。

2、数据仓库是集成的，数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出

数据仓库的核心工具
数据仓库的核心工具
来，进行加工与集成，统一与综合之后才能进入数据仓库；
数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

3、数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及的操作主要是数据的查询；

4、数据仓库是随时间而变化的，传统的关系数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存，且不随时间改变。

5、汇总的。操作性数据映射成决策可用的格式。

6、大容量。时间序列数据集合通常都非常大。

7、非规范化的。Dw数据可以是而且经常是冗余的。

8、元数据。将描述数据的数据保存起来。

9、数据源。数据来自内部的和外部的非集成操作系统。

ETL （数据仓库技术）

ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。

数据集市

数据集市(Data Mart) ，也叫数据市场，数据集市就是满足特定的部门或者用户的需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。

从范围上来说，数据是从企业范围的数据库、数据仓库，或者是更加专业的数据仓库中抽取出来的。数据中心的重点就在于它迎合了专业用户群体的特殊需求，在分析、内容、表现，以及易用方面。数据中心的用户希望数据是由他们熟悉的术语表现的。

基本介绍

数据仓库是一个集成的、面向主题的数据集合，设计的目的是支持DSS（决策支持系统）功能。在数据仓库里，每个数据单元都与特定的时间相关。数据仓库包括原子级别的数据和轻度汇总的数据，是面向主题的、集成的、不可更新的(稳定性)、随时间不断变化（不同时间）的数据集合，用以支持经营管理中的决策制定过程。
单独的DB2数据库包括企业的数据集市。每个数据集市包括来自中央数据仓库的历史数据的子集，用以满足特定部门、团队、客户或应用程序分析和报告需求。主管此DB2数据库的系统称为数据集市服务器。尽管可以有许多数据集市，但只能有一个数据集市服务器。

数据集市组件需要IBM DB2 Universal Database Enterprise Edition，您必须在安装控制服务器前手工安装它。

IBM Tivoli Monitoringfor Transaction Performance仓库包创建结构适用于报告界面的数据集市。IBM Tivoli Monitoringfor Transaction Performance通过提供一个称为数据集市ETL的抽取、转换和装入（ETL）过程来实现此操作，该进程创建数据集市并将来自中央数据仓库的数据装入其中。

可以修改现有的数据集市或创建包含略微不同的数据的新数据集市，以迎合您所在环境下的特定报告需要。要修改或创建数据集市，必须熟悉数据库ETL过程以及数据集市在Tivoli。

那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向某个特定的主题。为了解决灵活性与性能之间的矛盾，数据集市就是数据仓库体系结构中增加的一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据，从而满足用户对性能的需求。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。

特征

1．数据集市的特征包括规模小。
2．有特定的应用。
3．面向部门。

4．由业务部门定义、设计和开发。

5．业务部门管理和维护。

6．能快速实现。

7．购买较便宜。

8．投资快速回收。

9．工具集的紧密集成。

10．提供更详细的、预先存在的、数据仓库的摘要子集。

11．可升级到完整的数据仓库。

数据结构

数据集市中数据的结构通常被描述为星型结构或雪花结构。一个星型结构包含两个基本部分——一个事实表和各种支持维表。

事实表

事实表描述数据集市中最密集的数据。在电话公司中，用于呼叫的数据是典型的最密集数据；在银行中，与账目核对和自动柜员机有关的数据是典型的最密集数据。对于零售业而言，销售和库存数据是最密集的数据等等。

事实表是预先被连接到一起的多种类型数据的组合体，它包括：一个反映事实表建立目的的实体的主键，如一张订单、一次销售、一个电话等等，主键信息，连接事实表与维表的外键，外键携带的非键值外部数据。如果这种非键外部数据经常用于事实表中的数据分析，它就会被包括在事实表的范围内。事实表是高度索引化的。事实表中出现30到40条索引非常常见。有时事实表的每列都建了索引，这样作的结果是使事实表中的数据非常容易读取。但是，导入索引所需的资源数量必须为等式提供因数。通常，事实表的数据不能更改，但可以输入数据，一旦正确输入一个记录，就不能更改此记录的任何内容了。

维表

维表是围绕着事实表建立的。维表包含非密集型数据，它通过外键与事实表相连。典型的维表建立在数据集市的基础上，包括产品目录、客户名单、厂商列表等等。

数据集市中的数据来源于企业数据仓库。所有数据，除了一个例外，在导入到数据集市之前都应该经过企业数据仓库。这个例外就是用于数据集市的特定数据，它不能用于数据仓库的其他地方。外部数据通常属于这类范畴。如果情况不是这样，数据就会用于决策支持系统的其他地方，那么这些数据就必须经过企业数据仓库。

数据集市包含两种类型的数据，通常是详细数据和汇总数据。

详细数据

就像前面描述过的一样，数据集市中的详细数据包含在星型结构中。值得一提的是，当数据通过企业数据仓库时，星型结构就会很好的汇总。在这种情况下，企业数据仓库包含必需的基本数据，而数据集市则包含更高间隔尺寸的数据。但是，在数据集市使用者的心目中，星型结构的数据和数据获取时一样详细。

​

汇总数据

数据集市包含的第二种类型数据是汇总数据。分析人员通常从星型结构中的数据创建各种汇总数据。典型的汇总可能是销售区域的月销售总额。因为汇总的基础不断发展变化，所以历史数据就在数据集市中。但是这些历史数据优势在于它存储的概括水平。星型结构中保存的历史数据非常少。

数据集市以企业数据仓库为基础进行更新。对于数据集市来说大约每周更新一次非常平常。但是，数据集市的更新时间可以少于一周也可以多于一周，这主要是由数据集市所属部门的需求来决定的 [1]

数据集市类型

独立型

独立型数据集市的数据来自于操作型数据库，是为了满足特殊用户而建立的一种分析型环境。这种数据集市的开发周期一般较短，具有灵活性，但是因为脱离了数据仓库，独立建立的数据集市可能会导致信息孤岛的存在，不能以全局的视角去分析数据。

从属型

从属型数据集市的数据来自于企业的数据仓库，这样会导致开发周期的延长，但是从属型数据集市在体系结构上比独立型数据集市更稳定，可以提高数据分析的质量，保证数据的一致性 。

专业产品

国外知名的Garnter关于数据集市产品报告中，位于第一象限的敏捷商业智能产品有QlikView, Tableau和SpotView，都是全内存计算的数据集市产品，在大数据方面对传统商业智能产品巨头形成了挑战。国内BI产品起步较晚，知名的敏捷型商业智能产品有PowerBI, 永洪科技的Z-Suite，SmartBI等，其中永洪科技的Z-Data Mart是一款热内存计算的数据集市产品。国内的德昂信息也是一家数据集市产品的系统集成商 。

Yonghong Data Mart是永洪科技基于自有技术研发的一款数据存储、数据处理的软件。

Yonghong Data Mart底层技术：

  1. 分布式计算
  2. 分布式通信
  3. 内存计算
  4. 列存储
  5. 库内计算

“独立”性

企业规划数据仓库项目的时候，往往会遇到很多数据仓库软件供应商。各供应商除了推销相关的软件工具外， 同时也会向企业灌输许多概念。其中，数据仓库和数据集市是最常见的两个术语了。各个供应商术语定义不统一、销售策略不一样，这往往会给企业带来很大的混淆。最典型的问题是：到底是先上一个企业级的数据仓库呢？还是先上一个部门级的数据集市？这其实是是否要上独立型数据集市的问题。

数据集市可以分为两种类型——独立型数据集市和从属型数据集市。独立型数据集市直接从操作型环境获取数据，从属型数据集市从企业级数据仓库获取数据，带有从属型数据集市的体系结构。

数据仓库规模大、周期长，一些规模比较小的企业用户难以承担。因此，作为快速解决企业当前存在的实际问题的一种有效方法，独立型数据集市成为一种既成事实。独立型数据集市是为满足特定用户（一般是部门级别的）的需求而建立的一种分析型环境，它能够快速地解决某些具体的问题，而且投资规模也比数据仓库小很多。

独立型数据集市的存在会给人造成一种错觉，似乎可以先独立地构建数据集市，当数据集市达到一定的规模再直接转换为数据仓库。有些销售人员会推销这种观点，其实质却常常是因为建立企业级数据仓库的销售周期太长以至于不好操作。

多个独立的数据集市的累积，是不能形成一个企业级的数据仓库的，这是由数据仓库和数据集市本身的特点决定的—数据集市为各个部门或工作组所用，各个集市之间存在不一致性是难免的。因为脱离数据仓库的缘故，当多个独立型数据集市增长到一定规模之后，由于没有统一的数据仓库协调，企业只会又增加一些信息孤 岛，仍然不能以整个企业的视图分析数据。借用Inmon的比喻：人们不可能将大海里的小鱼堆在一起就构成一头大鲸鱼，这也说明了数据仓库和数据集市有本质的不同。

如果企业最终想建设一个全企业统一的数据仓库，想要以整个企业的视图分析数据，独立型数据集市恐怕不是合适的选择；也就是说“先独立地构建数据集市，当数据集市达到一定的规模再直接转换为数据仓库”是不合适的。从长远的角度看，从属型数据集市在体系结构上比独立型数据集市更稳定，可以说是数据集市未来建设的主要方向。

区别数据仓库

在数据结构上，数据仓库是面向主题的、集成的数据的集合。而数据集市通常被定义为星型结构或者雪花型数据结构，数据集市一般是由一张事实表和几张维表组成的。

目标分析

数据集市主要是针对一组特定的某个主题域、部门或者特殊用户需求的数据集合。这些数据需要针对用户的快速访问和报表展示进行优化，优化的方式包括对数据进行轻量级汇总，在数据结构的基础上创建索引。数据集市的目标分析过程包括对数据集市的需求进行拆分，按照不同的业务规则进行组织，将与业务主题相关的实体组织成主题域，并且对各类指标进行维度分析，从而形成数据集市目标说明书。内容包括详细的业务主题、业务主题域和各项指标及其分析维度。

常见问题

建立不同规格的数据仓库、数据集市的成本，国外的咨询机构有专门的评估，在一定程度上可以借鉴。但是这些结果在国内也许并不适用，因为国情不同，在国内的构建成本需要专门的调研。以人们为企业构建的客户主题数据集市为例，一般成本在20万元到50万元人民币之间。数据集市的设计可以采用迭代式的方法。在迭代式开发中，每个迭代为上一次的结果增加了新的功能。功能增加的顺序要考虑到迭代平衡以及尽早发现重大风险。通俗地说，就是在正式交货之前多次给客户交付不完善的中间产品“试用”。这些中间产品会有一些功能还没有添加进去、还不稳定，但是客户提出修改意见以后，开发人员能够更好地理解客户的需求。如此反复，使得产品在质量上能够逐渐逼近客户的要求。这种开发方法周期长、成本高，但是它能够避免整个项目推倒重来的风险，比较适合大项目、高风险项目。
理论上讲，应该有一个总的数据仓库的概念，然后才有数据集市。实际建设数据集市的时候，国内很少这么做。国内一般会先从数据集市入手，就某一个特定的主题（比如企业的客户信息）先做数据集市，再建设数据仓库。数据仓库和数据集市建立的先后次序之分，是和设计方法紧密相关的。而数据仓库作为工程学科，并没有对错之分。

主要意义

快速发展的、充满竞争的商业世界对于及时、准确的信息有着永无止境的需求，一些IT专家对此认为其必然结果就是创建数据集市。其他专家却质疑用户和客户所要付出的工作和成本。毕竟，难道不能直接从遗留系统和在线事务处理（On Line Transaction Processing，OLTP）系统通过特定的报表获得相同的信息吗?在EDS 的商业智能小组里，人们就经常被问到这一问题。经验让人们有许多机会使人们的同行和客户了解这项有用技术的价值。
那么，一个组织为何要构建数据集市呢?虽然OLTP和遗留系统拥有宝贵的信息，但是可能难以从这些系统中提取有意义的信息并且速度也较慢。而且这些系统虽然一般可支持预先定义操作的报表，但却经常无法支持一个组织对于历史的、联合的、“智能的”或易于访问的信息的需求。因为数据分布在许多跨系统和平台的表中，而且通常是“脏的”，包含了不一致的和无效的值，使得难于分析。数据集市将合并不同系统的数据源来满足业务信息需求。

若能有效地得以实现，数据集市将可以快速且方便地访问简单信息以及系统的和历史的视图。一个设计良好的数据集市将会：发布特定用户群体所需的信息，且无需受制于源系统的大量需求和操作性危机。支持访问非易变（nonvolatile）的业务信息。（非易变的信息是以预定的时间间隔进行更新的，并且不受OLTP系统进行中的更新的影响）。调和来自于组织里多个运行系统的信息，比如账目、销售、库存和客户管理以及组织外部的行业数据。通过默认有效值、使各系统的值保持一致以及添加描述以使隐含代码有意义，从而提供净化的（cleansed）数据。为即席分析和预定义报表提供合理的查询响应时间（不同于OLTP系统中所需的调优需求）。通过提供对于遗留系统和OLTP应用程序的选择来减少对这些应用程序的要求，以获得更多所需信息 [4] 。

案例分析

通过吉林市等城市的成功试点，中国移动已经决定将数据集市作为2006年移动地市级公司的建设重点之一。这也同时意味着，电信行业建立在数据仓库基础上的BI应用已经进入到更加深入挖掘的阶段，其产生的结果将直接服务于一线的生产销售 ……

数据集市：深化挖掘第一步

电信行业对于数据仓库并不陌生，为了实现从产品导向往客户导向的转变，电信公司纷纷建立以客户为中心的数据仓库，希望依据客户的需要、期望及喜好来制订策略，提升企业竞争力。简单说，数据仓库就是为了保证数据查询和分析的效率，按照主题将所有的数据分门别类进行存储，需要的时候，可以按主题提取数据并做进一步的分析处理。

数据集市，可以称作"小数据仓库"，是用来分析相关专门业务问题或功能目标而做的专项的数据集合。它建立在具有统一数据存储模型的数据仓库下，各级业务人员按照各部门特定的需求把数据进行复制、处理、加工，并最终统一展现为有部门特点的数据集合，数据集市的应用是对数据仓库应用的补充。

经过近几年的努力，吉林移动通信有限责任公司已经成功在省级公司建立起了面向决策支持的经营分析系统，BI系统也逐渐完善。省级公司从业务系统中将相关业务数据进行抽取、清洗、加工、整理、加载到数据仓库中，在数据仓库中形成基础的分析数据的存储，对地市一级公司的营销策略进行指导。

问题也随之产生，由于下属分公司在客户群体、市场容量、利润来源等地域差异明显，省级公司通过全省范围内分公司数据的汇总和分析，难以对单个地市级分公司产生个性化决策支持。另一方面，地市一级的分公司在开拓终端市场的过程中，激发了旺盛的应用需求，具体表现为对数据粒度的要求更加精细、需求更加灵活多变、要求更强的可操作性。

2005年6月，中国移动通信有限公司制定了《中国移动经营分析系统数据集市（试点）业务技术建议书》。为了使经营分析系统在地市级公司日常生产经营中发挥更大作用，吉林移动最终决定与亚信科技合作，全面进行"数据集市"的搭建。吉林省吉林市成为12个试点中第一个"吃螃蟹"的城市。

吉林移动希望通过数据集市的建设及时准确地了解掌握地市公司的分析需求，更好地为一线地市公司的生产营销服务。吉林市分公司也希望提升自身的经营分析水平，落实集团公司的精细化营销战略。

在总体设计方面，吉林移动希望通过吉林市的试点为吉林省其它分公司建设统一的数据集市的模型，基本涵盖地市固定统计报表及分析的需求，统一建模，统一管理。在功能上，为地市分公司的市场营销行为提供客户个体分析，提高经营分析结果的可实施能力，支持精细化营销，支持地市开发过灵活专题分析。开发标准化、开放的数据平台，满足省内不同地市分公司更多个性化的、临时性的分析需求。

总体来说，吉林移动对亚信科技提出了很实际的业务描述，就是"以提供丰富的数据为基础，以提供简要分析功能、提高日常分析能力为主要手段，以解决各类业务目标为最终目的，大力提升地市公司数据综合运用、分析能力，大力提升分公司主动服务、主动营销效能"。

数据集市项目从2005年6月开始组织需求调研，经历了5个月的建设时间，于2005年11月底上线使用，完成了中国移动集团公司试点所要求完成的所有基本集功能以及符合吉林本地特色的扩展集的内容。

作为实施方，亚信科技在吉林数据集市建设过程中遵循了"平台标准化、业务个性化"的原则。亚信一方面在数据集市基础平台采用标准的系统软件，使数据集市的逻辑数据模型统一、标准；另一方面，在地市分公司开发应用功能时，结合本地的实际情况，体现了本地的需求特色。在项目建设期间，吉林移动曾两次就该项目建设的方法与思路向中国移动集团公司领导汇报，亚信的建设思路及建设成果得到了移动总公司的高度认可。

随着吉林移动、云南移动等公司"数据集市"项目的成功试点，中国移动31个省的上百家地市级公司将纷纷上马数据集市项目。可以预见，2006年将是移动公司进一步深入挖掘BI应用，提升BI建设水平的一年，数据集市作为专项的数据集合与分析系统，对中国移动地市级分公司的日常经营管理将产生至关重要的作用，成为中国移动落实精细化经营策略的重点工程。

商业智能(BI)

商业智能（BI）的实质是从数据中有效地提取信息，从信息中及时的发现知识，从而为决策提供支持的一种技术。

商业智能有以下三个主要优点：

商务智能系统不仅采用了最新的信息技术，而且提供了预先打包好的应用领域的解决方案。

商务智能系统着眼于终端用户对业务数据的访问和业务数据的传送，它可同时服务于信息提供者和信息消费者。

商务智能系统支持对所有形式的信息的访问，而不仅仅是那些存储在数据仓库中的信息。

OLTP

On-Line Transaction Processing联机事务处理过程(OLTP)，也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。

OLTP定义

联机事务处理系统是一种以事务元作为数据处理的单位、人机交互的计算机应用系统。它能对数据进行即时更新或其他操作，系统内的数据总是保持在最新状态。用户可将一组保持数据一致性的操作序列指定为一个事务元，通过终端、个人计算机或其他设备输入事务元，经系统处理后返回结果，应用于飞机订票、银行出纳、股票交易、超市销售、饭店前后管理等。

这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(Real time System)。衡量联机事务处理结果的一个重要指标是系统性能，具体体现为实时请求-响应时间(Response Time)，即用户在终端上输入数据之后，到计算机对这个请求给出答复所需要的时间。OLTP是由前台、应用、数据库共同完成的，处理快慢以及处理程度取决于数据库引擎、服务器、应用引擎。

OLTP数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。

OLTP特征

  • 支持大量并发用户定期添加和修改数据。

  • 反映随时变化的单位状态，但不保存其历史记录。

  • 包含大量数据，其中包括用于验证事务的大量数据。

  • 可以进行优化以对事务活动做出响应。

  • 提供用于支持单位日常运营的技术基础结构。

  • 个别事务能够很快地完成，并且只需访问相对较少的数据。

  • 实时性要求高。

  • 交易一般是确定的，所以OLTP是对确定性的数据进行存取。(比如存取款都有一个特定的金额)

  • 并发性要求高并且严格的要求事务的完整、安全性。(比如这种情况：有可能你和你的家人同时在不同的银行取同一个帐号的款)。

应用领域

OLTP 系统中的数据主要被组织为支持如下事务：

  1. 记录来自销售点终端或通过网站输入的订单。

  2. 当库存量降到指定级别时，订购更多的货物。

  3. 在制造厂中将零部件组装为成品时对零部件进行跟踪。

  4. 记录雇员数据。

当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLAP

联机分析处理OLAP是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多维信息的快速分析的特征。其中F是快速性(Fast)，指系统能在数秒内对用户的多数分析要求做出反应；A是可分析性(Analysis)，指用户无需编程就可以定义新的专门计算，将其作为分析的一部 分，并以用户所希望的方式给出报告；M是多维性(Multi—dimensional)，指提供对数据分析的多维视图和分析；I是信息性(Information)，指能及时获得信息，并且管理大容量信息。

发展背景

自20世纪80年代开始，许多企业利用关系型数据库来存储和管理业务数据，并建立相应的应用系统来支持日常的业务运作。这种应用以支持业务处理为主要目的，被称为联机事务处理(On line Transaction Processing，OLTP)应用，它所存储的数据被称为操作数据或者业务数据。

随着数据库技术的广泛应用，企业信息系统产生了大量的业务数据，如何从这些海量的业务数据中提取出对企业决策分析有用的信息，这成为企业决策管理人员所面临的重要难题。因此，人们逐渐尝试对OLTP数据库中的数据进行再加工，以形成一个综合的、面服务对象、访问方式、事务管理乃至物理存储等方面都有不同的特点和要求，因此，直接在操作型数据库上建立决策支持系统是不合适的。数据仓库技术就是在这样的背景下发展起来的。

随着市场竞争的日趋激烈，企业更加强调决策的及时性和准确性，这使得以支持决策管理分析为主要目的的应用迅速崛起，这类应用被称为联机分析处理，它所存储的数据被称为信息数据。

联机分析处理的概念最早由关系数据库之父E．F．Codd于1993年提出。Codd认为，联机事务处理已不能满足终端用户对数据库查询分析的要求，SQL对大容量数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量的计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，Codd提出了多维数据库和多维分析的概念，即OLAP。OLAP委员会对联机分析处理的定义为：使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互的存取，从而获得对数据更深入了解的一类软件技术。

逻辑概念

联机分析处理
OLAP展现在用户面前的是一幅幅多维视图。维（Dimension）：是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维（时间维、地理维等）。
维的层次（Level）：人们观察数据的某个特定角度（即某个维）还可以存在细节程度不同的各个描述方面（时间维：日期、月份、季度、年）。

维的成员（Member）：维的一个取值，是数据项在某维中位置的描述。（“某年某月某日”是在时间维上位置的描述）。

度量（Measure）：多维数组的取值。（2000年1月，上海，笔记本电脑，0000）。

OLAP的基本多维分析操作有钻取（Drill-up和Drill-down）、切片（Slice）和切块（Dice）、以及旋转（Pivot）等。

钻取：是改变维的层次，变换分析的粒度。它包括向下钻取（Drill-down）和向上钻取（Drill-up）/上卷(Roll-up)。Drill-up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；而Drill-down则相反，它从汇总数据深入到细节数据进行观察或增加新维。

切片和切块：是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片；如果有三个或以上，则是切块。

旋转：是变换维的方向，即在表格中重新安排维的放置（例如行列互换）。

体系结构

数据仓库与OLAP的关系是互补的，现代OLAP系统一般以数据仓库作为基础，即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取。

OLAP系统按照其存储器的数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型。

​

ROLAP

ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。

​

MOLAP

MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构，从物理层实现起，因此又称为物理OLAP（PhysicalOLAP）；而ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（VirtualOLAP）。

​

HOLAP

由于MOLAP和ROLAP有着各自的优点和缺点（如下表所示）,且它们的结构迥然不同，这给分析人员设计OLAP结构提出了难题。为此一个新的OLAP结构——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止，对HOLAP还没有一个正式的定义。但很明显，HOLAP结构不应该是MOLAP与ROLAP结构的简单组合，而是这两种结构技术优点的有机结合，能满足用户各种复杂的分析请求。

功能

基本功能

(1)切片和切块(Slice and Dice)

切片和切块是在维上做投影操作。

切片就是在多维数据上选定一个二维子集的操作，即在某两个维上取一定区间的维成员或全部维成员，而在其余的维上选定一个维成员的操作。

维是观察数据的角度，那么切片的作用或结果就是舍弃一些观察角度，使人们能在两个维上集中观察数据。因为人的空间想象能力毕竟有限，一般很难想象四维以上的空间结构，所以对于维数较多的多维数据空间，数据切片是十分有意义的．

(2)钻取(Drill)

钻取有向下钻取(Drill Down)和向上钻取(Drill up)操作。向下钻取是使用户在多层数据中展现渐增的细节层次，获得更多的细节性数据。向上钻取以渐增概括方式汇总数据(例如，从周到季度，再到年度)。

(3)旋转(Pivoting)

通过旋转可以得到不同视角的数据。旋转操作相当于在平面内将坐标轴旋转。例如，旋转可能包含了交换行和列，或是把某一个行维移到列维中去，或是把页面显示中的一个维和页面外的维进行交换(令其成为新的行或列中的一个)。

​

广义功能

从广义上讲，任何能够有助于辅助用户理解数据的技术或者操作都可以作为OLAP功能，这些有别于基本OLAP的功能被称为广义OLAP功能。

(1)基本代理操作

“代理”是一些智能性代理，当系统处于某种特殊状态时提醒分析员。

①示警报告：定义一些条件，一旦条件满足，系统会提醒分析员去做分析。如每日报告完成或月订货完成等通知分析员作分析。

②时间报告：按日历和时钟提醒分析员。

③异常报告：当超出边界条件时提醒分析员。如销售情况已超出预定义阈值的上限或下限时提醒分析员。

(2)计算能力

计算引擎用于特定需求的计算或某种复杂计算。

(3)模型计算

增加模型，如增加系统优化、统计分析、趋势分析等模型，以提高决策分析能力。

特点

联机分析处理的主要特点，是直接仿照用户的多角度思考模式，预先为用户组建多维的数据模型，在这里，维指的是用户的分析角度。例如对销售数据的分析，时间周期是一个维度，产品类别、分销渠道、地理分布、客户群类也分别是一个维度。一旦多维数据模型建立完成，用户可以快速地从各个分析角度获取数据，也能动态的在各个角度之间切换或者进行多角度综合分析，具有极大的分析灵活性。这也是联机分析处理被广泛关注的根本原因，它从设计理念和真正实现上都与旧有的管理信息系统有着本质的区别。

事实上，随着数据仓库理论的发展，数据仓库系统已逐步成为新型的决策管理信息系统的解决方案。数据仓库系统的核心是联机分析处理，但数据仓库包括更为广泛的内容。

概括来说，数据仓库系统是指具有综合企业数据的能力，能够对大量企业数据进行快速和准确分析，辅助做出更好的商业决策的系统。它本身包括三部分内容：

1、数据层：实现对企业操作数据的抽取、转换、清洗和汇总，形成信息数据，并存储在企业级的中心信息数据库中。

2、应用层：通过联机分析处理，甚至是数据挖掘等应用处理，实现对信息数据的分析。

3、表现层：通过前台分析工具，将查询报表、统计分析、多维联机分析和数据发掘的结论展现在用户面前。

从应用角度来说，数据仓库系统除了联机分析处理外，还可以采用传统的报表，或者采用数理统计和人工智能等数据挖掘手段，涵盖的范围更广；就应用范围而言，联机分析处理往往根据用户分析的主题进行应用分割，例如：销售分析、市场推广分析、客户利润率分析等等，每一个分析的主题形成一个OLAP应用，而所有的OLAP应用实际上只是数据仓库系统的一部分

Hive （数据仓库工具）

hive是基于Hadoop的一个数据仓库工具，用来进行数据提取、转化、加载，这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。hive数据仓库工具能将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，能将SQL语句转变成MapReduce任务来执行。Hive的优点是学习成本低，可以通过类似SQL语句实现快速MapReduce统计，使MapReduce变得更加简单，而不必开发专门的MapReduce应用程序。hive十分适合对数据仓库进行统计分析。

简介

hive是基于Hadoop构建的一套数据仓库分析系统，它提供了丰富的SQL查询方式来分析存储在Hadoop分布式文件系统中的数据：可以将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能；可以将SQL语句转换为MapReduce任务运行，通过自己的SQL查询分析需要的内容，这套SQL简称Hive SQL，使不熟悉mapreduce的用户可以很方便地利用SQL语言查询、汇总和分析数据。而mapreduce开发人员可以把自己写的mapper和reducer作为插件来支持hive做更复杂的数据分析。它与关系型数据库的SQL略有不同，但支持了绝大多数的语句如DDL、DML以及常见的聚合函数、连接查询、条件查询。它还提供了一系列的1：具进行数据提取转化加载，用来存储、查询和分析存储在Hadoop中的大规模数据集，并支持UDF（User-Defined Function）、UDAF(User-Defnes AggregateFunction)和UDTF（User-Defined Table-Generating Function），也可以实现对map和reduce函数的定制，为数据操作提供了良好的伸缩性和可扩展性。

hive不适合用于联机(online)事务处理，也不提供实时查询功能。它最适合应用在基于大量不可变数据的批处理作业。hive的特点包括：可伸缩（在Hadoop的集群上动态添加设备）、可扩展、容错、输入格式的松散耦合

适用场景

hive 构建在基于静态批处理的Hadoop 之上，Hadoop 通常都有较高的延迟并且在作业提交和调度的时候需要大量的开销。因此，hive 并不能够在大规模数据集上实现低延迟快速的查询，例如，hive 在几百MB 的数据集上执行查询一般有分钟级的时间延迟。

因此，hive 并不适合那些需要高实时性的应用，例如，联机事务处理（OLTP）。hive 查询操作过程严格遵守Hadoop MapReduce 的作业执行模型，hive 将用户的hiveQL 语句通过解释器转换为MapReduce 作业提交到Hadoop 集群上，Hadoop 监控作业执行过程，然后返回作业执行结果给用户。hive 并非为联机事务处理而设计，hive 并不提供实时的查询和基于行级的数据更新操作。hive 的最佳使用场合是大数据集的批处理作业，例如，网络日志分析。

设计特征

hive 是一种底层封装了Hadoop 的数据仓库处理工具，使用类SQL 的hiveSQL 语言实现数据查询，所有hive 的数据都存储在Hadoop 兼容的文件系统（例如，Amazon S3、HDFS）中。hive 在加载数据过程中不会对数据进行任何的修改，只是将数据移动到HDFS 中hive 设定的目录下，因此，hive 不支持对数据的改写和添加，所有的数据都是在加载的时候确定的。hive 的设计特点如下。

● 支持创建索引，优化数据查询。

● 不同的存储类型，例如，纯文本文件、HBase 中的文件。

● 将元数据保存在关系数据库中，大大减少了在查询过程中执行语义检查的时间。

● 可以直接使用存储在Hadoop 文件系统中的数据。

● 内置大量用户函数UDF 来操作时间、字符串和其他的数据挖掘工具，支持用户扩展UDF 函数来完成内置函数无法实现的操作。

● 类SQL 的查询方式，将SQL 查询转换为MapReduce 的job 在Hadoop集群上执行。

体系结构

主要分为以下几个部分：

​

用户接口

用户接口主要有三个：CLI，Client 和 WUI。其中最常用的是 Cli，Cli 启动的时候，会同时启动一个 hive 副本。Client 是 hive 的客户端，用户连接至 hive Server。在启动 Client 模式的时候，需要指出 hive Server 所在节点，并且在该节点启动 hive Server。 WUI 是通过浏览器访问 hive。

​

元数据存储

hive 将元数据存储在数据库中，如 mysql、derby。hive 中的元数据包括表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在目录等。

​

解释器、编译器、优化器、执行器

解释器、编译器、优化器完成 HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在 HDFS 中，并在随后由 MapReduce 调用执行。

​

Hadoop

hive 的数据存储在 HDFS 中，大部分的查询由 MapReduce 完成（不包含 * 的查询，比如 select * from tbl 不会生成 MapReduce 任务）。

数据存储模型

hive中包含以下四类数据模型：表(Table)、外部表(External Table)、分区(Partition)、桶(Bucket)。

(1) hive中的Table和数据库中的Table在概念上是类似的。在hive中每一个Table都有一个相应的目录存储数据。

(2)外部表是一个已经存储在HDFS中，并具有一定格式的数据。使用外部表意味着hive表内的数据不在hive的数据仓库内，它会到仓库目录以外的位置访问数据。

外部表和普通表的操作不同，创建普通表的操作分为两个步骤，即表的创建步骤和数据装入步骤（可以分开也可以同时完成）。在数据的装入过程中，实际数据会移动到数据表所在的hive数据仓库文件目录中，其后对该数据表的访问将直接访问装入所对应文件目录中的数据。删除表时，该表的元数据和在数据仓库目录下的实际数据将同时删除。

外部表的创建只有一个步骤，创建表和装入数据同时完成。外部表的实际数据存储在创建语句。LOCATION参数指定的外部HDFS文件路径中，但这个数据并不会移动到hive数据仓库的文件目录中。删除外部表时，仅删除其元数据，保存在外部HDFS文件目录中的数据不会被删除。

(3)分区对应于数据库中的分区列的密集索引，但是hive中分区的组织方式和数据库中的很不相同。在hive中，表中的一个分区对应于表下的一个目录，所有的分区的数据都存储在对应的目录中。

(4)桶对指定列进行哈希(hash)计算，会根据哈希值切分数据，目的是为了并行，每一个桶对应一个文件

NoSQL

NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在处理web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，出现了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，特别是大数据应用难题。

基本含义

NoSQL最常见的解释是“non-relational”， “Not Only SQL”也被很多人接受。NoSQL仅仅是一个概念，泛指非关系型的数据库，区别于关系数据库，它们不保证关系数据的ACID特性。NoSQL是一项全新的数据库革命性运动，其拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

NoSQL有如下优点：易扩展，NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。无形之间也在架构的层面上带来了可扩展的能力。大数据量，高性能，NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。

分类

键值(Key-Value)存储数据库

这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果数据库管理员(DBA)只对部分值进行查询或更新的时候，Key/value就显得效率低下了。举例如：Tokyo Cabinet/Tyrant， Redis， Voldemort， Oracle BDB。

​

列存储数据库

这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra， HBase， Riak.

​

文档型数据库

文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值，在处理网页等复杂数据时，文档型数据库比传统键值数据库的查询效率更高。如：CouchDB， MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。

​

图形(Graph)数据库

图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如：Neo4J， InfoGrid， Infinite Graph。

不同分类特点对比

分类Examples举例典型应用场景数据模型优点缺点
键值（key-value）Tokyo Cabinet/Tyrant， Redis， Voldemort， Oracle BDB内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。Key 指向 Value 的键值对，通常用hash table来实现查找速度快数据无结构化，通常只被当作字符串或者二进制数据
列存储数据库Cassandra， HBase， Riak分布式的文件系统以列簇式存储，将同一列数据存在一起查找速度快，可扩展性强，更容易进行分布式扩展功能相对局限
文档型数据库CouchDB， MongoDbWeb应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）Key-Value对应的键值对，Value为结构化数据数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构查询性能不高，而且缺乏统一的查询语法。
图形(Graph)数据库Neo4J， InfoGrid， Infinite Graph社交网络，推荐系统等。专注于构建关系图谱图结构利用图结构相关算法。比如最短路径寻址，N度关系查找等很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。

特点

对于NoSQL并没有一个明确的范围和定义，但是他们都普遍存在下面一些共同特征：

​

易扩展

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。无形之间，在架构的层面上带来了可扩展的能力。

​

大数据量，高性能

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache。NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说性能就要高很多。

​

灵活的数据模型

NoSQL无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是——个噩梦。这点在大数据量的Web 2.0时代尤其明显。

高可用

NoSQL在不太影响性能的情况，就可以方便地实现高可用的架构。比如Cassandra、HBase模型，通过复制模型也能实现高可用。

体系框架

NoSQL框架体系NosoL整体框架分为四层，由下至上分为数据持久层(data persistence)、整体分布层(data distribution model)、数据逻辑模型层(data logical model)、和接口层(interface)，层次之间相辅相成，协调工作。

数据持久层定义了数据的存储形式，主要包括基于内存、基于硬盘、内存和硬盘接口、订制可拔插四种形式。基于内存形式的数据存取速度最快，但可能会造成数据丢失。基于硬盘的数据存储可能保存很久，但存取速度较基于内存形式的慢。内存和硬盘相结合的形式，结合了前两种形式的优点，既保证了速度，又保证了数据不丢失。订制可拔插则保证了数据存取具有较高的灵活性。

数据分布层定义了数据是如何分布的，相对于关系型数据库，NoSQL可选的机制比较多，主要有三种形式：一是CAP支持，可用于水平扩展。二是多数据中心支持，可以保证在横跨多数据中心是也能够平稳运行。三是动态部署支持，可以在运行着的集群中动态地添加或删除节点。

数据逻辑层表述了数据的逻辑表现形式，与关系型数据库相比，NoSQL在逻辑表现形式上相当灵活，主要有四种形式：一是键值模型，这种模型在表现形式上比较单一，但却有很强的扩展性。二是列式模型，这种模型相比于键值模型能够支持较为复杂的数据，但扩展性相对较差。三是文档模型，这种模型对于复杂数据的支持和扩展性都有很大优势。四是图模型，这种模型的使用场景不多，通常是基于图数据结构的数据定制的。

接口层为上层应用提供了方便的数据调用接口，提供的选择远多于关系型数据库。接口层提供了五种选择：Rest，Thrift，Map/Reduce，Get/Put，特定语言API，使得应用程序和数据库的交互更加方便。

NoSQL分层架构并不代表每个产品在每一层只有一种选择。相反，这种分层设计提供了很大的灵活性和兼容性，每种数据库在不同层面可以支持多种特性。

适用场景

NoSQL数据库在以下的这几种情况下比较适用：

1、数据模型比较简单；

2、需要灵活性更强的IT系统；

3、对数据库性能要求较高；

4、不需要高度的数据一致性；

5、对于给定key，比较容易映射复杂值的环境。

开源的NoSQL数据库软件

Membase

Membase是NoSQL家族的一个新的重量级成员。Membase是开源项目，源代码采用了Apache2.0的使用许可。该项目托管在GitHub.Source tarballs上，可以下载Beta版本的Linux二进制包。该产品主要是由North Scale的Memcached核心团队成员开发完成的，其中还包括Zynga和NHN这两个主要贡献者，这两个组织都是很大的在线游戏和社区网络空间供应商。

Membase容易安装、操作，可以从单节点方便地扩展到集群，而且为Memcached（有线协议的兼容性）实现了即插即用功能，在应用方面为开发者和经营者提供了一个较低的门槛。作为缓存解决方案，Memcached已经在不同类型的领域（特别是大容量的Web应用）有了广泛的使用，其中Memcached的部分基础代码被直接应用到了Membase服务器的前端。

通过兼容多种编程语言和框架，Membase具备了很好的复用性。在安装和配置方面，Membase提供了有效的图形化界面和编程接口，包括可配置的报警信息。

Membase的目标是提供对外的线性扩展能力，包括为了增加集群容量，可以针对统一的节点进行复制。另外，对存储的数据进行再分配仍然是必要的。

这方面的一个有趣特征是，NoSQL解决方案所承诺的可预测性能，通过如下方式可以获得：

1)自动将在线数据迁移到低延迟的存储介质的技术（内存，固态硬盘，磁盘）。

2)可选的写操作——异步、同步（基于复制，持久化）。

3)反向通道再平衡。

4)多线程低锁争用。

5)尽可能使用异步处理。

6)自动实现重复数据删除。

7)动态再平衡现有集群。

8)通过把数据复制到多个集群单元和支持快速失败转移来提供系统的高可用性。

​

MongoDB

MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似Json的Bjson格式，因此可以存储比较复杂的数据类型。MongoDB最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，还支持为数据建立索引。它的特点是高性能、易部署、易使用、存储数据非常方便。

主要功能特性：

1)面向集合存储，易存储对象类型的数据。

“面向集合”( Collenction-oriented)，意思是数据被分组，存储在数据集中，被称为一个集合。每个集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库里的表，不同的是它不需要定义任何模式( Schema)。

2)模式自由。

模式自由，意味着对于存储在Mongodb数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。

NewSQL

NewSQL 是对各种新的可扩展/高性能数据库的简称，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。

NewSQL是指这样一类新式的关系型数据库管理系统，针对OLTP（读-写）工作负载，追求提供和NoSQL系统相同的扩展性能，且仍然保持ACID和SQL等特性（scalable and ACID and (relational and/or sql -access)）。

历史

​

NewSQL一词的提出

NewSQL一词是由451 Group的分析师Matthew Aslett在研究论文中提出的。它代指对老牌数据库厂商做出挑战的一类新型数据库系统。

发展趋势

NoSQL谢幕，NewSQL登场

NoSQL将改变数据的定义范围。它不再是原始的数据类型，如整数、浮点。数据可能是整个文件。NoSQL可能会吓到DBA，因为他们担心失去他们自己的领域。

NoSQL数据库是非关系的、水平可扩展、分布式并且是开源的。MongoDB的创始人Dwight Merriman表示NoSQL可作为一个Web应用服务器、内容管理器、结构化的事件日志、移动应用程序的服务器端和文件存储的后备存储。

分布式数据库公司VoltDB的首席技术官Michael Stonebraker表示NoSQL数据库可提供良好的扩展性和灵活性，但他们也有自己的不足。由于不使用SQL，NoSQL数据库系统不具备高度结构化查询等特性。NoSQL其他的问题还包括不能提供ACID（原子性、一致性、隔离性和持久性）的操作。另外不同的NoSQL数据库都有自己的查询语言，这使得很难规范应用程序接口。Stonebraker表示数据库系统的滞后通常可归结于多项因素。诸如以恢复日志为目的的数据库系统维持的缓冲区池，以及管理锁定和锁定的数据字段。在VoltDB的测试中发现以上这些行为消耗系统96%的资源。

​

现有NewSQL系统厂商举例

包括(顺序随机)Clustrix、GenieDB、ScalArc、Schooner、VoltDB、RethinkDB、ScaleDB、Akiban、CodeFutures、ScaleBase、Translattice和NimbusDB，以及 Drizzle、带有 NDB的 MySQL 集群和带有HandlerSocket的MySQL。后者包括Tokutek和JustOne DB。相关的“NewSQL作为一种服务”类别包括亚马逊关系数据库服务，微软SQLAzure，Xeround和FathomDB。

系统分类

NewSQL系统虽然在的内部结构变化很大，但是它们有两个显着的共同特点：(1)它们都支持关系数据模型，(2) 它们都使用SQL作为其主要的接口。已知的第一个NewSQL系统叫做H-Store，它是一个分布式并行内存数据库系统。目前NewSQL系统大致分三类：

新架构

第一类型的NewSQL系统是全新的数据库平台，它们均采取了不同的设计方法。它们大概分两类：

(1) 这类数据库工作在一个分布式集群的节点上，其中每个节点拥有一个数据子集。 SQL查询被分成查询片段发送给自己所在的数据的节点上执行。这些数据库可以通过添加额外的节点来线性扩展。现有的这类数据库有： Google Spanner, VoltDB, Clustrix, NuoDB.

(2) 这些数据库系统通常有一个单一的主节点的数据源。它们有一组节点用来做事务处理，这些节点接到特定的SQL查询后，会把它所需的所有数据从主节点上取回来后执行SQL查询，再返回结果。

SQL引擎

第二类是高度优化的SQL存储引擎。这些系统提供了MySQL相同的编程接口，但扩展性比内置的引擎InnoDB更好。这类数据库系统有：TokuDB, MemSQL。

透明分片

这类系统提供了分片的中间件层，数据库自动分割在多个节点运行。这类数据库包扩：ScaleBase，dbShards, Scalearc。

ACID （数据库事务正确执行的四个基本要素的缩写）

概念

ACID，是指数据库管理系统（DBMS）在写入或更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性：原子性（atomicity，或称不可分割性）、一致性（consistency）、隔离性（isolation，又称独立性）、持久性（durability）。

简介

ACID，是指数据库管理系统（DBMS）在写入或更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性：原子性（atomicity，或称不可分割性）、一致性（consistency）、隔离性（isolation，又称独立性）、持久性（durability）。

在数据库系统中，一个事务是指：由一系列数据库操作组成的一个完整的逻辑过程。例如银行转帐，从原账户扣除金额，以及向目标账户添加金额，这两个数据库操作的总和，构成一个完整的逻辑过程，不可拆分。这个过程被称为一个事务，具有ACID特性。ACID的概念在ISO/IEC 10026-1:1992文件的第四段内有所说明。

四大特性

  • Atomicity（原子性）：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
  • Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
  • Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
  • Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

Hadoop生态圈笔记

1、图示生态架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DIVsYlHe-1619101517567)(img\hadoop生态圈.jpg)]

2、从低往上学

HDFS

直译分布式文件系统，相当于windows机器上的视频、图片、文档等都是存到硬盘上，硬盘再需要做一些格式化。

在Hadoop上需要存储大数据，而且是存储在各个不同的机器上的。所以HDFS也就是一个分布式系统（分布式意思就是一个集群里面有很多台机器）。

HDFS作为一个最基本的文件系统就是存储大数据用的。

Hbase（Key-Val）

列存取数据库，可以理解为一个数据库，也是一个分布式的数据库。

可以把数据存到HDFS上，也可以存到Hbase。那为什么要存到Hbase呢？

Hbase既然是一个数据库，那么就更侧重于结构化的数据，有字段和列等等，方便上游的读取，然后快速检索。

那为什么Hbase为什么要在HDFS之上呢？因为Hbase的数据基本上都存在了HDFS上，所以Hbase也可以理解为HDFS的一层框架，有利于数据的快速读取，但是实际上数据仍让存储在HDFS里。

这一层负责存储。例如日志收集与数据存储、和数据预处理（Hbase，把非结构化数据结构化，就是数据预处理）

MapReduce和Storm

以上HDFS和Hbase都是帮我们解决了数据存储问题。那么数据要怎么应用呢，通常需要写程序，那么程序由谁来执行呢，由计算框架执行，也就是MapReduce，和Storm。MapReduce是整个Hadoop最核心的计算框架，由它来执行计算任务。

比如统计一篇文章每一个单词的出现次数，那么MapReduce就是我们写的程序，由整个程序来读取HDFS上的文件，然后具体数数过程需要自己写代码实现。

两者之间的区别：MapReduce适合做离线，Storm适合做在线。离线和在线后续再了解。

这一层只负责计算，不负责存储，后写入在线数据库（NoSql）。例如推荐策略算法模块

Hive

像一个数据库，但是本质上更是一个语言的转化工具。之前习惯了使用SQL语句读写数据库，为了方便我们对大数据操作，通过Hive支持SQL语句，叫做HSQL。和标准的MySql有一些细节不一样，但是整体差不多。

相当于一个翻译程序，把Sql语句翻译给MapReduce，然后再由MapReduce作数据处理（HDFS和Hbase）

本质上也是一个MapReduce或多个MapReduce执行程序。

Mahout

Mahout是在hadoop里封装的一个机器学习算法库，比如数据挖掘需要的分类算法、回归算法、推荐算法等等。主流算法Mahout都支持。提高效率。

Mahout和Hive一样，本质也是一个MapReduce或多个MapReduce，执行达到数据挖掘的目的。

Mahout是凌驾于整个计算框架之上的一个工具封装。

Online Engine

在线检索引擎，这是一个Web Server。

每个计算框架生成的数据之所以能体现它的价值是因为它能实现对外服务，数据是怎么服务呢，就是通过Online Engine。

Zookeeper

最拽的一个，横跨了这么多层。它是用来全局协调集群用的。Hbase和Storm需要zookeeper。

Hadoop2.0整套架构都是依赖于Zookeeper，Hadoop1.0不需要。

MapReduce笔记

1、简介

MapReduce是一个用于处理海量数据的分布式计算框架。这个框架解决了：

1.数据分布式存储

MapReduce自身是不存储数据的，数据都存取在HDFS上，计算的目标数据就是来自于HDFS。

2.作业调度

一个Hadoop集群上可以跑很多个MapReduce，不可能某一个MapReduce占了所有资源，资源是共享的。

3.容错

非个人因素导致的问题比如网络堵塞、机器间通信等复杂问题，会自动切换到其他节点上。

2、MapReduce分而治之思想

1、数钱实例：一堆钞票，各种面值分别多少

-单点策略

一个人数所有的钞票，数出各种面值有多少张
-分治策略

每个人分得一堆钞票，数出各种面值有多少种
汇总，每个人负责统计一种面值

2、解决数据可以切割进行计算的应用

分治思想
-分解

​ -求解

​ -合并

MapReduce映射
-分：map 把复杂的问题分解为若干“简单的任务”

​ -合：reduce

3、MapReduce计算框架·执行流程（重点）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yvfNQa47-1619101517570)(img\hadoop计算流程.png)]

开发人员一般情况下需要关心的是图中灰色的部分。

Map和Reduce部分细节化：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-G91zeBed-1619101517571)(img\mapreduce流程.png)]

Map部分：

一个map实际上对应一个split分片，首先map读取split，因为map是一个程序，作为系统里面的一个进程，自己维护着一个进程空间。把split数据读进来之后直接存到了自己的内存上（buffer in memory），然后开始往内存写。内存默认大小为100M，但是100M很容易写满，当它写到80M的时候会锁住内存区，然后把这80%的数据转储到磁盘上，然后清理内存。转储的过程中会作排序（sort），图中partitions中三个部分相当于前面数钱的例子中面值的分类。三个小的数据部分再归并排序成大的数据（merge on disk）。途中只展示出一个Map的执行流程，还有other maps。

Reduce部分

还是数钱的例子，假设图中Reduce部分是负责处理一百元面值的，把每个Map上属于一百元区域的数据通过fetch红线全部归纳到Reduce机器上（相当于拷贝）。然后把从每个从Map拷贝过来的数据两两合并，再统一交给Reduce处理，最后输出。

4、两个重要的进程

-JobTracker

主进程，负责接收客户作业提交，调度任务到作节点上运行，并提供诸如监控工作节点状态及任务进度等管理功能，一个MapReduce集群有一个JobTracker，一般运行在可靠的硬件上。
TaskTracker是通过周期性的心跳来通知JobTracker其当前的健康状态，每一次心跳包含了可用的Map和Reduce任务数目、占用的数目以及运行中的任务详细信息。JobTracker利用一个线程池来同时处理心跳和客户请求。

-TaskTracker

由JobTracker指派任务，实例化用户程序，在本地执行任务并周期性地向JobTracker汇报状态。在每一个工作节点上永远只会有一个TaskTracker。
-JobTracker一直在等待用户提交作业

-TaskTracker每隔3秒向JobTracker发送心跳询问有没有任务可做，如果有，让其派发任务给它执行

-Slave主动向Master拉生意

Storm笔记

Storm简介

ApacheStorm是Twitter开源的一个类似于Hadoop的实时数据处理框架，它原来是由BackType开发，后BackType被Twitter收购，将Storm作为Twitter的实时数据分析系统。

Storm能实现高频数据和大规模数据的实时处理。

官网资料显示storm的一个节点1秒钟能够处理100万个100字节的消息(IntelE5645@2.4Ghz的CPU,24GB的内存)。（即单节点每秒大概处理95MB左右数据）

官网：<http://storm.apache.org>;

Storm和Hadoop比较

  • 数据来源

    HADOOP处理的是HDFS上TB级别的数据(历史数据)，STORM是处理的是实时新增的某一笔数据(实时数据)；

  • 处理过程

    HADOOP是分MAP阶段到REDUCE阶段，STORM是由用户定义处理流程，流程中可以包含多个步骤，每个步骤可以是数据源(SPOUT)或处理逻辑(BOLT)；

  • 是否结束

    HADOOP最后是要结束的，STORM是没有结束状态，到最后一步时，就停在那，直到有新数据进入时再从头开始；

  • 处理速度

    HADOOP是以处理HDFS上TB级别数据为目的，处理速度慢，STORM是只要处理新增的某一笔数据即可，可以做到很快；

  • 适用场景

    HADOOP是在要处理批量数据时用的，不讲究时效性，STORM是要处理某一新增数据时用的，要讲时效性

基础概念

拓扑（Topology）

Storm 的拓扑是对实时计算应用逻辑的封装，它的作用与 MapReduce 的任务（Job）很相似，区别在于 MapReduce 的一个 Job 在得到结果之后总会结束，而拓扑会一直在集群中运行，直到你手动去终止它。拓扑还可以理解成由一系列通过数据流（Stream Grouping）相互关联的 Spout 和 Bolt 组成的的拓扑结构。Spout 和 Bolt 称为拓扑的组件（Component）。

在Java中使用TopologyBuilder来构建拓扑。

数据流（Data Stream）

数据流（Streams）是 Storm 中最核心的抽象概念。一个数据流指的是在分布式环境中并行创建、处理的一组元组（tuple）的无界序列。数据流可以由一种能够表述数据流中元组的域（fields）的模式来定义。在默认情况下，元组（tuple）包含有整型（Integer）数字、长整型（Long）数字、短整型（Short）数字、字节（Byte）、双精度浮点数（Double）、单精度浮点数（Float）、布尔值以及字节数组等基本类型对象。当然，你也可以通过定义可序列化的对象来实现自定义的元组类型。

在声明数据流的时候需要给数据流定义一个有效的 id。不过，由于在实际应用中使用最多的还是单一数据流的 Spout 与 Bolt，这种场景下不需要使用 id 来区分数据流，因此可以直接使用 OutputFieldsDeclarer来定义“无 id”的数据流。实际上，系统默认会给这种数据流定义一个名为“default”的 id。

元组（Tupe）

Tuple是Storm中最小的数据传输单元，可以理解为一个值列表或者键值对，其键（有的地方也称之为“域名”或者“字段”，在Storm中用Field类代表）在Spout或者Bolt中通过declareOutputFields（）方法定义，值在emit（）方法中指定。具体参见后面的Spout/Bolt介绍。Tuple 中的值可以是任何类型的，动态类型的Tuple 的fields 可以不用声明；默认情况下，Storm 中的Tuple 支持私有类型、字符串、字节数组等作为它的字段值，如果使用其他类型，就需要序列化该类型。
Tuple 的字段默认类型有：integer、float、double、long、short、string、byte、binary（byte[]）。

数据源（Spout）

数据源（Spout）是拓扑中数据流的来源。一般 Spout 会从一个外部的数据源读取元组然后将他们发送到拓扑中。根据需求的不同，Spout 既可以定义为可靠的数据源，也可以定义为不可靠的数据源。一个可靠的 Spout 能够在它发送的元组处理失败时重新发送该元组，以确保所有的元组都能得到正确的处理；相对应的，不可靠的 Spout 就不会在元组发送之后对元组进行任何其他的处理。

数据流处理组件（Bolt）

拓扑中所有的数据处理均是由 Bolt 完成的。通过数据过滤（filtering）、函数处理（functions）、聚合（aggregations）、联结（joins）、数据库交互等功能，Bolt 几乎能够完成任何一种数据处理需求。

一个 Bolt 可以实现简单的数据流转换，而更复杂的数据流变换通常需要使用多个 Bolt 并通过多个步骤完成。例如，将一个微博数据流转换成一个趋势图像的数据流至少包含两个步骤：其中一个 Bolt 用于对每个图片的微博转发进行滚动计数，另一个或多个 Bolt 将数据流输出为“转发最多的图片”结果（相对于使用2个Bolt，如果使用3个 Bolt 你可以让这种转换具有更好的可扩展性）。

Bolt中的关键方法有execute、prepare、declareOutputFields和cleanup等。

declareOutputFields：与 Spout 相同，Bolt 也可以输出多个数据流。为了实现这个功能，可以先通过 OutputFieldsDeclarer 的 declareStream 方法来声明定义不同的数据流，然后在发送数据时在 OutputCollector 的 emit 方法中将数据流 id 作为参数来实现数据发送的功能。

在定义 Bolt 的输入数据流时，你需要从其他的 Storm 组件中订阅指定的数据流。如果你需要从其他所有的组件中订阅数据流，你就必须要在定义 Bolt 时分别注册每一个组件。

**execute：**Bolt 的关键方法是 execute 方法。execute 方法负责接收一个元组作为输入，并且使用 OutputCollector 对象发送新的元组。在接收时，可以通过Tupe.getValueByField()方法获取指定的元组，也可以根据元组List的下标接收或者全部接收。

如果有消息可靠性保障的需求，Bolt 必须为它所处理的每个元组调用 OutputCollector 的 ack 方法，以便 Storm 能够了解元组是否处理完成（并且最终决定是否可以响应最初的 Spout 输出元组树）。一般情况下，对于每个输入元组，在处理之后可以根据需要选择不发送还是发送多个新元组，然后再响应（ack）输入元组。IBasicBolt 接口能够实现元组的自动应答。

对于需要保证消息可靠性的topology，bolt也需要在emit数据的时候，将传入的Tupe作为anchor进行锚定，相关概念参见下文或者链接“消息可靠性保证”

**prepare：**此方法类似Spout中的open方法，在初始化bolt时调用。同样地，如果一个bolt有多个executor线程，则该方法将被执行多次。

**cleanup：**在bolt执行完毕后关闭时执行，可以释放一些资源等。需要注意的是，在本地模式（LocalCluster）中，该方法一定会执行，但是在集群模式下，Storm不保证该方法一定执行。

数据流分组（Stream Grouping）

为拓扑中的每个 Bolt 的确定输入数据流是定义一个拓扑的重要环节。数据流分组定义了在 Bolt 的不同任务（tasks）中划分数据流的方式。

在 Storm 中有八种内置的数据流分组方式（原文有误，现在已经已经有八种分组模型——译者注），而且你还可以通过CustomStreamGrouping 接口实现自定义的数据流分组模型。这八种分组分时分别为：

  1. 随机分组（Shuffle grouping）：这种方式下元组会被尽可能随机地分配到 Bolt 的不同任务（tasks）中，使得每个任务所处理元组数量能够能够保持基本一致，以确保集群的负载均衡。

  2. 域分组（Fields grouping）：这种方式下数据流根据定义的“域”来进行分组。例如，如果某个数据流是基于一个名为“user-id”的域进行分组的，那么所有包含相同的“user-id”的元组都会被分配到同一个任务中，这样就可以确保消息处理的一致性。

  3. 部分关键字分组（Partial Key grouping）：这种方式与域分组很相似，根据定义的域来对数据流进行分组，不同的是，这种方式会考虑下游 Bolt 数据处理的均衡性问题，在输入数据源关键字不平衡时会有更好的性能1。感兴趣的读者可以参考这篇论文，其中详细解释了这种分组方式的工作原理以及它的优点。

  4. 完全分组（All grouping）：这种方式下数据流会被同时发送到 Bolt 的所有任务中（也就是说同一个元组会被复制多份然后被所有的任务处理），使用这种分组方式要特别小心。

  5. 全局分组（Global grouping）：这种方式下所有的数据流都会被发送到 Bolt 的同一个任务中，也就是 id 最小的那个任务。

  6. 非分组（None grouping）：使用这种方式说明你不关心数据流如何分组。目前这种方式的结果与随机分组完全等效，不过未来 Storm 社区可能会考虑通过非分组方式来让 Bolt 和它所订阅的 Spout 或 Bolt 在同一个线程中执行。

  7. 直接分组（Direct grouping）：这是一种特殊的分组方式。使用这种方式意味着元组的发送者可以指定下游的哪个任务可以接收这个元组。只有在数据流被声明为直接数据流时才能够使用直接分组方式。使用直接数据流发送元组需要使用 OutputCollector 的其中一个 emitDirect 方法。Bolt 可以通过 TopologyContext 来获取它的下游消费者的任务 id，也可以通过跟踪 OutputCollector 的 emit 方法（该方法会返回它所发送元组的目标任务的 id）的数据来获取任务 id。

  8. 本地或随机分组（Local or shuffle grouping）：如果在源组件的 worker 进程里目标 Bolt 有一个或更多的任务线程，元组会被随机分配到那些同进程的任务中。换句话说，这与随机分组的方式具有相似的效果。

可靠性保证（Reliability）

Storm 可以通过拓扑来确保每个发送的元组都能得到正确处理或者说完整地处理。通过跟踪由 Spout 发出的每个元组构成的元组树可以确定元组是否已经完成处理。每个拓扑都有一个“消息延时”参数，如果 Storm 在延时时间内没有检测到元组是否处理完成，就会将该元组标记为处理失败，并会在稍后重新发送该元组。

为了充分利用 Storm 的可靠性机制，你必须在元组树创建新结点的时候以及元组处理完成的时候通知 Storm。这个过程可以在 Bolt 发送元组时通过 OutputCollector 实现：在 emit 方法中实现元组的锚定（Anchoring），同时使用 ack 方法表明你已经完成了元组的处理。

Storm的设计思想

Storm是对流Stream的抽象，流是一个不间断的×××的连续tuple，注意Storm在建模事件流时，把流中的事件抽象为tuple即元组。

Storm将流中元素抽象为Tuple，一个tuple就是一个值列表——valuelist，list中的每个value都有一个name，并且该value可以是基本类型，字符类型，字节数组等，当然也可以是其他可序列化的类型。

Storm认为每个stream都有一个stream源，也就是原始元组的源头，所以它将这个源头称为Spout。

有了源头即spout也就是有了stream，那么该如何处理stream内的tuple呢。将流的状态转换称为Bolt，bolt可以消费任意数量的输入流，只要将流方向导向该bolt，同时它也可以发送新的流给其他bolt使用，这样一来，只要打开特定的spout（管口）再将spout中流出的tuple导向特定的bolt，又bolt对导入的流做处理后再导向其他bolt或者目的地。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RSVDrI3i-1619101517576)(img\topology.png)]

以上处理过程统称为Topology即拓扑。拓扑是storm中最高层次的一个抽象概念，它可以被提交到storm集群执行，一个拓扑就是一个流转换图，图中每个节点是一个spout或者bolt，图中的边表示bolt订阅了哪些流，当spout或者bolt发送元组到流时，它就发送元组到每个订阅了该流的bolt（这就意味着不需要我们手工拉管道，只要预先订阅，spout就会将流发到适当bolt上）。

拓扑的每个节点都要说明它所发出的元组的字段的name，其他节点只需要订阅该name就可以接收处理。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-J9lAAPmU-1619101517578)(img\topology2.png)]

Storm并发（Worker|Executor|Task）

一个Topology可能会在多个Supervisor节点中拥有多个worker，一个worker可能包含多个Executor，一个Executor可能包含多个Task。Task是执行业务逻辑的最小任务逻辑实体。

工作进程（Workers）

worker运行在工作节点上（supervisor节点），是被Supervisor守护进程创建的用来干活的进程。拓扑是在一个或多个工作进程（worker processes）中运行的。每个工作进程都是一个实际的 JVM 进程，并且执行拓扑的一个子集。一个Worker里面不会运行属于不同的topology的执行任务。

线程（Executors）

Executor可以理解成一个Worker进程中的工作线程。一个Executor中只能运行隶属于同一个component（spout/bolt）的task。一个Worker进程中可以有一个或多个Executor线程。在默认情况下，一个Executor运行一个task。

任务（Tasks）

在 Storm 集群中每个 Spout 和 Bolt 都由若干个任务（tasks）来执行。每个任务都与一个执行线程相对应。数据流分组可以决定如何由一组任务向另一组任务发送元组。你可以在 TopologyBuilder 的 setSpout 方法和 setBolt 方法中设置 Spout/Bolt 的并行度。

Flink笔记

Flink简介

1.1 Flink的初步认识

Apache Flink是为分布式、高性能、随时可用以即准确的流处理应用程序打造的开源处理框架
Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据进行有状态计算，Flink被设计在所有常见的集群环境中运行，以内存执行速度和任意规模来执行计算。

Flink的几个模块：

Flink Table & SQL
Flink Gelly (图计算)
Flink CEP (复杂事件处理)

1.2 选择Flink的理由

在流处理技术中，我们常见的Storm，层风靡一时。他是流处理的先锋，Storm提供了低延时的流处理，但是他为了实时性付出了一些代价：很难实现高吞吐，并且其正确性没能达到通常所需的水平，也就是说不能保证 exactly-once语义。

在低延时和高吞吐的流处理系统中维护良好的容错性是非常困难的，因此，开发人员提出将连续事件中的数据分割成一系列微小的批量作业。几遍分割在小，也无法做到完全的实时，这个就是Spark Streaming的使用方法。使用微批处理方法，可以实现exactly-once语义，从而保障状态的一致性。如果一个微批处理作业失败了，它可以重新运行。这比连续的流处理方法更容易。Storm Trident是对Storm的延伸，它的底层流处理引擎就是基于微批处理方法来进行计算的，从而实现了exactly-once语义，但是在延迟性方面付出了很大的代价。

通过间歇性的批处理作业来模拟流处理，会导致开发和运维相互交错。完成间歇性的批处理作业所需的时间和数据到达的时间紧密耦合，任何延迟都可能导致不一致(或者说错误)的结果。这种技术的潜在问题是，时间由系统中生成小批量作业的那一部分全权控制。Spark Streaming等一些流处理框架在一定程度上弱化了这一弊端，但还是不能完全避免。另外，使用这种方法的计算有着糟糕的用户体验，尤其是那些对延迟比较敏感的作业，而且人们需要在写业务代码时花费大量精力来提升性能。

也因此，Flink诞生了。Flink的一个优势是，它拥有诸多重要的流式计算功能。其他项目为了实现这些功能，都不得不付出代价。比如，Storm实现了低延迟，但是做不到高吞吐，也不能在故障发生时准确地处理计算状态; Spark Streaming通过采用微批处理方法实现了高吞吐和容错性，但是牺牲了低延迟和实时处理能力，也不能使窗口与自然时间相匹配，并且表现力欠佳。

看下面一张图，就是Flink , Spark Streaming , Storm三者之间的区别。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M42UseCU-1619101517578)(img\区别.png)]

Spark Streaming VS Flink

Micro Batching 模式（Spark）

该计算模式认为流是批的特例，流计算就是连续不断的批进行持续计算，但是该计算模式在一定程度上可以满足99%的实时计算场景，在该模式的架构实现上有一个自然流数据进入系统进行攒批的过程，这样就增加了延迟。如图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mYNZPCoy-1619101517580)(img\micro batching模式.png)]

可以看出，把输入流分割成微小的批次，然后一个批次一个批次的处理，一个批次一个批次的输出。

Native Streaming 模式（Flink）

该计算模式认为批是流的特例，其是将每条数据都进行计算，这种计算模式很自然，并且延迟性能更低，如图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7c9cVuF2-1619101517582)(img\native streaming模式.png)]

数据模型

Spark最早使用的是RDD模型，这个比MapReduce快了100倍的计算模型有着显著的优势。对Hadoop生态大幅升级换代。RDD弹性数据集是分割为固定大小的批数据。
Spark Streaming里的DStream和RDD模型类似，把一个实时进来的无线数据分割为一个小批数据集合DStream，定时器定时通知系统去处理这些微批数据。然而，API少，无法胜任复杂的流计算业务，调大吞吐量而不触发背压是个体力活，不支持乱序处理。

Flink的基本数据模型是数据流，及事件（Event）的序列。数据流作为数据的基本模型可能没有表或者数据块的直观熟悉，但是可以证明是完全等效的。流可以是无边界的无限流，即所谓的流处理。可以说，有边界的有限流，这样就是批处理。
Flink采用Dataflow模型，和Lambda模式不同。Dataflow是纯粹的节点组成的一个图，图中的节点可以执行流计算、批计算、机器学习算法，流数据在节点间流动，被节点上的处理函数实时apply处理，节点间使用Netty连接起来的。两个Netty间Keepalive，网络Buffer是自然反压的关键。经过逻辑优化和物理优化，Dadaflow的逻辑关系和运行的物理拓扑相差不大。这种纯粹的流式设计，时延和吞吐理论山是最优的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vRXngl3Q-1619101517583)(img\流式设计.png)]

运行时架构

Spark运行时架构

批计算是把DAG划分为不同stage，DAG节点之间有血缘关系，在运行期间一个stage的task任务列表执行完毕，销毁再去执行下一个stage；Spark Streaming则是对持续流入的数据划分一个批次，定时去执行批次的数据运算。Structured Streaming将无限输入流保存在状态存储中，对流数据做微批或实时的计算，跟Dataflow模型比较像。

Flink运行时架构

Flink有统一的runtime，在此之上可以是Batch API、Stream API、ML、Graph、CEP等，DAG中的节点上执行上述模块的功能函数，DAG会一步步转化成ExecutionGraph，即物理可执行的图，最终交给调度系统。节点中的逻辑在资源池中的task上被apply执行，task和Spark中的task类似，都对应线程池中的一个线程。

在DAG的执行上，Spark和Flink有一个比较显著的区别。在Flink的流执行模式中，一个事件在一个节点处理完后的输出就可以发到下一个节点立即处理。这样执行引擎并不会引入额外的延迟。与之相应的，所有节点是需要同时运行的。而Spark的micro batch和一般的batch执行一样，处理完上游的stage得到输出之后才开始下游的stage。

在流计算的运行时架构方面，Flink明显更为统一且优雅一些。

1.3 Flink的重要特点

1.3.1 事件驱动型（Event-Driver）

事件驱动型是一类具有状态的应用，他从一个或多个事件流提取数据，并根据到来的事件除法计算、状态更新或其他外部动作。比较典型就是Kafka为代表的的消息对列几乎是事件驱动型应用。
与之不同的是Spark Streaming微批次，如图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7t4AEFtX-1619101517584)(img\spark streaming微批次.png)]

而事件驱动型，如图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KRTngMj7-1619101517585)(img\事件驱动型.png)]

1.3.2 流与批的两种世界观

批处理的特点是有界、持久、大量，非常适合需要访问全套记录才能完成的计算工作，一般用于离线统计。

流处理的特点是无界、实时，无需针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作，一般用于实时统计。

在Spark的世界观中，一切都是由批次组成的，离线数据是一个大批次，而实时数据是由一个一个无限的小批次组成的。

而在Flink的世界观中，一切都是由流组成的，离线数据是有界限的流，实时数据是一个没有界限的流，这就是所谓的有界流和无界流。

**无界数据流：**无界数据流有一个开始但是没有结束，它们不会在生成时终止并提供数据，必须连续处理无界流，也就是说必须在获取后立即处理event。对于无界数据流我们无法等待所有数据都到达，因为输入是无界的，并且在任何时间点都不会完成。处理无界数据通常要求以特定顺序(例如事件发生的顺序)获取event，以便能够推断结果完整性。

**有界数据流：**有界数据流有明确定义的开始和结束，可以在执行任何计算之前通过获取所有数据来处理有界流，处理有界流不需要有序获取，因为可以始终对有界数据集进行排序，有界流的处理也称为批处理。
这种以流为世界观的架构，获得最大好处就是具有极低的延迟

1.3.3 分层API

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-P03KHSVZ-1619101517585)(img\分层api.png)]

Flink目前作为批处理还不是主流，不如Spark成熟，因此DataSet使用不是很多，Flink Table API和Flink SQL也并不完善。Flink作为最接近Google DataFlow模型的实现，是流批统一的观点，因此使用DataStream

有状态的流式处理简介

Apache Flink是一个分布式流处理器，具有直观和富有表现力的API，可实现有状态的流处理应用程序。它以容错的方式有效地大规模运行这些应用程序。

2.1 传统数据处理架构

两种数据处理类型：事务处理（OLTP）和分析处理（OLAP）

2.1.1 事务处理

公司系统通常设计有单独的层，用于数据处理（应用程序本身）和数据存储（事务数据库系统）。应用程序通常连接到外部服务或直接面向用户，并持续处理传入的事件。处理事件时，应用程序会读取数据库的状态，或者通过运行事务来更新它。

2.1.2 分析处理

一般不会直接在事务数据库上运行分析查询，而是复制数据到数据仓库。数据仓库是对工作负载进行分析和查询的专用数据存储。为了填充数据仓库，需要将事务数据库系统管理的数据复制过来。将数据复制到数据仓库的过程称为extract-transform-load（ETL）。 ETL过程从事务数据库中提取数据，将其转换为某种通用的结构表示，可能包括验证，值的规范化，编码，重复数据删除（去重）和模式转换，最后将其加载到分析数据库中。 ETL过程可能非常复杂，并且通常需要技术复杂的解决方案来满足性能要求。 ETL过程需要定期运行以保持数据仓库中的数据同步。

将数据导入数据仓库后，可以查询和分析数据。通常，在数据仓库上执行两类查询。第一种类型是定期报告查询，用于计算与业务相关的统计信息，比如收入、用户增长或者输出的产量。这些指标汇总到报告中，帮助管理层评估业务的整体健康状况。第二种类型是即席查询，旨在提供特定问题的答案并支持关键业务决策，例如收集统计在投放商业广告上的花费，和获取的相应收入，以评估营销活动的有效性。两种查询由批处理方式由数据仓库执行，

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w5JF7yLh-1619101517586)(img\分析处理.png)]

2.2 有状态的流式处理

如果我们想要无限处理事件流，并且不愿意繁琐地每收到一个事件就记录一次，那这样的应用程序就需要是有状态的，也就是说能够存储和访问中间数据。当应用程序收到一个新事件时，它可以从状态中读取数据，或者向该状态写入数据，总之可以执行任何计算。原则上讲，我们可以在各种不同的地方存储和访问状态，包括程序变量（内存）、本地文件，还有嵌入式或外部数据库。

Apache Flink将应用程序状态，存储在内存或者嵌入式数据库中。由于Flink是一个分布式系统，因此需要保护本地状态以防止在应用程序或计算机故障时数据丢失。 Flink通过定期将应用程序状态的一致性检查点（check point）写入远程且持久的存储，来保证这一点。状态、状态一致性和Flink的检查点将在后面的章节中更详细地讨论，但是，现在，图1-4显示了有状态的流式Flink应用程序。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FpnNuXgU-1619101517587)(img\有状态的流式flink程序.png)]

有状态的流处理应用程序，通常从事件日志中提取输入事件。事件日志就用来存储和分发事件流。事件被写入持久的仅添加（append-only）日志，这意味着无法更改写入事件的顺序。写入事件日志的流，可以被相同或不同的消费者多次读取。由于日志的仅附加（append-only）属性，事件始终以完全相同的顺序发布给所有消费者。现在已有几种事件日志系统，其中Apache Kafka是最受欢迎的，可以作为开源软件使用，或者是云计算提供商提供的集成服务。

在Flink上运行的有状态的流处理应用程序，是很有意思的一件事。在这个架构中，事件日志会按顺序保留输入事件，并且可以按确定的顺序重播它们。如果发生故障，Flink将从先前的检查点（check point）恢复其状态，并重置事件日志上的读取位置，这样就可以恢复整个应用。应用程序将重放（并快进）事件日志中的输入事件，直到它到达流的尾部。此技术一般用于从故障中恢复，但也可用于更新应用程序、修复bug或者修复以前发出的结果，另外还可以用于将应用程序迁移到其他群集，或使用不同的应用程序版本执行A / B测试。

如前所述，有状态的流处理是一种通用且灵活的设计架构，可用于许多不同的场景。在下文中，我们提出了三类通常使用有状态流处理实现的应用程序：（1）事件驱动应用程序，（2）数据管道应用程序，以及（3）数据分析应用程序。

我们将应用程序分类描述，是为了强调有状态流处理适用于多种业务场景；而实际的应用中，往往会具有以上多种情况的特征。

2.2.1 事件驱动应用程序（Event-Driven Applications）

事件驱动的应用程序是由状态的流应用程序，使用特定的业务逻辑来提取事件流并处理事件。

2.2.2 数据管道（Data Pipelines）

以较低的延迟，来提取、转换和插入数据是有状态流处理应用程序的另一个常见应用场景。这种类型的应用程序称为数据管道（data pipeline）。数据管道必须能够在短时间内处理大量数据。操作数据管道的流处理器还应具有许多源（source）和接收器（sink）的连接器，以便从各种存储系统读取数据并将数据写入各种存储系统。当然，同样地，Flink完成了所有这些功能

2.2.3 流分析

ETL作业定期将数据导入数据存储区，数据的处理是由即席查询（用户自定义查询）或设定好的通常查询来做的。无论架构是基于数据仓库还是基于Hadoop生态系统的组件，这都是批处理。多年来最好的处理方式就是，定期将数据加载到数据分析系统中，但它给分析管道带了的延迟相当大，而且无法避免。

流式分析应用程序不是等待定期触发，而是连续地提取事件流，并且通过纳入最新事件来更新其计算结果，这个过程是低延迟的。这有些类似于数据库中用于更新视图（views）的技术。通常，流应用程序将其结果存储在支持更新的外部数据存储中，例如数据库或键值（key-value）存储。流分析应用程序的实时更新结果可用于驱动监控仪表板（dashboard）应用程序。

流分析应用程序最大的优势就是，将每个事件纳入到分析结果所需的时间短得多。除此之外，流分析应用程序还有另一个不太明显的优势。传统的分析管道由几个独立的组件组成，例如ETL过程、存储系统、对于基于Hadoop的环境，还包括用于触发任务（jobs）的数据处理和调度程序。相比之下，如果我们运行一个有状态流应用程序，那么流处理器就会负责所有这些处理步骤，包括事件提取、带有状态维护的连续计算以及更新结果。此外，流处理器可以从故障中恢复，并且具有精确一次（exactly-once）的状态一致性保证，还可以调整应用程序的计算资源。像Flink这样的流处理器还支持事件时间（event-time）处理，这可以保证产生正确和确定的结果，并且能够在很短的时间内处理大量数据。

Flink简介总结

Apache Flink是第三代分布式流处理器，它拥有极富竞争力的功能。它提供准确的大规模流处理，具有高吞吐量和低延迟。特别的是，以下功能使Flink脱颖而出：

  • 事件时间（event-time）和处理时间（processing-tme）语义。即使对于无序事件流，事件时间（event-time）语义仍然能提供一致且准确的结果。而处理时间（processing-time）语义可用于具有极低延迟要求的应用程序。

  • 精确一次（exactly-once）的状态一致性保证。

  • 每秒处理数百万个事件，毫秒级延迟。 Flink应用程序可以扩展为在数千个核（cores）上运行。

  • 分层API，具有不同的权衡表现力和易用性。本书介绍了DataStream API和过程函数（process function），为常见的流处理操作提供原语，如窗口和异步操作，以及精确控制状态和时间的接口。本书不讨论Flink的关系API，SQL和LINQ风格的Table API。

  • 连接到最常用的存储系统，如Apache Kafka，Apache Cassandra，Elasticsearch，JDBC，Kinesis和（分布式）文件系统，如HDFS和S3。

  • 由于其高可用的设置（无单点故障），以及与Kubernetes，YARN和Apache Mesos的紧密集成，再加上从故障中快速恢复和动态扩展任务的能力，Flink能够以极少的停机时间 7 * 24全天候运行流应用程序。

  • 能够更新应用程序代码并将作业（jobs）迁移到不同的Flink集群，而不会丢失应用程序的状态。

  • 详细且可自定义的系统和应用程序指标集合，以提前识别问题并对其做出反应。

  • 最后但同样重要的是，Flink也是一个成熟的批处理器。

除了这些功能之外，Flink还是一个非常易于开发的框架，因为它易于使用的API。嵌入式执行模式，可以在单个JVM进程中启动应用程序和整个Flink系统，这种模式一般用于在IDE中运行和调试Flink作业。在开发和测试Flink应用程序时，此功能非常有用。

HBase学习笔记

1. Hbase简介

  • Hadoop-Database根据’bigtable’论文实现的
  • 分布式 可扩展的大数据存储技术
  • 随机访问 实时读写海量数据
  • 存储数 '十亿行 百万列’的数据
  • 高可靠性、高性能、面向列、可伸缩的分布式存储系统
  • hbase的底层存储基于hdfs
  • 利用Zookeeper作为协调工具

2. Hbase是什么?

  • 分布式开源数据库，基于hadoop分布式文件系统（HDFS）
  • 模仿提供了Google文件系统的BigTable数据库所有功能
  • 处理非常庞大的表
    • 数十亿行 百万列
    • 利用mapreduce计算数据，利用zookeeper协调资源
  • HBase是一款NoSQL

3. 行存储和列存储

  • 行存储:mysql oracle底层基于行存储数据的

    • 查询数据需要全表扫描,效率较低
    • 对数据压缩支持不太好

  • 列存储:hbase底层基于列存储数据的

    • 查询数据不需做全表扫描
    • 支持较好的数据压缩

4. Hbase的特点

  • 可以分布式存储海量的数据
  • 具有容错能力强，数据高可靠的特点
  • HBase是一个列式NoSQL数据库
  • 数据存储的结构是按照列进行存储

5. Hbase的安装部署

安装hbase高可用集群之前首先要保证zookeeper和hadoop已经安装完成

  • 准备安装包

    hbase-1.1.5-bin.tar.gz

  • 集群的规划

    • uplooking01: master
    • uplooking02: master
    • uplooking03: regionserver
    • uplooking04: regionserver
    • uplooking05: regionserver

  • 解压安装包

    [root@uplooking01: /soft]:
        tar -zxvf hbase-1.1.5-bin.tar.gz  -C /opt/

  • 重命名

    [root@uplooking01: /opt]:
        mv hbase-1.1.5/ hbase

  • 配置环境变量

    [root@uplooking01: /opt]:
    #配置HBASE的环境变量
    export HBASE_HOME=/opt/hbase
    export PATH=$PATH:$HBASE_HOME/bin

  • 配置vim hbase-env.sh

    [root@uplooking01: /opt/hbase/conf]:
    vim  hbase-env.sh 

    export JAVA_HOME=/opt/jdk
export HBASE_MANAGES_ZK=false   #不使用hbase自带的zookeeper
export HBASE_CLASSPATH=/opt/hadoop/etc/hadoop

  • 配置hbase-site.xml

    [root@uplooking01: /opt/hbase/conf]:
    vim  hbase-site.xml 

    <configuration>
    <property>
    <name>hbase.rootdir</name>
    <value>hdfs://ns1/hbase</value>
    </property>

    <property>
    <name>hbase.tmp.dir</name>
    <value>/opt/hbase/tmp</value>
    </property>

    <property>
    <name>hbase.cluster.distributed</name>
    <value>true</value>
    </property>

    <property>
    <name>hbase.zookeeper.quorum</name>
    <value>uplooking03:2181,uplooking04:2181,uplooking05:2181</value>
    </property>
</configuration>

  • 配置 regionservers

    [root@uplooking01: /opt/hbase/conf]:
    vim  regionservers

    uplooking03
uplooking04
uplooking05

  • 分发文件

    [root@uplooking01: /opt]:
    scp -r hbase uplooking02:/opt
    scp -r hbase uplooking03:/opt
    scp -r hbase uplooking04:/opt
    scp -r hbase uplooking05:/opt
    
    scp /etc/profile uplooking02:/etc/
    scp /etc/profile uplooking03:/etc/
    scp /etc/profile uplooking04:/etc/
    scp /etc/profile uplooking05:/etc/

    source /etc/profile(所有节点都做,要使环境变量生效)

  • 启动hbase集群

    start-hbase.sh

  • 单独启动master

    [root@uplooking02:/]
    hbase-daemon.sh start master

  • 注意事项

    启动hbase集群一定要保证整个集群的时间一致

  • 附加(一般不会有这种情况)

    如果启动集群执行start-hbase.sh,master节点可以启动,但是regionserver节点不能启动,但是单独启动regionserver(hbase-daemon.sh start regionserver)是可以启动的,也没有问题,name就需要拷贝一个jar包,

    将HADOOP_HOME/share/hadoop/common/lib下的htrace-core-3.0.4.jar 复制到$HBASE_HOME/lib下

6. Hbase的体系结构(模型)

6.1 逻辑结构(模型)

  • 表（table）
    • 划分数据集合的概念，和传统的db中的表的概念是一样的
  • 行键（rowKey）
    • 对应关系数据库中的主键，作用就是唯一标示一行记录
    • 获取hbase中的一个记录(数据),要通过行键来获取
    • 行键是字节数组, 任何字符串都可以作为行键
    • 表中的行根据行键(row key)进行排序 ,数据按照Row key的字节序(byte order)排序存储
  • 列簇(列族)columnFamily
    • 简单的认为是一系列**“列”的集合**
  • 列限定符（column Qualifier）
    • 或者叫列
    • 每个列簇都可以有多个列
  • 时间戳（version）
    • 在单元格中可以存放多个版本的数据
  • 单元格（cell）
    • 主要用来存储数据
    • 单元格的定位要通过三级定位才能定位到具体的单元格
  • 三级定位
    • 行键+(列族:列)+时间戳

6.2 物理结构(模型)

  • Zookeeper

    • 分布式协调

  • Master

    • HMaster没有单点问题，HBase中可以启动多个HMaster
    • 负责Table和Region的管理工作
    • 管理用户对Table的增、删、改、查操作
    • RegionServer的负载均衡
    • 调整Region分布 ,在Region Split后，负责新Region的分配
    • 在HRegionServer停机后，负责失效HRegionServer上的Regions迁移

  • RegionServer

    • RegionServer主要负责响应用户I/O请求
    • 向HDFS文件系统中读写数据，是HBase中最核心的模块
    • HLog部分和多个Region部分

  • Hlog

    • HLog保存着用户操作hbase的日志
    • 实现了Write Ahead Log (WAL)预写日志
    • Hlog会删除已存储到StoreFile中的数据

  • Region

    • 区域
    • 保存了row-key的固定区域范围的数据
    • 一个Hregion对应一个Region
    • 一个Hregion对应多个Hstore

  • Hstore

    • 对应一个列簇(列族)
    • 一个Hstore包含一个MemStore(内存储) 和多个StoreFile

  • MemStore

    • 内存储
    • 内存中的一块区域,一个Hstore对应一个MemStore
    • 当MemStore中的内容存放不下了就会刷出到硬盘以一个个的StoreFile存储

  • StoreFile

    • 其实就是数据的存储位置
    • 对HFile的封装****

  • Hfile

    • Hadoop File
    • Hdfs的一个文件对象

7. Hbase读写数据的流程

  • zookeeper(寻找元数据信息)
    • get /hbase/meta-region-server
  • 找到提供元数据信息访问的regionserver
  • 找"hbase:meta"表,再去查找要请求哪个regionser来读写数据

8. Hbase的Shell操作

  • 列出所有的命名空间(相当于mysql中的show databases)
    • list_namespace
  • 列出指定命名空间下的所有表
    • list_namespace_tables ‘ns1’
  • 创建命名空间
    • create_namespace ‘ns1’
  • 创建表
    • create ‘ns1:t1’,‘f1’
  • 禁用表,因为删除表之前首先需要禁用了
    • disable ‘ns1:t1’
  • 启用表
    • enable ‘ns1:t1’
  • 删除表
    • drop ‘ns1:t1’
  • 添加数据
    • put ‘ns1:t1’,‘row001’,‘f1:name’,‘xiaohua’
  • 查询数据
    • get ‘ns1:t1’,‘row001’,{COLUMN=>‘f1:name’}
  • 删除数据
    • delete ‘ns1:t1’,‘row001’,‘f1:name’
  • 删除一行数据
    • deleteall ‘ns1:t1’,‘row001’
  • 统计表的行数
    • count ‘ns1:t1’

9. Hbase中的版本数据

  • 创建Hbase表时指定列族的显示版本数

    • create ‘ns1:t1’,{NAME=>‘f1’,VERSIONS=>3}

  • 修改Hbase表中的列族的显示版本数

    • alter ‘ns1:t1’,{NAME=>‘f1’,VERSIONS=>5}

  • 查询指定版本数的数据

  • get ‘ns1:t1’,{COLUMN=>‘f1:name’,VERSIONS=>3}

  • 版本号的作用

    根据显示的版本数,查询出来想要版本的时间戳,根据时间戳找出具体值

10. Hbase中API的基本操作

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <hbase-version>1.1.5</hbase-version>
</properties>
<dependencies>
    <dependency>
        <groupId>org.apache.hbase</groupId>
        <artifactId>hbase-client</artifactId>
        <version>${hbase-version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.hbase</groupId>
        <artifactId>hbase-server</artifactId>
        <version>${hbase-version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.hive</groupId>
        <artifactId>hive-hbase-handler</artifactId>
        <version>2.1.0</version>
    </dependency>

    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
    </dependency>
</dependencies>


public class HbaseTest {
    //添加数据
    @Test
    public void testPut() throws IOException {
        Configuration conf = HBaseConfiguration.create();
        //指定zk的地址
        conf.set("hbase.zookeeper.quorum", "uplooking03:2181,uplooking04:2181,uplooking05:2181");
        Connection conn = ConnectionFactory.createConnection(conf);
        Table table = conn.getTable(TableName.valueOf("ns1:t1"));
        Put put = new Put(Bytes.toBytes("row001"));
        put.addColumn(Bytes.toBytes("f1"), Bytes.toBytes("name"), Bytes.toBytes("admin02"));
        table.put(put);
    }


    //删除数据
    @Test
    public void testDelete() throws IOException {
        Configuration conf = HBaseConfiguration.create();
        //指定zk的地址
        conf.set("hbase.zookeeper.quorum", "uplooking03:2181,uplooking04:2181,uplooking05:2181");
        Connection conn = ConnectionFactory.createConnection(conf);
        Table table = conn.getTable(TableName.valueOf("ns1:t1"));
        Delete delete = new Delete(Bytes.toBytes("row001"));
        table.delete(delete);
    }

    //查询数据
    @Test
    public void testGet() throws IOException {
        Configuration conf = HBaseConfiguration.create();
        //指定zk的地址
        conf.set("hbase.zookeeper.quorum", "uplooking03:2181,uplooking04:2181,uplooking05:2181");
        Connection conn = ConnectionFactory.createConnection(conf);
        Table table = conn.getTable(TableName.valueOf("ns1:t1"));
        Get get = new Get(Bytes.toBytes("row001"));
        Result result = table.get(get);
        String s = Bytes.toString(result.getValue(Bytes.toBytes("f1"),Bytes.toBytes("name")));
        System.out.println(s);
    }
}

11. Hbase中的API的管理操作

public class HbaseAdminTest {

    private Connection connection;

    @Before
    public void init() throws Exception {
        Configuration conf = new Configuration();
        conf.set("hbase.zookeeper.quorum", "uplooking03:2181,uplooking04:2181,uplooking05:2181");
        connection = ConnectionFactory.createConnection(conf);
    }

    /**
     * 创建表
     *
     * @throws Exception
     */
    @Test
    public void testCreateTable() throws Exception {
        //获取管理对象
        Admin admin = connection.getAdmin();
        HTableDescriptor htd = new HTableDescriptor(TableName.valueOf("t2"));
        HColumnDescriptor hcd = new HColumnDescriptor(Bytes.toBytes("f1"));
        htd.addFamily(hcd);
        admin.createTable(htd);
    }


    /**
     * 列出所有的表
     * @throws Exception
     */
    @Test
    public void testListTableNames() throws Exception {
        //获取管理对象
        Admin admin = connection.getAdmin();
        TableName[] tableNames = admin.listTableNames("ns1:.*");
        for (TableName tableName : tableNames) {
            System.out.println(tableName);
        }
    }

}

12. Hbase高级查询

//查询数据
@Test
public void testScan() throws IOException {
    Configuration conf = HBaseConfiguration.create();
    //指定zk的地址
    conf.set("hbase.zookeeper.quorum", "uplooking03:2181,uplooking04:2181,uplooking05:2181");
    Connection conn = ConnectionFactory.createConnection(conf);
    Table table = conn.getTable(TableName.valueOf("ns1:t1"));
    Scan scan = new Scan();
    byte[] cf = Bytes.toBytes("f1");
    byte[] column = Bytes.toBytes("name");
    Filter filter = new SingleColumnValueFilter(cf, column, CompareFilter.CompareOp.EQUAL, Bytes.toBytes("admin123"));
    scan.setFilter(filter);
    //获取包含多行数据的对象
    ResultScanner resultScanner = table.getScanner(scan);
    for (Result result : resultScanner) {
        System.out.println(Bytes.toString(result.getValue(Bytes.toBytes("f1"), Bytes.toBytes("age"))));
    }
}

13. 百万数据的插入

13.1 mysql百万数据写入

耗时约20分钟
自己测试10分钟

8800000ms，插入15851742tiao数据

13.2 hbase百万数据的写入

/**
 * 百万数据的插入
 */
public class HbaseMiTest {

    private Connection connection;

    @Before
    public void init() throws Exception {
        Configuration conf = new Configuration();
        conf.set("hbase.zookeeper.quorum", "uplooking03:2181,uplooking04:2181,uplooking05:2181");
        connection = ConnectionFactory.createConnection(conf);
    }

    @Test
    public void test01() throws IOException {
        HTable table = (HTable) connection.getTable(TableName.valueOf("ns1:t1"));
        //不使用每个put操作都刷出一次
        table.setAutoFlush(false);
        long startTime = System.currentTimeMillis();
        for (int i = 0; i < 1000000; i++) {
            Put put = new Put(Bytes.toBytes("row" + i));
            //关闭预写日志,但是不建议使用,因为这样做不安全
            put.setWriteToWAL(false);
            put.addColumn(Bytes.toBytes("f1"), Bytes.toBytes("name"), Bytes.toBytes("admin" + i));
            table.put(put);
            if (i % 100000 == 0) {
                table.flushCommits();
            }
        }
        table.flushCommits();
        long endTime = System.currentTimeMillis();
        System.out.println("总耗时:" + (endTime - startTime) + "ms");
    }
}

大约耗时27s
自己测试，1分20秒 590/80=7.4倍
查询一行是9秒
97602ms,插入15851742tiao数据 8800/175=50倍

14. Hbase中的手动切分region

split ‘ns1:t1’,'row040’

15. Hbase手动移动region

move ‘f6e6164514db53d660c5414df1f3864e’,'uplooking05,1602

**0,1539222350164'**

16. Hbase中row-key的设计

  • 行健的热点问题

是由于行健相似、连续且数据量过大操作成单region的数据量过大，进而影响读写效率

行健应该尽量的随机、不要出现连续行健。

常见的行健设计就是，比如手机号码倒置+时间戳，比如随机前缀+关系型数据库中的主键

因为hbase提供的查询内容非常非常low，但是所有关于hbase的查询只能通过rowkey，所以

在设计行健的时候，应该考虑将尽量多的查询条件放到rowkey中去，形成的行健就成为复合键

列族的设计：

cf1----->“columnFamily”

cf2----->“cf”

建议hbase表是高表，不建议宽表，因为宽表拥有的列族很多，操作并跨越的文件(HFile)就很多，效率会有相应影响，

反之建议使用高表，列族不宜过多(列族一般使用一个)。

在设计表的时候，各个列/列族名称不宜过长，因为hbase需要对这些数据在内存中做缓存，做索引，进而影响内存容量，所以建议不易过长，以便能够在内存中容纳更多的数据。至于阅读性，有项目文档搞定。

17. Hbase中客户端工具

HbaseExplorer

Spark 学习笔记：简介

关于 Spark

Spark 最初由美国加州伯克利大学的AMP实验室于2009年开发，是基于内存计算的大数据并行计算框架，可用于构建大型的、低延迟的数据分析应用程序。Spark的主要特点是能够在内存中进行计算，并适用于各种各样原先需要使用不同的分布式平台的场景，包括批处理、迭代计算、交互式查询、流处理。通过在一个统一的框架下支持这些不同的计算，Spark是我们可以简单而低耗地把各种处理流程整合在一起。

特点介绍：

  1. 运行速度快：Spark 使用先进的 DAG (Directed Acyclic Graph，有向无环图) 执行引擎，以支持循环数据流和内存计算，相比于 Hadoop 基于磁盘来进行 MapReduce 运算要快上百倍；
  2. 容易使用：Spark 支持使用 Scala、Java、Python 语言进行编程，简洁的 API 设计有助于用户轻松构建并行程序，且可以通过 Spark Shell 进行交互式编程；
  3. 通用性：Spark 提供了完整而强大的技术栈，包括 SQL 查询、流式计算、机器学习和图算法组件，这些组件可以无缝整合在同一个应用中，足以应对复杂的计算；
  4. 运行模式多样：Spark 可运行于独立的集群模式中，或者运行于 Hadoop 中，也可运行于 Amazon EC2 等云环境中，并且可以访问 HDFS、HBase 以及 Hive 等多种数据源。

Spark vs Hadoop

  1. 表达能力更丰富：Spark 的计算模式也属于 MapReduce，但不局限于 Map 和 Reduce 操作，还提供了多种数据集操作类型，编程模型比 MapReduce 更灵活；
  2. 运算效率更优：Spark 提供了内存计算，中间结果直接放到内存中，但 Hadoop 每次在执行 MapReduce 操作时都需要从磁盘读取数据，并在计算完成后又再次将中间结果写入到磁盘中，导致 IO 开销更大，延迟较高；
  3. 先进的任务调度机制：Spark 时基于 DAG 的任务调度执行机制，要优于 MapReduce 的迭代执行机制。
  4. 实际开发更方便：在实际进行开发时，使用 Hadoop 需要编写不少相对底层的代码，不够高效。相对而言，Spark 提供了多种高层次、简洁的 API。更重要的是，Spark 提供了交互式编程环境，可以方便地验证、调整算法。

尽管 Spark 相对于 Hadoop 而言具有较大优势，但 Spark 并不能完全替代 Hadoop，主要用于替代 Hadoop 中的 MapReduce 计算模型。实际上，Spark 已经很好地融入了Hadoop生态圈，并成为其中的重要一员，它可以借助于 YARN 实现资源调度管理，借助于 HDFS 实现分布式存储。此外，Hadoop 可以使用廉价的、异构的机器来做分布式存储与计算，但是，Spark 对硬件的要求稍高一些，对内存与 CPU 有一定的要求。

Spark 生态系统

在实际的应用中，大数据处理主要包括以下三种类型：

  • 复杂的批量数据处理：时间跨度通常在数十分钟到数小时之间；
  • 基于历史数据的交互式查询：时间跨度通常在数十秒到数分钟之间；
  • 基于实时数据流的数据处理：时间跨度通常在数百毫秒到数秒之间。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Wk4OqThB-1619101517589)(img\spark)]

相比于其它框架在功能上的单一性， Spark 能同时支持批处理、交互式查询和流数据处理。其生态系统主要包含的核心组件有 Spark core 、Spark SQL 、Spark Streaming 、 MLlib 和 GraphX 等，各个组件的具体功能如下：

  1. **Spark core**：包含 Spark 的基本功能，如内存计算、任务调度、部署模式、故障恢复、存储管理等。Spark 建立在统一的抽象 RDD 之上，使其可以以基本一致的方式应对不同的大数据处理场景；
  2. **Spark SQL**：支持对 Hive 、HBase 等外部数据源的类 SQL 查询，每个数据表被当做一个 RDD ；
  3. **Spark Streaming**：支持高吞吐量、可容错处理的实时流数据处理，其核心思路是将流式计算分解成一系列短小的批处理作业；
  4. **MLlib**：提供了常用机器学习算法的实现，包括聚类、分类、回归、协同过滤等，降低了机器学习的门槛；
  5. **GraphX**：支持在 Spark 中进行图计算，可认为是 Pregel 在 Spark 上的重写及优化，GraphX 性能良好，拥有丰富的功能和运算符，能在海量数据上自如地运行复杂的图算法。
版权声明：本文为qq_46600445原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。