近来有很多机构在企业架构设计中尝试采用数据湖架构，也有不少客户在咨询我关于数据湖架构设计的方法。对于数据湖，我一直认为这其实是一种理念，而并不是数据架构方法论。尤其随着大数据发展逐渐成熟，无论是数据仓库还是数据湖，本质上都需要解决企业架构规划中的问题，而并不是炒概念。
数据湖(DataLake)是Pentaho的CTOJamesDixon提出来的(Pentaho作为一家BI公司在理念上是挺先进的)，是一种数据存储理念——即在系统或存储库中以自然格式存储数据的方法。由于这些数据最初很难定义其用途，所以在使用之前难以将其有效分类、构建主题模型并形成需求式报表的开发，但是这些数据又可以被原地分析、计算和存储，并作为企业大数据资产为未来业务发展需求提供数据储备服务。
数据湖是否有价值，与企业应用这种架构的目的直接相关；所有的数据是不是都有必要，也因应用场景而异所不同。若与企业整体架构规划的原则相悖，这种直接加载数据、再按需转换数据的方法，或许真的会变成“数据沼泽”。
从数据仓库到数据湖
随着大数据技术日趋成熟，互联网和物联网推动新形态数据的持续产生，新的数据仓库架构也在悄然发生转变，即由传统关系型数据库支撑的结构化数据仓库，演变为由结构化、半结构化、非结构化、实时流数据处理等多种数据处理手段和模块相结合，构成新的逻辑数据管理平台。
这种新型的企业级数据管理平台应理解为广义的大数据平台，也就是把基于传统的结构化数据的数据仓库和狭义的处理半结构化、非结构化信息大数据技术融合形成的逻辑上新的数据管理体系，亦可以称为“数据湖”，多由RDBMS或MPP架构结合大数据架构(Hadoop/Spark/Hive)体系混搭形成。这种平台通常具备以下特点：
将传统关系型数据库技术和大数据技术互补性整合的能力
能够将结构化和非结构化数据进行无缝关联的分析能力
海量数据对线性扩展能力要求
低价值密度的数据存储对平台开放性和成本降低的诉求
实时数据处理和分析决策技术的采用，如内存数据库和实时流处理技术
过去机构在做数据仓库时，数据在进入仓库之前需要是事先归类，数据得到清洗、转换后，通过数据仓库建模(如星型模型或雪花模型)、业务主题域建模，以便于未来的分析；与之不同的是，由于廉价存储时代的到来，数据湖架构确保多个数据源集成和数据汇总，既可以满足实时分析的需要，也可以作为数据仓库处理批量数据挖掘与分析。此外，还可以通过集群分割做大数据实验室这样的数据和技术服务模式。
需要注意的是，把数据仓库与数据湖混为一谈是不正确的。相比较而言，数据仓库更有针对性，数据应用方向明确：为报表、商业智能、数据集市、数据挖掘与分析应用等提供支撑。常见的数据仓库技术架构多为一体机，也有用Hadoop/Hive来实现以节省成本；数据湖则是从数据资产的角度出发，更灵活，通过敏捷、简单的数据集成，整合多源、多维、多元的数据模型，通过低成本服务器集群实现扩展，实现按需的数据应用服务。
数据湖架构
基于大数据的数据基础设施构建是大多数金融机构应用大数据的第一步。数据平台扮演着全公司数据中枢和引擎的角色，更是未来构建多维大数据应用的基础和抓手，重要性不言而喻。过去一些金融机构的数据架构多基于传统Oracle数据库或数据仓库，已经难以适应数字化、互联网时代的数据管理要求：
数据加载的耗时长、系统计算负载高，无法满足目标系统对数据的时效性要求，关键任务的SLA不能得到保证；
性能优化无法逾越I/O瓶颈，随着不断增加索引和分区也增加了系统在加载时的资源消耗，同时增加了系统维护难度；
系统架构不支持线性扩展，使数据的存储得到制约，扩容需要花费高成本以购买大型设备，即便如此，也无法控制数据增长带来的性能处理压力；
平台只能对结构化数据进行处理，不能满足多样化格式数据处理需求，因而无法支撑对影像、文本、图像等非结构化数据、HTML/XML等半结构化数据的应用场景。
购买数据仓库和一体机的成本日益增高，却无法根本解决未来数据增长带来的存储和性能瓶颈。
寻求一种成本集约化、资源分布合理、满足线性扩展、支持非结构化数据处理、满足数据分析与挖掘能力的新一代数据管理体系，成为支撑新形势下的金融机构业务与科技管理的紧迫需求。在这个背景下，数据湖架构也应运而生。
数据湖可提供大容量低成本的数据存储，以原始格式存储数据，并提供灵活的、面向任务的数据绑定，而不需要提前定义数据模型。数据湖也改变了用户使用数据的方式，其整合了结构化、非结构化数据的分析和存储，用户不必为海量不同的数据构建不同数据库、数据仓库，通过数据湖就可以完成或实现不同数据管理的功能。未来数据湖作为一种云服务随时按需满足对不同数据的分析、处理和存储需求，数据湖也可通过云的方式来部署到虚拟机、物理环境或云上。
当前数据湖架构并没有行业统一的标准来约束和定义。按行业实践经验来说，数据湖架构一般分为两类：统一基于Hadoop架构的数据平台，以及基于传统MPP架构+Hadoop架构的混合式数据架构。其两者的区别在于：
可以看出，混合式架构其实是统一架构的超集，两者中都使用了基于Hadoop框架的。这其中具体实现又可分为多种形式：
RDBMS+Hadoop：RDBMS提供实时或准实时ODS服务，Hadoop作为持久化。我认为这不能称之为数据湖架构，但也有这么用的；
MPP+Hadoop：应用较广的数据湖架构之一，同时提供短查询和历史数据查询存储功能，Teradata/EMC是这类解决方案。数据交互形式也有多种：数据通过ELT模式进入到Hadoop存储，基于MPP构建数仓；或者用于查询和分析的数据进入MPP，Hadoop提供历史数据查询、批量处理；
Hadoop：SQLonHadoop形式(如Impala+Kudu)，应用目前逐渐在一些互联网公司、行业公司兴起。优点是统一平台管控、成本低、灵活弹性；短板在于短查询、即席查询的能力需要验证。数据湖本身也不是数据仓库，所以还是要考虑统一架构设计的合理性；
NoSQL+Hadoop：如MongoDB/Redis+Hadoop也是一种方案，使用场景较局限；
多种数据库(包括内存数据库)和Hadoop架构的整合：目前很少看到这种杂糅形式，不便于统一管理，基本上不能作为数据湖架构设计的参考。
由于企业级数据架构设计是随着应用架构和技术架构的转化而变化。数据架构的层级设计，数据流转，数据生命周期管理和数据治理体系，均需要围绕业务条线的应用需求和技术架构需求而定。
一种基于RDBMS+Hadoop的混合式架构
从业务价值角度看数据湖
金融机构的信息化建设的复杂度和管理难度在逐年加大。一方面是业务复杂度提高，另一方面是新兴技术层出不穷。随着大数据、人工智能等技术的蓬勃发展，数据智能逐渐渗透到金融业，冲击着传统技术架构、数据架构和应用架构。过去业务系统的BS/CS架构、数据库+应用服务器模式，已经逐渐偏离了主流信息技术的轨道，被分布式架构、私有云服务、容器化等技术替代。
从金融业信息化建设历史和现状可以看到一些显著的问题：
业务系统逐渐增多，数据孤岛效应凸显，数据不一致现象频繁出现，质量、格式、结构、指标均存在混乱。如何通过数据架构设计改进，结合数据治理和标准化工作，将多个业务数据源之间关系打通，形成全公司统一数据标准；
大量数据、实时数据对数据存储体系、响应时间形成了极大的挑战，券商亟待寻找到更适合的技术框架应对大规划、快数据的处理和计算需求；
历史存量数据的存储和管理带来了传统服务器成本大大提升；另外如何利用历史存量数据、挖掘存量数据的价值是机构当前努力探索的方向；
随着网络金融业务、线上渠道的开拓，大数据价值日益凸显，数据正逐渐成为金融行业的新型资产。如何利用大数据资产提升金融服务水平、体现业务价值也是众多机构面临的问题。
我以证券公司为例，解释一下数据湖架构为什么能够为企业数据管理问题提供一种较为适宜的解决方案。
从数据存储角度上，数据湖通过分布式集群提供大容量低成本的数据存储，能够为大量交易明细、客户数据、资产和产品数据、渠道数据、日志类数据提供足量、可线性扩展的数据平台，满足历史数据存储、查询的应用需求。另外，数据湖可整合非结构化数据的分析和存储，对日志、文本、语音、视频、图像等类型的数据提供了存储和分析环境。在业务应用层面，可结合机器学习、深度学习模型，对客户语音、开户图像进行识别和模型构建，为实现机器客服应答、客户身份验证提供模型训练所学的大规模结构化、半结构化和非结构化数据源。
从数据管理的角度上，由于传统证券公司数据没有做到有效集中，导致大量数据散落在各个业务系统中，大量历史数据丢弃，一些对业务提升有价值、有潜力的数据得不到有效利用。通过数据湖集中的全量数据资产，能够为各业务条线提供便捷的数据接口访问多源、多维、多样化的资讯、行情、交易、客户、财务、舆情等数据。例如，券商自营业务中，可利用历史交易所Tick数据分析，分析最高最低价、成交量、委托挂单等实时行情，构建策略模型实现量化择时交易；利用知识图谱类(如GraphX图计算和图数据库Neo4j技术)实现自动化的二级市场研报读取分析；通过自然语言情感分析，判断对行业、板块、事件的态度来预测股票涨跌等。
在大数据应用方面，数据湖能够为经纪业务、自营、财富管理、风险管理、合规等业务条线提供了深度发掘数据价值的基础设施。例如：
在自营业务中，利用股票、债券、基金、票据、期货、衍生品等权益类和固收类资产的历史数据(流动性、财务指标、报收价格、最大回撤...)预测远期波动率；利用循环神经网络(RNN/LSTM)方法，借助历史行情数据，实现金融产品的时间序列分析评估；
在财富管理业务中，借助现代投资组合理论和用户画像，实现因客定价、量化大类资产配置；
在风险管理业务中，基于二级市场和场外市场的交易明细数据，判断冲洗、谎骗等异常交易特征识别；利用外部数据如工商、司法、税务、消费行为和操作行为的身份识别，与合规反洗钱业务结合，实现大数据智能风控；
在网络金融业务中，构建智能营销引擎，结合用户画像模型、产品定价模型实现自动化的C端客户(投资人)与产品匹配，智能推荐服务；通过系统日志读取和分析，实现运营环节自动化等。
总之，数据湖架构提供了一种更灵活、扩展性更佳、成本更低、数据应用模式更广泛的架构方案，也能够解决当前机构在新兴业务不断涌现、行情动态变化、市场环境复杂形势下，各业务线从传统人工判断到数据智能的决策业务转型，面临用数据难、数据标准差的痛点，实现数据资产服务化和统一管理。
数据湖存在的问题
若数据架构设计与企业架构规划脱节，数据湖仍有变成“数据沼泽”的可能。数据本身的价值应从业务价值出发来存储、管理、分析。从这种意义上说，数据仓库确是提供了一种良好的、符合业务规则的管理方式。同时，利用Hadoop架构也可以实现可扩展、成本节约的数据仓库解决方案。
而对于数据湖来说，其存在的先决条件是金融机构意识到数据资产价值、以及找出数据变现的可行性方案。所以，在金融机构IT战略规划中的架构选择中，我不认为就一定要选择数据湖这种模式，在其优势之外也带来诸多问题和难点：
一方面是数据本身的问题。什么样的数据值得存储和保存？数据生命周期的界定是什么？怎样保证数据湖中的数据具有流动性和价值挖掘能力？
另一方面是管理问题。数据湖中的数据治理如何进行？是否需要纳入数据标准体系中？混合式架构需要两套甚至多套的异构技术体系，提升了运维、管理、分析的IT管理复杂度，也对于灾备、维护的成本有了更多要求。
无论数据是否有价值都丢到数据湖里面去，我不认为这是可落地的架构设计。在企业数据治理体系中，数据架构设计也需要符合业务和IT对于数据的认知程度和应用策略。对于大部分机构来说，数据仓库本身就已经提供了可分析探索的模式；而对于筹备构建大数据或人工智能实验室、数据资产管理和数据开放服务的机构来说，数据湖才是一种比较符合需求的方案。
金融科技系列原创文章
智能时代的金融机构转型升级：利用大数据与AI创造价值
谈谈数据治理
证券业大数据与人工智能发展现状与应用趋势
由第二届中国金融科技大会想到的
如何构建一个Kensho？
从大类资产配置角度看智能投顾
金融科技中大数据技术应用趋势
新金融环境下的监管科技(RegTech)与技术应用趋势
从投资组合理论与实践角度看智能投顾
互联网时代商业银行的数据思维与企业转型
大数据时代的金融风险管理
金融科技的数据逻辑
云计算时代业务绩效管理BPM构想
区块链与数据库：一种混合计算系统架构
机器学习与人工智能专栏
企业级人工智能平台架构设计与应用服务
金融科技时代：人工智能中的数据、模型和架构
知识图谱在金融科技中的应用
真实的谎言？人工智能时代的量化投资
LSTM在金融时序分析中的应用
人工智能是不是“灰犀牛”?
机器学习在金融领域的创新应用
人工智能是个伪命题
机器学习与金融风险管理
从机器学习角度看智能投顾
关于作者多年金融服务、金融科技咨询经验，曾服务于大型金融集团、FinTech公司、跨国IT企业，为多家商业银行、证券公司、保险机构提供业务战略咨询与信息化解决方案，在金融科技、大数据与人工智能在金融业的应用、金融风险管理、数据治理和信息化战略等方面拥有丰富的经验。
订阅方式：搜索