关于大数据:数据平台发展史从数据仓库数据湖到数据湖仓

7次阅读

共计 11735 个字符，预计需要花费 30 分钟才能阅读完成。

做数据的同学常常听到一些数据相干的术语，常见的包含数据仓库，逻辑数据仓库，数据湖，数据湖仓 / 湖仓一体，数据网格 data mesh, 数据编织 data fabric 等.

笔者在这里回顾了下数据平台的发展史，也介绍和比照了下常见的概念，次要包含数据仓库，数据湖和数据湖仓，心愿大家有所播种。

回顾数据平台倒退历史，梳理数据平台变迁脉络，更全面精确地了解数据仓库数据湖和数据湖仓！

所谓数据平台，次要是指数据分析平台，其生产（剖析）外部和内部其它系统生成的各种原始数据（比方券商柜台零碎产生的各种交易流水数据，内部行情数据等），对这些数据进行各种剖析开掘以生成衍生数据，从而反对企业进行数据驱动的决策：An analytics platform is a unified solution that combines technologies to meet enterprise needs across the end-to-end analytics lifecycle from data storage, data management, data preparation, and other data analytics processes.

数据分析平台既能够部署在本地，也能够部署在云端，其典型特色有：

数据分析平台，须要上游零碎（外部或内部）提供原始数据；
– 数据分析平台，会通过剖析生成各种后果数据（衍生数据）；
数据分析平台，生成的后果数据，个别次要服务于企业本身，反对企业进行数据驱动的决策，从而助力企业更好地经营：为顾客提供更好的服务，企业本身降本增效更好地经营，或发现新的商业洞察从而反对新的商业翻新和新的业务增长点等（foster innovation）；
数据分析平台，生成的后果数据，也能够服务于内部客户: 通过数据变现，为企业发明新的业务模式和利润增长点；（各种提供数据服务的公司）
数据分析平台，反对各种类型的数据分析利用，包含 BI 也包含 AI;

数据（剖析）平台，常见的相干术语有：数据仓库，数据湖，数据湖仓，数据中台，逻辑数仓 Logical data warehouse，数据编织 Data fabric，Data mesh 等：

数据仓库，数据湖，数据湖仓 / 湖仓一体：是数据平台次要的撑持载体，是以后应用最宽泛的术语，其中数据湖仓也称湖仓一体，实质是数据湖的 2.0 版本；
国内也常常讲数据中台：数据中台在数据仓库数据湖数据湖仓的根底上，强调了将数据进行服务化 API 化，从而反对更疾速敏捷地开发各种新型数据利用；
数据编织 Data fabric，数据网格 Data mesh：是随着企业云化迁徙以及微服务架构衰亡，逐步流行起来的新的术语，在治理数据时更强调数据人造分布式的个性和数据产品的理念（数据是一种产品，来自不同服务由不同团队治理）；
须要留神的是，数据仓库，数据湖与数据湖仓尽管有着显著的学术定义上的区别，然而在业界很多场景下咱们并不严格辨别三者；

本次分享，咱们次要关注数据仓库数据湖和数据湖仓

整个数据平台的发展史，其实能够用一句话简略概括下：数据平台的倒退，是随着企业信息化和数字化的逐步推动，从数据库，数据仓库，数据湖到数据湖仓逐步演进的：

在企业信息化晚期，建设了各种线上业务零碎如 ERP/CRM/OA 等，这些业务零碎通过数据库积淀了多种数据，其数据库个别采纳的是 OLTP 的关系型数据库；
随着信息技术的进一步倒退，企业逐步意识到数据具备价值，并能够通过各种分析方法开掘其中的价值，反对企业的管理决策，于是逐步有了数据仓库平台（数据仓库诞生于数据库时代）；
随着大数据时代的到来，数据在品种和体量上都有了爆炸式的增长，数据的存储和剖析解决技术也有了进一步倒退，为更好地开掘数据中的价值，呈现了数据湖平台（数据湖脱胎于大数据时代，有着很强的开源和凋谢的基因）；
随着企业向数字驱动进一步迈进，对数据的存储和剖析解决有了更高的要求，呈现了交融数据仓库和数据湖各自特点的新型数据平台，其实质是数据湖 2.0，也被称为数据湖仓；

2.1 数据仓库

