• [认证交流] HCCDP – Big Data 认证
    请问大家这个HCCDP – Big Data 有没有视频学习课程或者更多的学习资料 报名后提供的资料太少了
  • [问题求助] Flink不同版本API变化很大,华为云的数据湖是通过Flink SQL,支持所有版本的Flink(包括最新版)吗?
  • [问题求助] 华为云数据湖的SQL语法是标准sql,还是mysql语法,亦或是跟gaussDB一样的pgsql语法?
    华为云数据湖的SQL语法是标准sql,还是mysql语法,亦或是跟gaussDB一样的pgsql语法?
  • [问题求助] opcDA协议数据是否可以接入数据湖中?
    opcDA协议数据是否可以接入数据湖中?
  • [问题求助] DGC如何与其他华为数据产品集成?如DWS
    如何与其他华为数据产品(DWS)集成,以及如何实现数据共享、交换和协同工作以提高效率和减少冗余。
  • [存储] 数据湖存储方案Lakehouse带来数据仓库架构的提升【转】
    转自:https://baijiahao.baidu.com/s?id=1732516299254778715&wfr=spider&for=pc众所周知,数据仓库的初始架构旨在通过把来自各种异构数据源的数据,收集到集中式的存储库中,以提供分析的见解,并充当决策支持和商业智能(business intelligence,BI)的支点。不过,由于它只能支持写入时模式(schema-on-write),而无法存储非结构化的数据、不能与计算紧密集成、以及只能实现本地设备存储,因此近年来,数据仓库碰到了诸如数据模型设计耗时过长等各种挑战。尽管目前的数据仓库能够支持以在线分析处理(OLAP)服务器作为中间层的三层架构,但是它仍然属于一种被用于机器学*和数据科学的整合平台。此类平台虽然具有元数据层、缓存层和索引层,但是这些层次并非单独存在。下面,我将向您重点介绍如何改进当前的数据湖平台,并最终将其变成Lakehouse,以增强架构模式,进而改造传统的数据仓库。HDFS上图展示了传统数据仓库平台的逻辑架构。近年来,随着音频、视频等非结构化数据集的快速增长,许多组织和企业都在寻找和探索某种高级的替代产品,以解决与传统数据仓库系统相关的复杂性问题(正如本文开头所提到的各种痛点)。目前,业界常用的是于2006年面世的Apache Hadoop生态系统。通过利用HDFS(Hadoop分布式文件系统),它解决了在被加载到传统数据仓库系统之前,将原始数据提取并转换为结构化格式(即:行和列的形式)的主要瓶颈问题。HDFS不但能够处理在商用硬件上运行的大型数据集,而且可以适应通常具有GB和TB体量的数据集应用程序。此外,它还可以通过在集群上添加新的节点,来进行水平扩展,以适应海量的数据,而无需考虑任何数据格式的需求。你可以通过链接—https://dataview.in/installation-of-apache-hadoop-3-2-0/,来进一步了解如何在多节点集群上安装和配置Apache Hadoop。Hadoop生态系统(Apache Hive)的另一个优势在于,它支持读取时模式(schema-on-read)。由于传统数据仓库具有严格的写入时模式原则,因此ETL(Extract-Transform-Load的缩写)步骤在遵守已设计好的表空间时,非常耗费时间。而通过一行语句,我们可以将数据湖定义为一个存储库,以存储大量原始数据的原生格式(包括:结构化、非结构化和半结构化等),以用于后续分析,预测分析,通过执行机器学*代码与APP,来构建算法等大数据处理操作。如上图所示,由于没有适合的数据模式,因此数据湖在加载之前不需要进行任何数据转换,那么如何保持数据质量便成了一个大问题。数据湖并没有完全具备解决数据治理和安全相关问题的能力。因此,机器学*(ML)以及数据科学的应用,需要使用非SQL代码,来处理海量的数据,以便成功地部署和运行在数据湖上。但是与SQL引擎相比,由于缺乏已优化的处理引擎,因此数据湖往往无法很好地服务此类应用。而且,仅靠这些引擎,是不足以解决数据湖的所有问题,甚至取代数据仓库的。此外,数据湖中仍然缺少诸如ACID(原子性,atomicity;一致性,consistency;隔离性,isolation;持久性durability)属性等功能、以及索引等高效的访问方法。据此,构建在它上面的机器学*和数据科学等应用,也会遇到例如数据质量、一致性和隔离性等数据管理问题。因此,数据湖需要额外的工具和技术,来支持SQL查询,以便执行各种商业智能和报告。Lakehouse借助着S3、HDFS、Azure Blob等数据湖的处理能力,Lakehouse结合了数据湖的低成本存储优势,以开放的格式为各种系统提供访问,并凸显了数据仓库强大的管理和优化功能。目前,Databricks和AWS都相继引入了数据Lakehouse的概念。Lakehouse能够提高各种高级分析负载的速度,并为其提供更好的数据管理功能。如上图所示,Lakehouse通常分为五层,它们分别是摄取层、存储层、元数据层、API 层、以及最后的消费层。摄取层是Lakehouse的第一层,负责从各种来源提取数据,并将其传送到存储层。该层可以使用各种组件来摄取数据。其中包括:用于从IoT设备处流式传输数据的Apache Kafka、用于从关系数据库管理系统(Relational Database Management System,RDBMS)处导入数据的Apache Sqoop、以及支持批量数据处理的更多组件。由于计算层和存储层得到了分离,因此数据Lakehouse最适合云存储库服务。它可以利用HDFS平台在本地得以实施。在设计上,Lakehouse允许开发者将各种数据保存在诸如AWS S3等低成本对象的存储中,并作为使用标准文件格式(例如Apache Parquet)的对象。Lakehouse中的元数据层负责为湖存储(lake storage)中的所有对象提供元数据(即,提供有关其他数据片段信息的数据)。此外,它还可以管理如下方面:确保并发各项ACID事务使用更快的存储设备(如,处理节点上的SSD和RAM)缓存来自云服务对象所存储的文件通过索引,以加快查询的速度Lakehouses中的API层提供了两种类型的API:声明性DataFrame API和SQL API。在DataFrame API的帮助下,数据科学家可以直接使用数据,来执行他们的各种应用。例如,TensorFlow和Spark MLlib等机器学*代码库,可以读取Parquet等开放的文件格式,并直接查询元数据层。而SQL API可以用于为组合业务分析、数据挖掘、数据可视化等商业智能、以及各种报告类工具,获取数据。最后,消费层包含了诸如Power BI、Tableau等各种工具和应用。整个企业的所有用户都可以使Lakehouse的消费层,来执行各种分析任务。其中包括:商业智能化仪表板、数据可视化、SQL查询、以及机器学*作业等。此外,Lakehouse架构也最适合在组织内部,为各种数据提供单点式访问。小结Lakehouse架构是应对数据提纯的复杂性、查询的兼容性、热数据的缓存等需求产生的。目前,该单体架构尚处于初级阶段。但是,在不久的将来,Lakehouse作为一种数据工具,将能够实现数据发现、数据使用指标、数据治理等更加丰富的功能。
  • [存储] 一文读懂 —— 数据湖
    什么是数据湖数据湖(Data Lake) 是一个用于存储大规模原始和未处理数据的存储系统。与传统的数据库和数据仓库不同,数据湖接受各种类型和格式的数据,包括结构化、半结构化和非结构化数据,而不需要对数据进行事先的转换或预处理。数据湖的目标是为数据科学家、分析师和其他数据使用者提供更灵活、可扩展且可访问的数据存储方式。数据湖是目前比较热的一个概念,许多企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前,搞清楚什么是数据湖,明确一个数据湖项目的基本组成,进而设计数据湖的基本架构,对于数据湖的构建至关重要。关于什么是数据湖,有如下定义。Wikipedia是这样定义的:数据湖是一类存储数据自然/原始格式的系统或存储,通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据,各类任务包括报表、可视化、高级分析和机器学习。数据湖中包括来自于关系型数据库中的结构化数据(行和列)、半结构化数据(如CSV、日志、XML、JSON)、非结构化数据(如email、文档、PDF等)和二进制数据(如图像、音频、视频)。数据沼泽是一种退化的、缺乏管理的数据湖,数据沼泽对于用户来说要么是不可访问的要么就是无法提供足够的价值。数据湖的用途数据湖主要有如下5点用途存储大规模数据:数据湖可以存储海量的数据,无论数据的来源、类型和格式如何。这包括传感器数据、日志文件、图像、音频、视频等。数据集成:数据湖可以整合来自不同系统、应用和部门的数据,无需强制统一的数据模型。这为组织内数据集成提供了更灵活的途径。数据探索和分析:数据湖为数据科学家和分析师提供了更多探索数据的可能性。原始数据可以在需要时进行转换和分析,而不需要事先的预处理。支持大数据处理:数据湖可以与大数据处理框架(如Hadoop、Spark)集成,以进行复杂的数据处理、分析和挖掘。实时分析:数据湖还可以支持实时数据处理,从而使实时分析和反应更加容易。数据湖诞生的历史使命数据湖的诞生为我们工作生活带来了极大的便利,它解决了如下问题数据多样性和复杂性:传统数据库和数据仓库难以处理各种来源、类型和格式的数据。数据湖允许原始数据保留其本来的形式,避免了转换和预处理的繁琐过程。成本效益:存储和处理大量数据的成本持续下降,使得数据湖成为存储海量数据的经济有效方法。需求的不确定性:在实时分析和洞察领域,数据需求可能会不断变化。数据湖使组织能够更快速地适应新的数据需求。数据科学和机器学习:数据湖为数据科学家提供了更大的数据集,使他们能够进行更深入的分析和建模。总的来说,数据湖的出现为组织提供了一种更加灵活、可扩展和成本效益的方法,来存储和利用大量的多样化数据,以支持分析、洞察和决策。开源解决方案以下是一些开源的数据湖解决方案:Apache Hadoop:Hadoop 是一个大数据处理框架,它包括分布式文件系统(HDFS)和用于分布式计算的MapReduce。Hadoop可以用于构建数据湖,存储和处理大规模数据。Apache Spark:Spark 是一个快速、通用的大数据处理引擎,它支持批处理、实时流处理、机器学习和图计算等任务。Spark 也可以用于构建数据湖,并在数据湖中进行复杂的数据处理和分析。Apache Hive:Hive 是一个基于Hadoop的数据仓库系统,它允许使用类似SQL的语法查询和分析存储在Hadoop中的数据。Hive 可以与数据湖一起使用,以提供更灵活的数据存储和查询方式。Presto:Presto 是一个分布式SQL查询引擎,可以查询多种数据源,包括数据湖中的原始数据。它支持高性能、交互式查询,适用于数据探索和分析。Dremio:Dremio 是一个自助数据分析平台,它能够将数据湖中的原始数据转化为结构化数据,提供高性能的查询和分析。它还提供数据虚拟化、数据加速和自动化等功能。Delta Lake:Delta Lake 是一种开源的存储层,可以在数据湖上提供ACID事务、批处理和流式处理,以及模式演化。它在数据湖中引入了数据一致性和可靠性。Hopsworks:Hopsworks 是一个用于构建和管理数据湖的平台,它基于Hadoop和Spark,提供了数据工程、机器学习和数据科学的功能。请注意,这些解决方案都有不同的特点和用途,你可以根据你的需求和技术栈选择适合的开源数据湖解决方案。在选择解决方案时,还要考虑其社区支持、文档、易用性和性能等因素。
  • [问题求助] 一通会话,录音出现多个的问题
    【问题来源】深圳容大【问题简要】一通会话,录音出现多个的问题【问题类别】CC-DIS【期望解决时间】在线等【问题描述】 1690011050-202351,使用openEYE呼入,不知道什么原因,trecordinfo表中出现了两条录音 (绝大多数情况下,一次呼入接听后挂机,无其他操作,只会有一次录音,有极少情况下会出现两条录音,而且录音时间前后衔接不上)  话单数据 INSERT INTO `icdbill_service_22_100`.`tcurrentbilllog`(`TABLEID`, `CALLID`, `CALLIDNUM`, `CALLERNO`, `CALLEENO`, `WAITBEGIN`, `WAITEND`, `ACKBEGIN`, `ACKEND`, `CALLBEGIN`, `CALLEND`, `SERVICENO`, `TRKNO`, `TRKGRPNO`, `MODNO`, `DEVICETYPE`, `DEVICENO`, `DEVICEIN`, `CALLTYPE`, `WAITCAUSE`, `RELEASECAUSE`, `SUBCCNO`, `VDN`, `MEDIATYPE`, `UVID`, `OrgCCNO`, `OrgCallID`, `OrgCalleeNo`, `OrgServiceNo`, `SerCCNO`, `SerService`, `UserLevel`, `UserType`, `CallInCause`, `EnterReason`, `LeaveReason`, `BillInfo`, `PreServiceNo`, `PreDeviceType`, `PreDeviceNo`, `PreDeviceIn`, `MediaInfoType`, `SkillID`, `LocationID`, `BillInfo1`, `BillInfo2`, `BillInfo3`, `BillInfo4`, `OBSServiceID`, `OBSUniqueID`, `CurrentSkillID`, `UapID`, `NetEntID`, `SubMediaType`, `InitVdnId`) VALUES (1454460, '1690011050-202351', -1, '10021', '121', '2023-07-22 15:30:50', '2023-07-22 15:30:50', '2023-07-22 15:30:50', '2023-07-22 15:30:59', '2023-07-22 15:30:59', '2023-07-22 15:31:44', 1, 10, -1, 56, 2, 20213, 'DEVICE_AGENT', 0, 0, 1281, 1, 1, 5, 104170889, 1, '-1--1', NULL, -1, 1, 1, 0, 0, -1, 0, 16, -1, 0, 0, 0, NULL, 1, 1, 0, -1, -1, -1, -1, '', '', 1, 0, 100, -1, 1);  录音数据 INSERT INTO `icdbill_service_22_100`.`trecordinfo7`(`CALLID`, `CallerNo`, `CalleeNo`, `AgentID`, `CallCenterID`, `VirtualCallcenterID`, `BeginTime`, `EndTime`, `FileName`, `CallType`, `ServiceNo`, `VisitTime`, `VisitFlag`, `MediaType`, `ModNo`, `TrkNo`, `ServiceID`, `ServiceInfo`, `CallInfo`, `StopReason`, `LocationID`, `RecordFormat`, `UserWantedSkillID`, `CurrentSkillID`, `CustLevel`, `UapInnerInfo`, `UsEncryptRecordID`) VALUES ('1690011050-202351', '10021', '121', 20213, 1, 1, '2023-07-22 15:30:51', '2023-07-22 15:31:02', 'Y:\\1\\0\\20230722\\20213\\1530501.V3', 0, 1, '2023-07-22 15:30:50', 104170889, 5, 56, 10, 0, '', '', 1, 0, 0, 1, 1, 0, 'D8010000', 65535); INSERT INTO `icdbill_service_22_100`.`trecordinfo7`(`CALLID`, `CallerNo`, `CalleeNo`, `AgentID`, `CallCenterID`, `VirtualCallcenterID`, `BeginTime`, `EndTime`, `FileName`, `CallType`, `ServiceNo`, `VisitTime`, `VisitFlag`, `MediaType`, `ModNo`, `TrkNo`, `ServiceID`, `ServiceInfo`, `CallInfo`, `StopReason`, `LocationID`, `RecordFormat`, `UserWantedSkillID`, `CurrentSkillID`, `CustLevel`, `UapInnerInfo`, `UsEncryptRecordID`) VALUES ('1690011050-202351', '10021', '121', 20213, 1, 1, '2023-07-22 15:31:24', '2023-07-22 15:31:44', 'Y:\\1\\0\\20230722\\20213\\1531233.V3', 0, 1, '2023-07-22 15:30:50', 104170889, 19, 56, 10, 0, '', '', 1, 0, 0, 1, 1, 0, 'D8010100', 65535);