议题主持： 金海波 昆仑银行 大数据架构师
议题参与交流共识人员：
董生 某大型银行 大数据架构师；
bryan 某国有银行 数据架构师
贺成奎 某城商行 大数据研发
李阅兵 某城商行 大数据工程师
关于数据湖建设的必要性和价值的探讨及共识，可点击：金融企业为什么有建设数据湖的必要性？价值如何体现？（同行共识总结）
1、数据湖是否有必要上云，上不上云各自优缺点是什么？
@董生 某大型银行 大数据架构师：
个人觉得需要综合考虑。先说下上云的优势：
（1）带来了灵活性，云平台提供了弹性的伸缩功能，可以根据业务需求快速调整资源 ，实际上资源的使用更加合理和降本增效。
（2）云上提供了很多管理工具，运维和监控起来较为方便。
（3）数据恢复，数据灾备这些都不需要自己动手建设，云端提供了良好的机制与策略。然后说下不太好的地方：首先是数据安全方面，数据是企业最大的资产，云上虽然提供了很多保护，但是还是存在风险。其次就是与云厂商绑定太深，迁移时候会有痛点。
@bryan 某国有银行 数据架构师：
个人认为数据湖有必要上云，理由如下：
（1）充分利用云底座的资源集约化管理，数据湖对计算和存储的需求量都很大，利用云的虚拟机，裸金属和容器，均可以进行池化管理，有效提升资源效率。
（2）可以充分利用云底座的资源快速供应能力。数据湖的很多场景需要快速应对业务的峰值波谷变化，云的弹性伸缩能力可以有效应对业务需求，快速供应资源和回收。从国外snowflake等先进公司实践，从技术发展趋势看，数据湖和云结合都是未来技术发展趋势。
@贺成奎 某城商行 大数据研发：
Hadoop技术建设数据湖能替代MPP数据仓库的能力吗？如果替代优缺点是什么？
@董生 某大型银行 大数据架构师：
Hadoop技术建设数据湖能替代MPP数据仓库的能力吗，结合这块我谈谈我的想法，仅供参考：结合我们的实际经验，目前看还是不能取代的，MPP的出现是为了并行计算，更快的获取到计算的结果。数据湖即使例如hudi等产品，已经说做到准实时，但是基本都还是数十秒的才能获取到结果。相对MPP快速的查询还是有所不行。但是数据湖的优势是包容性，对各类数据格式的兼容。我相信未来对MPP的发展一定是兼容各种类的数据存储格式，那个时候，可以说两者就不远了。
@bryan 某国有银行 数据架构师：
个人认为不能。
（1）MPP数据库目前主要擅长存储大数据量和大表之间的复杂查询，一般有开源和成熟的市场产品。
（2）hadoop更擅长存储和一定场景的数据计算加工。仔细研究大数据生态就会发现，各种软件琳琅满目，但每种软件都是适应一定的业务场景，换个场景可能就得换个软件。另外，基本主流的hadoop生态产品也都是基于开源软件改造，并且保持与开源的同步发展，因为一旦建立一个公司的独立分支，就意向着深不见底的人力投入，产品效果还未必如开源软件做的好。这种生态就决定了公司几乎无力改变各种生态软件的架构缺点，也没法增加更多的适配场景。所以就会出现各家银行大数据软件用的种类多，难以统一。银行更重要的是系统稳定运行，这就决定了不会投入更多人员会研究各种开源软件，不论是MPP数据库还是hadoop生态，必然购买产品服务，但产品公司也无力和无意对软件深度改造，这就决定了无法替代。
@贺成奎 某城商行 大数据研发：
3、哪些数据应该入湖，入湖规则是什么？入湖数据的生命周期如何定义和管理？
@董生 某大型银行 大数据架构师：
如果只是考虑数据入湖，正常的说所有的原始数据（文本、图片、表、语音等）都需要入湖，在使用时候，提取出需要的结构化数据，纳入数据仓库，进行ETL加工和后续分析使用。分析的结果一般是也是存储在数据仓库中。但是现在都在提湖仓一体，所有的分析前后的数据都存储在数据湖中，其实也就是鼓励所有数据存放在湖中。数据的保留周期，取决于业务的需要和企业战略，定义仓内数据的生命周期。
@bryan 某国有银行 数据架构师：
数据湖的理念是存数已备未来用，而不是过去用啥存啥的理念，所以任何有可能用到的数据都应该存。入湖数据应该是所有业务数据，包括结构化和非结构化数据。鉴于数据量大，资源成本高，业务入湖时一定做好生命周期管理，满足业务需求的前提下，尽量分级分类做好数据管理，每类数据做好周期管理。
@贺成奎 某城商行 大数据研发：
4、实时数据湖在建设存算分离过程中有哪些坑需要避免？
@bryan 某国有银行 数据架构师：
我行正在进行数据湖建设，并在同步探索存算分行模式，分享如下：
（1）实时数据湖的商业产品正在成熟完善中，各家大厂产品并不是那么完善，如果自行搭建开源产品，建议也经过一两年的沉淀，不要迷行厂商宣传。
（2）实时计算只是一种场景而已，不要试图任何一药治百病，有些时效性不高的可能采用批量加工更合适。
（3）不是所有的数据湖都必要配备25G网卡，很多人认为存算分离后需要更好的硬件配合，但要不要高配硬件，需要看一下实际场景，如果10G的网卡都跑不满，没必要配25G网卡。
@金海波 昆仑银行 大数据架构师：
实时数据湖在建设存算分离过程中主要有以下需要注意：
存储性能方面：选择的存储系统如果不能满足实时数据湖对数据读写性能的要求，会导致数据处理延迟增加，影响实时性。实时数据湖中可能会存在大量的小文件，如果存储系统在处理大量小文件的随机读写时性能较差，将会导致实时数据湖无法满足业务需求。在选型时要充分考虑存储系统的读写性能、吞吐量、延迟等指标，做好测试和评估。
网络带宽方面：存算分离后，计算节点需要频繁地从存储节点读取和写入数据，网络带宽成为影响系统性能的关键因素。如果网络带宽不足，会导致数据传输延迟增加，影响实时数据处理。在建设实时数据湖时，要确保计算节点和存储节点之间有足够的网络带宽，并对网络性能进行监控和优化。
系统维护方面：存算分离的系统架构在升级和维护时可能会涉及到多个组件的协同工作，如果升级和维护方案不合理，可能会导致系统停机时间过长或数据丢失等问题。在进行系统升级和维护时，要制定详细的计划和方案，进行充分的测试和验证，并选择合适的时间窗口进行操作。
@任巍 某股份制银行 大数据工程师：
实时数据湖在建设存算分离过程中有哪些坑需要避免，结合这块我可以谈谈我们行的一些实践的经验，希望可以给你带来参考和帮助：
5、对于湖仓一体架构下，如何避免数据沼泽的形成？
@金海波 昆仑银行 大数据架构师：
防止出现数据沼泽需要做以下工作：
（1）制定数据入湖策略，明确哪些数据可以进入湖仓一体系统，以及数据的采集方式和频率。对数据进行筛选和过滤，只将有价值的数据存入湖仓，避免大量无用数据的积累。
（2）强化元数据管理，建立全面的元数据存储库，记录数据的来源、结构、业务含义、数据质量等信息。当用户查询数据时，可以通过元数据快速了解数据的背景和含义，提高数据的可理解性和可用性，并对元数据及时更新，保障准确性和及时性。
（3）建立明确的数据标准，定义统一的数据格式、编码规范和数据质量要求。例如，对于客户信息，明确规定姓名、地址、联系方式等字段的格式和取值范围。这样可以确保进入湖仓一体系统的数据具有一致性，减少数据混乱。
（4）建立数据质量检测机制，在数据入湖前对数据进行质量检查，不符合质量要求的数据不予入湖。例如，检查数据的完整性、准确性和一致性等。
@贺成奎 某城商行 大数据研发：
针对数据湖数据沼泽的情况，要做到数据的可查询、可溯源。入湖的数据需要打好标签，非结构化数据标记清楚数据来源以及用途、数据使用周期等，该类元数据信息可以存放ES以便快速进行检索使用；结构化数据或者数据湖表则做好数据的生命周期管理，数据文件与元数据服务进行绑定，标记好表注释、字段注释等，对表进行归类，与资产平台进行集成，方便业务人员快速检索探查数据。数据安全方面则交由资产平台进行管控，通过至下而上的审批流程保障数据的安全。
@任巍 某股份制银行 大数据工程师：
数据沼泽是数据湖发展过程中的一个棘手问题。随着时间的推移，就会发现数据湖的数据量增长速度越来越快，进一步分析就会发现贴源层数据会占据数据湖总容量的很大部分内容，很多集市缺少清理策略，很多数据都是每日全量保存，因此数据湖的数据增长速度越来越快。如果从业务增长的角度分析，如此快速的数据增长速率是很难理解的，因为无论是核心系统还是外围的上游系统，业务数据量增长速率不应该如此之快。所以就出现了让很多人内心产生疑惑的问题：数据湖里的数据都是必要的吗?下面重点探讨一下数据沼泽的无效数据问题。
数据湖的定位与归档系统的定位影响到了数据湖里的数据是否可以清理，如果数据湖作为上游系统数据最终归宿，那么贴源层数据还是要永久保留的，一方面是因为上游系统已经没有了历史数据，另一方面存储于数据湖中的数据在数据提取和数据使用方面都是很方便的。但是HDFS三副本机制下对应的存储成本是很高的，因此随着数据湖数据的快速增加，对于冷数据的归属，还是建议放置于低成本的普通对象存储或者分布式存储中，相比较HDFS而言成本是较低的。除了归档以外，从客观来看，无论是贴源数据还是集市数据，都需要推动业务人员制定清理策略。比较容易推动的是集市层，因为贴源层如果不清理的话，集市层所需要的数据可以通过重跑的方式跑出来；难点在于贴源数据是否可以清理，由于经常会遇到上游集市数据不准确需要重跑的需求，贴源层需要及时的为上游提供重跑所需数据，若是已清理（且归档），数据恢复时效也很难保证业务需求。贴源层需要更加精细化的管理，尽可能减少数据保存量，减轻数据湖压力。从Hadoop集群层面看，基于HDFS的文件存储系统，在存储和算力两个角度分析，更多的瓶颈在于存储，数据沼泽是造成存算的重要因素。存算分离一定程度可以缓解，但是并不能根部改变。使用更大的数据盘也是一个思路，但是成本会增加更多。目前看来，从业务层面推动数据沼泽问题中无效数据的清理是优化该问题的一个思路，让业务人员明白数据湖最宝贵的除了算力资源，还有存储资源。为每个集市设定合理的存储空间，并严格加以管控，可以一定程度避免数据沼泽无效数据问题的发生。
@bryan 某国有银行 数据架构师：
过去很多行在做大数据建设时就已经形成了数据沼泽，这和部门各自为政有一定的管理，所以四大行的总行一般配置专门的数据管理部门。一般采用如下方式：
（1）做好数据统一平台：建议全行统一的数据湖平台，服务于所有业务部门，不会因为某个业务部门需求单独建设仓库。
（2）做好元数据管理：从raw data到ODS到加工数据，做好配套的元数据管理，避免找不到数据是形成数据沼泽的一个重要原因。实践中，很多业务部门不知其他业务部门已经建设了相关模型，所以才会有反复的建设需求，并形成不同业务领域的数据仓库，这会逐步形成数据沼泽。
6、总行内部如何降低数据共享成本？总行与分行之间如何降低数据共享成本？
@bryan 某国有银行 数据架构师：
现在银行基本情况是，核心系统全国统一的业务系统，产生的业务数据必然全国集中统一。各家省分行一般会有自己特色业务，形成了“总行共性业务+分行特色业务”的特点。按照人民银行、金监局等各级部门要求，一般各行分行会收到总行数据。并根据自己的特色业务进行加工处理，这是历史形成的事实，但这面临如下挑战：
（1）对分行技术要求高，每家分行需要自建基础硬件设施和软件数据处理平台，会造成硬件资源浪费，分行人员技能难以满足要求。
（2）分行管理水平相对有限，往往会出现数据合规保护的问题。
（3）总行每日将一些未加工的分行数据集中传输到分行 ，对网络带宽要求较高。基于此方面考虑，建议采用数据集中管理+分行特色加工的模式。
数据集中管理：将所有分行数据集中在总行进行统一管理，有利于构建统一的数据处理的软硬件成本，1）硬件集中到一起，形成云计算的硬件池化效应，有效提升资源效率；2）软件统一加工处理，省去了分行各自分别加工的复杂性，分行和总行各个业务部门均按照统一的数据标准和数据加工口径形成报表，解决了各部门及其分行报数口径不统一的问题；3）形成有效的数据管理，极大避免分行和业务部门管理不善带来的数据安全合规问题。
分行/各部门个性数据加工：分行和各部门在同一的资源池中按照统一的数据模型和加工标准进行个性数据加工，加工后的数据依然保存在同一的数据湖平台中，并做好元数据管理，可实现数据的有效共享，无需二次加工。
@金海波 昆仑银行 大数据架构师：
降低总行内部和总分行数据共享成本主要有以下几个方面：
（1）建设全行统一的数据平台，整合全行数据资源，实现数据的集中存储和管理。这样可以避免数据的重复存储和分散管理，降低存储成本。提供统一的数据访问接口，方便各部门快速获取所需数据，减少数据查询和获取的时间成本。
（2）建立全行数据标准，制定统一的数据标准和规范，包括业务含义、技术含义等。确保各部门的数据具有一致性和可比性，方面跨部门和机构层级的数据使用。
（3）建立数据激励机制，通过排名、打分等形式鼓励各部门各层级积极参与数据共享，提高部门的数据共享积极性。建立数据共享的评价机制，对各部门的数据共享情况进行评估和反馈，促进数据共享的持续改进。
@任巍 某股份制银行 大数据工程师：
结合如何降低总行内部共享成本，我可以谈谈我们的经验：可以考虑在数据集市层面推动数据共享的解决。数据集市建议设立专门的系统名称，从而根据系统业务归属方来确定该集市的业务主管部门。所有的业务指标均由对应的主管业务部门负责制定、审核。数据集市开发团队根据主管业务部门的要求进行统一开发。对于分行的数据共享，同样可以建立分行集市，由该团队统一建立接口定义，下发分行。如果分行有自己个性化的指标，可以基于总行的数据进行二次开发。
@李阅兵 某城商行 大数据工程师：
个人观点 ：想降低数据共享成本，必须做到以下几点 ：
（1）数据统一的指标定义，统一指标口径。全行一个口径，不能一个指标，不同部门不同加工逻辑。指定数据指标的归口管理部门。
（2）总行业务部门整合各自条线的数据需求，数据部门给出数据需求的解决方案。
难点总结：综上所述，数据湖建设在企业数字化转型中面临诸多难点。上云与否需权衡灵活性与数据安全风险及厂商绑定问题；Hadoop 技术建设的数据湖难以完全替代 MPP 数据仓库，存在性能、稳定性等不足；确定入湖数据规则，要考虑湖仓关系、业务场景及数据生命周期等；实时数据湖存算分离需关注产品成熟度、计算场景、硬件配置及网络存储性能，系统维护难度大；避免数据沼泽需在策略制定、元数据管理、标准建立及业务层面清理无效数据等多方面着力；降低数据共享成本要建设统一平台、建立标准激励机制及推动集市共享等。这些难点需要企业综合考虑自身情况，谨慎决策，运用有效的技术和管理手段逐一攻克，以充分发挥数据湖在数字化转型中的重要作用。
欢迎点击文末阅读原文到社区原文下留言交流
觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
欢迎关注社区以下 “湖仓一体”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Topic/145621