数据仓库 (Data Warehouse)，是由被誉为寰球数据仓库之父的 W.H.Inmon 于 1990 年提出的，其绝对学术的解释：数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrated）、绝对稳固的（Non-Volatile）、反映历史变动的（Time Variant）数据汇合，用于反对管理决策和信息的全局共享；
所谓主题：是指用户应用数据仓库进行决策时所关怀的重点方面，如：支出、客户、销售渠道等；
所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务撑持零碎那样是依照业务性能进行组织的；
所谓集成：是指数据仓库中的信息不是从各个业务零碎中简略抽取进去的，而是通过一系列加工、整顿和汇总的过程，因而数据仓库中的信息是对于整个企业的统一的全局信息。
所谓随工夫变动：是指数据仓库内的信息并不只是反映企业以后的状态，而是记录了从过来某一时点到以后各个阶段的信息。通过这些信息，能够对企业的倒退历程和将来趋势做出定量分析和预测；
之所以应用数据仓库而不是前台线上业务零碎的 OLTP 数据库进行 BI 等数据分析，一个重要的原始是 OLTP 只能应答简略的关联查问，撑持根本的和日常的事务处理，不实用数据的多维度剖析；而数仓底层个别是善于多维分析的 OLAP 数据库（还有一个起因是数据分析属于后盾零碎，不能影响前台线上业务零碎的性能）

数据仓库个别具备以下特点：

数仓强调数据建模，须要依据畛域常识依照分层建模实践，进行具体的模型设计；
数据由内部零碎进入数仓时，须要通过荡涤转化后加载进数据仓库，即 ETL；
数据须要 ETL 后进入数仓，实质是因为内部零碎中的数据模型跟数仓中的数据模型是不同的（内部 OLTP 零碎个别是依照范式设计的数据库中的表，而数仓个别是 OLAP 中反范式的大宽表）；
数仓模型的建设个别耗时耗力，但数仓模型一旦创立结束，相对来说不会轻易做出扭转；
ETL 的实质是 SCHEMA ON WRITE，即数据进入数仓时经由 ETL 实现了荡涤和转换，所以数仓中的数据品质较高；
数仓分层比拟经典的有：ODS,DWD,DWS,ADS 等；
数仓是商业智能 BI 的根底，次要基于建好的数仓模型，通过剖析答复固定的已知问题，从而撑持 BI 的报表和大屏等；
数仓个别内置存储系统，且不对外间接裸露存储系统接口（不容许内部零碎间接拜访数仓底层存储系统中的数据比方文件），而是将数据抽象的表或视图的形式，通过提供数据进出的服务接口对外提供拜访（最常见的数据拜访形式是 SQL，有的数仓对加载数据也提供了 RESTFUL 接口或专用的 LOAD/COPY 等命令）；
数据仓库通过形象数据拜访接口 / 权限治理 / 数据自身，带来了肯定的封闭性，但换取了更高的性能（无论是存储还是计算）、闭环的平安体系、数据治理的能力等，能够应答平安 / 合规等企业级要求;
数仓内置存储系统但不对外间接裸露存储系统接口，而是提供数据进出的服务接口，带来了以下优缺点：
- 数仓具备封闭性，只能应用数仓专用的剖析引擎，个别不能对接三方其它引擎；
- 数仓具备封闭性，不同数仓之间的数据迁徙绝对较难；
- 数仓性能较好：数仓计算引擎对内置存储系统的数据存储格局有深刻理解，存储和计算能够配合着做深度优化，进步数仓的性能；
- 数仓在数据治理上具备劣势：有欠缺的元数据管理能力，欠缺的血统体系等，能够对数据进行全生命周期的细粒度的治理；

对于数仓，有以下几点须要留神下：

传统的数仓，底层个别是基于数据库的，底层只能以表的模式存储结构化数据，如 GreenPlum，Teradata，Vertica 等，老本绝对较高；
传统的数仓，个别是存储计算耦合的架构，在横向扩展性和弹性能力上绝对有余，能治理的数据量绝对较小；
新兴的云数仓，底层个别是基于云上对象存储的，如 AWS Redshift、Google BigQuery、阿里云 MaxCompute, Snowflake 等；
新兴的云数仓，个别是存算拆散的架构，存储和计算能够独立进行扩大，有着很好的横向扩展性和弹性，能够治理大量数据；

数据湖是大数据时代的产物，自身没有绝对官网的概念，其最早是由 Pentaho 的创始人兼首席技术官 James Dixon 与 2010 年 10 月提出的，其后不同厂商有所延长和细化：

