大数据处理技术与区块链技术 -- 相关技术概念

　　下学期导师接了一个973军工项目，会用到大数据处理、分布式存储等相关技术。整体来讲，仍是与本身以后想要从事的区块链领域有些相关性的，能够为本身以后的求职简历增长些相关项目经验。下面，咱们来分析几个区块链工程师的任职要求，来看看相关性。

 

 

---

　　分析以上岗位，咱们很容易发现，许多区块链开发工程师的应聘要求：对分布式数据库、分布式系统、分布式存储 熟悉并由相关经验者优先！

　　下面对相关概念进行下梳理：

Redis

Redis是一个key-value存储系统。和Memcached相似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操做，并且这些操做都是原子性的。在此基础上，redis支持各类不一样方式的排序。与memcached同样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操做写入追加的记录文件，而且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合能够对关系数据库起到很好的补充做用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。

 

KV数据库

KV数据库速览

　　这部分旨在简短的介绍K-V数据库，更详细的描述能够参考文章下方的引用部分。

　　K-V存储系统是最简单的数据库类型之一。几乎全部的编程语言都带有内置的K-V存储功能。好比C++中STL的map，Java的HashMap，Python的dictionary。K-V数据库一般包含下列接口：

• Get(key): 获取以前以"key"做为标识存储的数据，若"key"不存在则获取失败。
• Set(key,value): 将"value"存储内存中，其标识符为"key"，以便咱们以后能够用"key"来获取数据。若是在"key"下已经有数据了，那么原数据将被替换。
• Delete(key): 删除"key"标识下的数据。 

　　大多数底层的实现都使用了hash table或者是自平衡的树结构（好比B-Tree和红黑树）。有时候数据太大了没法放在内存中，或者为了防止宕机必须把数据持久化，这种状况下，就必须使用文件系统来存储。 

　　K-V数据库是NoSQL运动的一部分，它重组了没有彻底使用关系数据库中概念的众多数据库，Wikipedia articles on NoSQL  总结了这些数据库的主要特色：

• 不使用SQL查询语言
• 可能不对ACID规范提供彻底支持
• 可能提供分布式，可容错的架构

K-V数据库和关系型数据库

　　不一样于关系型数据库，K-V数据库并不清楚存储数据的值，并且也没有像MySQL和PostgreSQL中schema的概念。这也就意味着它不能像关系型数据库同样经过

使用带where的SQL语句来过滤并查询所存数据的部份内容。若是你不知道该从哪查询，你须要遍历全部的key值，找到对应的value，对其进行过滤，最终只保留你

想要的那部分数据。这样以来计算量会很是大，同时也意味着只有在key已知的状况下，K-V数据库才能保证高性能，不然其性能明显不足。（注：有一些K-V数据库

支持结构化存储，并且有域索引）所以，虽然在绝对访问速度方面K-V数据库优于关系型数据库，但须要已知key值的要求限制了其应用场景。

 

NoSQL数据库（Not Only SQL）

　　NoSQL(NoSQL = Not Only SQL )，意即“不只仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势愈加高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地 的关系型数据库运用，这一律念无疑是一种全新的思惟的注入。

　　NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了不少难以克服的问题，而非关系型的数据库则因为其自己的特色获得了很是迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤为是大数据应用难题。

虽然NoSQL的流行与火起来才短短几年的时间，可是不能否认，如今已经开始了第二代运动。尽管早期的堆栈代码只能算是一种实验，然而如今的系统已经更加的成熟、稳定。不过如今也面临着一个严酷的事实：技术愈来愈成熟——以致于原来很好的NoSQL数据存储不得不进行重写，也有少数人认为这就是所谓的2.0版本。该工具能够为大数据创建快速、可扩展的存储库。

 

NoSQL数据库的四大分类表格分析

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

详情参考：https://baike.baidu.com/item/NoSQL/8828247

 

SPARK（计算引擎）

　　Apache Spark 是专为大规模数据处理而设计的快速通用的计算引擎。Spark是UC Berkeley AMP lab (加州大学伯克利分校的AMP实验室)所开源的类Hadoop MapReduce的通用并行框架，Spark，拥有Hadoop MapReduce所具备的优势；但不一样于MapReduce的是——Job中间输出结果能够保存在内存中，从而再也不须要读写HDFS，所以Spark能更好地适用于数据挖掘与机器学习等须要迭代的MapReduce的算法。

