FinTech研发报告-之大数据技术（第三章）

1. 大数据生态

前面一个的章节重点介绍了传统系统设计中数据架构的变迁与发展，或者说重新对数据架构设计进行了总结归纳，叙述的内容主要是以分布式架构作为切入点，来重新认识了应用分布式和数据库分布式的重要性，通过前面的探讨，我们能发现其实要不要分布式，或者说到底什么架构才是真正的分布式架构其实并不重要，我们是要通过前面的分析探讨让大家能认识到，架构是死的，实际的应用场景下要灵活掌握，灵活运用，尤其对于现在比较火热的分布式数据库的要有清醒的认识。

这个章节我们进入大数据技术的分析和探讨，相比大数据技术一词，我更愿意说大数据生态，大数据并不是某个单项技术或者技术平台，而是由一整套庞大技术生态共同组成，针对不同的应用场景选择不同的技术组合使用，尤其对于应用系统，使用大数据技术的难度在于生态架构选型和搭建，而不在某项单项技术上。

1. 1. 生态抢占的重要性

大数据技术的选择和以往传统技术选择不同的是，大数据平台的选择其实是平台生态的选择，目前业内的大数据平台大一部分是在开源技术Hadoop生态上进行二次封装的，一些成熟的平台有完善的配套平台和技术，有一些则显得比较薄弱，在大数据领域，各家厂商更多的是要抢占整个生态市场，国内比较完善的大数据生态中，阿里该是首屈一指了，从数据传输工具DataX到，分析型数据库MaxComputer（比较尴尬，有pg/gp数据库又有自己的这个数据库很是奇怪），反观腾讯和百度就逊色很多了，尤其百度作为搜索引擎尽然在大数据领域无所建树，真是匪夷所思，百度未来的技术投资更多用于AI方面，后面的章节我重点分析一下阿里的大数据生态和Hadoop生态，由于篇幅有限其它大数据生态技术就不展开分析了，尤其是亚马逊，我想在后面的云技术分析报告中作为重点分析对象。

在大数据技术的运用中，首先要明确自己选择什么样的大数据生态平台，比如你选择了阿里，就决定了你的数据使用是要遵循阿里的规则，使用的支撑技术都是阿里提供的，当然有些阿里没有成熟的技术时会提供原生态API接口。如果选择了开源的Hadoop生态，那么就意味着各项技术都是原生态技术，需要自己进行封装组合使用；如果选择了阿里，那么就意味着大部分技术是使用阿里提供的（基于原生态二次封装的），另外，就是使用模式上一般来说数据是要入阿里云平台的，没有办法独立使用某一部分，是一个重度封装的生态平台，这种模式很大程度上让一些自建数据平台的企业无法选择阿里。

1. 1. 如何选择大数据技术

前面说过大数据技术选择其实就是一个生态的选择，所以到底选择专业的商业软件，还是选择原生态的开源平台，这个其实要根据应用场景和自己的现状来决定，总结来说包括如下几种情况：

1. 大型企业

对于大型企业由于其安全性、可控性等方面的要求，信息化生产系统一般都是自己独立建设的，有自己的生产数据中心，企业内的数据挖掘、分析也在内部进行，当然也有个别业务把数据外传到其它平台进行分析的，但由于存在数据泄密风险，所以总体来说大型企业的数据挖掘基本都在内部平台中进行，比如银行、证券、运营商都是如此。如果是这类公司选择大数据时该如何选型呢？到底是选择开源生态呢？还是选择商业生态呢？这里面要区别对待，对于一些有雄厚技术实力的企业，一般来说会自己在开源生态下选择合作伙伴一起建设，对于技术实力不足的公司，一般会选择可靠的大数据商业平台来作为合作伙伴，选择了商业服务厂商的有点是，后期的维护服务比较有保障，但技术有技术限制，只能选择合作伙伴的技术生态，日后的扩展可能受到一定的限制。对于这种大型企业来说建设全企业的分析系统总结一下几点：

1. 数据中心自建，所有的数据流转都在企业内部进行，这与互联网公司不太一样。
2. 有实力选择完全开源合作开发项目
3. 实力较弱选择服务厂商平台进行二次扩展开发

1. 中小型企业