AWS 的定义绝对简洁：数据湖是一个集中式存储库，容许以任意规模存储所有结构化和非结构化数据，能够按原样存储数据（无需先对数据进行结构化解决），并运行不同类型的剖析 – 从控制面板和可视化到大数据处理、实时剖析和机器学习，以领导做出更好的决策;
维基的定义：数据湖将数据以天然 / 原始格局存储在对象存储或文件系统中，数据湖通常把企业所有数据对立存储，包含源零碎中的原始数据正本，传感器数据，社交媒体数据等，也包含转换后的数据，以用于撑持报表, 可视化, 高级数据分析和机器学习等。数据湖中的数据包含关系数据库的结构化数据 (行与列)、半结构化的数据(CSV，日志，XML, JSON)，非结构化数据 (电子邮件、文件、PDF) 和二进制数据(图像、音频、视频)；
Wiki: A data lake is a system or repository of data stored in its natural/raw format, usually object blobs or files. A data lake is usually a single store of data including raw copies of source system data, sensor data, social data etc., and transformed data used for tasks such as reporting, visualization, advanced analytics and machine learning）;
数据湖是人工智能 AI 的根底，存储了企业外部各种原始数据，反对丰盛的计算模型 / 范式，所以数据科学家和数据分析人员，能够采纳各种统计分析，机器学习，深度学习等办法，对数据进行各种探索性剖析开掘，答复各种已知问题和未知问题，从而撑持各种 AI 场景；

数据湖为什么叫数据湖，而不叫数据河，数据海？一个贴切的解释是：

“河”强调的是流动性，河究竟是要流入大海的，“海纳百川”，这与企业级数据须要长期积淀对应，因而叫“湖”比叫“河”要贴切；
“海”是无际无界的，而“湖”是有边界的，这与企业级数据有边界向对应（这个边界就是企业 / 组织的业务边界），因而叫“湖”比叫“海”要贴切；
“湖”人造是分层的，满足不同的生态系统要求，这与企业建设对立数据中心，寄存治理数据的需要是统一的，“热”数据在下层，不便利用随时应用；温数据、冷数据位于数据中心不同的存储介质中，达到数据存储容量与老本的均衡；
还有一个无关的概念是“数据沼泽”：数据湖须要精密的数据治理，包含权限治理，一个不足管控、不足治理的数据湖最终会进化为“数据沼泽”，从而使利用无奈无效拜访数据，使存于其中的数据失去价值（数据湖中数据越多越须要数据治理）;

数据湖个别具备以下特点:

数据湖应用对立的存储系统，能够存储结构化数据（数据库的表），半结构化数据（日志，JSON,xml 等），也能够存储非结构化数据（图像音视频等二级制格局）；
数据由内部零碎进入数据湖时，不须要通过荡涤转化后再加载进数据湖（ETL），而是采纳 ELT，间接进行抽取和加载；
数据湖中的数据，在后续须要针对具体场景进行剖析时，才会对湖中曾经存在的原始数据进行 transform 转化到特定的构造进而进行后续剖析，即采纳的是 schema on read 而不是 schema on write;
因为采纳了 ELT 和 schema on read，所以数据湖落地初期不强调数据建模，不须要当时依据畛域常识进行具体的模型设计，所以数据湖绝对数据仓库，我的项目落地速度更快；

数据湖具备开放性，其开放性体现在以下几点：

数据湖具备开放性，体现在数据湖中的数据能够应用多种文件格式进行存储（如开源的 orc/parquet/avro 等等）；
数据湖具备开放性，体现在数据湖尽管内置了存储系统，但个别会对外开放底层存储系统的拜访接口；（如能够间接拜访 HIVE 底层表对应的 HDFS/S3 的文件）；
数据湖具备开放性，也体现在数据湖中的数据能够应用多种剖析引擎进行剖析（实质还是因为数据湖底层存储层是凋谢的，所以能够反对 spark/presto/flink 等多种剖析引擎）；

数据湖开放性的特点，带来了以下优缺点：

通过底层存储系统的开放性，使得数据湖存储的数据结构能够是结构化的，能够是半结构化的，也能够是齐全非结构化；
底层存储系统的开放性，使得下层能够对接多种剖析引擎，各种引擎也能够依据本人针对的场景有针对性地进行各种性能优化；
但底层存储系统的开放性，也使得很多高阶的性能很难实现，例如细粒度（小于文件粒度）的权限治理和统一化的文件治理，所以数据湖中如何对数据进行全生命周期的细粒度的治理是一个难题（包含对立的欠缺的元数据管理和血统体系等）；

