概述Logstash 是免费且开放的服务器端数据处理管道，能够从多个来源采集数据，转换数据，然后将数据发送到“存储库”中。具体请参见：https://www.elastic.co/cn/logstashOBS是华为云的对象存储服务，OBS支持S3对象存储协议，Logstash内置了和s3进行交互的输入和输出插件，所以可以借助其S3插件完成和obs的对接，本文用于描述Logstash如何对接使用OBS。OBS服务有对象桶和并行文件桶两种选择，在大数据场景下建议选择并行文件桶。操作步骤以logstash-7.10.2为例1. 下载和安装logstash（1）https://www.elastic.co/cn/downloads/past-releases/logstash-7-10-2（2）tar zxvf logstash-6.4.2.tar.gz2. 示例以file为源端，以obs为目的端（1）创建配置文件file2obs.confinput {file {path => "/usr/local/nginx/logs/access.log"start_position => "beginning"}}output {s3 {endpoint => "obs endpoint"bucket => "obs桶名"access_key_id => "ak"secret_access_key => "sk"size_file => 1048576time_file => 1prefix => "test/logtest/"enable_metric => true}}重要参数说明：endpoint：obs的endpointaccess_key_id：具备访问obs权限的aksecret_access_key：具备访问obs权限的skbucket：obs的桶名称size_file：表示多少byte滚动文件保存time_file：表示多少分钟滚动文件保存prefix：指定文件存储的目录，例如”weili/logtest/”,此时文件会写入到桶的weili/logtest/目录下（注意路径不要以/开头）更多详情参见：https://www.elastic.co/guide/en/logstash/7.x/plugins-outputs-s3.html（2）运行logstashbin/logstash -f ../conf/file2obs.conf注意事项避免使用较老版本的logstash，请使用较新版本的logstash，例如>=7.10.2。

概述DataX是一个数据同步框架，实现了包括 MySQL、SQL Server、Oracle、PostgreSQL、HDFS、Hive、HBase、OTS、ODPS 等各种异构数据源之间高效的数据同步功能。具体请参见：https://github.com/alibaba/DataX/OBS是华为云的对象存储服务，OBS支持S3对象存储协议，同时也支持HDFS协议，在大数据场景中可以替代hadoop系统中的HDFS服务，本文用于描述DataX如何对接使用OBS。OBS服务有对象桶和并行文件桶两种选择，在大数据场景下建议选择并行文件桶。操作步骤1. 下载datax源码https://github.com/alibaba/DataX.git2. 修改datax源码（1）升级hdfsreader和hdfswrite模块依赖的hadoop版本：因为OBS不再支持hadoop2.8以下的版本修改datax\hdfswriter\pom.xml和datax\hdfsreader\pom.xml文件<properties><!--由2.7.1升级到2.8.3--><hadoop.version>2.8.3</hadoop.version></properties>3. 编译打包安装datax（1）进入datax源码根目录执行如下maven命令：mvn -U clean package assembly:assembly -Dmaven.test.skip=true在datax源码根目录/target目录下生成datax.tar.gz压缩文件（2）解压datax.tar.gz4. 添加hadoop-huaweicloud-xxx.jar包（1）下载对应版本的jar包：https://github.com/huaweicloud/obsa-hdfs/tree/master/release（2） 将上述jar包放入：datax根目录\plugin\writer\hdfswriter\libs和datax根目录\plugin\reader\hdfsreader\libs5. 示例以txtfilereader为源端，以obs为目的端：（1）创建作业配置文件file2obs.json{"setting": {},"job": {"setting": {"speed": {"channel": 2}},"content": [{"reader": {"name": "txtfilereader","parameter": {"path": ["/root/datax/bin/obstest.txt"],"encoding": "UTF-8","column": [{"index": 0,"type": "STRING"},{"index": 1,"type": "STRING"}],"fieldDelimiter": "\t"}},"writer": {"name": "hdfswriter","parameter": {"defaultFS": "obs://moguauthtest",##obs桶"fileType": "text","path": "/wgptesttable",##obs桶中的路径"fileName": "test","column": [{"name": "col1","type": "STRING"},{"name": "col2","type": "STRING"}],"writeMode": "append","fieldDelimiter": "\t","hadoopConfig": {##此部分hadoop配置必须添加"fs.obs.impl": "org.apache.hadoop.fs.obs.OBSFileSystem","fs.obs.access.key": "可访问OBS的ak","fs.obs.secret.key": "可访问OBS的sk","fs.obs.endpoint": "OBS桶所在region"}}}}]}}（2）启动DataXpython datax根目录/bin/datax.py file2obs.json注意事项1.OBS服务有对象桶和并行文件桶两种选择，目前datax暂时仅支持对接OBS并行文件桶

Flume 是一个分布式的、可靠的和高可用的服务，用于收集、聚合以及移动大量日志数据。具体请参见：http://flume.apache.org/OBS是华为云的对象存储服务，OBS支持S3对象存储协议，同时也支持HDFS协议，在大数据场景中可以替代hadoop系统中的HDFS服务，本文用于描述flume如何对接使用OBS。OBS服务有对象桶和并行文件桶两种选择，在大数据场景下建议选择并行文件桶。操作步骤以flume 1.9版本为例1. 下载flumehttp://flume.apache.org/download.html2. 安装flume：支持写数据到OBS（1）解压apache-flume-1.9.0-bin.tar.gz到apache-flume-1.9.0-bin目录（2）在部署了Hadoop的环境中（设置了HADOOP_HOME等环境变量）按照下述文档配置hadoop环境https://github.com/huaweicloud/obsa-hdfs/blob/master/release/doc/%E5%AF%B9%E8%B1%A1%E5%AD%98%E5%82%A8%E6%9C%8D%E5%8A%A1OBSA-HDFS%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97.pdf（3）在没有部署Hadoop的环境中下载hadoop并按照下述文档配置hadoop环境https://github.com/huaweicloud/obsa-hdfs/blob/master/release/doc/%E5%AF%B9%E8%B1%A1%E5%AD%98%E5%82%A8%E6%9C%8D%E5%8A%A1OBSA-HDFS%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97.pdf将hadoop中的相关jar包复制到 apache-flume-1.9.0-bin/lib 目录下，包含hadoop-huaweicloud-xxx.jar将配置好的core-site.xml文件复制到flume根目录/conf目录下3. 示例以flume内置的StressSource为source，以file为channel，以obs为sink（1）创建flume配置文件：sink2obs.propertiesagent.sources = r1agent.channels = c1agent.sinks = k1agent.sources.r1.type = org.apache.flume.source.StressSourceagent.sources.r1.channels = c1agent.sources.r1.size = 1024agent.sources.r1.maxTotalEvents = 100000agent.sources.r1.maxEventsPerSecond = 10000agent.sources.r1.batchSize=1000agent.sources.r1.interceptors = i1agent.sources.r1.interceptors.i1.type = hostagent.sources.r1.interceptors.i1.useIP = falseagent.channels.c1.type = fileagent.channels.c1.dataDirs = /data/agent/agent/flume-dataagent.channels.c1.checkpointDir = /data/agent/agent/flume-checkpointagent.channels.c1.capacity = 500000agent.channels.c1.transactionCapacity = 50000agent.sinks.k1.channel = c1agent.sinks.k1.type = hdfsagent.sinks.k1.hdfs.useLocalTimeStamp = trueagent.sinks.k1.hdfs.filePrefix = %{host}_k1agent.sinks.k1.hdfs.path = obs://obs桶名/flume/dc/create_time=%Y-%m-%d %H-%Magent.sinks.k1.hdfs.fileType = DataStreamagent.sinks.k1.hdfs.writeFormat = Textagent.sinks.k1.hdfs.rollSize = 0agent.sinks.k1.hdfs.rollCount = 1000agent.sinks.k1.hdfs.rollInterval = 0agent.sinks.k1.hdfs.batchSize = 1000agent.sinks.k1.hdfs.round = trueagent.sinks.k1.hdfs.roundValue = 10agent.sinks.k1.hdfs.roundUnit = minute（2）启动flume agent./bin/flume-ng agent -n agent -c conf/ -f conf/sink2obs.properties注意事项1. 多sink写同一文件OBS和HDFS在一致性保证上是有差别的：HDFS租约机制可以保证并发写同一个文件时不会产生一致性问题，但是OBS实现的HDFS协议不支持租约机制（并发写同一个文件时将产生不可确定的状态），所以在flume场景下可以通过文件命名规则进行解决，例如sink文件的命名规则：hostname-sinkname作为文件的前缀，如果一个主机上部署了多个flume agent，不同的agent要有不同的sinkname2. flume日志配置为了减少无谓的日志输出，可以在flume根目录/conf目录下的log4j.properties文件中增加如下配置：log4j.logger.org.apache.hadoop.fs.obs=ERRORlog4j.logger.com.obs=ERROR3. obsa写入时临时文件的目录配置Flume写obs时会先写入本地磁盘缓冲区，然后上传到obs，如果对写入obs有极致性能要求请选择高性能磁盘作为缓冲区，在core-site.xml文件中增加如下配置：<property><name>fs.obs.buffer.dir</name><value>xxx</value></property>

