- 前序：
手记血泪史：2016年底~2017年是自己技术生涯的元年，所以逼着自己写一般书籍（原打算，后来发现自律性和俗事太多最后没有实现），当时一直关注FinTech个方面的内容，所以决定先写大数据方面的一些自己的认知和感受。 后来由于时间等关系也没有全部写完，中间有一年多工作格外的忙所以基本上没有写，今天发现写完的可能性也没有来，所以今天决定还是以博文的形式和大家分享吧！！！全书大概是 2016年12月份开始筹划纲要和前面的几个章节，最后止于 2017年5月28日（一个特殊的日子），基本只完成了第一章~第三章，第八、九章，四、五、六章三个章节仅仅搭了提纲，很遗憾，后面由于精力关系很难完成了估计，今天整理了第一、二章内容，后面会陆续跟上，排版有些繁琐，懒得排了。文中只是个人的看法，仅仅代表个人观点，不对之处请各位为包含。
目 录
2.2.2 基于集中式的分布式（集群式）处理思想 - 4 -
6.4 Maxcomputer/Streemcomputer - 20 -
- 研究背景
- 概念炒作、群雄逐鹿
互联网、互联网＋、金融互联网、互联网金融、FinTech，近5~8年各种新概念不断涌现，昨天还是比较火热的金融互联网/互联网金融，今天貌似石沉大海，最近FinTech又是格外的火爆，国务院专门成立了科技金融处来推动相关技术和产业发展，做为一个技术性公司，或者说技术人员，我们如何能跟上技术的发展不被行业所淘汰真的应该值得我们每个人思考。
- 追本溯源
在这个信息爆炸的年代，各种垃圾信息堆积，各种为了不存目的地概念炒作，我们做为一个技术性公司或人员必须要擦亮眼睛，抛开概念深入本质，追本溯源的研究各项技术原理，只有深入研究才有发言权，才能在概念退潮时保持技术不落伍，不被淘汰。比如上文提到的金融互联网和FinTech概念，为什么之前谈的金融互联网突然不谈了呢？其实抛开金融互联网这个包装名称，金融互联网里到底包括那些技术才是事物的本质，在过去谈的金融互联网这个大概念下，应用的技术包括：AI、云计算、大数据。突然比特币的火爆打破了概念平衡，因为比特币提出了分布账簿和加密货币技术（利用Map寻址机制而已），所以就出现了FinTech概念，为的就是涵盖AI、云计算、大数据、区块链等四项技术。
- 大数据的前世今生
要谈大数据，就不得不谈数据仓库和BI，因为业务预测分析火爆了大数据，在大数据的4V（Volumes/variety/velocity/value）标准里，你发现条条都是针对传统数据仓库和BI的缺陷，传统数据仓库如果数据大到一定量时做离线BI分析可能跑一个月的分析算法也跑不出想要的结果，也正因为如此才出现了针对海量数据，高速分析，结构即非结构化数据，也就是说大数据技术的出现还是在原先数据仓库和BI业务的需要发展而来的，因此不存在颠覆性技术，爆炸性技术，一夜之间出现的，当然也正因为互联互通信息的爆炸性增长才触发了这种针对新要求的新技术。
从本质上说，大数据的本质是：在全量样本的基础上进行概率计算而得出导向性价值，这些本质概念无一不是过去分析型系统追求的目标，我们知道分析的准确性很大程度是依赖取样样本，过去的分析数据样本不足，导致在一些应用场景成为了鸡肋，大数据的出现解决了在足够多的数据样本的基础上高效的计算出结果，例如在一元线性回归计算模型和多元非线回归计算模型下，分析结果的准确与否与你的样本量有着必然的联系。
未来系统架构一定是包括两类系统一个数据组合层：两类数据分别是：数据生产系统和数据消费系统，一个组合层：用于成接数据生产系统和数据消费系统的中间层，相比较来说面向数据消费的系统更容易产生创新业务，数据服务的组合与重组能够快速的形成新业务生态，这种面向数据消费的企业数据架构会将更敏捷，更直接的参与企业的业务生产经营活动，而不像传统的数据中心仅仅为管理决策服务。我个人认为，在这些创新系统中，有一类智能分析反控系统会首当其冲的作为典型的智能化应用推出 ，但基于这种面向数据消费的数据架构，智能影响反控系统恐怕仅仅是开始，未来在这种架构的推动下推陈出新的新业务系统 ，如雨后春笋般的冒出，想象一下，基于数据服务组合快速形成新型应用将倒逼企业组织结构的变革，并不是仅仅现在的数据分析，大数据平台数据分析，分析也仅仅是这类系统的一种，基于数据的业务系统可能产生营销系统，新型制作系统等等……这与传统的IT系统是不一样的，是既包括信息架构又包括数据生态架构技术，也就是未来一定有基于数据生态的新型业务系统，而这个业务系统才能体现数据企业数据本身的价值，而不是现在简单的做一下分析f辅助，这种对于当下企业能有多大价值有待商榷，现阶段我们能想象出未来新型业务模式到底是什么吗？我想有人可能能预测出一些端倪，但大部分的预测、预言都是水中花，不靠谱，与其绞尽脑汁的想像虚无缥缈的未来新业务，不如想想基于什么样的数据架构能够更快速，更轻量的支撑业务创新，也就是尽快搭建基于面向消费数据的数据架构才是王道，有道才能有王，不建道，哪儿能有王呢？真理：“业务为王，数据为道”。
-
-
- 传统数据与大数据如何做数据流通
-
传统数据必定需要专门的中间系统将数据进行平稳、高效的入大数据生态系统中，目前能能承担这样的数据中间缓冲抽取的平台包括：Flume尤其擅长日志的抽取，各种离线ETL工具比如：DTS/kettle/Sqoop/DataX，流式抽取Kafka Connector等。
-
-
- 系统之间的数据流通
-
现在主流的系统整体架构都采用按业务差分不同的系统，系统拆分以后，应用系统本身的数据就会分散，那么就会遇到一个问题，一些业务公共数据该如何获取，当然可以开放一个公共数据平台供个系统查询使用，但是实践过程中发现，这种模式遇到一些瓶颈，就是数据交互效率比较差和接入控制难管理（比如记录锁控制混乱等），系统切分的越细遇到问题就越明显，此类问题在各行各业的信息系统架构都遇到了问题，因此基于“生产者/消费者”和“消息订阅”思想的系统出现了，以Kafka+各种MQ(RobbitMQ/ActiveMA)用于解决这种问题，多个生产者可以将公共数据消息写入消息总线，消费者可以随时订阅消息接收，框架支持多种消息写入模式和各种消息序列化和反序列化模式，并且保证数据完整性、顺序性、SSL加解密等等特性。生产者写入消息和消费者获取消息的模式，可以统称为如何通过RPC模式实现跨系统获取信息，目前支持的模式比较广泛，比如Agent模式，内嵌SDK模式等等。
2.数据架构的演变之路
- 数据架构在应用系统的重要性
过去设计业务系统时，设计人员把主要精力都放在了业务系统结构设计上，很少提及数据架构的规划与设计，针对底层数据建模仅仅是为了实现业务而简单的进行了表设计，有些系统虽然进行了表关联设计，但是只做到了逻辑建模，未来随着大数据，高并发的服务要求，系统面临着各种潜在性能问题和业务连续性问题，因此做为一个健壮的、稳定的应用系统，必须认识到数据架构设计对于系统的重要性，比如读写分库的架构设计，分区表的运用，高速缓存的使用，多实例、多节点的支持，这些都需要从数据架构建模时就要考虑，如果你的数据架构建模不合理对于未来系统发展的指标要求很难满足。
-
- 系统设计之数据架构设计
- 分布式数据架构VS集中式数据架构
- 系统设计之数据架构设计
CAP原理：在分布式计算（存储）的架构里，由于网络引起的时延是必然的（Partition Network Toleration），因此对于一个操作在数据一致性（C=Consistency）和数据可用性（A=Availability）方面必须取舍一个。
目前CAP原理在过去以及未来的一段时间内都是适用的，并没有因为新型数据库的出现打破其科学原理，尤其最近互联网中吹嘘分布式数据库的出现是革命性的，对于这个问题我们应该冷静看待，不可否认分布式数据库的出现对于一些应用场景确实起到了决定性作用。我们要构想分布式架构应该从两个方面深度思考与探讨，第一、运行实例的集群多活；第二、数据的分布式(集群式)。
集群多运行实例应用：现在的应用运行架构上一般都会把应用处理和数据处理做分离，为了支持高可用性和处理动态扩展，一般都会把处理进程分布在集群中，比如：硬件集群F5架构和Redware，这里的集群多实例设计时需要考虑两个问题：第一、应用文件落地问题；第二、内存数据同步问题；对于文件落地问题解决方案比较简单，通过共享存储方式可以很好的予以解决，另外，一些应用系统中有很多新数据类型需要保存，比如：Json/XML等，设计时需要仔细考虑，保存这里数据不一定要用外部文件保存，其实完全可以保存在数据库中，现在一些数据库可以支持Json/XML类型数据，比如：PG和GP数据库，而后选择ORM(SSH/SSM)框架选择时要考虑映射类型如何适应这种类型；对于内存同步问题解决方案比较复杂一点，需要从两个方面考虑选择，1.应用内置缓存选择机制，这种方式比较适合缓存数据变化少，变化实时性要求不高时使用；2.使用基于内存的缓存数据库，比如:Memcached/Redis，使用这类架构时应用架构要复杂一些，应用至少要支持多数据自动切换。
集中式数据库：信息数据的集中是现在发展的主流思想，各行各业的信息化建设都在做或已经完成了信息数据集中共享建设，通过信息数据集中打破信息社会信息壁垒已经成为社会的共识。过去的信息数据不论是量，还是形态都是比较固定的，增长变化都是相对缓慢的，另外，很多信息化建设走的比较快的行业，对于信息数据的一致性，准确性要求特别高，因此采用集中式的事务性关系数据库是必然的选择，这类数据库的核心原则就是ACID（代表Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性，是实现实时强一致性的基础）原则，代表：Oracle/Mysql/ MariaDB /DB2，这种类型的数据库为了保证一致性很多都采用MVCC（Multi-Version Concurrency Control）为理论依据进行数据多版本控制的，但是原则上都只支持单点单库事务一致性。
分布式(集群式)数据库：随着互联网的大众普及数据的量和形态都发生了巨大的变化，量比过去大了很多倍，形态出现了无固定结构数据，应用中又要根据这些数据进行查询统计分析，因此总总，出现了集群式数据库，我更愿意说这类型的数据库为集群式，而不是分布式，当然名称其实真的无所谓。准确说其实不存在真正意义上的分布式数据库定义标准，每种分布式数据库都是基于某种应用而开发的，大部分的分布式数据库都是牺牲了事务性而提升了读写效率，其中以Google的Bigtable为理论依据实现的Hbase和HpyerTable( 目前版本只支持查询)，如果完全不牺牲事务一致性，一般采用二次提交技术来实现分布式事务，这种就严重影响数据处理性能，所以如果你的应用场景是以查询统计为主，对于事务要求比较弱的情况下，可以采用这种类型的数据库来提升数据的可用性和分布式性，典型的应用是监控查询告警。在实际应用中还有基于分布式算法类型的数据库，其中基于Paxos的OceanBase（据说是阿里的支付宝应用在上面跑，但是是否是资金系统很难说）数据库是个不错的选择，然而这种类型的数据库并不一定适合强一致性的应用场景，这种场景还是要牺牲分布性，强调一致性的集中式数据库。
-
-
- 基于集中式的分布式（集群式）处理思想
-
基于集中式数据架构是否就要完全牺牲高可用性呢？这个不一定，即使是集中式数据架构也要考虑数据的可用性，目前在强调数据一致性的应用场景下，一般提供了两种数据高可用性架构：主备架构和数据双活架构。
给我们的启示不仅仅考虑数据架构的技术问题，应该考虑应用架构改如何合理设计能既满足一致性的前提下，又能保证一定的可用性，如何通过一定的分散处理机制来提高数据的高可用性和系统处理性能是我们做系统架构设计必须考虑的问题。
- 双活多数据中心架构和主备架构
Oracle提供了RAC技术用于实现高可用性的双活架构，此项技术的原理是通过高速网卡完成数据同步，主节点出现故障时从节点自动工作。
DB2提供了GDPC技术用于实现高可用性的双活架构。
高可用性架构解决了什么问题：不管是主备架构还是双活架构，只是解决了数据的高可用性，对于单点处理瓶颈并不能提供很好的解决方案，所以对于大型交易型系统的批量处理场景还要另辟蹊径。
- 批处理的集中式&分布式
上文已经说过，对于应用系统系统架构一般是采用多处理实例＋集中式数据库架构，在实际应用场景中很多应用场景都会涉及批量业务处理，那么如何提高应用批处理效率成为一个值得研究和探讨的议题，现在来看解决这个问题，基本就是两种思路，处理与数据分离模式和处理与数据集中模式。
处理节点与数据库节点分离模式下，数据的交互是通过网络传输的，通过增加并发处理节点来提高并行处理效率，其中通过何种节点切割算法来切割处理节点就显得非常重要，这种模式单点处理效率并没有得到特别大的提升，而且增加了网络开销，所以如果某个节点处理数据量比较大，那单业务处理效率不降反升。
处理与数据集中模式下，也就是业务处理进程与数据库进程在同一台服务器上，数据的交互是通过进程间内存传递的，单业务的处理效率一定比分离式要高很多，但是业务处理和数据处理在一台服务器上存在着资源竞争问题，另外，单节点处理技术选择的不同差别也会比较大，一般的处理模式包括JDBC、ODBC、嵌入式API、存储过程，处理效率由由高到底：存储过程>嵌入式API>ODBC>JDBC，其中处理语言的不同其差别也比较大，经测试C/C++的处理效率比Java的处理高10倍左右。
混合处理模式是必然的选择，针对单系统设计时如果有批处理业务，且有一些业务处理的数据量比较大，那么一定要考虑单节点处理效率和整体处理效率，根据上文所分析，完全集中和完全分离都面临一定的问题，所以采用混合处理模式来彻底解决这类问题，其中通过集中式处理模式来提高单业务处理效率；通过分散来提高资源竞争压力；具体来说：上层的调度平台负责调度整个批处理逻辑，单业务大量数据量的业务，采用数据库集中式调度，可以显著的提高单业务处理能力，尤其采用数据库内置存储过程其处理效率将得到非常大的提升，针对可以进行数据均匀拆分的业务可以采用处理分离方式进行调度，减少对数据库服务器的资源消耗，并且处理节点的水平增加将会有效的提升整体处理效率。
- 读写分离架构(分库处理)
目前应用系统设计时所有的表都在一个数据库中，现在有一些系统为了提高应用系统的处理效率和方便数据管理，将数据拆分成几个库，每个库对应不用的业务处理，比如：把历史查询在备机上查询，以降低主数据库的性能压力，但仅仅简单的根据业务把读数据库和写数据库分开，在大部分的场景下并效果不一定好，多数据源架构的思想在其它的一些应用场景相信更合适，比如：一个平台下为多个接入用户服务，相互之间数据关联性很小，我相信这种业务模式下应用架构相似，数据库拆开更为合适。
这种读写分离的思想一部分是借鉴了互联网架构的思想，一些银行也确实进行了实践，比如流水查询，打印等等业务分库处理，但根据实际反馈，由于数据同步的实时性问题，业务人员运用的并不多，不过也确实也减轻了主服务的压力。
为了提高数据库的管理效率和处理性能，数据架构设计是一定要进行表空间规划，好的表空间规划将大大提升应用系统的处理效率和后期维护效率，表空间到底如何规划其实应用系统本身关系非常大，每个表空间可以设置独立的存储页大小，对于单条记录大的表其表空间的页缓存可以设置大一点，对于单条记录小的表空间页缓存可以设置的少一点，至于是否要设置很多表空间也不一定，这里提供几点设计建议：
历史表空间：存放不常用数据，并且结合分区表对数据进行高效管理。
索引表空间：专用用于存放索引的表空间。
常用主表空间：专用用于常用表数据
- 分区表&分表
数据架构设计时不得不考虑数据量变大的情况下，单表的处理能力会有巨大的影响，一般设计者会考虑到水平记录的增加将对于数据库的性能有影响，其实，单表数据量的增加不单单要考虑记录数的增加，还要考虑横向列的增加也会对数据操作有巨大影响，一行记录占的字节数多少，同样会影响数据库的读写性能，所以设计一张表时字段不宜过多，必须要根据页缓存的大小来规划自己的最大记录数，避免出现记录缓存换页。对于水平记录数过多的情况，解决这类问题一般有两种思路，第一、采用数据库的内部机制分区表，分区表逻辑上是个整体，外部使用和普通表没有区别，开放性数据库一般投提供分区表，对于AS400中，多Member类似于分区表；第二、业务分表，物理上已经分成不同的表，外部使用需要根据分区键值拼接表名；一般情况下，采用分区表基本能解决数据性能问题和数据管理问题，比如系统的流水表，可以采用按日期进行分区，可以提高系统的读取效率，采用分区卸载/装载可以方便数据管理。有一些情况为了提高数据库的处理效率，物理上根据一定规则把业务数据装入不同的表中，使用时根据一定规则确定访问表名，常见的分表分区规则：
按日期：流水类表可以根据日期或时间分区/分表。
按Hash分：按照业务要素Hash分表，比如按照账号Hash分区/分表。
按机构分：按用户归属机构分
按数据量大小分：按照固定数据大小进行分区，这种方式一般不能用于分表
- 数据表维护的关键操作：
索引的重要性：为了提高数据定位效率，所以表设计时一定要如何建立好的索引，以提高数据处理效率，索引不是越多越好，建议单表不超过5个索引。
表/索引重整的重要性(reorg(table/index))：数据库的删除操作往往一般都是逻辑删除，记录占的空间并没有得到释放，DBA为了提高数据库的写入效率，一般都采用追加写入模式，这种模式对于已经删除的记录空间并不能很好的重复利用，所以表空间会越来越大，当然有些业务中删除操作是很少的，可是数据清理入历史时往往会产生这类问题，所以为了提高空间利用率，一般要对碎片比较大的表进行定时重整，现在很多数据库都支持在线reorg。
运行统计信息：SQL执行时一般依赖查询优化器产生数据定位执行计划，数据库根据解析到的SQL和数据运行统计信息来选择使用合适的索引，这里有一个问题，如果运行统计信息更新不及时，不准确产生的执行计划完全不同，那么数据访问效率差别巨大，另外由于同一张表支撑不同的业务，比如联机业务和批量业务，其产生的统计信息并不一样，同样的SQL如果在联机服务中使用执行计划采用了A索引，在批量处理中突然可以就会切换成B，这就是因为运行统计信息发生了变化，所以一些系统设计时，处理某些业务时专门重新获取运行统计信息，一般的数据库都提供，例如：DB2的runstatus，Oracle的dbms_stats，最后要提醒设计者，有一些特殊业务自动生成的执行计划不可靠时，一般都会通过指定索引的方式确保数据的高效性和稳定性，一般的数据库都支持指定索引处理。
- 视图的使用：很长一段时间我发现数据库视图似乎被我们的设计人员遗忘啦，一些系统中经常有多表关联查询，而且使用特别频繁，但是我们的技术人员好像只会用关联查询，写的SQL非常复杂，每次关联查询处理效率比较低，程序中的处理逻辑也比较复杂，在这里我想提醒我们的设计者，在数据库设计时不要忘了还有视图可以使用，要搞清楚实体表和视图的使用场景。
基于Google的BigTable思想：HBase(Java)/Hypertable(C++)目前版本支持单表查询，这种类型的数据库共同的特点支持多节点集群处理，但仅仅支持单行事务，后期为了支持分布式的跨行跨表事务，推出了Percolator数据库，其主要是通过二次提交来实现跨节点分布式事务，但处理响应时间在2秒以上，性能比较差。
基于Paxos算法的集群式数据库：阿里在2010年6月份由阳振坤（俗称阳老师），带头开发OceanBase，目前0.5(http://code.taobao.org/p/OceanBase/src/ )版本开源了(https://github.com/alibaba/)，据官方说明适合金融领域使用，其实OceanBase的是在Mysql上增加了集群处理技术，单点控制基本上是用以前开源的Mysql改造的，当然后期增加了很多自研发的功能，但是成熟度还有待考证，从本质上分析我人为，现在的OceanBase在银行领域使用并不适用，理由有以下两点：第一、上文说的CAP原理OceanBase并没有突破，也就是注重了分布式和可用性，那么一致性肯定会有损失，而银行业过去几十年的技术架构一直强调强一致性的重要性，这就与银行业的业务产生了冲突；第二、支付宝等业务的处理过程其实是相对简单的，一般设计买家、卖家，而银行的业务处理一般都会涉及多个账务实体比如：客户帐、内包账，核实等等，这种业务模式下更新操作特别的多，按照OceanBase的架构这种操作基本都发生在UpdateServer上，因此并不可能提高数据的处理效率，另外如果UpdateServer出现问题，那么单点故障无法避免。这种类型的数据库比较适合做少量更新大量查询的业务。
基于Nosql的非关系型数据库：MonogDB，如果说前面介绍的集群式数据库在数据存储结构上与传统的RDB相似，那么现在由于一些非结构化数据的出现，比如网页访问信息、图片信息等等，则完全改变了数据存储和检索的方式方法，一般的关系型数据库对于数据的检索一般是采用SQL语言，对于一些非结构化数据的相关性检索时SQL可能使用起来不一定方便，由此出现了Nosql（这里强调一下是No only SQL不是No SQL）数据库，这里数据库的出现对于数据相关性检索特别的快，而且比较方便，但是有一个缺陷就是每个不同的Nosql数据库都有自己的数据检索规则(API)，访问程序编写起来晦涩难懂，学习成本比较高。
分布式数据库存在的合理性：性价比应该是各种分布式技术得以出现的必要条件，如果当时Oracle平台的各种数据平台都是免费的，我想现在很多技术都不会出现，因为免费竞争，Oracle先后用收购手段消灭了Mysql和Java，虽然Mysql鼻祖良心发现又出來搞了MariaDB，但已不复当年之勇，反而使得PostgresSQL焕发了青春。互联网的各项技术的出现很多都是为了节省成本，比如云平台，通过廉价的PC机搭建服务器。另外由于很多新业务模式根本就不用考虑事务性，可以说根本就不用考虑数据库事务，业务中更多是关注并行快速分析，精准营销，这也为分布式数据架构创造了机遇。
在未来的架构设计时系统级的缓存技术一定会越来越重要，所有缓存思想就是避免从硬盘中读取数据，转而从内存中读取数据，以加快系统处理效率。缓存共享机制大致可以分为，进程内缓存，进程间缓存，跨机器缓存，针对这几种缓存技术做一下总结：
进程内缓存：运行进程启动时加载到进程独立内存内，线程之间数据是可以共享读取，处理时直接从本地内存读取速度最快，但缺点是只能在本进程内获取数据。
进程间缓存：通过共享内存技术可以是的同一台机器上实现跨进程间数据共享读取，速度比较快，但技术复杂，无法跨机器使用，尤其在应用集群部署模式下很难使用。
跨机器缓存：一些独立的缓存平台可以跨主机使用，尤其在目前集群架构模式下一般都会考虑使用这种架构来提升系统处理效率，但这种模式相比进程内缓存和进程间缓存处理速度最慢，会消耗网络流量，目前比较主流的两款缓存平台Redis和Memcached。
建议总结：一、一些变化少的或者变化不需要立即生效的数据建议可以采用进程内缓存加手工刷新和自动刷新的方式来最大可能的提升性能；二、共享内存缓存建议尽量不用使用，尤其现在的系统都要提集群架构，所以不要用这种缓存技术；三、一些数据不但只是简单的数据缓存，而是要涉及到数据计算操作，这种情况下完全可以用Redis或者Memcached缓存技术。
扫一扫
4013
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