数据湖与上云无关，底层存储能够采纳文件系统也能够采纳对象存储，常见的实现有：

自建开源 Hadoop 数据湖架构（最常见）；
云上托管 Hadoop 数据湖架构（如阿里和 AWS 的 EMR 数据湖）；
云上非 hadoop 数据湖，如 Azure 数据湖，阿里云 OSS 数据湖，Alluxio 虚构数据湖等（对象存储）；

通过后面对数据仓库和数据湖的比拟，咱们能够看到，两者在设计上的基本分歧点是对包含存储系统拜访、权限治理、建模要求等方面的把控：

数据仓库，更加关注的是数据应用效率、大规模下的数据管理、平安 / 合规这样的企业级需要；
数据仓库中，数据通过对立但凋谢的服务接口进入数据仓库，数据通常事后定义 schema，用户通过数据服务接口或者计算引擎拜访分布式存储系统中的文件；
数据仓库中，通过形象数据拜访接口 / 权限治理 / 数据自身，换取了更高的性能（无论是存储还是计算）、闭环的平安体系、数据治理的能力等，这些能力对于企业久远的大数据应用都至关重要；
数据湖，通过凋谢底层文件存储，给数据入湖带来了最大的灵活性：进入数据湖的数据能够是结构化的，也能够是半结构化的，甚至能够是齐全非结构化的原始日志。
数据湖，通过凋谢底层文件存储，给下层的引擎也带来了更多的灵便度：各种引擎能够依据本人针对的场景随便读写数据湖中存储的数据，而只须要遵循相当宽松的兼容性约定；
数据湖，凋谢底层文件存储容许文件系统间接拜访，使得很多更高阶的性能很难实现：例如细粒度（小于文件粒度）的权限治理、统一化的文件治理，ACID 事务管理等，读写接口降级也十分困难（须要实现每一个拜访文件的引擎降级，才算降级结束）；
因为数据湖的上述特点，数据湖尽管容易落地，但随着湖中数据量的增多，一旦数据治理措施不善，数据湖容易进化为数据沼泽，数据品质低下，用户无法访问数据或不易找到须要的数据，整个数据湖的价值也就进化了；

数据仓库和数据湖，各有本人的优缺点，前者次要撑持 BI 场景，后者次要撑持 AI 场景，两者并不是互斥的关系：企业搭建数据平台时，既有 BI 需要也有 AI 需要，所以现阶段，很多数据平台是交融了数据仓库和数据湖的：应用数据湖泊作为底座，在数据湖根底上组建多个数据仓库，数据仓库撑持各种 BI 业务场景，数据湖泊的底座除了撑持各个数据仓库，也能够间接撑持机器学习和深度学习等 AI 场景；

上文讲到，企业搭建数据平台时，因为既有 BI 需要也有 AI 需要，所以现阶段，很多数据平台中交融搭建数据湖和数据仓库以应答 BI 和 AI 两大类数据分析场景，然而这样势必会造成资源的节约，减少了数据老本。
为解决数据平台中交融搭建数据仓库和数据湖造成的资源节约问题，数据仓库和数据湖厂商都做了本人的尝试，给出了相应的解决方案：

数据仓库厂商，推出的计划是，在本身已有性能的根底上，开发各种连接器 connector，而后以表面模式拜访内部数据湖底层存储系统中的数据，从而扩大本人的性能；（如 GP/Doris 等都推出了拜访 HDFS 数据湖的 connector）
而数据湖厂商，推出的计划是，补齐短板，改良和加强本身性能，包含反对 ACID 事务，增强数据治理能力等，这种计划实质是数据湖 2.0，业界偏向叫它湖仓一体或数据湖仓 lake house，以强调其整合了传统的 data lake 和 data warehouse 的能力；

笔者尝试应用如下一句话概括总结下数据湖仓：数据湖仓是在数据湖的根本架构上，通过一系列以表格局 Table Format 为代表的新技术解决了数据湖泊的各种传统痛点，将数据仓库和数据湖泊性能交融在一起，使其具备了数据仓库在数据管理方面的各种长处，并间接反对 BI 和 AI 的各种数据分析场景的新型架构