　　Spark 是一种与 Hadoop 类似的开源集群计算环境，可是二者之间还存在一些不一样之处，这些有用的不一样之处使 Spark 在某些工做负载方面表现得更加优越，换句话说，Spark 启用了内存分布数据集，除了可以提供交互式查询外，它还能够优化迭代工做负载。

　　Spark 是在 Scala 语言中实现的，它将 Scala 用做其应用程序框架。与 Hadoop 不一样，Spark 和 Scala 可以紧密集成，其中的 Scala 能够像操做本地集合对象同样轻松地操做分布式数据集。

尽管建立 Spark 是为了支持分布式数据集上的迭代做业，可是实际上它是对 Hadoop 的补充，能够在 Hadoop 文件系统中并行运行。经过名为 Mesos 的第三方集群框架能够支持此行为。Spark 由加州大学伯克利分校 AMP 实验室 (Algorithms, Machines, and People Lab) 开发，可用来构建大型的、低延迟的数据分析应用程序。

　　 Apache Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架。

　　与Hadoop和Storm等其余大数据和MapReduce技术相比，Spark有以下优点：

首先，Spark为咱们提供了一个全面、统一的框架用于管理各类有着不一样性质（文本数据、图表数据等）的数据集和数据源（批量数据或实时的流数据）的大数据处理的需求。

Spark能够将Hadoop集群中的应用在内存中的运行速度提高100倍，甚至可以将应用在磁盘上的运行速度提高10倍。

Spark让开发者能够快速的用Java、Scala或Python编写程序。它自己自带了一个超过80个高阶操做符集合。并且还能够用它在shell中以交互式地查询数据。

除了Map和Reduce操做以外，它还支持SQL查询，流数据，机器学习和图表数据处理。开发者能够在一个数据管道用例中单独使用某一能力或者将这些能力结合在一块儿使用。

 

详情请参考：http://dataunion.org/13853.html

 

分布式存储

　　分布式存储是一种数据存储技术，经过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。

 

详情请参考：https://baike.baidu.com/item/%E5%88%86%E5%B8%83%E5%BC%8F%E5%AD%98%E5%82%A8/5557030?fr=aladdin

 

Docker容器

　　Docker 容器是一个开源的应用容器引擎，让开发者能够打包他们的应用以及依赖包到一个可移植的容器中，而后发布到任何流行的Linux机器上，也能够实现虚拟化。容器是彻底使用沙箱机制，相互之间不会有任何接口（相似 iPhone 的 app）。几乎没有性能开销,能够很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架包括系统。

 

高并发、分布式系统特色：

如今不少高谈阔论，高并发，大流量，分布式，SOA，名词一大堆每每抓不住要点，对于熟悉的人来讲，言之无味，而对不熟悉的人来讲，更相似大师讲法，除了增长神秘感外，让人愈加无从了解。

其实这些问题，本质是成本收益的平衡，严格说，这其实就是所谓技术最关注的问题， 
正由于没有银弹，没有统一的解决方案，因此任何系统都要结合业务自身特色，与软件，硬件平衡一块儿考虑完整的解决方案。

能够从一个典型的电商平台来分析，

假如，从无到有，有足够人力时间，并且目标也很是明确，一个支持海量商家，海量用户的，海量商品的平台，应该怎么设计？

1.前端接入 
只要高并发，即使所有是静态页面，哪怕只有一个文件，海量的并发链接也是必须首先解决的。 
这个方案相对比较成熟，能够经过负载均衡，简单增长web服务器，承载浏览器链接。单台服务器nginx能承载的并发链接大体5000到数万， 
根据优化状况，能够简单算出到底须要多少台机器。在用户使用浏览器的状况下，这里几乎没有取巧的地方。 
若是不能接受则只能考虑专用客户端，经过长连接，甚至UDP这类协议，来本身实现。

2.一旦请求所有接入了，就须要考虑处理问题 
若是应用很单一，那么应用服务器就能够简单扩展，相似接入的web服务器，单台时间能处理的请求数，和单位时间总请求数，便可算出须要多少应用服务器，固然通常场景每每与用户相关，这里最重要的就是要解决，应用服务器无状态的问题，这样才能无缝扩展，任何web接入的请求，能够随便找一个空闲的应用服务器丢过去。

典型的，能够把用户相关的信息保存到专门的状态服务器中，请求时仅仅经过cookie提交一个令牌，用令牌从状态服务器得到对应用户的信息。