PrestoSQL对接OBS简介Presto分为prestoSql（现更名为Trino）和PrestoDB两大分支或是发行版。Presto on OBS仅支持prestoSql/Trino发行版，下述对接步骤以prestoSql-333版本为例。OBS是华为云的对象存储服务，OBS支持S3对象存储协议，同时也支持HDFS协议，在大数据场景中可以替代hadoop系统中的HDFS服务，本文用于描述flume如何对接使用OBS。OBS服务有对象桶和并行文件桶两种选择，在大数据场景下建议选择并行文件桶。安装HadoopHadoop版本2.8.3，按照https://github.com/huaweicloud/obsa-hdfs/tree/master/release/doc配置hadoop安装HiveHive版本2.3.3安装presto server下载安装版本：prestoSQL-3331.下载Presto客户端和服务端：https://repo1.maven.org/maven2/io/prestosql/presto-cli/https://repo1.maven.org/maven2/io/prestosql/presto-server2.下载华为OBSA-HDFS插件：hadoop-huaweicloud-${hadoop.version}-hw-${version}.jarhttps://github.com/huaweicloud/obsa-hdfs/tree/master/release3.解压Presto服务端：tar –zxvf presto-server-333.tar.gz在presto根目录/plugin/hive-hadoop2下放入如下两个jar包hadoop-huaweicloud-${hadoop.version}-hw-${version}.jarApache commons-lang-xxx.jar（可从maven中央仓库下载或从hadoop目录中拷贝）配置presto在安装目录里创建etc目录。这目录会有以下配置（自己创建）：· 结点配置文件：每个结点的环境配置· JVM配置文件：Java虚拟机的命令行选项· Server配置文件（Config Properties）：Persto server的配置· Catelog配置文件：配置presto的各种Connector（数据源）· 日志配置文件：配置Presto日志结点配置文件结点属性文件etc/node.properties，包含每个结点的配置。一个结点是一个Presto实例。这文件一般是在Presto第一次安装时创建的。以下是最小配置：node.environment=productionnode.id=ffffffff-ffff-ffff-ffff-ffffffffffffnode.data-dir=/var/presto/data解释：node.environment: 环境名字，Presto集群中的结点的环境名字都必须是一样的。node.id: 唯一标识，每个结点的标识都必须是唯一的。就算重启或升级Presto都必须还保持原来的标识。node.data-dir: 数据目录，Presto用它来保存log和其他数据eg：node.environment=presto_clusternode.id= bigdata00node.data-dir /home/modules/presto-server-0.215/data #data需要自己手动创建JVM配置文件JVM配置文件etc/jvm.config，包含启动Java虚拟机时的命令行选项。格式是每一行是一个命令行选项。此文件数据是由shell解析，所以选项中包含空格或特殊字符会被忽略。以下是参考配置：-server-Xmx16G-XX:-UseBiasedLocking-XX:+UseG1GC-XX:G1HeapRegionSize=32M-XX:+ExplicitGCInvokesConcurrent-XX:+ExitOnOutOfMemoryError-XX:+UseGCOverheadLimit-XX:+HeapDumpOnOutOfMemoryError-XX:ReservedCodeCacheSize=512M-Djdk.attach.allowAttachSelf=true-Djdk.nio.maxCachedBufferSize=2000000备注：以上参数都是官网参数，实际环境需要调整Server配置文件配置属性文件etc/config.properties，包含Presto server的配置。Presto server可以同时为coordinator和worker，但一个大集群里最好就是只指定一台机器为coordinator。（1）coordinator节点的配置文件coordinator=truenode-scheduler.include-coordinator=truehttp-server.http.port=5050discovery-server.enabled=truediscovery.uri=http://192.168.XX.XX:5050query.max-memory=20GBquery.max-memory-per-node=1GBquery.max-total-memory-per-node=2GB（2）worker节点的配置文件coordinator=falsehttp-server.http.port=5050discovery.uri=http://192.168.XX.XX:5050query.max-memory=20GBquery.max-memory-per-node=1GBquery.max-total-memory-per-node=2GB解释：coordinator： 是否运行该实例为coordinator（接受client的查询和管理查询执行）。node-scheduler.include-coordinator:coordinator是否也作为work。对于大型集群来说，在coordinator里做worker的工作会影响查询性能。http-server.http.port:指定HTTP端口。Presto使用HTTP来与外部和内部进行交流。query.max-memory: 查询能用到的最大总内存query.max-memory-per-node: 查询能用到的最大单结点内存discovery-server.enabled: Presto使用Discovery服务去找到集群中的所有结点。每个Presto实例在启动时都会在Discovery服务里注册。这样可以简化部署，不需要额外的服务，Presto的coordinator内置一个Discovery服务。也是使用HTTP端口。discovery.uri: Discovery服务的URI。将example.net:8080替换为coordinator的host和端口。这个URI不能以斜杠结尾，这个错误需特别注意，不然会报404错误。另外还有以下属性：jmx.rmiregistry.port: 指定JMX RMI的注册。JMX client可以连接此端口jmx.rmiserver.port: 指定JXM RMI的服务器。可通过JMX监听。Catelog配置文件（重点）hive connector配置如下:a、在etc目录下创建catalog目录b、创建一个hive connector的配置文件：hive.properties# hive.propertiesconnector.name=hive-hadoop2 #连接名hive.metastore.uri=thrift://192.168.XX.XX:9083 #配置hive metastore连接hive.config.resources=/home/modules/hadoop-2.8.3/etc/hadoop/core-site.xml,/home/modules/hadoop-2.8.3/etc/hadoop/hdfs-site.xml,/home/modules/hadoop-2.8.3/etc/hadoop/mapred-site.xml #指定hadoop的配置文件，注意core-site.xml需要按照https://github.com/huaweicloud/obsa-hdfs/tree/master/release/doc配置hive.allow-drop-table=true #给删表权限日志配置文件创建文件log.properties写入内容：com.facebook.presto=INFO备注：日志级别有四种，DEBUG, INFO, WARN and ERROR启动presto步骤如下：a、启动hive metastore：hive --service metastore &b、启动presto server：bin/launcher startc、启动presto client：重命名presto-cli-333-executable.jar为presto,放在bin目录下，然后赋予执行权限：chmod +x presto启动client：./presto --server XX.XX.XX.XX:5050 --catalog hive --schema default关闭presto服务bin/launcher stopPresto查询OBS创建hive表CREATE TABLE sample01(id int,name string,address string)ROW FORMAT DELIMITEDFIELDS TERMINATED BY ','STORED AS TEXTFILElocation obs://obs-east-bkt001/sample01';insert into sample01 values(1,'xiaoming','cd');insert into sample01 values(2,'daming','sh');presto查询hive表./presto --server XX.XX.XX.XX:5050 --catalog hive --schema defaultselect * from sample01;