数据湖仓最大的技术创新是，通过一系列以表格局 Table Format 为代表的新技术，为数据湖的根本架构带来了 ACID 事务反对，提供了对记录级别的增删改的反对，对多作业并发读写同一个表或同一个分区的的反对，从而反对了以下个性：

数据湖仓在数据湖的架构根底上交融了数仓式的数据管理能力：A lakehouse uses similar data structures and data management features as those in a data warehouse but instead runs them directly on data lakes，
数据湖仓同时间接反对 BI 和 AI:A lakehouse allows traditional analytics, data science, and machine learning to coexist in the same system, all in an open format;
在数据湖仓 lake house 这个概念下，目前有 delta lake/hudi/iceberg 甚至 hive orc 事务表这些框架来反对；

数据湖仓个别具备以下基本特征：

应用对立的存储引擎和凋谢的格局(文件格式和表格局)；
对象存储优先；
反对多种剖析引擎；
反对并发读写和事务的 acid 个性；
反对记录级别的增删改；
反对增量更新数据；
数据湖仓通常也反对以下高级个性:
模式演变模式束缚: schema evolution,schema enforecement
历史版本回溯: history
流式增量导入(流批一体存储)

数据湖厂商，改良和加强了本身性能，包含反对 ACID 事务和增强数据治理能力等，交融了传统的 data lake 和 data warehouse 的特点，推出了数据湖 2.0 计划，该计划即湖仓一体或数据湖仓 lake house，在数据湖仓 lake house 这个概念下，目前最支流的是数据湖三剑客：delta lake/apache hudi/apache iceberg;

Delta lake: Delta Lake 是由 Apache Spark 背地的商业公司 Databricks 推出的一个致力于在数据湖之上构建湖仓一体架构的开源我的项目，Delta Lake 反对 ACID 事务，可扩大的元数据存储，在现有的数据湖（S3、ADLS、GCS、HDFS）之上实现流批数据处理的对立；
Apache Hudi：Hudi 最后是由 Uber 的工程师为满足其外部数据分析的需要而设计的数据湖我的项目，其设计指标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），在开源的文件系统之上引入了数据库的表和事务的概念，反对高效的更新 / 删除、索引、流式写服务、数据合并、并发管制等性能个性。
Apache Iceberg：Iceberg 最后是由 Netflix 为解决应用 HIVE 构建数据湖仓时的诸多缺点而研发的，最终演化成 Apache 下一个高度形象通用的开源数据湖计划，用于解决海量剖析数据集的凋谢表格局，反对 Spark, Trino, PrestoDB, Flink and Hive 等计算引擎，它具备高度的形象和优雅的设计；

三大数据湖仓框架在官网对本身的介绍如下：

Delta Lake is an open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs for Scala, Java, Rust, Ruby, and Python.
Apahce Hudi: Hudi is a rich platform to build streaming data lakes with incremental data pipelines on a self-managing database layer, while being optimized for lake engines and regular batch processing. brings transactions, record-level updates/deletes and change streams to data lakes!
Apache Iceberg: Iceberg is a high-performance format for huge analytic tables. Iceberg brings the reliability and simplicity of SQL tables to big data, while making it possible for engines like Spark, Trino, Flink, Presto, Hive and Impala to safely work with the same tables, at the same time.

三者均为 Data Lake 的数据存储中间层，是文件格式 file format 之上的表格局 table format，其数据管理的性能均是基于一系列的 meta 文件：

文件格式：文件格式形容的是单个文件中数据的组织和治理格局，如 ORC/PARQUET/AVRO 等；
表格局：表格局表述的是由一系列文件形成的逻辑汇合，即表，其底层的文件与数据的组织和治理格局；
meta 文件相似于数据库的 catalog/wal，起到 schema 治理、事务管理和数据管理的性能：
与数据库不同的是，这些 meta 文件是与数据文件是一起寄存在存储引擎中的，用户能够间接看到；
meta 文件通常应用行存 json/avro 格局，数据文件通常应用列存 parquet/orc 格局；
Meta 文件蕴含有表的 schema 信息: 因而零碎能够本人把握 Schema 的变动，提供 Schema 演变的反对；
Meta 文件蕴含有事务日志 transaction log: meta 文件中记录了 transaction log，所以能够提供 ACID 事务反对；
所有对表的变更操作都会生成一份新的 meta 文件：于是零碎就有了多版本的反对，能够提供拜访历史版本的能力；

