议题参与交流共识人员：
董生 某大型银行 大数据架构师；
bryan 某国有银行 数据架构师
贺成奎 某城商行 大数据研发
任巍 某股份制银行 大数据工程师
李阅兵 某城商行 大数据工程师
1、数据湖建设为什么有必要性？数据方向的投入产出比如何？
@任巍 某股份制银行 大数据工程师：
上游系统建设太多，各个系统不同厂家，每个系统都有自己的管理功能，再加上一些业务数据上的重合，冗余数据太多。不利于体系架构。数据湖的一部分作用，我认为是可以推动上游系统功能整合，将重复功能提炼出来，推动架构改造。从最早的时候的ODS，再到数据仓库，再到数据湖。最明显的变化就是数据量越来越大，承接的上游系统越来越多，批处理加工逻辑越来越复杂。建设数据湖，个人认为还是要结合企业的实际情况来做选择，主打一个降本增效，如果架构改革可以带来更高性价比的数据条线的系统群，那么是有意义的。
@金海波 昆仑银行 大数据架构师：
在已有数据仓库系统的情况下，是否建设数据湖取决于企业的业务发展是否需要，以及投入成本是否合适，相比于数仓建设，数据湖在以下场景有优势：
（1）历史数据存储：银行数据量庞大，包括多年的交易记录、客户信息等。数据湖可用于存储大量的历史数据，以供后续的分析和查询。在存算分离的架构下可以存储数据的成本有明显优势。
（2）非结构化数据存储：银行在业务过程中会产生大量的非结构化数据，如客户的身份证扫描件、合同文件、交易凭证的图像或视频等。数仓主要针对结构化高价值数据进行存储和分析，数据湖擅长非结构化数据存储和关联分析。
（3）实时数据分析：相较于数仓，数据湖使用Kafka、Flink技术可以对进入数据湖的实时数据进行快速处理和分析，满足实时分析的需求。
综上，如果企业没有海量历史数据的查询需求，没有实时数据分析需求和非结构化数据存储需求，就没有必要建设数据湖。
@董生 某大型银行 大数据架构师：
选择数据仓库还是数据湖，取决于具体需求和业务场景。
如果需要高效的数据访问和查询能力，以及稳定的数据支持，且数据以结构化为主，那么数据仓库是更好的选择。
如果需要快速响应新兴的数据分析需求，并希望进行深度数据挖掘与分析，那么数据湖将是更合适的选择。
实际上数据湖与数据仓库的概念不再严格对立，而是趋向于一种互补与融合的发展态势。现代数据架构中，“数据湖仓一体化”成为新的趋势，旨在结合两者的优点，形成更加高效、灵活的数据管理体系。
数据的统一管理和分析，提供统一的服务入口和解决“数据孤岛”。实际上不管是数据仓库和数据湖都能够解决，这3者并不是采用某个产品就无法承载的互斥关系，而是面向应用和依托数据治理的基础，做好数据治理工作，实际上就解决了上面问题的大部分。
@bryan 某国有银行 数据架构师：
产出方面，数据湖是大数据发展的下一阶段，过去只是hadoop和mpp数据湖满足业务需求，但数据类型较少，数据范围偏少，流批计算各自为政等弊端逐渐凸显，有必要扩大数据类型，存储更多数据量，实现一个脚本简单修改即可计算批量和计算一套代码，这种产出或者收益是从软的层面讲述，可能无法难以精准的衡量。
2、湖仓融合后对外提供哪些数据服务，这些服务以什么方式提供？服务的时效性如何？
@贺成奎 某城商行 大数据研发：
基于我行的湖仓融合建设方案，我行湖仓融合后可以对外提供离线数据加工、即席查询、联邦查询等服务。这类数据服务都提供标准SQL能力，部分还提供Restful Api接口，同时具备健全的用户认证以及数据鉴权体系 ，与行内的数据开发平台、数据同步工具、报表平台等集成，供数据开发工程师、数据提取人员、建模师等高效的进行数据处理。
其中离线数据加工使用 Hive 或者 Kyuubi 等技术来实现，该类批处理技术可以稳定处理大数据量加工场景，数据延迟较高，基本在分钟级以上。
即席查询和联邦查询通过Trino、OpenLookeng等技术实现，该类技术基于Coordinator、Worker模式设计，具有任务启动快、高效的基于成本的优化器 、数据流式处理、基于内存处理等特性，资源充足的情况下，能够达到秒级或者毫秒级响应。
@董生 某大型银行 大数据架构师：
提供的数据服务，我理解可以提供绝大部分的内容，包括BI 报表、交互式分析、实时分析、ETL 数据加工、即席查询、数据治理等。
3、目前企业在哪些业务场景支撑方面使用了数据湖？其相对数据仓库(离线、实时)有哪些性能、价值的提升？
@金海波 昆仑银行 大数据架构师：
相比于数仓建设，数据湖在以下场景有优势：
历史数据存储：银行数据量庞大，包括多年的交易记录、客户信息等。数据湖可用于存储大量的历史数据，以供后续的分析和查询。在存算分离的架构下可以存储数据的成本有明显优势。
非结构化数据存储：银行在业务过程中会产生大量的非结构化数据，如客户的身份证扫描件、合同文件、交易凭证的图像或视频等。数仓主要针对结构化高价值数据进行存储和分析，数据湖擅长非结构化数据存储和关联分析。
实时数据分析：相较于数仓，数据湖使用Kafka、Flink技术可以对进入数据湖的实时数据进行快速处理和分析，满足实时分析的需求。
@贺成奎 某城商行 大数据研发：
（1）目前企业在实时数仓方面使用数据湖的场景比较多，实时数仓可以基于Paimon、Hudi等湖表格式来建设，实现数据的流读以及批读加速实时数据的处理。
（2）在非结构化数据处理方面也有比较广泛的应用，比如日志文件，数据可以先存储到数据湖，需要时再建模使用。
（3）在数据探索查询方面也有应用，目前银行业需要对历史数据进行价值挖掘，存量的历史数据存放仓库会加重仓库的建设，读写性能也会有一定影响，有的企业会创建多套集群，以满足批处理任务以及报表查询分析等需求，往往会存在数据的冗余存储，建设的成本高。
基于数据湖的存算分离架构，可以减少数据的冗余存储，同时保证数仓的稳定性。
数据湖相比于数据仓库主要优势有：更加灵活、实时数据处理效率更高、数据存储成本低、支持多模态计算以及丰富的生态。
@bryan 某国有银行 数据架构师：
4、湖仓一体架构与传统的数据仓库与大数据平台架构对比，优势在哪里？
@金海波 昆仑银行 大数据架构师：
在一套架构下可以支持结构化、半结构化和非结构化多种数据类型的数据存储。避免了数据在不同存储系统之间的频繁转换和迁移，大大提高了数据的可用性和价值。基于存算分离架构，降低了存储的冗余，提升了数据压缩比，降低了硬件设备成本，节省了存储成本。数据处理效率，由于使用了实时数据处理和批量数据处理相结合的方式，提升了数据处理效率并保障了数据处理的准确性。数据处理的灵活性，在一套架构下可以使用不同的技术对存储的数据进行数据，既可以使用传统的 SQL 进行数据分析，也可以使用机器学习、人工智能等技术对数据进行深度挖掘和预测分析。数据治理方面，在一套架构下可以实现对全行数据资产的统一数据管理。资源的扩展性，基于存算分离架构，实现了存储和计算资源良好的扩展性，也减少了扩容时间窗口对服务的影响。
@贺成奎 某城商行 大数据研发：
主要优势在于更高的灵活性、成本低、效率高。
灵活性体现在数据存储格式以及计算引擎方面，存储侧可以支持结构化以及非结构化文件存储，数据仓库则需要依赖固定的数据格式；数据湖可以基于Schema On Read或者Schema On Write两种方式进行数据建模，数据仓库则需要预先创建表结构；数据湖基于存算分离架构，存储与计算可以分开进行扩缩容，数据仓库则存算一体，扩容存储时需要同时进行扩容。
成本更低：数据湖存储可以使用对象存储或者分布式存储这类价格更加低廉的存储介质，该类存储介质基于纠删码等机制可以极大提高存储的实际所得率。数据仓库则依赖高性能的磁盘读写，大多采用主备从的模式保障数据的安全性，空间所得率低。
效率更高：数据湖可以支持多模态的引擎处理数据，比如使用Kyuubi处理离线数据，使用Trino处理即席查询、报表分析等场景，同时也可以集成Alluxio等缓存技术，加速数据的快速访问；数据湖在实时数据处理方面优于传统数仓。
传统的中小银行可以根据自己的业务发展程度决定是否需要采用湖仓一体架构，主要考虑点有当前数据的时效性是否能够满足、非结构化数据是否能处理、是否需要通过多模态计算解决读写性能问题等。没有必要一味的追求新技术。
@bryan 某国有银行 数据架构师：
按照大数据领域发展历史，数据仓库将OLTP数据导出来加工，后因hadoop发展对数据量的加工处理又上一台阶。不论数仓还是大数据平台，都希望用户用SQL语句以解决OLTP数据库的思维解决业务需求，但不论大数据平台还是数据仓库，有几个问题依然没有解决：
（1）数据事务的问题，hadoop生态一般不知道，商业产品的MPP数据库直接事务。
（2）数据量的问题，当OLTP的数据库一直将数据泵出给到大数据平台时，对存储资源提出了很多挑战，所以一般都是ETL，按照抽取-转换-加载的模式来操作数据，不需要的数据不加载。
（3）程序开发的问题，过去批量加工为主，随着需求发展，交互查询和流式加工日渐强烈。同样的加工逻辑可能得按照流式加工和批量加工分别写，耗费人力。
（4）基础设施的问题，过去hadoop出现时没有云，所以一般都是yarn调度，现在k8s成为主流，很多计算资源和存储资源可以借助云平台去实现。所以出现了数据湖的技术，去解决事务的问题，存储更大数据量，搞定流批一体和借助云资源的弹性供给能力更好满足运维需求。
5、大数据平台和数据湖建设的价值如何体现？
【问题描述】我们行现在有一套星环的TDH集群和一套Gbase 8a的MPP，每天数据采集平台从业务系统抽取数据后，同步传输给TDH和Gbase。其中，Gbase中按照数仓架构形成了近源层、标准层、共性层和若干集市，供下游应用使用。TDH存储了抽取的原始接口文件，并通过外表和Orc表的方式建设了缓冲层和近源层，还用Gbase回流了一部分共性层数据。
按照当前的架构，绝大部分的数据加工和数据查询都是通过Gbase完成的，TDH仅承担了一部分数据存储的工作。现在存在一系列的问题，包括：两个数据库中存在大量的冗余数据，两个系统间额外的ETL导致时效性变差，两个数据库中各有一部分独有的数据，数据分析师无法跨库关联查询。
问题（1）对于数据体量不是特别大的银行来说，是否有必要同时保留Hadoop平台和Mpp平台？如何优化改进我行的架构体系，实现湖仓一体或者湖仓融合？
问题（2）我行使用Kafka、Flink和Doris建设了一套实时数据架构，实时数仓和离线数仓应该如何协同建设，离线指标和实时指标如何保证口径一致？
问题（3）如何建设Dataops能力，同时适配Mpp、Hadoop、Flink等多套技术体系？
@Ott 某城商行 项目经理科技部：
问题（1）建议梳理行内的数据流向及架构规划，建议可根据应用切分，TDH与Gbase承载不同的应用，如每日经营报表，监管报送，业务系统接口等对数据时效、稳定性及准确性都较高的，由Gbase承载，避免数据搬迁中的时间消耗及依赖等待；自主分析及数据建模等，可以接受T+2及临时性的综合查询需求，可以继续由TDH承载，分析后需要固化的，以需求形式转化到Gbase中，避免数据的网状交互。
问题（2）基于开发成本及对业务系统的数据采集压力，实时数仓应用上可注重于实时营销事件、实时交易欺诈等业务成效高的需求，慎重处理实时统计内需求（可优先流动性监测等影响较大的统计需求，考核及业务运营内建议T+1，建议制定一个需求受理 的标准)，历史查询部分可以将实时数仓数据同步至离线数据处理，历史指标也可有离线数仓同步至实时数仓，进行增量计算。
问题（3）建议综合评估成本投入及成效、业务连续性及人员技能水平，故障应急措施等，是否需要一个统一的大平台。
@bryan 某国有银行 数据架构师：
问题（1）对于一般中小体量的银行，如果MPP可以支撑住，个人感觉可能只使用MPP ，hadoop的存在只是为了解决更大数据量更大并发量的操作，如果以满足业务需求为目标，现在的MPP产品单集群300节点都没问题，数据量已经足够大，有必要按照数据温冷热拆分几个集群也足够了。所谓的数据湖或者湖仓一体，要以该技术解决什么问题来看，在数据量小时没有遇到那么多痛点，没必要为了技术而技术。
问题（2）实时数仓和离线数仓可以建立统一模型，保存到同一数据平台中。批量和实时除了对加工时效性要求外，尽量保证数据模型统一，按照我行实践，采用宽表建立统一模块是比较好的解决方案
问题（3）购买产品，大数据技术栈太多，太复杂，小行自行构建不如直接购买商业产品。不论从云数据、血缘关系、调度平台等，厂商一般都配套成熟的方法论和配套的数据工具，并且小行没有太多人力投产专门做技术研究，这是一笔很大的人力成本。
@董生 某大型银行 大数据架构师：
问题（1）如果数据量不大的情况下，选择一套即可，如果是重在实时查询和分析，建议选择MPP数据库，现在MPP数据仓库支持的数据量也已经达到了PB级别。如果业务偏重于离线处理，可以考虑成本低廉一些的HADOOP。
问题（2）实时数仓和离线数仓，其实就是数据处理的一个演化过程，从最早的ETL到后面的LAMBDA架构再到后面的KAPPA架构。实际上是一个从离线转向实时、快速处理的过程。如果需要两者的一致性，可以使用一些mpp的数据引擎，例如doris，能支撑大量的数据计算，也可以通过消息队列实现流式处理。
问题（3）DATAOPS，主要围绕以下内容建设：需求管理，数据开发，集成测试，质检校验，部署发版，运营治理。实现的方式也多种多样。题主说的兼容hadoop和mpp，个人感觉可以通过建设一个配置化参数的调度工具，兼容多种数据引擎，实现开发集成。
@李阅兵 某城商行 大数据工程师：
问题（1）贵行在大数据平台应用场景多么？如果不多的话不建议再在大数据上投入。可以考虑发展其他平台，例如doris，starrocks。
问题（2）我认为实时数仓即时查询作用最大。可以为各个业务系统减负。实时数仓和离线数仓是两个应用场景。从实时数仓出的数据不可追溯，不可还原。允许第二次查询结果与首次查询结果不一致。口径一致只要求到加工逻辑一致即可，数据不能保证一致。
欢迎点击文末阅读原文到社区原文下留言交流
觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
欢迎关注社区以下 “湖仓一体”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Topic/145621
*本公众号所发布内容仅代表作者观点，不代表社区立场