最近，随着健康码的流行，大数据又重回大众的视野。作为新基建产业的原油，数据逐步迈向信息产业的核心。不过随着数据量级的不断扩大，从数据仓库到数据湖再到仓湖一体，如何将各种大数据技术栈整合在一起，发挥出大数据技术的最大价值成为业界都在关注的问题。越来越大的数据，想说爱你不容易权威的咨询机构IDC对于大数据的定义是现有技术难以处理的数据。从历史来看，在谷歌提出大数据三驾马车的论文时，当时的关系型数据库技术的确难以处理大规模的数据。传统SQL在谷歌海量的查询记录面前，根本跑不出结果。当前，科技企业要处理的数据量还在迅速增长，以笔者所在的银行为例，创新性的产品令银行要存储越来越多的数据，以开放银行和数字货币最为典型。比如开放银行产品推出之前，无论是柜台、ATM、网上银行还是手机银行，银行的交易都是由自身完全可控的设备或APP发起的，而开放银行产品无处不在、无时不在，要求银行必须要记录客户的行为数据，这也就使银行要处理更多更庞大的数据。同样的情况也出现在数字货币上，我国的央行数字货币(DCEP)一个最重要的属性就是离线钱包，这也就意味着DCEP必然要记录之前不会体现在银行账面上的现金交易信息，这也会将金融交易的数据量级再上台阶。在诸多行业业务上云如火如荼的大背景下，从工业互联网及IoT的角度看，数据的量级不断创新高，从我了解到的情况，各大厂的数据量级正在以年化80%左右的速度增长，因此可以说大数据技依旧术方兴未艾，未来还有广阔的发展空间。从数据库到数仓，再到数据湖在梳理数据存储模型演进的历史后，明显可以发现，这是一个随着数据量级不断扩大，数据模型不断将传统特性退化掉的过程，在这个演化当中存储的效率不断提升。从最早关系型数据库的视角看，数据库是工厂的车间，数据是原材料。车间为了进行原材料加工，有大量的操作设备，原材料随时会被重塑修改，不适合进行大量材料的储存场所。关系型数据库在大量数据存储方面的短板直接催生了Hadoop等大数据技术的革命，从大数据的视角看，大数据自身就是储存仓库，而数据已经是加工完成的成品，没有被重塑修改回滚的需求。比如HDFS的实现中所有数据只能写入一次，无法修改，这其实是退化掉数据的特性，以换取海量数据的储存与查询性能。而随着大数据应用的进一步拓展，业界发现价值密度更低的非结构化数据也有储存及挖掘的必要。比如客服的对话可能是语音、文字甚至是图像、视频，这都不是传统意义上数据库、数仓可以处理的结构化数据，因此用于储存非结构化的数据湖出现了，在数据湖中数据标准化、结构化的特性也退化了。三座大山，大数据所不能承受之重第一座大山是处理时效：在了解数据存储模型的演进过程后，我们可以看出关系型数据库、数据仓库与数据湖的底层构建模型并不相同，彼此兼容性不佳。这首先就会催生出数据处理的时效性问题，对于处理时效的要求可能是大数据工程师与产品经理之间永远无法达到的协议。以笔者所在的银行为例，分析数据在交易核心数据库中跑批处理，再ODS抽取ETL分析到数仓，再进一步训练流式计算，最后再入湖，其时效最快也是T+1日，而且Hadoop和数据湖的开源生态中很多组件并不兼容，日常运维已捉襟见肘，想提速也无从下手，但业务对了转瞬即逝的营销机会又如此渴求，T+1分钟可能都会嫌慢。如果还回答不出更细节、隐含的问题，比如非线性问题，还要把数据复制到SAS中做机器学习，再做统计的指标体系，去做进一步挖掘。数据要在这里搬动三次，复制三份冗余，还要管理数据一致性，每天数据中心运维的大量工作在做数据搬家。第二座大山是数据治理: 现在，数据中心也开始要做一个融合性的计算框架。比如，现在AI要做online训练，淘宝推荐引擎，滴滴打车的路径动态规划都在做即时数据，这都需要很高的数据治理水平进行支撑。数据治理作为摆在大数据工程师面前的一大痛点，去年初微盟发生了举世瞩目的删库事件，可以看到从2月23日删库中断事件，到3月1日的数据全面找回，再到3月3日的数据恢复整个事件持续了一周多的时间。对微盟这样体量的电商来说，损失无疑是巨大的，股市市值的蒸发是一方面，更重要的是科技公司从本质上是经营数据的公司，而数据丢失事件与银行金库被盗事件从某种程度来说是同样性质的事件，都会对当事公司的声誉造成极大的影响。造成这个问题的本质还是由于数据治理水平，只有将数据按照重要性把数据分类，并分别制订治理策略，才能在真正有用的数据丢失时找到最切实可行的应对办法，眉毛胡子一把抓难以真正降本提效。按照笔者的观察，目前从治理角度，可以将数据分为以下三种类型：应用数据：也就是交易类应用所产生的数据。为了满足业务需要构建业务IT系统，随着IT业务系统的不断运行，大量应用数据就产生了，这些数据经过ETL加工进入数据仓库，进行再处理，供业务应用。这些数据都是单一的关系型数据，数据量级是GB的。用户行为数据：随着互联网和电商的快速发展，大量人的操作行为和使用行为产生的数据，像谷歌、脸书等大数据互联公司，都记录人的形成产生的数据。上网行为、浏览行为、购买行为、评论行为、刷微博，做抖音等都可以产生大量数据。这些数据不再是单一的结构化数据，出现了大量文档、音频和视频数据，数据量级是TB级的。硬件日志数据：进入万物互联的时代，大量机器传感器，IoT设备都会产生大量数据。这些设备 7*24小时产生数据，数据格式也是多种多样，有的是日志数据，有的是时序数据，有的是网格数据等等，数据量级是PB的。从数据治理角度上讲，上述数据的备份需求是不同的，如果混到一起，那快速恢复业务根本无从谈起。而从数据使用的角度上讲，随着海量的行为及日志类数据的出现，数据的价值必然要从数据治理的角度去要价值。针对行为及日志等重要性等级不高的数据，一般采用异地磁带备份的方式，使用温备乃至冷备的试进行，不过从目前情况看不少企业尤其是创业型企业，都没有百年老店的观念，在初创时期对于这方面考虑和规划还不够，规划没做好，将来必然会对企业发展有负面影响。这又就引出第三座大山 - 灾备规划：但也经常被公司管理人员所忽略，大多数初创公司不会提前规划灾备体系，公司上规模之后再进行灾备建设又是mission impossible。一般来说两地三中心中的生产与同城中心是双活的可以快速接管业务，异地中心数据延迟同步，以应对一些删库删表类的误操作。正如刚刚所说Hadoop与数据湖两套体系中的开源组件兼容性很差，能让两者协同工作已属不易，再补充建设灾备节点难上加难。一般来说目前比较流行的灾备体系是两地三中心的架构，也就是至少在两个地域建设三个数据中心，其中:主中心：正常情况下全面提供业务服务同城中心：一般与主中心处在同一省份，主中心使用同步复制的方式来向同城灾备中心传输数据，保证同城中心数据复本为最新，随时可以接管业务，以保证RTO的指标。但是同城中心无法应对此类删库事件。异地中心：一般使用延时异步复制（延时时间一般为30分钟左右）的方式向异地灾备中心传输数据，其中同步复制的好处是一旦主中心被人工破坏，那么不会立刻涉及异地中心。以保证RPO的指标。总结灾备体系的最佳实践就是两地三中心；同城保证业务连续性，优先负责用户体验;异地保证数据连续性，确保企业生存底线。上云后的灾备规划也一定要纳入设计范围，一旦没有提前的规划，后续的补齐填坑的工作非常麻烦。云原生打开大数据未来的正确方式从上面三座大山可以看出，大数据最终用户的最佳选择就是在云平台上找到大数据的一栈式解决方案，屏蔽底层组件的差别，才能提高效率，低成本运维，因此可以说与云计算无缝对接的云原生技术肯定会是未来的方向。而华为云云原生大数据以其容器化集成及全栈大数据云平台的两大特性，很好解决了大数据技术在实际落地中的特点，我们用“大数据的操作系统”来定义华为云的云原生大数据会更加直观贴切：容器化集成：基于Mesos的资源管理，支持Marathon和Kubernetes的容器编排框架，采用云原生架构的数据平台。底层是对容器化的支持，以及对Hadoop、Spark、Kafka、Tensorflow、Hive等这些大数据开源组件的容器化发布，这就是打地基。华为云通过开源的Docker、K8S、Mesos等技术，对主流的Hadoop、Hive、Spark、Kafka等多种大数据技术组件进行了容器化集成，实现大数据应用与底层运行环境之间的解耦，推出了应用云平台（PaaS）与容器大数据平台。也就是说华为云的用户不用再过度关心底层开源组件的运维了，可以更加专注于自身的业务。全栈大数据云：在大数据开源组件容器化的基础上，华为云还把数据开发平台统一集成，推出了数据湖治理中心DGC（Data Lake Govenance Center，链接：https://www.huaweicloud.com/product/dayu.html），包括数据采集、数据规范、数据开发、数据服务、数据治理、数据可视化等多项工具。数据集成开发平台与应用云平台（PaaS）与容器大数据平台打包交付。 并已经服务了能源、教育、医疗健康、物联网、金融等领域的数十家客户，据笔者掌握的信息，华为云的客户复购率近100%。更进一步，华为云最近还推出了一套帮助政企构建数据体系的数据使能DAYU服务（链接：https://www.huaweicloud.com/solution/dataenabling.html），结合华为数字化转型实践和30多年在ICT基础设施领域积累的技术，携手行业合作伙伴，为客户提供一站式数据全生命周期管理解决方案，打造“全域、服务化、资产化、智能、安全”的数据体系，释放数据价值。展望未来，云原生大数据技术还可以充分利用AI技术降本增效：利用人工智能将冷热数据分层分离，让计算和存储资源充分利用，有效降低数据管理成本。通过分析系统运行状态和日志数据信息，利用人工智能建模，来实现动态系统参数调整和系统优化，显著降低系统数据管理者的运维成本。利用机器学习技术帮助系统建立更加准确高效的在线预警与实时监测系统，来实现智能化的运维管控和资源调配，帮助系统管理人员将更多的时间和精力集中在更重要的系统任务上。