对于中小型企业更在乎业务的拓展，由于投入成本的限制，所以信息化建设的规模不宜太大，因此一些企业通过云托管的方式把自己的业务运行在第三方托管平台上，本身并没有数据中心，公网云托管通过提供IaaS云服务的方式解决了中小型企业信息化建设过程中关于基础设施投入的问题，既然企业的核心生产系统都在云平台中运转，那么后续的数据分析等等相关的服务都要在托管方的云环节下进行，所以这种模式决定了企业的生态选择了什么样的云平台，未来大数据相关的生态也必定在此平台下运转，比如阿里云不但能提供IaaS服务，后期还可以提供PaaS服务，未来相关的运营企业都通过阿里服务的方式来获取自己的相关服务，再选取去其它数据生态的可能性也比较小。

1. 应用系统中用到数据分析

如何利用大数据技术生态来构建我们的应用系统是我这里想重点说明的内容，我认为未来的业务系统设计时都或多或少的涉及到智能预测以及自动干预功能，这也是很多应用系统未来建设的目标，也就是说大数据分析功能再未来的业务系统中也会有直接的体现

1. 1. 未来数据架构混合才是正道

总体来说，目前在传统的业务系统（信息系统）领域，一般都是采用传统的集中式关系型数据库(RDB)，随着业务形式的发展，数据形态也会随之变化，一些无固定结构的数据需要进行查询统计分析，数据量的增速也比过去大了很多，针对现在业务上的变化技术架构设计时，到底该从哪些方面入手来设计我们的系统架构呢？尤其是数据架构到底该如何设计，我认为未来单系统的架构越来越倾向专业化和混合并存的态势。

1. 数据架构说明：

             

1. 核心业务系统：以事务性业务系统为主还会长期存在于各行各业的业务系统中，未来这种类型的数据库的高可用性也会随着技术的进步而进步，由于业务本身的需要，所以不太可能切换成分布式数据库。
2. 中间业务系统：对于一些中间环节的系统，没有记录核心数据，主要负责内外业务转换，类似这类中间业务系统，有必要使用一些分布式数据库来提高自身的业务处理性能（业务处理中有很多数据查询需求），比如银行领域常见的卡系统前置、大小额等等，账务的一致性一般是由核心和第三方进行对账来保证，中间的系统大部分是做中转处理。
3. 分析行系统：对于一些分析系统，比如BI，需要支持多种类型的数据源，至少要包括HDFS，其实完全意思上的分析型系统现在已经实现了多数据源撮合的功能，而且向着数据可视化方向发展了，总体发展方向已经趋于成熟，比如MSTR等公司，我这里更想说的是，对于应用生产系统，目前的业务逻辑控制已经实现了参数化控制，但参数调整依然依靠人工经验和制度来控制，未来一定会通过智能分析加人工调整结合来控制，系统一旦要适应新的业务需求，那我们的应用系统必须要具备数据采集、清洗、实时计算、入库的能力，这就倒逼我们的应用系统设计者必须要具备这种架构设计能力，也就是说未来设计师设计系统时必须要考虑，如何采用合理的架构布局来适应未来业务的发展需要。
   1. 1. 数据共享技术作为必备技能

数据仓库技术：ETL(JDBC/ODBC):kettle,Sqoop,DTS(库转库)

Kafka解决方案：1.kafka connector(库转消息中间件);2. Dbvisit Replicate Connector for Kafka.; Oracle(Golden gate),Mysql(Binlog),DB2(Datastage),Sqoop(MysqlSqoop/DB2Sqoop)

日志文件采集传输：flume->kafka->storm；ELKStack(Elasticsearch、Logstash、Kibana)

数据入库技术：

1. 离线入库技术：Timetunnel(阿里)/Scribe(fackbook)/Sqoop(Hadoop)
2. 流量入库技术：DataX(阿里)/kafka(linkedIn)/

             

1. 1. 1. 未来的单应用的数据架构

                     

1. 多数据源：未来的应用系统很多都需要支持预测分析控制，针对这种业务模式，业务系统的架构必须支持多数据源获取数据进行混合分析，也就是需要分析预测模块要支持同时访问不同的数据库（多库）。
2. 支持MPP数据库：并行分析业务中使用到的数据库与传统的RDB存在一些差别，这类数据库主要用来做查询统计，所以数据架构与传统数据库不一样，轻事务重并发，一般成为MPP类型数据库，未来分析预测内置以后业务系统的数据结构要支持这种类型的数据库。
3. 分析模块内置、控制接口开发：业务系统中的分析预测与本身的业务息息相关，所以我认为这种处理会内置于业务系统内部，运行控制以接口方式暴露给外系统。
4. 数据流处理外挂：对于数据的采集，入库等处理一定是在业务系统架构外独立存在的，业务系统中使用到的数据都从MPP数据库中获取，这些数据都是由独立转存架构系统独立清洗、筛选、入库的。