状态服务器，有一个天生的优点，就是各个用户数据之间每每隔离的，当单台服务器抗不住时，简单增长状态服务器，而在应用服务器上简单根据用户id或令牌，计算出对应的状态服务器便可。

状态服务器能够充分利用各类NoSQL服务，好比典型的Redis，这里系统设计与业务需求就要综合考虑了。

A 若是偶尔丢失状态，能够接受，redis便可配置成不持久化。此时效率最高。 
万一状态服务器挂了，应用端，简单该向请求到新状态服务器，用户从新登陆便可，不会中断太长服务。

B 若是但愿尽可能少的丢失状态，那么redis就应该按期持久化，并作复制。 
这样某台状态服务器挂了，能够根据状况，选择恢复主服务器，中断一小段时间，数据最完整，或备用状态服务器接管，快速恢复服务，数据可能多丢失一点点。 
大部分用户彻底感知不到，个别用户从新登陆便可。业务中断也很小。

若是有可能，作成自动切换，会更高效率，可是必定要注意，不是什么都自动的好，若是没有积累，你写的程序，每每没法考虑大量意外，在“正常”的异常状况下可能切换很好，可是更多的异常状况下，有可能更糟糕。

C 若是要求绝对不能丢失状态，容许中断服务一段时间，redis能够配置成每次都持久化。持久化的硬盘也作冗余甚至作成共享存储。 
若是出问题，由于数据都没有丢失，系统重启或更换其余硬件，全部状态便可恢复。可是显然此时redis处理能力将大大减弱。

D 若是要求绝对不能丢失状态，尽可能减小中断服务， 
redis能够适当本身改造，将数据成功推送到备份服务器上，且备份服务器持久化以后，再返回成功。那么理论上，当主服务器挂掉，能够马上切换到备份服务器上，而不丢失数据，用户也基本感知不到变化。固然如何判断主的挂掉，这里仍是有大量陷阱，处理很差，反而更多的中断服务。

若是去问一个不太了解技术的产品，这个用户状态到底什么要求，他极可能认为D是理所固然的，由于他彻底没有成本意识。 
实际上对于大部分系统，A,B都是更佳的选择，不管对于开发者，运维者，仍是最终用户。

A,B简单，所以可靠，不容易出其余问题，开发成本低，运维成本低，最终更稳定，致使最终用户更满意。

只有用户量足够多，技术团队，运维团队足够强，有能力实现更好的D，这时候D才是对产品来讲更好的方案。

3.应用的拆分 
到2，实际上解决了绝大多数系统的并发问题，由于能够简单的经过增长硬件来扩容。 
可是当应用原来越复杂以后，让一个应用服务器包含全部的服务，是很困难的，从运维成本上考虑，必然有很大浪费，由于每一个服务使用频率不同。 
一些，不太经常使用的服务，可能所有集中到两台服务器上就足够了，这样从其余大量服务器上将这些服务去掉，至关于整个系统节省大量内存。

而从开发角度，也必然是10个小项目每一个10人维护，比100人维护一个大项目更容易，所以从开发角度也要求拆分应用。

拆分应用，虽然有些技术辅助手段，但实际主要仍是依赖业务自己的分析，技术仅仅是辅助，好比解决各个应用系统之间数据同步问题，跨系统RPC问题等等。

而流行的SOA，则会努力将服务拆成更小而独立的服务，一方面提升功能复用，另外一方面便于开发维护，也方便运维管理。

可是这里有一个误区，认为服务拆分得越小越好，其实，从理论上，服务怎么拆分，传统的面向对象已经指明了方向，低耦合，高内聚， 
说直白些，就是要善于封装，面向对象历来不是类越多，方法越多越好。

所谓SOA治理，关键仍是业务梳理！

4.持久化问题 
若是说上面各类问题，目前技术均可以给出比较理想的解决方案，那么持久化瓶颈问题，却始终是最大的问题所在。 
前端接入服务器，应用服务器，均可以很好的横向扩展，而状态服务器，也由于其特殊性（持久化能够不太严格，数据之间无关联），也能够比较好的横向扩展。

而典型的联机交易系统，老是要求数据一致性的，没有产品会说偶尔用户帐户上少1分钱，是能够接受的。

传统的银行系统数据库系统，会选择更快的专有共享存储，多机互备，将数据实实在在的写到可靠存储里，存储经过raid方式来保证冗余防止单硬盘故障， 
当主机故障时，不管软硬件，简单将共享存储挂到备机上，来完成切换。