华为开发者大会2021（Cloud）即将到来，华为云数据使能团队为你准备了大数据训练营，欢迎提前报名咨询~训练营内容：1、清华大学老师介绍大数据教学最新变革方向2、华为云DAYU 专家介绍数据治理方法论、价值和实践案例 3、实际演练：基于华为云DAYU平台演示数据治理过程参加训练营你将获得：1、训练营期间免费使用华为云部分资源2、初步掌握数据治理的概念和实操流程3、免费抽奖机会

如何能进行千万大数据量的数据库设计和优化呢？

    20世纪之时，计算机对于我们来说是陌生的，就好比鱼儿生活在水里，当它见到外面的世界的时候，对这充满色彩的世界既好奇，又陌生，殊不知这好奇的事物改变了自己对于世界的认识。    历史告诉我们，**改变了昔日的落后，闭关锁国注定贫穷落后，教育、医疗、科学技术、能源环境等永远都是一个国家向前发展的基础，不断探索、努力学习、不断创新是21世纪的发展精神，因为如今的世界正在高速发展，以计算机信息技术为基础的人工智能正在改变着我们，如果我们不思进取，终会被这信息时代所淘汰，这个社会上的强者不属于有多少金钱的人，而是属于有多少智慧、知识、文化的人！        如今我们都懂得网上购物，我们通过淘宝、京东或拼多多等平台购物，可以让我们对物品有所选择，而且可以通过快递方便的获取；当我们付款时，我们可以通过移动支付，支付宝、微信等平台给我们带来便利；当我们外出时可以通过互联网购票、百度地图导航；通过网络社交平台发表工作、生活等视屏，网上看病预约挂号，互联网教育平台学习等等，我们无时无刻的不与互联网为伴！互联网通过对人们出行、社交、购物、教育、工作等方面的大数据分析和后台云计算，不断储存和更新信息，为我们提供更好的服务，物联网是人工智能服务，我们可以通过远程控制系统进行办公、学习等，这一切的成果离不开学习，离不开科学技术与创新！    人人都希望生活在日新月异的时代中，希望人工智能取代那重复性、劳累的工作，给更多的家庭学习当代信息技术的机会，“光阴似箭，日月如梭”，我们不可能在年老之时也卖苦力，因此我们需要学习更多的科学文化知识，这个世界上不缺劳动力，随着时代的发展也终将不会缺有文化的人，但是这个世界上永远缺有责任与担当、有思想与智慧、有理想与追求的胸怀天下者！历史告诉我们，**改变了昔日的落后，闭关锁国注定贫穷落后，教育、医疗、科学技术、能源环境等永远都是一个国家向前发展的基础，不断探索、努力学习、不断创新是21世纪的发展精神，因为如今的世界正在高速发展，以计算机信息技术为基础的人工智能正在改变着我们，如果我们不思进取，终会被这信息时代所淘汰，这个社会上的强者不属于有多少金钱的人，而是属于有多少智慧、知识、文化的人！