三者的类似点如下：

三者都是 Data Lake 的数据存储中间层，在技术实现上都是基于一系列的 meta 文件构建了 file format 之上的 table format；
三者都应用了对立的存储引擎和凋谢的格局(文件格式和表格局)；
三者都能反对支流的高可用存储如 HDFS、S3，对象存储优先；
三者都反对记录级别的 update/delete，以增量更新数据；
三者都反对并发读写和事务 ACID 个性：即原子性、一致性、隔离性、持久性，通过防止垃圾数据的产生保障了数据品质；
三者都 (致力）反对流批一体存储，以流式增量导入数据；
三者都提供了对多查问引擎的反对：如 Spark/Hive/Presto；
三者都反对历史版本回溯；
三者都反对模式束缚和演变 schema evolution,schema enforecement；

三者最后的设计初衷和对应场景并不完全相同，尤其是 Hudi，其设计与另外两个相比差异更为显著，但数据湖仓要解决的问题是独特的，随着工夫的倒退，三者都在一直补齐本人缺失的能力，在未来会彼此趋同，成为性能类似却又各有特点的支流数据湖仓框架，目前三者的差别点次要如下：

Hudi 为了高效的 incremental 的 upserts，设计了相似于主键的 HoodieKey 的概念，表也分为 Copy On write 和 Merge On Read，别离为读和写进行了优化；
Iceberg 定位于高性能的剖析与牢靠的数据管理，专门针对 HIVE 的诸多痛点进行了设计；（如 HIVE 只有目录级别而没有文件级别的统计信息，元数据扩散在 MySQL 和 HDFS 中写入操作原子性差，等等）
Delta 定位于流批一体的数据处理，与 SPARK 的兼容性最好；

以下重点看下 Iceberg 的架构特点：

整体分为三层：Catalog 层，元数据层和数据层；
元数据层自身又是多层级的体系，包含：metadata file, manifest list, manifest file;
- Metadata file: Table state is maintained in metadata files. All changes to table state create a new metadata file and replace the old metadata with an atomic swap. The table metadata file tracks the table schema, partitioning config, custom properties, and snapshots of the table contents. A snapshot represents the state of a table at some time and is used to access the complete set of data files in the table.
- Manifest file: Data files in snapshots are tracked by one or more manifest files that contain a row for each data file in the table, the file’s partition data, and its metrics. The data in a snapshot is the union of all files in its manifests. Manifest files are reused across snapshots to avoid rewriting metadata that is slow-changing. Manifests can track data files with any subset of a table and are not associated with partitions.
- Manifest list/snapshot: The manifests that make up a snapshot are stored in a manifest list file. Each manifest list stores metadata about manifests, including partition stats and data file counts. These stats are used to avoid reading manifests that are not required for an operation.
通过表格局在文件而不是目录级别进行治理（显著区别与 HIVE 的中央）：This table format tracks individual data files in a table instead of directories. This allows writers to create data files in-place and only adds files to the table in an explicit commit.

对大多数尚未大规模引进数据湖仓技术的公司，笔者有如下几点倡议：

随着数字化转型的进一步推动，BI 和 AI 等各类数据分析需要日益递增，为更好地撑持各种数据需要，应尽早调研尝试引入数据湖仓作为企业级数据平台；（抉择适合的产品 / 我的项目 / 场景，能够先从公司本身的数据平台着手）；
随着数字化转型的进一步推动，大数据与云计算的联合越来越严密，数据湖仓平台底层的存储系统更偏向于应用 S3/MINIO/OZONE 等对象存储，应尽早调研尝试应用对象存储（私有云公有云行业云甚至数据中心等场景，都有相应的对象存储解决方案，存算拆散架构下能够通过 Alluxio 等缓存框架减速剖析性能）；
随着数字化转型的进一步推动，企业更加器重资源和利用的弹性 / 可扩展性以及老本，应尽早调研尝试在 K8S 上搭建数据湖仓平台；（大数据计算引擎如 spark/flink 等在 ON K8S 上部署计划曾经成熟，AI 的 tensorflow 等引擎在 K8S 上的部署计划也已成熟）；
增强公司外部 AI 和大数据部门之间的交换单干，尝试通过数据湖仓平台满足两个部门日常各种 BI/AI 类数据分析需要；

正文完