从安全角度，这种方案是很是高的，可是有两个问题，一是价格昂贵，二是系统容量仍是有限。

这种方案，其实就是目前大多数云平台提供给中小系统的解决方案，只是用云存储代替了传统昂贵的共享存储。 
若是你的系统能够用云平台的数据库系统或者强劲单机来提供，其实这就是一个合理的好方案。不管你是租用云主机，仍是本身弄个物理机。

可是若是系统规模足够大，云平台提供的单机没法知足，或者其云数据库也没法知足（或者仅仅是由于价格过高），那么仍是要想办法本身来实现。

首先，存在这样一个大数据库相似传统单机数据库那样，能够无限横向扩展吗？ 
在我看来是不存在的，由于传统单机数据库，重要的就是提供严格的事务支持，多机分布式事务，要想简单横向扩展，至少目前看来是很困难的。

CAP原则指出在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。 
而三者如何权衡，仍是要依赖业务！而不是技术。

固然目前由于技术问题P是没法避免的，因此问题每每简化成CA的选择。

对于电商系统，从业务角度，A每每不能舍弃，而C则能够根据业务设计成最终一致性。

好比，购买业务，若是用户帐户钱一扣，他的订单就应该是支付成功，单机上这点经过事务很容易实现，可是对于分布式系统，若是作这样的要求，用户未必高兴，由于假设订单系统出了些问题，订单没法更新状态，那么此时只能将用户成功的支付也取消掉！

对于一个庞大的分布式系统，要保证每一个系统都正常是不可能的，因此即使放弃A，容许任何一系统故障，整个系统暂停以保证数据一致性，从实际角度看也是不现实的。更不要说，参与系统越多分布协调成本越高，最终多是即使全部系统都正常，其处理速度也彻底没法接受了。

反之，若是支付成功了，容许订单状态暂时没变，就能够等待订单系统恢复后，再将其状态修改成成功。经过业务设计，避免分布式事务，不光获得最大限度的A，也提升了整个系统的处理能力。 具体细节可参看《多数据源之间不使用分布式事务实现异步最终一致性》

用户会不会容忍这个短暂的数据不一致呢？钱付了，订单状态却没马上改。

会的，其实现实中他们常常这样，之前去汇款时，本身的钱马上交了出去，可是对方却没马上收到，过几天后，对方才收到，或者对方不在了，汇款再退回。

固然另一些最终一致却不会被接纳，好比，若是存在一段时间，订单先支付成功，用户余额却没扣。

此时用户便可用没扣的余额去购买其余商品，这是系统巨大的漏洞。

因此必定是要和业务结合才能解决现实问题，也所以，在持久层这里，不要指望一个完整的分布式强数据一致性的系统，而应该学习现实世界的实现方式，分析业务，找到能够接受的最终数据一致性方案。

只要能接受最终数据一致性方案，那么就能够将存储系统拆分红多个相对独立的子系统，每一个子系统内都是传统的强一致性严格事务实现，而各个系统之间则经过相对松散的消息机制来互动。任何一个子系统均可以故障，操做能够在其余系统被cache，要么随后恢复，要么超时取消。

其实很典型的例子就是第三方支付系统，每一个系统都会对接，显然这是两个彻底独立的系统,甚至全部者也不一样，可是对于支付业务的确很好的实现了，是一个真正意义上的分布式系统。

总结

对于一个电商平台，能够大体描述一下其基础架构， 
1.一个接入的web集群，用来接入连接 
2.一个状态保存系统 
3.拆分红多个相对独立的应用系统，每一个系统都无状态，可横向扩展。 
4.根据应用和数据规模，将数据拆分红多个相对对立的存储系统 
能够是相似：用户系统，订单系统，支付系统这样按功能拆分， 
也能够再拆分红：用户1系统，用户2系统…这些系统功能彻底一致，只是保存了不一样用户群的数据

其中每一个存储系统本身负责容错，不一样存储系统经过应用系统经过内部消息来衔接，老是假定其余系统可能故障，也就必须考虑恢复或冲正。

这一切，尤为是3和4显然更多依赖于业务的分析与设计，那么从技术角度，最终的系统就是一个彻底分布式的系统，能够支持几乎无限的扩展。

而某些技术，热门中间件，框架，其实仅仅是一个技术手段，并无想象的那么重要。