据预测未来4年数据量将激增5-8倍，达180ZB，到35年呈50倍增长。同时，数据作为继土地、资本、技术、劳动力的第5种生产要素，已是数字经济发展的重要要素。但相关调查结果显示，企业运营中仅56%的数据被存储，仅32%的数据被利用。因此，在政企数字化转型的关键阶段，如何利用数据湖、数据仓库、数据库等技术，加速数据资产化，发挥数据新价值，成为当前数据领域的重要话题。4月8日，华为云TechWave全球技术峰会在深圳成功举办，峰会以“创新·普惠”为主题，汇聚业界精英、技术大咖、先锋企业、合作伙伴等，共话前沿技术，分享行业优秀应用实践，探讨企业智能升级的成长之道。其中，数据使能分论坛围绕“数据使能，驱动业务增长”为主题，首先解读华为云数据使能服务DAYU，同时招商银行、深圳地铁将分享数字化转型创新实践，合作伙伴永洪BI畅谈联合解决方案，最后由华为云FusionInsight MRS云原生数据湖、GaussDB数据库、GaussDB(DWS)数据仓库等技术专家共同探讨政企用数之道。（数据使能分论坛现场照片）华为云数据使能DAYU重磅开场：加速数据资产化，开发数据新价值（华为云数据使能服务总经理马麟瑜演讲）华为云数据使能服务总经理马麟瑜表示，“数据管理的领导者正在通过挖掘数据价值来驱动数字化转型，创造发展机会，改善客户体验和重塑行业格局。华为云数据使能DAYU致力于打通企业数据从资源到资产的通路，助力政企客户跨越孤立系统、感知业务的数据资源智能管理解决方案，实现全域数据入湖，帮助政企客户从多角度、多层次、多粒度挖掘数据价值，实现数据驱动的数字化转型。”华为云数据使能服务DAYU包含三层能力：数据技术平台-智能数据湖 FusionInsight：为政企客户提供覆盖海量数据全生命周期的管理方案。包含MRS云原生数据湖、GaussDB数据库、GaussDB(DWS)数据仓库、数据湖治理中心DGC等服务。使能套件 DAYU Ekit：包含使能在线化工作台，资产化效率提升10X； 行业使能知识库，协同伙伴沉淀行业资产模型，同时将AI驱动方法论与行业知识结合，实现数据资产化智能流水线工作。资产中心 DAYU Hub：通过为客户提供丰富的数据模型、数据资产管理方法，帮助企业实现资产可信管理，资产模型智能分析 ，多方安全可信计算，保障全局数据的安全流通。招商银行、深圳地铁分享大数据创新实践数据使能分论坛中，招商银行、深圳地铁分别分享了基于华为云数据域的行业创新实践。（招商银行数据仓库架构师曾民演讲）招商银行数据仓库架构师曾民表示：招商银行通过使用华为云强化了数据平台的建设，“人人用数”战略让招行没有难用的数据，打造金融数仓，秉承“源于业务，高于业务，先于业务”的理念，以解决实际业务问题为出发点，沉淀可复用易扩展的数据使能能力，成为数据“能用，好用，爱用”的践行者与布道者。早在2019年下半年，招商银行就开始了新一代MPP数据仓库平台的选型，旨在通过对数据平台的数据处理能力、性能、高可用性、扩展性、易用性、通用性等特性进行多方位的考察。通过多维度的测试，最终选定华为云GaussDB(DWS)作为新一代云上数据仓库平台，进一步提升了金融数仓的算力、备份、存储等性能，加速落实招行“人人用数，人人都是数据分析师”的数据发展战略！同时招商银行已和华为云FusionInsight MRS展开了一系列金融数据湖联合创新，旨在使用HetuEngine提高用数效率，简化用数方式。（深圳地铁运营集团线网管控中心副总经理张洪庆演讲）深圳地铁运营集团线网管控中心副总经理张洪庆在“云数赋能，实现智慧深铁“议题中表示：“在智慧城轨快速发展的大背景下，深圳地铁以科技赋能运营为目标，积极探索智慧运维新模式。在智慧城轨探索上，试点先行，顶层规划和企业标准同步推进，采用了华为城轨云解决方案，利用云计算、大数据、5G、人工智能等技术核心，建立了统一、开放、智能的城轨数字平台。在城轨云平台基础上，利用华为云 FusionInsight MRS云原生数据湖能力构建深圳地铁大数据分析平台，在智慧车站、智慧运维方面，对新技术与地铁场景进行创新融合，推进了车站业务全日自动运行、线上线下一体化客服、设备主动检测、健康管理等应用，探索数字化、高效化的新业务模式，科技赋能运营更高质量运行，企业更低成本运作，为城市提供更优质的公共交通服务。”（永洪BI技术专家黄华晃演讲）合作伙伴永洪BI分享基于华为云实现敏捷BI的联合解决方案永洪BI技术专家黄华晃分享了“永洪BI自助用数，敏捷提效20倍“议题，并表示基于华为云FusionInsight MRS云原生数据湖，永洪BI实现快速搭建应用，打造了更敏捷、更快速、更强大的“永洪BI”，具备自服务、高性能、极致易用等特点，已广泛用于金融、政务、能源等行业，让人人都成为数据分析师！至今，华为云FusionInsight联合800+ISV，已为千行百业的客户提供“一企一湖、一城一湖“的数字化转型方案。数字化转型之路离不开客户对于华为云FusionInsight智能数据湖的信赖，也离不开伙伴的精诚合作。同时，华为云也坚持技术创新，在MRS云原生数据湖、GaussDB数据库、GaussDB(DWS)数据仓库等产品上不断潜心钻研，勇攀技术高峰！华为云FusionInsight、GaussDB技术专家共谈数字化转型创新技术华为云FusionInsight解决方案首席架构师徐礼锋在会议中分享了“华为云FusionInsight MRS云原生数据湖一架构三湖，持续演进“的议题，深度解读了一个架构实现三种湖的能力和新技术。（华为云FusionInsight解决方案首席架构师徐礼锋演讲）逻辑数据湖：HetuEngine提供跨湖、跨仓、跨云统一访问，减少数据搬迁，数据高效流动，全域数据秒级协同分析秒级响应，业务上线效率提升10倍，由周级缩短至天级。实时数据湖：流处理 + Hudi实现数据更新入湖，从T+1到T+0； ClickHouse提供毫秒级实时OLAP分析能力；Flink提供FlinkSQL能力，批流SQL接口统一，实现流批一体。离线数据湖：HetuEngine提供秒级交互式查询能力，数据不出湖，分析链路短，性能比Impala快30%+，分析提效10倍+；DLC提供统一的元数据，数据全局可视； HetuEngine提供湖内统一SQL接口：HDFS、Hive、HBase、ES等，简化用数。华为云FusionInsight MRS践行产学研合作，全面推进大数据开源技术发展，联合清华大学发布了IoTDB时序引擎版本。目前华为云FusionInsight MRS已应用于60多个国家3000+客户，助力政企客户实现一企一湖、一城一湖，业务洞见更准，价值兑现更快！华为云GaussDB技术专家胡彦军分享了“华为云云原生分布式数据库GaussDB，多模架构，多元生态“的议题，为我们解读了华为倾力打造的云原生数据库GaussDB系列产品的技术创新与行业普惠。（华为云GaussDB技术专家胡彦军演讲）华为云GaussDB(for openGauss)基于云化的部署模式，分布式形态，生态开放，更好满足了企业的数据库诉求。经过13年的积累，从内部锤炼，再到外部行业实践，华为云GaussDB(for openGauss)淬炼出6大核心能力：（1）超高可用：支持跨机房、同城、异地、多活高可用，支持分布式强一致，数据0丢失。（2）开放生态：openGauss开放生态，确保客户避免被类似传统商业数据库的封闭生态锁定。（3）极致扩展：通过分布式全局事务一致性优化，实现计算与存储的垂直扩展能力，同时支持新增分片的数据在线重分布能力。（4）卓越性能：分布式优化器+Numa-aware技术加持，提供极致性能。在TPC-C、TPC-H等企业级负载下性能表现卓越。以及具备丰富的企业级特性（如支持HTAP混合负载，拥有AI自治能力）和超高的安全性（具备独立的代码级的问题修复能力及架构优化能力），构建了极具竞争力的能力。华为云GaussDB(DWS)技术专家李海丰分享了“华为云GaussDB(DWS)实时数仓，提速全场景数据分析“的议题，其中实时数仓的时序引擎和CEP引擎成为亮点。（华为云GaussDB(DWS)技术专家李海丰演讲）华为云GaussDB(DWS) 是一款具备分析及混合负载能力的分布式数据仓库，支持行存储与列存储，提供PB级数据分析能力、多模分析能力和实时处理能力，用于数据仓库、数据集市、实时分析、实时决策和混合负载等场景，广泛应用于汽车、制造、零售、互联网、金融、政府、电信等行业核心分析决策系统。作为新一代全场景云原生数据仓库，它不仅仅是把数仓搬上云这么简单，而是真正面向未来的云原生架构的数仓服务。传统数仓一般是基于分布式shared nothing的MPP架构实现的，而GaussDB(DWS)在MPP架构的基础上，与高性能的云存储相结合，打造了多温存储的存算分离架构，支持资源的弹性伸缩。同时，逻辑集群和多租户技术，将存储和计算资源进行了更细粒度的隔离，用户可以对不同的业务划分不同的逻辑集群或租户，实现更加灵活的弹性。受益于云服务的多样性，GaussDB(DWS)支持多源、多模的融合分析，既可以在库内支持时序、流、全文检索、GIS等内置多引擎的数据分析，又可以基于OBS实现跨引擎的协同计算，例如与FusionInsight MRS云原生数据湖、GES图引擎、ModelArts AI平台等实现数据免搬迁。至此，华为云TechWave全球技术峰会数据使能分论坛圆满结束。围绕“数据使能，驱动业务增长”主题，为现场观众讲述了金融、交通等行业的数字化转型创新实践，联合合作伙伴畅谈数据湖BI联合解决方案，云集华为云DAYU数据使能、FusionInsight MRS云原生数据湖、GaussDB数据库、GaussDB(DWS)数据仓库等技术专家共聚一堂“鹏城论数”，探讨政企用数之道，分享了政企客户数字化前沿技术。下一场，上海，与您不见不散！调查问卷更多内容，华为云FusionInsight系列文章：https://bbs.huaweicloud.com/forum/thread-66105-1-1.html 

【大数据全栈成长计划】Spark学习篇课程内容都已经全部更新完毕。大家积极的学习态度，遇到问题及时在学习群内提出，让本阶段全栈课程可以顺利完成再次感谢大家：◎积极完成每章的随堂测验打卡，做到了课后的知识强化与巩固；◎认真完成每周读书笔记打卡，将自己的学习心得总结下来；◎有活力地问答官打卡，分享自己在学习中的问题和经验。十分感谢大家能顺利完成这一阶段的学习内容现在，大家迎来了第三阶段考核，我们为大家准备了两种考核方式，让我们来看一下：▶方式一：微认证考核  提供订单截图 阶段考核+15分、提交微认证证书截图 阶段考核在订单的基础上再+15分通过特定场景化学习和实际操作，可以获得华为云微认证提供的具有【华为云官方微认证证书】以下三种场景选择一种参与认证考核，多参加选取最高分数模拟场景认证链接基于流计算的双十一大屏开发案例https://edu.huaweicloud.com/certifications/35e95745f9344e1a9b5a92a0bf201fc3球星薪酬决定性因素分析https://edu.huaweicloud.com/certifications/f20642504f504d54b7559659b759612f网站消费者行为分析https://edu.huaweicloud.com/certifications/1866d21d8c074186b72ed952344df625参与认证的同学请将【微认证订单截图&微认证证书截图+华为云ID】回复到本帖当中 才能算作最终考核成功，考核分数才能统计▶方式二： <HDC.Cloud2021>自测考试——大数据   阶段考核分数为考试成绩x10%①打开此链接：https://developer.huaweicloud.com/activity/hdc2021_developer.html②找到[进阶线路]-[大数据]，完成考试后截图成绩本次考试只有一次机会，考试成绩为第一次答题（最早一次答题时间）的分数，请认真作答。答题结束后请将【第一次答题成绩截图+华为云ID】发送至本帖视为打卡成功成绩将以系统后台的成绩为准。▶考核打卡时间：即日起 — 2021.04.21 23:59选择以上两种【Spark学习篇考核】方式进行考核，多参加分数可累计。符合证书的发放条件后均可以获得【第三阶段考核纪念证书】，证书的发放条件和发放方式将于2021.04.21后在最终成绩贴中公布。

