一篇技术派文章｜数据湖 数据仓库和文档型数据库是证券公司最早引用的大数据技术

“ 大数据技术发展至今，已经从10年前刚江湖出道的童孩发展成今天的饱经沧桑。当年靠分布式技术起家，只有文件系统、并发处理引擎，而今天已经发展成产品和行业的生态标杆。这再次触发我对大数据技术架构的热爱与思考。 ”

这是我给某知名证券公司做方案的资料

大数据平台第一个要素就是数据源，我们要处理的数据源往往是在业务系统上，数据分析的时候可能不会直接对业务的数据源进行处理，而是先经过数据采集、数据存储，之后才是数据分析和数据处理。

从整个大的生态圈可以看出，要完成这些，就需要大量的系统计算、大量的作业资源、还要控制和协调这些资源需要监控和协调分派；面对大规模的数据怎样部署更方便更容易；还牵扯到日志、安全、还可能要和云端结合起来，这些都是大数据圈的边缘，同样都很重要。

在今天的思考与总结中，我们发现大数据在工作中的应用主要还是这三类特点：与业务相关、与决策相关和与工程相关。

与业务相关：比如客户标签、用户画像、智能推荐、风险控制等领域，这都是业务模型的信息化能力塑造；与决策相关：比如数据科学的领域，包括统计学、算法和数据挖掘，这些都是数据科学家的范畴；与工程相关：比如平台如何搭建、如何开展实施、解决什么业务问题等，这都是数据工程师的工作。

就拿证券公司的大数据系统而言，其整体架构包括数据源、基础平台架构、业务分析应用和能力访问几个区间。

数据源涉及证券公司的集中交易数据、行业融资融券数据、个人企业机构开户等账户系统数据、企业管理、财务账务和日志分析数据，当然还包括互联网或外部资料的引入，这些都是构建大数据环境的基础。

在大数据平台主体架构层，包括数据流转、数据管理和数据访问的能力贯穿，涉及运用数据湖获取海量数据资源的能力、实现大数据集的低成本存储和信息归档，当然还包括数据过滤、预处理等ETL过程，甚至还有非结构化日志数据的分析与管理。涉及运用数据仓库实现传统关系型数据的处理和分析，基于稳定结构化负载的数据质量和一致性管理，包括数据模型、指标体系的统一管理，从而支持基础的业务服务和运营智能。涉及到咨询数据处理平台，引入了MongoDB的文档型NoSQL数据库，针对于网站数据，非常适合实时插入与更新查询；针对于缓存处理，可以实现持久化的数据固化；针对于高度事务性数据系统，还适用于需要大量原子性复杂事务的应用程序。

在业务分析应用层，主要面向市场监管提供统计分析和报表、面向内部管理和外部伙伴提供各类应用和查询环境、面向企业经营战略提供商业智能和科学决策、面向智能化等特殊应用提供数据挖掘和数学工程等。

在能力访问层，则面向营销管理员、系统管理员、客户合作伙伴、前端工作人员、业务分析师、数据科学家、系统工程师提供一些列的访问接口，助力平台能力的好用、好管、好运营。

从传统的数据生产到数据消费，长期围绕这永恒不变的逻辑过程，那就是数据采集、存储架构、关联分析、视图展现和应用访问等区间，当然，这里当然也有比较系统的分类和能力作用域。从来源来看分为内部数据和外部数据，数据源的特点决定数据采集与数据存储的技术选型，我根据数据源的特点将其分为几大类：

第一类：从结构来看分为非结构化数据和结构化数据；

第二类：从可变性来看分为不可变可添加数据和可修改删除数据；

第三类，从规模来看分为大量数据和小量数据；

不得不说，大数据在面向应用支撑的过程中，其开发过程仍旧太过于偏向底层，仍旧学习难度大，涉及的技术面非常广。而且即便业务上云、服务上云、架构上云，云的IaaS层能力也无法规避。种种迹象表明，这仍旧是制约大数据普及的平静点，我们似乎真的需要一种技术，能够把大数据开发中一些通用的，重复使用的基础代码、算法封装为类库，降低学习门槛、降低开发难度、从而提高大数据项目的稳固执行与效率提升。

因此，大数据平台就是要打通数据生态系统与传统非大数据公司之间的通道而设计的一站式搜索引擎级，实现搜索引擎级的性能提升。而且需要通过各类中间件技术，将复杂的大数据集群配置简化并低密度衔接，极大简化集群的管理运维，增强了集群的高可用性、高可维护性、高稳定性。当然，还需要考虑与开源系统功能效能的高度整合，实现大数据能力的一体化框架，从而实现从传统信息系统到面向大数据和分布式系统的无缝衔接。