数据湖，大数据的下一个变革！
大数据存储已经走到了一个新的阶段，肯定会有新的革命性技术来替换它。
前十多年，大数据的发展主要集中在技术框架上，社区出现了一系列优秀的作品，如最开始引领大数据风潮的 Hadoop，到计算引擎 Spark、Flink ，消息中间件 Kafka ，以及资源调度器 Kubernetes 等等，大数据领域的技术框架已经比较成熟。
通过开源架构策略，现代化数字企业逐渐意识到自己的目标是通过业务实现数据的价值化，未来将会把更多的精力投向研究底层数据消费和上层的产品应用。
2019 年 6 月，谷歌以 26 亿美元收购了数据分析公司 Looker。同月，Salesforce 宣布以 157 亿美元收购 BI 企业 Tableau 。2019 年 9 月，Cloudera 宣布收购商业智能实时分析厂商 Arcadia Data。这些收购案例都说明企业的目标开始转向解读所积累的海量数据。
赋能业务，快速应对挑战，正是数据湖所能提供的。数据湖的概念，最早是在 2011 年由 Dan Woods 提出，”是一个集中化存储海量的、多个来源，多种类型数据，并可以对数据进行快速加工，分析的平台，本质上是一套先进的企业数据架构“。例如在社交广告中的用户画像，需要行为日志等非结构化数据，经过层层数据加工形成业务价值。以后也会延伸到图像、语音等类型。这些就是数据湖能提供的特别优势。
Apache Ozone 项目是由大数据公司 Hortonworks 贡献出来的，最初是为了解决 Hadoop 系统中的对象存储问题。面对 Hadoop 向云上发展的方向，腾讯选择了在一年多前正式加入 Ozone，组了一支队伍，利用腾讯的业务场景和数据规模，进行协同开发，扩展成数据湖存储，并推进技术落地。InfoQ 采访了腾讯大数据海量存储与数据湖研发负责人 堵俊平，了解数据湖的发展和面临的挑战，本文基于这次采访。堵俊平曾在 Hortonworks 供职 4 年，负责 YARN 团队，目前在腾讯负责腾讯大数据的海量存储、海量计算以及数据湖等研发方向，有 10 多年的云计算与大数据产品研发经验。今年 10 月，他将在 QCon 全球软件开发大会（上海站）2019 作题为 《OZone - 下一代数据湖存储》 的演讲。
关于数据湖的定义确实是一个业界有较多争议的地方。狭义的数据湖指的是数据湖存储，即可以存放海量数据（各种格式）的地方，包括 Hadoop 的文件系统 HDFS 或者云上的对象存储系统 S3 都属于这个范畴。广义的数据湖除了数据湖存储，还包括数据湖的管理和分析，即提供一整套工具，提供数据目录（Data Catalog）服务以及统一的数据访问。
业界很重要的趋势，是从传统的数据仓库向数据湖的方向在演进。
最早出现的是数据库一体机，是由单独的硬件软件所构成，这种数仓的问题也很明显，它需要一个专有的硬件设计，你只要用的不是通用的硬件，一般成本都会比较高。第二，它的扩展性非常差，在往前推十年、二十年是可以的，但是在这样的大数据时代，大家都不想随意地抛弃掉自己的数据和数据资产，所以一体机模式的数仓肯定要被这个时代淘汰掉。
这个阶段也分两块，一块是从分库分表，从逻辑上把这个数据分成不同的模块，放在不同的数据库上面；另外一个方式，整个过程是通过 MPP 这个架构，通过一些独立的数据库组建出来 MPP 数据库，总体来说 MPP 数据库还是非常强大的。但是 MPP 有一个限制，它不能支持海量的数据，因为更多添加节点，尤其是当它的扩展规模超过 100 个节点以上的时候，会发现大的任务几乎无法执行，因为最慢的节点会拖累整个任务的执行。
这些 adhoc 分析的任务在业务不断变化的情况下，包括经历波峰、波谷，对计算资源有不同的需求，这个时候云原生数仓就会越来越流行，因为它是一个多集群的，弹性可伸缩的，并且支持海量的高并发。这里说回传统的 MPP 数仓，还有个问题，就是 SQL 并发能力跟单机数据库是一样的，因为并发的所有 SQL 都要在每一台机器上去执行，无法突破单机数据库的并发限制。
无论是传统数仓还是新型数仓，无论是类似 Teradata，还是 MPP 架构，或者是 Oracle 单机加强版架构，都是从数据库发展而来的。使用的场景也主要是用格式化的数据。但数据湖并不要求很强的数据格式，非结构化、半结构化数据都行，也不要求数据入库之前需要像数仓那样建立严格的一套 ER 模型，或者其他的范式模型。
数据可以很轻松进入数据湖，用户也可以延迟数据的采集、数据清洗、规范化的处理，可以把这些延迟到业务需求来了之后再进行处理。这跟早期的数仓思维就很不一样，它相对于企业来说，灵活性比较强。传统的数仓，因为模型范式的要求，业务不能随便的变迁，变迁涉及到底层数据的各种变化。传统数仓没法支持业务变化。对于数据湖来说，尤其像互联网行业中新的应用，不断的发生变化，它的数据模型也不断的变化。相对来说，数据湖就更加的灵活，能更快速的适应上层数据应用的变化。
数据湖的三个层次，分为数据库等底层存储、元数据管理、跨不同数据源的 SQL 引擎。数据湖也是数据仓库发展的高级阶段，对于数仓来说，数据湖有很多扩展能力。数仓解决的核心问题，数据湖也解决了一遍，而且涉及面更广。比如说，数据库的数据有对齐的要求，数据库是面向应用的，每个应用可能需要一个数据库。如果一个公司有几十个应用，就会有几十个数据库。几十个数据库之间怎么去连接分析、统一分析？是没有办法的。随后就由数据库发展成了一个数据仓库，数据仓库不面向任何应用。但是，它对接到数据库，如果需要每天定时有些 ETL 的批处理的任务，将不同应用和数据汇总起来，按照一些范式模型去做连接分析，得到一定时间段的总体数据视图。这个前提是很多数据库要给数仓供应数据。这些供应数据是数据库是表格化、规范化的方式。
但现在互联网企业的应用，大部分数据不再来源于数据库了，它可能来源于日志，比如用户的行为日志，或机器的日志，可能来源于各种各样的非格式化的数据。这时就必须要用数据湖这种方式。可以跨越之前数仓建模种种的约束，针对业务需求去做联合分析和查询。对上层数据应用所提供的接口更像是一个统一的界面，屏蔽了底层异构数据源的差异，这也是大数据发展未来的重要趋势。
二十年前，Google 用普通硬盘代替了昂贵的专有硬件设备方案，但当时的网络带宽只有 100M。为了快读访问，同时也创造出了计算和存储耦合的架构。Hadoop 延续了计算存储一体化的方式。
存储计算一体化架构的性能是经过了优化的：通过任务调度的方式，将计算调度到离数据更近的地方，访问更快也省资源。而云端的场景，采用的是计算和存储分离的方式，第一性能可能不是最重要的点，第二大家更考虑”弹性伸缩“，业务需要大的波峰时候，需要很多的资源，业务相对在低谷的时候，希望资源可以是收缩的。
Ozone 这样的下一代数据湖兼顾 Hadoop 的计算存储一体化和云的弹性伸缩的优势，一方面实现了逻辑上的计算存储分离，同时在任务调度时，又能做到数据和机架感知功能（data、rack awareness），能让计算更贴近存储。
这也是对传统云存储数据访问方式的一个变革。
如上图所示传统云访问方式，存储计算是分离的，各种计算节点统一的通过接口，也即 RESTful 方式访问数据。之后，计算框架在基于 Ozone 计算存储分离的条件下，可以把计算任务发送到临近存储的节点之上，通过调度计算而不是拖数据的方式达到高性能。
Hadoop 的三副本保证了数据的可靠性，传统的大数据的 HDFS 写的方式是依次写多个副本。在写性能优化上，Ozone 采用 Raft 分布式通讯协议，同时写几个副本。这种局部创新，让 Ozone 得到了很好的性能上的提升。
对于 Hadoop 存储面向云的演化，还要看 HDFS 如何跟云上的对象存储配合。在 HDFS 上，所有的元数据（命名空间、块管理等）都会放在单个的 NameNode 节点上，如果考虑到同时并行的文件操作以及数据块上报、RPC 的响应等因素，这个时候就会遭遇扩展瓶颈。如果集群存储的是海量小文件，元数据体量会剧烈暴增，这个瓶颈期会更快到来。所以这种架构不适合海量的高性能大数据处理。Ozone 将元数据进行了分散处理，规避了以前的问题。并且云上的对象存储方式，从硬件上和通用 API 访问的方式上，性价比比较高。Ozone 除了提供文件接口，为了跟云去做对接，还提供了对象存储，这样就可以在云上部署类似的系统，对数据访问进行无缝的集成，而且相比传统的云端对象存储还可以做高性能的拓扑感知。
这相当于在传统的对象存储和 HDFS 海量分布式文件存储中做了取长补短，也是一个重要的变革。
现在面对机器学习和离线计算，跟大数据场景下处理的数据方式不一样，现在需要去处理的可能是一张张图片，或云语料文字，这种数据的颗粒度更小，不像传统的大数据应用那么集中。这种海量小文件，不是传统的 HDFS 所擅长的，正好在 Ozone 里得到了解决，可以支撑小文件或对象存储方式，对机器学习的发展也有促进作用。
现在深度学习和超大规模的神经网络潮流来了之后，更离不开大量的数据。AI 和大数据在技术层面上，两个社区也开始相互对接融合，不断出现在大数据平台做深度学习的 AI 框架，这样的平台能在底层有调度的能力，能同时调度好 AI 模型训练、推理以及做数据预处理的任务。
针对云和机器学习场景，Ozone 项目具有很多特点，包括：无限的扩展能力，强一致性的对象存储能力，与主流计算调度框架 YARN 和 Kubernetes 无缝对接，以及同时兼容对象存储与 HDFS API 等。这些技术特性也决定了 OZone 的现在的发展方向。
堵俊平总结说：“大数据存储已经走到了一个新的阶段，肯定会有新的革命性技术来替换它。”
数据湖的使用场景，是为了将各种数据汇集到一起，但现在的数据引擎太千差万别了，SQL 引擎是一套，NoSQL 包括 Cassandra、HBase 又是另一套东西，还有类似 Elasticsearch 和图计算等等。很多引擎都自带存储，将这些数据从不同的引擎里去拉通，堵俊平觉得是很有价值的。但是目前还没有哪家公司有工具能完全做到，大部分是选择少数几个数据引擎去统一。堵俊平表示”腾讯内部有研发项目，来做类似的事情。希望能够把各种各样的数据引擎和元数据都能够做一个聚合和统一，这样才能真正达到理想中的数据湖管理和统一数据分析的愿景“。
基础设施技术是业务快速发展的基石，在 QCon 上海 2019 的演讲中，堵俊平老师将介绍 Ozone 的架构、技术、场景以及腾讯大数据的实践。