华为商城（Vmall商城）隶属于华为技术有限公司，是华为公司旗下的自营电子商务平台，以最终用户为主要对象，提供华为手机、无线上网设备、平板电脑、配件等系列终端产品和服务；是以营造用户的移动信息生活为服务宗旨的互联网商务平台。2012年3月，华为商城内部测试版正式对外试运营，并于3月18日正式上线营业。        在华为产品的众多销售渠道中，华为商城具有以下优势：正品保证：华为商城为华为终端自有官方销售服务网站。提供全系列华为产品，保证正品、服务可靠！一站式的网站体验：华为商城一站式提供产品和服务。服务无忧：从商品、验货、库存、配货售后服务等环节全方位保证商品品质。社区互动优势：发挥已有社区的优势，增加官方与用户、用户与用户的互动。        随着华为消费者产品的销售的持续增长，作为消费者产品的最重要渠道之一，Vmall是如何支撑保障华为终端业务的快速发展呢？今天我们就为大家来解密Vmall商城成功背后的秘密。        一个成熟的电商平台，一般至少包含以下几个功能：门户Portal、交易系统、端侧APP、用户画像、推荐系统、搜索系统、报表等。究竟Vmall商城通过是什么神秘的技术力量，保障这些系统有机高效的运行，来成就Vmall商业上的成功呢？       下面我们就来为大家揭秘Vmall的大厦是如何建成的？我们仅以报表、营销、画像、推荐等几个核心系统来介绍整个系统是如何有机运行。话不多说，请看图：                整个系统的数据来源包含2部分，一部分来自于交易系统，包括产品管理系统、订单管理系统、客户管理系统、风险管理系统等等。另一部分数据来自于端测的流数据，包括用户点击率、商品搜索等行为数据。从软件架构上来看，这些数据都被流入、汇聚到一个DWS集群中，并且，整个框架的ODS层、DWI/DWD、DWS、DM层，都是构筑于同一套DWS集群中。因此，DWS才是这一系列魔法的关键。        报表系统的数据流如下： 业务系统将数据映像到TiDB中。通过CDM和ROMA服务将数据同步至DWS中。经过SDI、DWD/DWI层加工后，在DWS层进行进一步加工，生成面向各个主体的DM层数据。OAR数据系统通过调用相应DM层数据，进行报表和大屏数据呈现。        说到营销，就不得不提到画像系统。画像是推荐和营销、搜索的基石。画像系统的数据主要来自于对端侧行为数据的分析归类，其业务流程如下：端侧行为数据通过DAP模块汇聚至kafka组件。通过CSS组件（Flink）将数据实时汇聚只DWS中。在DWS中通过标签算法，对用户行为进行标签、分析和归类。将相关标签同步至ES中进行画像查询。        营销系统数据流程如下：基于画像相关的流程基础上，将ES中的画像数据同步至DMP平台。基于DMP平台进行营销获得的策划、编排、跟踪等。        推荐系统和搜索系统强相关的。因为推荐系统需要调用画像、商品等信息。Vmall商城的搜索系统基于华为云ES服务之上，使用了增强的泊松引擎，通过RPC网关，对外提供搜索RPC API接口调用，为商城Web端和移动端APP提供商品搜索和推荐服务。        在整个华为商城的架构中，DWS服务起到了极其重要核心的作用。既有效地承载了传统数仓的批处理和高并发查询任务，又完美实现了高并发实时流数据的接入和实时分析，经受住了618等重大业务极限流量高峰的考验，成为华为商城数据处理基座的中流砥柱。        那么，华为云DWS服务究竟是如何做到这些，这里面又包含了哪些不为人所熟知的独门秘技呢，请听下回分解！

前言：数据处理现状，当前基于Hive的离线数据仓库已经非常成熟，数据平台体系也基本上是围绕离线数仓进行建设。但是随着实时计算引擎的不断发展以及业务对于实时报表的产出需求不断膨胀，业界最近几年就一直聚焦并探索于两个相关的热点问题：实时数仓建设和大数据架构的批流一体建设。实时数仓建设：实时数仓1.0        传统意义上我们通常将数据处理分为离线数据处理和实时数据处理。对于实时处理场景，我们一般又可以分为两类，一类诸如监控报警类、大屏展示类场景要求秒级甚至毫秒级；另一类诸如大部分实时报表的需求通常没有非常高的时效性要求，一般分钟级别，比如10分钟甚至30分钟以内都可以接受。        对于第一类实时数据场景来说，业界通常的做法比较简单粗暴，一般也不需要非常仔细地进行数据分层，数据直接通过Flink计算或者聚合之后将结果写入MySQL/ES/HBASE/Druid/Kudu等，直接提供应用查询或者多维分析。如下所示：        而对于后者来说，通常做法会按照数仓结构进行设计，我们称后者这种应用场景为实时数仓，将作为本篇文章讨论的重点。从业界情况来看，当前主流的实时数仓架构基本都是基于Kafka+Flink的架构（为了行文方便，就称为实时数仓1.0）。下图是基于业界各大公司分享的实时数仓架构抽象的一个方案：        这套架构总体依然遵循标准的数仓分层结构，各种数据首先汇聚于ODS数据接入层。再接着经过这些来源明细数据的数据清洗、过滤等操作，完成多来源同类明细数据的融合，形成面向业务主题的DWD数据明细层。在此基础上进行轻度的汇总操作，形成一定程度上方便查询的DWS轻度汇总层（注：这里没有画出DIM维度层，一般选型为Redis/HBase，下文架构图中同样没有画出DIM维度层，在此说明）。最后再面向业务需求，在DWS层基础上进一步对数据进行组织进入ADS数据应用层，业务在数据应用层的基础上支持用户画像、用户报表等业务场景。        基于Kafka+Flink的这套架构方案很好的解决了实时数仓对于时效性的业务诉求，通常延迟可以做到秒级甚至更短。基于上图所示实时数仓架构方案，笔者整理了一个目前业界比较主流的整体数仓架构方案：        上图中上层链路是离线数仓数据流转链路，下层链路是实时数仓数据流转链路，当然实际情况可能是很多公司在实时数仓建设中并没有严格按照数仓分层结构进行分层，与上图稍有不同。        然而基于Kafka+Flink的实时数仓方案有几个非常明显的缺陷：Kafka无法支持海量数据存储。对于海量数据量的业务线来说，Kafka一般只能存储非常短时间的数据，比如最近一周，甚至最近一天；Kafka无法支持高效的OLAP查询。大多数业务都希望能在DWD\DWS层支持即席查询的，但是Kafka无法非常友好地支持这样的需求；无法复用目前已经非常成熟的基于离线数仓的数据血缘、数据质量管理体系。需要重新实现一套数据血缘、数据质量管理体系；Lambad架构维护成本很高。很显然，这种架构下数据存在两份、schema不统一、 数据处理逻辑不统一，整个数仓系统维护成本很高；Kafka不支持update/upsert。目前Kafka仅支持append。实际场景中在DWS轻度汇聚层很多时候是需要更新的，DWD明细层到DWS轻度汇聚层一般会根据时间粒度以及维度进行一定的聚合，用于减少数据量，提升查询性能。假如原始数据是秒级数据，聚合窗口是1分钟，那就有可能产生某些延迟的数据经过时间窗口聚合之后需要更新之前数据的需求。这部分更新需求无法使用Kafka实现。        所以实时数仓发展到现在的架构，一定程度上解决了数据报表时效性问题，但是这样的架构依然存在不少问题，随着技术的发展，相信基于Kafka+Flink的实时数仓架构也会进一步往前发展。那会往哪里发展呢？        大数据架构的批流一体建设。        带着上面的问题我们再来接着聊一聊最近一两年和实时数仓一样很火的另一个概念：批流一体。对于批流一体的理解，笔者发现有很多种解读，比如有些业界前辈认为批和流在开发层面上都统一到相同的SQL上是批流一体，又有些前辈认为在计算引擎层面上批和流可以集成在同一个计算引擎是批流一体，比如Spark/Spark Structured Streaming就算一个在计算引擎层面实现了批流一体的计算框架，与此同时另一个计算引擎Flink，目前在流处理方面已经做了很多的工作而且在业界得到了普遍的认可，但在批处理方面还有一定的路要走。实时数仓2.0        笔者认为无论是业务SQL使用上的统一还是计算引擎上的统一，都是批流一体的一个方面。除此之外，批流一体还有一个最核心的方面，那就是存储层面上的统一。在这个方面业界也有一些走在前面的技术，比如最近一段时间开始流行起来的数据湖三剑客-- delta/hudi/iceberg，就在往这个方向走。存储一旦能够做到统一，上述数据仓库架构就会变成如下模样（以Iceberg数据湖作为统一存储为例），称为实时数仓2.0：         这套架构中无论是流处理还是批处理，数据存储都统一到数据湖Iceberg上。那这么一套架构将存储统一后有什么好处呢？很明显，可以解决Kafka+Flink架构实时数仓存在的前面4个问题：可以解决Kafka存储数据量少的问题。目前所有数据湖基本思路都是基于HDFS之上实现的一个文件管理系统，所以数据体量可以很大。DW层数据依然可以支持OLAP查询。同样数据湖基于HDFS之上实现，只需要当前的OLAP查询引擎做一些适配就可以进行OLAP查询。批流存储都基于Iceberg/HDFS存储之后，就完全可以复用一套相同的数据血缘、数据质量管理体系。Kappa架构相比Lambad架构来说，schema统一，数据处理逻辑统一，用户不再需要维护两份数据。        有的同学说了，这不，你直接解决了前4个问题嘛，还有第5个问题呢？对，第5个问题下文会讲到。        又有的同学会说了，上述架构确实解决了Lambad架构的诸多问题，但是这套架构看起来就像是一条离线处理链路，它是怎么做到报表实时产出呢？确实，上述架构图主要将离线处理链路上的HDFS换成了数据湖Iceberg，就号称可以实现实时数仓，听起来容易让人迷糊。这里的关键就是数据湖Iceberg，它到底有什么魔力？        为了回答这个问题，笔者就上述架构以及数据湖技术本身做一个简单的介绍（接下来也会基于Iceberg出一个专题深入介绍数据湖技术）。上述架构图中有两条数据处理链路，一条是基于Flink的实时数据链路，一条是基于Spark的离线数据链路。通常数据都是直接走实时链路处理，而离线链路则更多的应用于数据修正等非常规场景。这样的架构要成为一个可以落地的实时数仓方案，数据湖Iceberg是需要满足如下几个要求的：支持流式写入-增量拉取。流式写入其实现在基于Flink就可以实现，无非是将checkpoint间隔设置的短一点，比如1分钟，就意味每分钟生成的文件就可以写入到HDFS，这就是流式写入。没错，但是这里有两个问题，第一个问题是小文件很多，但这不是最关键的，第二个问题才是最致命的，就是上游每分钟提交了很多文件到HDFS上，下游消费的Flink是不知道哪些文件是最新提交的，因此下游Flink就不知道应该去消费处理哪些文件。这个问题才是离线数仓做不到实时的最关键原因之一，离线数仓的玩法是说上游将数据全部导入完成了，告诉下游说这波数据全部导完了，你可以消费处理了，这样的话就做不到实时处理。        数据湖就解决了这个问题。实时数据链路处理的时候上游Flink写入的文件进来之后，下游就可以将数据文件一致性地读走。这里强调一致性地读，就是不能多读一个文件也不能少读一个文件。上游这段时间写了多少文件，下游就要读走多少文件。我们称这样的读取叫增量拉取。解决小文件多的问题。数据湖实现了相关合并小文件的接口，Spark/Flink上层引擎可以周期性地调用接口进行小文件合并。支持批量以及流式的Upsert(Delete)功能。批量Upsert/Delete功能主要用于离线数据修正。流式upsert场景上文介绍了，主要是流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的，而离线数仓做更新的话需要全量数据覆盖，这也是离线数仓做不到实时的关键原因之一，数据湖是需要解决掉这个问题的。支持比较完整的OLAP生态。比如支持Hive/Spark/Presto/Impala等OLAP查询引擎，提供高效的多维聚合查询性能。        这里需要备注一点，目前Iceberg部分功能还在开发中。具体技术层面Iceberg是怎么解决上述问题的，请持续关注本号，接下来一篇文章会详细讲解哦。实时数仓3.0        按照批流一体上面的探讨，如果计算引擎做到了批流一体的统一，就可以做到SQL统一、计算统一以及存储统一，这时就迈入实时数仓3.0时代。对于以Spark为核心技术栈的公司来说，实时数仓2.0的到来就意味着3.0的到来，因为在计算引擎层面Spark早已做到批流一体。基于Spark/数据湖的3.0架构如下图：        假如未来Flink在批处理领域成熟到一定程度，基于Flink/数据湖的3.0架构如下图：        上面所介绍的，是笔者认为接下来几年数据仓库发展的一个可能路径。对于业界目前实时数仓的一个发展预估，个人觉得目前业界大多公司都还往实时数仓1.0这个架构上靠；而在接下来1到2年时间随着数据湖技术的成熟，实时数仓2.0架构会成为越来越多公司的选择，其实到了2.0时代之后，业务同学最关心的报表实时性诉求和大数据平台同学最关心的数据存储一份诉求都可以解决；随着计算引擎的成熟，实时数仓3.0可能和实时数仓2.0一起或者略微滞后一些普及。        目前，华为云FusionInsight MRS云原生数据湖，助力客户一个架构可持续演进，构建离线、实时、逻辑三种数据湖。通过LakeHouse范式，缩短数据分析链路和数据冗余，数据分析不出湖，在离线数据湖内实现常见批处理、流处理和全文检索等；通过Hudi实现数据实时增量Upsert入湖，通过ClickHouse使PB级数据实时OLAP毫秒级分析，实现全链路实时数据湖。通过HetuEngine，实现数据虚拟化，提供统一SQL接口访问，可跨湖跨仓跨云协同计算，将传统天级的人工摆渡数据，转变为跨湖跨仓跨云协同计算分钟级，实现逻辑数据湖。基于云原生能力，采用OBS实现大数据存算分离，提供企业级EC，将传统3副本降至1.2，TCO降低60%；采用BMS裸金属更好支持大数据高密集型计算场景，独家SDI技术彻底打通大数据所需的“CPU、内存、磁盘、网络”等资源的最后一环，释放100%数据基础设施算力。转载自过往记忆大数据，作者：大数据平台  https://mp.weixin.qq.com/s/cK6VA7Mnn6F6zdpdiBODPg免责声明：转载文章版权归原作者所有。如涉及作品内容、版权等问题，请及时联系文章编辑！

