对数据湖概念及其应用场景若干问题的思考 - 快生活（kuaish.com）

　　在大数据平台后可以看到有两个衍生出来的概念词相当的火热，一个是数据中台，还有一个就是数据湖，今天准备谈下对这方面的一些思考。从数据湖的基本概念说起
　　首先看下维基百科上的定义如下：
　　数据湖（DataLake）是一个以原始格式存储数据的存储系统。它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）。
　　而在百度百科上的定义如下：
　　数据湖或hub的概念最初是由大数据厂商提出的，表面上看，数据都是承载在基于可向外扩展的HDFS廉价存储硬件之上的。但数据量越大，越需要各种不同种类的存储。最终，所有的企业数据都可以被认为是大数据，但并不是所有的企业数据都是适合存放在廉价的HDFS集群之上的。
　　如果综合这两个定义，可以看到数据湖的核心即是：存储各种类型数据的大型可扩展的存储库。这里面实际体现了两个重点，其一就是结构化，非结构化，关系表或视频图片等都可以进行原始格式存储，其次就是这个存储是分布式可无限水平扩展的。
　　当看到这里的时候，相信大家都会想到，这个和日常谈到的大数据平台里面的类似HDFS的分布式存储不是一个意思吗，为何又要去发明一个数据湖的概念。
　　在谈这个之前，先回到大数据平台这个概念。
　　当我们在谈大数据平台的时候，更容易将其理解为一个技术平台。比如对于大数据平台常见的定义如下：大数据平台是对海量结构化、非结构化、半机构化数据进行采集、存储、计算、统计、分析处理的一系列技术平台。
　　因此大数据平台的关注点在技术平台上，而非在数据上面。而当谈数据湖的时候，可以看到这个时候的关注点是在数据上，而不是具体的实现技术或平台上。数据湖的底层技术支撑可以是类似Hadoop的大数据平台，也可以是其它，比如类似亚马逊的S3对象存储为核心支撑能力并进行扩展。
　　其次，数据中台这个概念最近几年也相当活，在原来谈数据中台的时候谈得比较多的是共性数据服务能力的共享和开放。而谈到数据中台的时候刚好同时体现了数据平台两个方面的关键特性。
　　简单来说就是既要关注底层平台建设，又要关注最终的数据资产和能力。数据湖参考架构
　　在这里不准备详细去谈数据湖的参考架构和具体功能点，因为当你去分析详细的架构模块和功能的时候，发现仍然是类似数据采集，数据集成，数据存储，数据管控治理，数据接口开放等功能，这个和实际你谈数据中台架构，大数据平台，包括传统的BI系统的时候功能都差不多。
　　数据湖的核心是多样化数据的可扩展存储。基于这个核心实际上可以将数据湖核心功能理解为如下三个方面的内容。数据流入：包括了数据的采集，数据的集成
　　数据存储：包括各类结构化，非结构化数据的可扩展弹性存储
　　数据流出：需要提供标准统一的API接口或统一的SQL层等开放数据能力
　　这三个方面可以理解为数据湖的核心能力，其它的类似数据清洗转化，数据治理，数据质量管理等都是扩展能力，不是数据湖的核心。同时我个人实际是比较反对将这些能力全部加到数据湖参考架构里面的，一个重要的原因就是数据湖会构建得越来越重，而脱离了提出数据湖这个概念的初衷。数据湖概念的提出和扩展
　　这个术语由Pentaho公司的创始人兼首席技术官詹姆斯狄克逊（JamesDixon）发明，他对数据湖的解释是：把你以前在磁带上拥有的东西倒入到数据湖，然后开始探索这些数据。当时Pentaho公司刚发布了基于Hadoop的BI分析软件，推出这些概念更多的是为了自身产品和市场营销。
　　而最近几年这个概念却是以亚马逊为首的各大公有云服务厂商。亚马逊AWS对数据湖做了进一步解释，即：
　　数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。
　　简单来说公有云服务厂商希望企业本身的大数据存储，数据分析等业务也全部迁移到公有云服务上。类似亚马逊以S3为核心并扩展的数据湖相关服务和产品。国内的阿里云基于HDFS扩展的数据湖产品服务等。
　　为何公有云厂商如此重视这块？
　　拿传统企业IT建设和信息化来举例大家很容易明白。一般企业的IT规划建设都是先建设了底层的IT基础设施，然后构建了满足企业各类业务运作的IT系统，其次才是构建了类似BI商业智能等相关分析类系统，从OLTP走向OLAP分析。
　　对于公有云服务厂商来说，从最早的仅仅提供IaaS资源层服务能力，到随着云原生技术的推进，逐步开始提供完整的PaaS层应用和服务托管能力。企业内部的IT系统完全基于云平台提供的服务能力进行构建和持续集成交付。
　　那么企业IT在交付到云端，并持续运行后，一定存在多个业务系统间的数据整合和集成，大数据分析等场景。这个时候公有云就需要提供配套的大数据分析类平台和服务。这种服务的核心除了基础的大数据技术平台外，更加重要的是提供一套完整的数据采集集成，数据存储，数据开放的能力。
　　当企业的IT系统全部上云后，数据存储全部在云上，这个时候不可能说还需要把数据采集和集成回到企业内部数据中心在进行数据整合和分析。那么云端提供传统大数据分析或BI分析的能力就是必须配套的一个能力。
　　从这个意思上来说，数据湖和数据分析能力提供就是必须的。
　　一个企业如果所有的IT系统都还在自己的私有数据中心里面，这个时候会不会把所有的数据采集同步到公有云提供提供的数据湖服务，并进行数据分析？
　　这个场景当然也存在，但是实际上更多的仅仅是数据扩展存储和存储后的标准接口开放。如果这些数据真要用到数据分析，往往很难。这个涉及到私有云端和公有云端的大量接口协同问题，并没有那么容易解决。数据湖，数据中台，大数据平台和数据仓库
　　数据湖和数据中台
　　数据中台包括了底层数据技术平台（可以是我们熟悉的大数据平台能力），中间的数据资产层，上层的数据对外能力开放。核心的资产层本身也分层，从最底层的贴源数据，到分域应用数据，再到上层的数据仓库和数据标签库。而数据湖更多对应到数据中台概念里面的数据贴源层。
　　数据湖和数据中台映射如下：
　　简单来说就是数据中台在数据资产层比数据湖重得多，数据湖建议是仅仅是原始数据存储，而不应该是大量的数据清洗加工，数据模型，数据分析算法。包括复杂的数据质量管理，数据管控治理等都应该弱化。
　　数据湖和大数据平台
　　对于数据湖和大数据平台，实际更多的只是侧重点不同，一个侧重于数据，一个侧重于技术平台。当然对于大数据平台本身提供了数据湖建设的核心技术底座。
　　在前面已经谈到数据湖核心还是数据存储和接口开放，因此可以看到对于完整的大数据平台构建内容实际上进行了分层解耦。
　　即数据存储和能力开放与后续的数据处理和数据分析解耦。解耦后你可以看到数据湖提供的能力既可以用于传统的BI，大数据分析，也可以应用到直接提供数据服务能力给业务系统协同使用。
　　数据湖和数据仓库
　　对于这两个概念的比较，网上更多在强调数据湖可以存储结构化，非结构化各类数据，而传统的数据仓库仅仅是存储和处理分析结构化数据。
　　但实际在这里个人更强调数据湖仅仅是数据仓库的底座，而不应该具备类似数据仓库有的复杂数据建模，数据清洗转换，数据分析等能力。
　　也就是说经过加工和聚合后的数据可以放在独立的数据分析类应用中，但是当需要查看详细的数据明细的时候，这直接调用数据湖接口访问数据湖里面的数据资源。
　　传统的数据仓库和BI系统建设是一个很复杂的事情，类似数据建模，数据质量管理，数据治理，数据可视化等很多内容本身不属于数据湖的范畴。传统企业是否有必要搞数据湖？
　　首先表明个人观点，数据湖更多的是当前头部的公有云服务厂商在玩的事情，对于传统企业来说完全没有必要搞数据湖，包括大数据平台都没有必要。
　　为何这样说？
　　简单来说一般的企业本身遇到的数据类型，数据量等问题，用传统的BI方法就已经可以很好地解决，即使传统BI无法扩展，还有类似MPP等方式来解决。这种方式本身是最容易实施，也是见效最快的方式。
　　而对于数据湖或者大数据平台来讲，本身会引入更多的技术复杂性，包括前期的投入成本。而唯一的好处就是可以满足企业5到10年，甚至更长时间的业务发展，资源弹性扩展需求。为了这种扩展性去引入这种技术复杂性和成本投入对于大部分企业来说都不值得。
　　在前面我就谈到过。
　　当你为了满足扩展性和性能等需求的时候，整个IT技术架构的复杂性会越来越大，在这种情况下往往后续整个IT治理管控的复杂性，平台运维的复杂性，功能开发和交付的复杂性都显著增加。这种复杂性不是一般的企业能够扛得住的。
　　在谈数据湖的底层数据存储的时候，实际我一直有一个疑惑。即按照理想的做法是，各类数据采集和集成后，都通过标准的方式进行存储和能力提供，类似亚马逊的S3对象存储。即使是结构化的数据，最终也存储到S3分布式对象存储中。
　　在这种场景下，你就需要提供更换的类似传统SQL查询的接口能力，否则数据存储下去是方便了，但是使用却变得更加复杂的。如果你是用的S3存储或HDFS存储，简单来说要完整的提供完整的数据服务能力往往变得更加困难。比如常说的虽然OLAP能力增强了，但是OLTP方面能力，数据实时查询或处理的能力却变弱了。
　　在类似华为的解决方案里面，实际看到仍然采用了传统的结构化数据库来存储结构化数据，这个实际才是短期更加可行的方案。数据库的数据存储可以采用结构化数据库，MPP库，HDFS等多种存储方式，虽然底层数据存储有差异，但是可以提供一个统一的数据服务能力开放层来解决问题。
　　那么企业本身的数据孤岛问题如何解决，特别是在微服务架构化后引入的数据孤岛问题。实际上这个我在很早文章就提到，企业更需要的是一个分布式的共享ODS存储库。
　　为何通过共享ODS库来提供数据服务能力，而不是由原来的业务系统或单个微服务模块来提供数据服务能力。这里面有一个重点就是对于数据服务而言往往需要提供领域数据服务能力，涉及到底层多种数据库表的关联查询动作。而在传统方式下，这个往往涉及到跨库查询才能够实现，也就是说单个业务系统往往并没有能力提供。
　　这也是为何在传统模式下，会考虑再规划建设一个独立的领域服务层微服务模块，来专门处理这类服务。即使这样处理也存在要多次调用后台数据库接口，然后在逻辑层进行组合和组装的问题，那么在性能上肯定会造成一定的损耗。
　　而共享ODS库要做的就是将共享的基础主数据和各个业务系统中共享的动态数据（类似项目，订单，合同）等全部进行集中，集中到ODS库来提供统一的共享数据服务能力。那么原来上层应用需要调用各个业务系统或模块提供的数据服务来获取数据，而新架构下只需要通过共享数据中心ODS库提供的共享数据服务来查询数据即可。