不久前召开的中央政治局常委会会议强调,“加快 5G 网络、数据中心等新型基础设施建设进度”。这一要求,为“新基建”按下快进键。战疫期间,助力线上交易、远程办公、在线教育,云服务无处不在;从流动人员健康监测,到疫情态势研判,大数据应用身手不凡;广泛应用机器人配送、无接触方舱 CT 、红外人体温度快速筛检仪,人工智能崭露头角。
企业数字化的转型必然产生大量数据,如何有效存储、治理和利用这些结构化和非结构化数据促进企业业务发展是所有企业面临的共同挑战。为解决这些挑战,业界提出了数据湖的新型数据架构。金融企业有很强烈的诉求搭建自己的数据湖,其不但能存储传统类型数据,也能存储任意其他类型数据,并且能在它们之上做进一步的处理与分析,产生最终输出供各类应用消费,从而助力数字化转型。
一个完整的数据湖项目一般包括数据获取、数据处理、数据分析、数据存储、数据服务等阶段,并且包括数据模型管理、数据安全等关键功能。
在数据湖建设工作中,大家对数据仓库、数据湖、数据中台等基本概念进行了讨论,然后主要围绕“为什么建、怎么建、项目过程中注意事项”等 3 方面的难点和问题展开了热烈讨论:
数据湖的概念可以这样理解,数据湖是将结构化数据与非结构化数据,统一放在一个数据池里,大数据平台提供数据服务,大数据分析软件会根据数据使用频率分级存储,底层采用 SSD 固态硬盘来提供 10% 的热数据计算和利用,使用 SATA 硬盘,提供 10-20% 的温数据相当于近 1-2 年重复使用的数据,采用磁带或蓝光光盘等形式提供 80% 的近线 + 离线数据,采用分级存储可满足数据的全生命周期管理的需求和法律法规、档案相关的规定和要求。
根据要求,典型的组织将需要数据仓库和数据湖,因为它们可满足不同的需求和使用案例。数据仓库是一个优化的数据库,用于分析来自事务系统和业务线应用程序的关系数据。事先定义数据结构和 Schema 以优化快速 SQL 查询,其中结果通常用于操作报告和分析。数据经过了清理、丰富和转换,因此可以充当用户可信任的“单一信息源”。
数据湖有所不同,因为它存储来自业务线应用程序的关系数据,以及来自移动应用程序、 IoT 设备和社交媒体的非关系数据。捕获数据时,未定义数据结构或 Schema 。这意味着您可以存储所有数据,而不需要精心设计也无需知道将来您可能需要哪些问题的答案。您可以对数据使用不同类型的分析(如 SQL 查询、大数据分析、全文搜索、实时分析和机器学习)来获得见解。
随着使用数据仓库的组织看到数据湖的优势,他们正在改进其仓库以包括数据湖,并启用各种查询功能、数据科学使用案例和用于发现新信息模型的高级功能。 Gartner 将此演变称为“分析型数据管理解决方案”或“ DMSA ”。
目前使用较多的是基于 hadoop 的大数据平台。主流 lamdba , kappa 架构与数据湖相比在需求、技术、业务领域有什么区别?什么情况下需要将大数据平台改造为数据湖
个人认为数据湖和大数据平台并没有本质的区别,仅是概念上的不同,都是为解决企业面临的海量结构化和非结构化数据存储、治理和使用等问题,所使用的技术栈也基本类似。上述提到的 lamdba 和 kappa 架构是具体的一种实时数据处理技术,范围更小,是数据湖中的一个子集。个人认为不需要关注过于关注概念,更应该关注企业的业务场景,使用大数据平台或数据湖等等概念均可以,只要解决了业务问题即可。
两者的侧重点完全不一样
( 1 )传统的数据仓库,做的是数据的聚集,将几个数据孤岛的数据汇总起来,做一定维度上的聚集和提炼;
( 2 )数据中台,其实是做数据的标准化,也就是做数据治理、数据管控,使得数据资产化,可以供各个业务所使用。
所以,数据中台的概念是包含数据仓库的,可以理解为数据仓库升级。要迁移,不是容易的事,做数据中台,你必须理解业务,不然你怎么治理,你怎么补全缺失的数据,你又怎么清洗数据。从某种意义上说,数据中台提供的是数据的“产品”,是企业各业务环节可以使用的数据,接近于数据湖的概念。
数据中台和数据仓库的区别核心在于理念的不同,数据仓库更多的是站在 IT 技术的角度,而数据中台是站在 DT 的交付,更多是服务于业务的视角,一开始就强调业务引领
( 1 )数仓主要是数据聚集,数据中台主要是在数据集上增加相关数据处理,快速应对业务需要
( 2 )我认为这中间可以先不用做迁移,保留 T0 层数据
数据来源和建立数仓的目标以及数据应用的方向不同。
首先,从数据来源来说 ,数据中台的数据来源期望是全域数据包括业务
数据库,日志数据,埋点数据,爬虫数据,外部数据等。数据的来源可以是结构化数据或者非结构化的数据。而传统数仓的数据来源主要是业务数据库,数据格式也是以结构化数据为主。
其次,建立数据中台的目标 是为了融合整个企业的全部数据,打通数据之间的隔阂,消除数据标准和口径不一致的问题。数据中台通常会对来自多方面的的基础数据进行清洗,按照主题域概念建立多个以事物为主的主题域比如用户主题域,商品主题域,渠道主题域,门店主题域等等。 数据中台遵循三个 one 的概念: One Data, One ID, One Service , 就是说数据中台不仅仅是汇聚企业各种数据,而且让这些数据遵循相同的标准和口径,对事物的标识能统一或者相互关联,并且提供统一的数据服务接口。就像做菜一样,按照标准化的菜名,先把所有可能用到的材料都准备好。而传统的数仓主要用来做 BI 的报表,目的性很单一,只抽取和清洗该相关分析报表用到基础数据,新增一张报表,就要从底层到上层再做一次。
然后,在数据应用方面 ,建立在数据中台上的数据应用 不仅仅只是面向于 BI 报表,更多面向营销推荐,用户画像, AI 决策分析,风险评估等 。而且这些应用的特点是比较轻,容易快速开发出来,因为重要的数据分析工作在数据中台已经完成并且沉淀,之前工作成果都能被多个应用共享。
结构化数据和非结构化数据是大数据的两种类型,这两者之间并不存在真正的冲突。客户如何选择不是基于数据结构,而是基于使用它们的应用程序:关系数据库用于结构化数据,大多数其他类型的应用程序用于非结构化数据。
结构化数据也称作百行数据,是由二维表结构来逻辑表达和实现的数据,严格地遵循数据格式与长度规范,主要通 度 过关系型数据库进行存储和管理。
与结构化数据相对的是不适于由数据库二维表来表现的非结构化数据,包括所有格式的办公文档、 XML 、 HTML 、各类报表、图片和音频、视频信息等。
曾经讲大数据课的时候给大伙举过一个例子:
拿破仑的航海日志,只有人能看的懂,叫非结构化数据,后续的科学家把航
海日志经过加工、处理,变成机器可读,这叫结构化数据。
简单的来说,结构化数据之间有很强的关联性,像学籍信息,姓名、性别、年龄、户籍、专业、毕业院校等等;非结构化数据,大多是指 office 文件、图片、音视频等文件数据,之间没有或者有很少的关联性。而关系型数据库在实际环境中,基本上可以视为存储或管理的都是结构化数据。
目前使用较多的是基于 hadoop 的大数据平台。主流 lamdba , kappa 架构与数据湖相比在需求、技术、业务领域有什么区别?什么情况下需要将大数据平台改造为数据湖
答:个人认为数据湖和大数据平台并没有本质的区别,仅是概念上的不同,都是为解决企业面临的海量结构化和非结构化数据存储、治理和使用等问题,所使用的技术栈也基本类似。上述提到的 lamdba 和 kappa 架构是具体的一种实时数据处理技术,范围更小,是数据湖中的一个子集。个人认为不需要关注过于关注概念,更应该关注企业的业务场景,使用大数据平台或数据湖等等概念均可以,只要解决了业务问题即可。
答:从定义上看,数据湖可以接收任何数据,不受监督或管理。没有描述性的元数据,和维护它的机制,数据湖会转变成数据沼泽。如果没有元数据,所有对数据的后续使用都意味着从零开始对数据进行分析。建议关注具体的业务场景和业务问题,和实际技术解决方案,对技术概念不必过多关注。
常规理解数据湖的就是一个海量空间,可以包容所有数据和应用,提供所需的所有接口,按需分配,自动精简配置。
首先适合的是私有云平台,现阶段金融行业虚拟化的普及率很高,除了一些重载数据库,大部分应用都适合上虚拟化,所有私有云肯定是适合的应用。第二是无纸化办公,针对现阶段双录系统的数据越来越多,文件数量也非常大,金融客户逐步都在搭建非结构化数据湖。第三大数据应用,大数据现阶段都在推广存算分离,可以做好隔离和弹性扩展,便于容灾等一系列优势。第四开发测试,开发测试区域应用种类越来越多, vmware 、 openstack 、 docker 等多种平台需求,对后端数据湖也提出了要求。
数据湖可以规划一个或者多个集群, XSKY 分布式存储可以一个集群同时提供块/文件/对象协议,提供 librbd / iscsi / nfs / cifs / samba / s3 等全协议。做到多集群统一管理,多种容灾保护功能,在国内多个金融客户落地数据湖案例。
目前数据湖一般作为大数据平台的一个组成部分建设。可用于业务办理中产生的存储图片、扫描件、视频等非结构化数据,也可以作为低成本的历史数据存储平台,存储交易明细、流水等历史数据。
目前一般有两种具体做法:一种是作为非结构化体系的承载平台,管理企业图片、语音等文件,并为上层查询和分析提供服务,基本上是数仓的补充。另外一种是作为整个 lambda 架构落地的逻辑概念,将仓库也囊括其中,整体提供流和批的数据 pipeline 逻辑服务。
答:一般可分为数据采集 -- 数据存储 -- 数据计算 -- 数据应用等功能。
答:开源数据湖方案选型: Hudi 、 Delta 、 Iceberg 。但对于传统行业,尤其是金融行业的企业,不建议使用开源解决方案,其并不满足《信息系统等级保护》等监管机构的要求,建议由厂商提供相应解决方案,如华为、星环、阿里等。这些商用方案都有很多成功案例,技术上差距不大,不好简单比较,主要看具体业务场景和技术人员的熟悉程度、厂商支持力度、商务价格等多种因素。
答:公有云上有非常成熟的方案,比如 aws 提供的 S3 、 EMR 、 Redshift , Athena 等组件,可以直接无缝组装成 lambda 架构落地方案。如果私有化设计相对比较麻烦,开源社区没有一体化方案,基本上需要 hadoop 、 spark 、对象存储、 flink 、数据联邦一系列技术体系组装成企业级的解决方案。
包括,数据存储规划、数据治理规划、数据应用规划等。
我所经历过的,业务场景不明确、组织架构不合理、人员能力不足、领导不够重视、业务部门不配合、合作厂商不给力,很多问题并不是技术问题。
数据湖建设不成功,数据归集、治理、应用有问题,自然就成了沼泽。
建议立项时业务场景一定要明确,解决了面临的业务问题项目就基本成功。挑战会有很多,数据安全、数据治理、团队建设等,但最重要的是要解决企业发展中面临的业务问题,切实帮助业务部门提升业绩、提升管理运营效率。
主要要考虑元数据管理问题,包括数据治理和数据质量之间缺乏协调、数据治理和数据安全之间缺乏协调、使用同一个数据湖的业务部门之间可能产生冲突等问题。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞2
添加新评论0 条评论