【摘要】 TPCDS是模拟OLAP应用的典型场景，因其贴近真实场景，且有工具直接生成数据，而成为SQL引擎测试组最常用的测试模型。，本文将从几个角度分别进行分析：模型、场景、语句、数据.1 前言   TPCDS是模拟OLAP应用的典型场景，因其贴近真实场景，且有工具直接生成数据，而成为SQL引擎测试组最常用的测试模型。然而实际手工用例编写过程中，并没有使用TPCDS完整模型，而只是选择部分表作为测试表，同时测试用例编写中主要考虑语法、及与相关特性结合，而没有结合实际应用场景。为了提高手工用例的质量，更贴近用户使用，同时结合TPCDS场景，构建集成测试和系统测试的测试用例、测试场景，深入分析TPCDS是非常有必要的，本文将从几个角度分别进行分析：模型、场景、语句、数据。2 TPCDS模型   2.1 TPCDS场景概述   TPCDS场景中，包含了一个成熟的决策支持系统所具有的两项最重要的因素：1.         用户查询语句，将数据操作转化为商业智能。TPCDS的语句可以分为以下四类决策支持语句：l  报告型，这类语句通常是预定义的，会周期性地运行，来判断企业的财务和运行状况，比如月度、季度、年度财务报表。通常为静态的，改变的只是时间段、地理位置或商品名称。l  即席查询（Ad hoc），这类语句主要用于即时、特定的商业问题。它与报告型语句的主要差别在于预知程度（报告型都是计划中的，而Ad hoc通常是临时性的）。l  迭代OLAP，这类语句主要通过对数据进行研究分析来判断事物之间的联系和发展趋势。与Ad hoc语句相似，区别为该类语句基于一个具体的用户场景，且会提交一系列的复杂或简单语句。比如，通过某类客户过去几年的购买力分析，预测将来的购买力趋势。l  数据挖掘，这类语句是对大量数据进行分析，挖掘潜在的、无法直观得出的结论，从而支持商业决策。比如购物网站的购买推荐。说明：报告型语句通常可预先优化，因此执行时间短，而即席查询正常相反。TPCDS中，catalog 渠道相关语句模拟报告型语句，而store和web渠道相关语句模拟即席查询部分。2.         数据维护，对于决策分析所依赖的源数据需要同步管理。在实际生产环境中，数据维护的过程通常包括三个步骤：数据抽取、数据转换、数据加载（ETL）。TPCDS数据维护过程为：l  加载要更新的数据集，包括insert/delete/update的数据l  加载要更新的数据集到数据仓库，进行数据转换l  插入新的事实表记录，并根据时间删除某些记录举例说明TPCDS模拟的商业活动：1.       记录各个销售渠道的所有客户购买信息与退货信息2.       根据促销信息修改价格3.       维护仓库存货信息4.       创建**页5.       维护客户信息2.2 TPCDS模型介绍   2.2.1 概念在多维分析的商业智能解决方案中，根据事实表和维度表的关系，常见的模型分为星型模型和雪花型模型。星型模型：中央表包含事实数据，多个表以中央表为中心呈放射状分布，它们通过数据库的主键和外键相互连接，是一种使用关系数据库实现多维分析空间的模式，其基本形式必须实现多维空间，以使用关系数据库的基本功能。同时星型模型也是一种非正规化的模型，多维数据集的每一个维度直接与事实表连接，没有渐变维度，所以存在冗余数据。在星型模型中，只需要扫描事实表就可以进行查询，主要的数据都在庞大的事实表中，所以查询效率较高，同时每个维度表和事实表关联，非常直观，很容易组合出各种查询。雪花型模型：雪花模型在星型模型的基础上，维度表进一步规范化为子维度表，这些子维度表没有直接与事实表连接，而是通过其他维度表连接到事实表上，看起来就像一片雪花，故称雪花模型。也就是说雪花模型是星型模型的进一步扩展，将其维度表扩展为更小的维度表，形成一种层次。这样就通过最大限度的减少数据存储量以及联合较小的维度表来改善查询性能，且去除了星型模型中的冗余数据。                                                                                 两种模型比较：星型模型雪花型模型特点1.         非正规化；2.         多维数据集中的每一个维度都与事实表连接（通过主键和外键）；3.         不存在渐变维度；4.         有冗余数据；5.         查询效率可能会比较高；6.         不用过多考虑正规化因素，设计维护较为简单1.         正规化；2.         数据冗余少；3.         有些数据需要连接才能获取，可能效率较低；4.         规范化操作较复杂，导致设计及后期维护复杂；2.2.2 TPCDS模型概述TPCDS模型模拟一个全国连锁的大型零售商的销售系统，其中含有三种销售渠道：store（实体店）、web（网店）、catalog（电话订购），每种渠道使用两张表分别模拟销售记录和退货记录，同时包含商品信息和促销信息的相关表结构。TPCDS采用雪花型数据模型，三种渠道的销售、退货表、及总体的存货清单作为事实表，其他商品相关信息、用户相关信息、时间信息等其他信息等都作为维度表，同时各表命名达到见名识义，详细如下表所示：事实表维度表Store Sales、Store ReturnsCatalog Sales、 Catalog   ReturnsWeb Sales、 Web   ReturnsInventoryStore、Call Center、Web_siteWarehouse 、Catalog_page、Web_pageCustomer、Customer_address、Customer_demographicsHousehold_demographics、Income_bandDate_dim、Time_dimItem、Promotion、Reason、Ship_mode上述维度表具体分为三类：1.         静态的：导入数据库以后，数据将永远保持不变，如date_dim、time_dim2.         历史相关的：即数据记录跟时间相关，每条记录只在对应的时间段内有效。比如：item（如一月份有商品1，二月份有商品2）3.         非历史相关的：即数据记录跟时间无关，不需要保留历史数据，比如：customer它包含几组模型关系图，详细如下：l  Store_sales 的ER图l  Store_returns 的ER图l  Catalog Sales 的ER图l  Catalog Returns 的ER图l  Web Sales 的ER图l  Web Returns的ER图l  Inventory的ER图Schema说明：1)        表、索引可以使用水平和垂直分区2)        除了基表，可以建立其他的辅助表结构（EADS），如索引、物化视图（只允许事实表与维度表间的主外键关系连接）。3)        可以使用主外键、NOT NULL约束2.3 TPCDS数据   TPCDS中，以SF定义数据量，如下图：具体对应的行数如下图：2.4 TPCDS语句   TPCDS所有99个Query，覆盖SQL99和2003的核心部分以及OLAP。下面我们从语法和语义两个角度进行分析。1.       语法l  语句特点，总结如下：SQL特征查询数量Correlated   subquery10Non-correlated   subquery34Group by81Order by89Rollup11Exists5Union18Intersect3Case29Substr9Having7Over15CTE28l  过滤条件主要用在维度表上，具体集中在如下几张表：date_dim（d_year/d_date/ d_qoy/d_dom）、item(i_category/i_current_price/i_manufact_id/i_class)、customer_address(ca_state/ca_zip/ca_gmt_offset/ca_city/ca_county)、customer_demographics(cd_gender/cd_marital_status/cd_education_status)、houshold_demographics(hd_vehicle_count/hd_buy_potential/hd_dep_count)、store(s_state)；l  连接条件为表间的PK-FK关系上l  聚集运算主要集中在事实表上，例如：价格、数量等。2.       语义TPCDS中每个语句都回答一个商业问题，重点在于各种统计，可以分为从客户、商品两个维度进行，统计通常只针对某个具体的时间、具体的类别，进行环比、同比等各种分析，各语句语义参见附录。语句可以进行修改，但不能改变语义。2.5 TPCDS测试流程   TPC-DS 测试流程包括:1)        数据加载测试l  数据加载分为两种方式：a)使用生成完的数据进行导入；b)使用dsdgen边生成边导入。l  数据加载时间包括：测试基础表创建、数据加载、约束验证、辅助数据结构( 如索引) 创建、表和辅助数据统计分析等。l  Power测试之前，不应重启系统2)        查询顺序执行( Power)测试l  评测数据库对单个查询流的处理能力。3)        第一次查询并行执行测试l  用于测试DBMS对多个查询流并发查询和操作的处理能力，最小值为4（记为Sq）。例如，模拟20个用户同时进行操作，则同时启动20个session。l  每个session会是一个不同的语句执行顺序（由dsdgen可生成，该顺序是固定的）。l  每个session一次只运行一条语句。4)        第一次数据维护测试l  更新次数为并发测试中的并发数除以2，即Sq/2。例如，模拟20个用户同时操作，则其中10个用户会有更新操作。l  单次更新中的语句可以顺序或并发执行，更新语句只涉及事实表。l  更新数据由dedgen生成，更新的顺序与dsdgen生成保持顺序一致。l  第一步中创建的EADS，会随之进行更新维护。l  数据维护过程中需要有硬件故障注入。5)        第二次查询并行执行测试6)        第二次数据维护测试2.6 TPCDS度量方法   TPC-DS 基准定义了两个评价指标:1.         反映每秒的有效查询数据量的性能指标，其计算公式为:各个参数的含义如下：l  SF，即数据量l  Q= Sq * 99，Sq 指并发测试中并发的个数l  TPT=TPower*Sq ，TPower 指Power测试的总执行时间l  TTT= TTT1+TTT2 ，TTT1指并发第一次测试的总执行时间，TTT2指并发第二次测试的总执行时间l  TDM= TDM1+TDM2，TDM1指第一次数据维护的总执行时间，TDM2指第二次数据维护的总执行时间l  TLD=0.01*Sq*TLoad ，TLoad指数据加载时间l  上述的时间单位要精确到秒2.         反映每秒每查询数据量的性价比指标，值越小说明性价比越高，其计算公式为：其中 P 是测试总花费。3 测试指导   3.1 用例   根据上文TPCDS的具体分析，用于手工用例的指导原则如下：1.       选择的表应为上文中的某个具体的ER图中的全部或部分表，根据使用频率，选取最小集示例如下： 2.       分布键主要建在PK键上，分区键主要建在常用的过滤条件上，在常用的过滤条件和PK、FK上建立单列、多列索引3.       实际编写用例时，注意如下几点：l  表之间的连接条件，主要根据上图中的PK-FK关系建立连接l  过滤条件主要放在维度表l  聚集运算主要放在事实表l  窗口函数、OLAP函数的灵活使用l  条件结合函数使用（如字符串函数、类型转换函数、数学运算函数）l  表达式的灵活使用（与条件结合、与聚集运算结合）l  灵活运用子查询、相关子查询l  多处使用同样的临时结果集时，考虑使用CTE，即CTE通常在多处被引用l  集合运算主要用在同一类操作、不同的事实表上3.2 场景   集成测试、系统测试、专项测试等都可以利用TPCDS场景，或根据TPCDS场景构建新的测试场景，构建场景注意：1.         场景测试应包括创建、加载、查询、更新等整体流程，做到一键式测试。测试结果可分析、可重现。2.         查询语句，依据2.1中四类语句进行构建，查询语句包含简单、复杂语句，结果集有大有小，同时查询语句可选择串行、并发运行。3.         更新语句，更新与查询语句交替进行测试，更新以事实表为主，更新的并发度与查询的并发度对应。原文链接：https://bbs.huaweicloud.com/blogs/198087【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【功能模块】【操作步骤&问题现象】1、本地环境测试正常2、按照FusionInsight 产品文档上IDEA打包方式打包提交到yarn集群后运行失败，提示入口类找不到【截图信息】【日志信息】（可选，上传日志内容或者附件）