数据仓库工程师的具体职责

2024-06-21

数据仓库工程师的具体职责（精选18篇）

篇1：数据仓库工程师的具体职责

Responsibility

1、负责建设数据仓库架构，包括元数据管理、ETL调度、数据集成、OLAP等子系统的设计和开发;

2、制定和推广数据字典，建立完善的元数据管理规范，负责数据质量监控设计;

3、搭建和维护数据仓库表，解决业务人员在仓库系统流程、工具使用、数据处理等遇到的问题;

4、深入了解网易游戏、CC直播、藏宝阁、网易大神等业务，负责数据仓库和其它业务系统接口。

5、基于对数据的理解和业务需求，对数据进行整理、分析和用户画像搭建。

Requirements

1、计算机相关专业本科及以上学历，有2年以上数据仓库、ETL工作经验;

2、熟悉SQL、Shell等相关技术，有海量数据处理、ETL及任务调度优化、数据仓库建模等经验;

3、熟悉Linux环境，了解Java/Python服务端系统开发;

4、熟悉Hadoop/Spark/Hive/Hbase/Kafka/Flume等大数据技术者优先;

5、逻辑清晰、对数据敏感，良好的沟通能力和协作能力，敢于接受挑战，能够承受压力;

篇2：数据仓库工程师的具体职责

1、负责数据仓库(HADOOP)ETL工作以及数据运营;

2、负责数据产品的业务需求梳理、数据开发以及维护;

3、负责数据仓库的维度建模以及设计相关的脚本调度;

4、负责维度模型的数据处理的脚本开发，程序开发以及接口对接。

职位要求：

1. 本科以上学历，信息管理、计算机相关专业，两年以上ETL、数据仓库和大数据相关经验;

2. 熟悉数据仓库架构，了解HADOOP等大数据平台;

3. 有ORACLEDB2等大型的数据仓库的开发经验;

4. 能够用HIVE的SQL，HADOOP的MAPREDUCE和SPARK去处理数据;

5. 熟悉关系数据库，并有HIVE的SQL的开发经验;

6. 熟悉Linux的shell编程;

7. 有银行和运营商相关的大数据或者数据仓库相关经验的优先

8. 热爱技术工作，具有较强的团队协作意识，数据安全意识;

篇3：数据仓库工程师的具体职责

1 数据仓库技术分析

数据仓库的创始人是William H.Inmon, 他在1991年出版的《Building the Data Warehouse》中提到的数据仓库的定义被广泛的接受, 他说:数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合, 用于支持管理决策。

数据仓库并不是大家眼里的“大型数据库”, 数据仓库的主要特点有: (1) 效率较高:数据仓库的分析周期一般为日、周、月、季、年。目前, 效益还可以的企业一般数据量都较大, 而传统的数据仓库对数据分析的效率并不够高, 而数据仓库则可以使客户轻松的看到昨天的数据分析, 可见其效率之高。 (2) 数据质量较高:由于数据仓库包括的内容较多, 且还要经过数据清洗、装载、查询等步骤, 架构复杂并且层次较多, 所以很可能导致数据失真, 也就是我们说的数据质量不好, 那么客户看到错误的数据分析后, 就可能就会做出错误的决策, 导致企业的效益和信誉下降。 (3) 扩展空间较大:大型数据仓库系统的复杂层次为自身提供了3~5年的扩展空间, 也就是说, 在短期内不需要花费金钱、人力和时间来重建数据仓库系统。

目前, 每一家企业和公司都有自己的数据, 它们有的存在于计算机系统中, 有的存在在别处。而如果使用数据仓库后, 这些数据都会被存到一个地方——数据仓库。它们将按照一定的规律储存, 当需要调出这些数据时, 也能够更加的方便和快捷。下面, 我们主要来分析在钻井工程决策中, 数据仓库的具体应用及其重要作用。

2 钻井工程中, 传统数据库与数据仓库的比较分析

目前, 绝大部分的钻井工程都是由钻井设计、钻前工程、钻井作业、固井作业和完成作业这几个部分组成的, 但是由于钻井工程涉及到的信息种类繁多, 且数据量较大, 因此, 及时得到准确的、科学的决策依据对工作人员来说是非常重要的。在传统的管理系统中, 信息的收集和处理并没有科学的机制, 往往满足不了工作人员对信息和数据的要求, 更别提能帮助管理人员对工程快速的做出决策。因此, 我认为, 数据仓库在钻井工程决策中是至关重要的存在。

数据仓库与数据库是相辅相成的。数据仓库的出现, 并非要取代数据库。目前, 大部分的数据仓库还是采用关系数据库管理系统进行管理的。首先, 两者的出发点是不同的:数据库是针对主体来设计的, 而数据仓库是针对事务设计的;两者存储的内容也是不同的:数据库储存的一般是在线的交易数据;数据仓库则是储存历史数据的工具。其次, 两者的设计原则也是不同的:数据库的设计是尽量避免冗余, 而数据仓库则相反;数据库主要为企业提供的是捕获数据的服务, 而数据仓库是提供分析数据的服务的。再次, 数据库的容量比数据仓库的要小, 数据库是为了能够高效的处理事务而产生的, 数据库则是为了分析数据帮助管理者决策而产生的。

3 钻井工程决策中数据仓库的应用及其作用

我国是钻井的起源地, 以卓筒井为代表的中国井盐凿井技术, 在盐卤凿井中发现了石油矿藏, 引领了我国步入了石油勘探与开发的时代。我国在钻井工作量的排行中位居世界第三, 可以说我国的钻井技术是比较先进的, 但是我认为, 我国钻井工程中的管理决策系统并不是很完善。因此, 改变传统的观念, 引进新的技术, 从而提高我国在钻井工程中的各项能力是非常必要的。例如, 许多专业人士提出的DEDS系统, 此系统的建立是基于数据仓库的钻井工程职能决策支持系统。数据仓库系统是由数据仓库、数据仓库管理系统和数据仓库工具集共同组成的, 其核心是数据仓库, 管理系统则是要保障整个系统的各项都能够良好的运转, 工具集是数据仓库能够发挥其作用的关键。

数据仓库在钻井工程决策中主要发挥着重要的辅助作用。工作人员首先要采集各项数据, 例如:设计记录、生产记录、库存井史记录等, 然后将这些数据存入数据仓库系统中, 数据仓库系统将数据进行分类, 一般简单的分为:集团公司级的资料;局级资料;井场级资料, 完成这些工作后, 数据仓库系统就能够为决策者提供准确的、有价值的数据, 帮助决策者能够及时的、科学的做出决策。

由于数据仓库是集成的、面向主题的、相对稳定且能反应历史变化的, 因此, 在钻井工程中, 其作用是巨大的。当决策者需要作出决策时, 数据仓库能够及时的提供出科学的数据, 帮助决策者全方面的分析数据, 为决策者提供历史资料进行参考。综上所述, 钻井工程决策中数据仓库的应用是一种趋势, 其作用也是不容忽视的。

4 结束语

数据仓库是面向应用的数据管理技术, 数据仓库中的各种数据可以为工程决策者提供综合性的数据分析和战略分析。国外的钻井服务商早在20世纪80年代起就引入了信息技术, 以此来帮助自己更好的为钻井工程企业及其领导者服务, 90年代时, 逐渐建立起钻井信息系统, 目前我们已进入21世纪, 钻井行业仍在处于不断发展的阶段, 钻井企业也逐渐普及了数据仓库技术, 利用其智能决策支持系统能够有效的为管理人员提供决策支持, 相信实现钻井工程的网络化、信息化指日可待。

摘要：近年来, 数据仓库技术成为了工程技术界的热点。由于在钻井工程决策中采用的传统的DSS方法, 只能进行简单的查询和报表, 不能够为决策者提供精准的数据分析。因此, 数据仓库的应用就越来越广泛。本文旨在近年来, 数据仓库技术的不断发展下, 针对数据仓库在钻井工程决策中的广泛应用及其作用来发表个人的一些观点。

关键词：钻井工程,工程决策,数据仓库,应用

参考文献

[1]王珊.数据仓库技术与联机分析处理[M].北京:科学出版社, 2009:138—145[1]王珊.数据仓库技术与联机分析处理[M].北京:科学出版社, 2009:138—145

[2]李志刚, 马刚.数据仓库与数据挖掘的原理及应用[M].北京:高等教育出版社, 2008:58—65[2]李志刚, 马刚.数据仓库与数据挖掘的原理及应用[M].北京:高等教育出版社, 2008:58—65

[3]胡保坤, 朱群雄.基于数据仓库的石化工程预算决策系统[J].北京化工大学学报, 2005, 05 (3) :37—39[3]胡保坤, 朱群雄.基于数据仓库的石化工程预算决策系统[J].北京化工大学学报, 2005, 05 (3) :37—39

[4]王爱玲, 葛雁冰, 魏政.钻井工程数据库的管理与规划[J].中国石油规划, 2005, 6 (3) :40—42[4]王爱玲, 葛雁冰, 魏政.钻井工程数据库的管理与规划[J].中国石油规划, 2005, 6 (3) :40—42

[5]王同良, 邹衡岳, 王汉良.石油信息技术进展[M].北京:石油工业出版社, 2006:128—135[5]王同良, 邹衡岳, 王汉良.石油信息技术进展[M].北京:石油工业出版社, 2006:128—135

篇4：数据仓库工程师的具体职责

关键词：金财工程数据仓库设计实现

中图分类号：F81 文献标识码：A 文章编号：1008-925X(2012)O9-0102-01

金财工程这一概念提出后，使得当前所有产品仅仅达到了各项财政业务应用系统的日常业务处理目标，而关于各系统间的数据集成目标并没有真正的实现，致使财政部门难以对各系统的数据加以全面的分析，应积极构建一套完善、高效的数据仓库体系，科学合理的利用各系统中已经形成的财政数据，以挖掘数据和分析数据。

1、金财工程背景下数据仓库的设计

金财工程主要由两个部分而组成，即涉及全国各级财政管理部门以及财政资金使用部门的信息网络系统，财政业务应用系统。其中，财政业务应用系统是由诸多的分系统组合而成，比如预算编制审核系统、现金管理系统、国债管理系统、固定资产管理系统等。

1.1数据仓库的设计

1.1.1体系结构设计

一，操作数据存储ODS技术具有的功能特点；随着数据仓库的提出以及具体实施，使得操作型处理与分析型处理两者相分离，构建了DB-DW两层体系结构。不过，通常情况下，这两层体系结构很难满足企业全部数据处理要求。追究其原因，主要是因为操作型处理与分析型处理两者间并没有明确的界限，数据实际处理过程中通常呈现出多层次，也就是说，部分数据处理属于操作型的，但是在操作型数据库中却行不通，有部分属于分析型的，但在数据仓库中行不通。诸多的问题不是联机事务处理，也不是高层决策分析，而往往是企业中层管理人员经常解决的问题。由于这一信息处理具有多层次特点，所以，应构建高效的操作数据存储。

随着ODS的提出，对DB-DW两层体系结构存在的不足加以有效的补充了，从而构成了三层体系机构，即DB-ODS-DW。ODS的主要任务是将企业日常中所有数据集合起来，将企业日常数据作为业务处理的基础，同时，其还能够提供有利的数据给数据仓库，因此，我们又将其称之为业务数据商店。ODS中储存的数据有四方面的特点，即面向主题、集成、可变以及数据是当前或者与当前接近的。

1.1.2事实表、维度表设计

所有的数据仓库都涵盖了一个或者多个事实数据表，星型或者雪花型架构的中心属于一个事实数据表，主要任务是收集与衡量企业业务运作的数据。该表的特点是涵盖了真实的数字数据，而这些数字数据能够进行汇总，从而提供相关单位运作过程中的历史信息。另外，所有事实数据表还涵盖了一个由诸多部分组合而成的索引，而此索引又涵盖了作为外键的有关维度表的主键，维度表所涵盖的是事实记录的特性。事实数据表中不包括描述性信息，也不包括数字度量字段等以外的所有数据。实际设计事实表时，应对以下几点加以考虑：一，为各项功能决定其数据仓库时距；二，为各项功能决定其统计采样原则；三，明确事实表中具体应涵盖的字段；三，将时间因素纳入到事实表中；四，尽可能的将事实表中字段的大小进一步缩减。在对维度表进行设计时，应根据具体的财政业务数据分析需求以及事实数据表实际状况加以合理的选择。

2、金财工程背景下的数据仓库查询系统的实现

2.1根据Struts架构的系统思想

笔者在仅构建部门级的数据仓库前提下，根据Struts架构设计了“预算外非税收入直缴系统”数据仓库查询系统，通过B/S模式中的Web三层体系结构，利用网页的形式对历史数据进行详细的查询，有着较好的人机界面，同时，使得“非税收入 ”主题域的查询得以实现。该架构主要是根据J2EE中的Web形式MVC模式而最终实现的，这里所说的 MVC就是模型、视图、控制器的缩写，这一设计模式应用普遍。MVC将业务逻辑接口与数据接口间的耦合度进一步减弱，并且提高了视图层的变化度，对于理清系统结构具有重要作用，大大降低了系统复杂度与维护难度。Struts将Servlet与 JSP标记（在J2EE规范范畴）当做实现的一部分，采用了MVC各项特性，同时参照J2EE自身特征，进行了必要的改变与扩展。

2.2对系统进行测试

测试在软件生存周期过程中属于一项重要的、独立的环节，它是确保软件具有较高质量的核心手段。根据测试方式进行分类，将始终依靠软件内部实现的测试称之为“白盒测试 ”将对软件内部实现测试不够重视的称之为“黑盒测试”，白盒测试主要以设计为基础，黑盒测试主要以需求为基础，本文使用的是白盒测试。

此系统的根本性目的是实现财务人员数据查询分析需求，所以，最主要的测试指标就是查询速度。测试过程中，通过vmstar工具对系统中的CPU使用与内存耗用等诸多情况进行查看，根据非税收入主题，以已有三年的财政部门非税收入业务数据为例加以测试，把测试数据纳入到数据仓库中，通过查询系统及时有效的查询到各种账目，利用监督控制充分的说明了系统查询响应速度是可以接受的，当前，随着访问用户数量的增加，促进了系统并发进程数的提高，当在线用户数在120的时候，系统CPU占用率为百分之二十，内存占用率为百分之三十五。由此可见，系统能够实现当前查询分析的实际需求，与预期系统设计目标相一致。

3、结论

综上所述可知，当前，应在金财工程背景下，构建各应用系统以及各级财政部门数据仓库，从而确保本部门的决策分析与预测得以全面的实现，然后再据此构建整体数据仓库系统。

参考文献：

[1]马军杰．基于数据仓库与联机处理的区域经济发展管理决策支持系统研究[D]．华东师范大学，2007年．

[2]于海鸿．多维数据环境中决策支持相关技术研究及应用[D]．吉林大学，2007年．

[3]谢胜平．设备管理数据仓库系统研究[D]．哈尔滨理工大学，2008年．

篇5：数据仓库工程师的职责精选

1、负责数据仓库架构、元数据、数据质量、血缘分析等环节的设计与实现，构建可扩展的数据仓库和分析解决方案;

2、负责将BI、运营、产品、客服等业务部门的需求抽象成数仓模型并落地;

3、负责参与智能用户画像体系开发与建设;

4、负责数据工具、数据产品及其他数据需求的开发。

技能要求：

1、有数据仓库需求调研和需求分析经验，能根据业务需求设计数据仓库模型，并对数据仓库数据模型进行管理，保证数据质量，熟悉kimball架构;

2、精通sql开发，有较丰富的Hive sql性能调优经验优先;

3、熟悉spark structured streaming、flink中至少一种流式处理计算框架，有相关开发经验;

4、熟悉大数据存储处理组件，包括但不限于Hive/HDFS/HBASE/presto/Druid/kylin/impala;

篇6：数据仓库工程师的职责精选

1、构建数据挖掘模型，推动业务精确营销实践;

2、根据业务需求开展数据分析与建模工作，提供相关的模型和算法支撑;

3、构建数据挖掘与建模解决方案，指导应用设计与开发;

任职要求：

1、具有数学统计、计算机相关专业的本科及以上学历

2、两年以上相关工作经验;

3、精通各种分类、聚类、预测、关联模型算法与原理;

4、精通SAS、MATLAB、CLEMENTINEL等主流数据挖掘工具的使用方法，并具有大型数据挖掘项目的成功实施经验;

5、对数据与业务有足够敏感性，具有极强的利用数据分析、挖掘，解决业务问题的能力;

6、对数据挖掘方法论有较深刻的理解，能独立规划数据挖掘模型解决方案并实施;

7、熟悉linux环境和命令，能编写简单的shell脚本。

篇7：数据仓库工程师的基本职责

1.负责VIVO公司级的数据集市和数据仓库的设计和开发

2.负责基于用户行为的用户标签探索和开发

3.负责基于业务需求的数据中间层和可视化开发

4.负责各类分类和预测模型的开发

任职资格:

1.本科学历，数统、计算机相关专业。

2.了解hadoopspark生态，有完整仓库设计和开发经验。

篇8：基建工程数据仓库构建与应用研究

经过多年发展,基本建设工程领域各个业务部门开发并使用各类管理信息系统,积累了大量业务数据。然而,现有系统互不联通,相应的数据资源被分割在不同的系统中,无法实现跨系统综合查询与分析,同时,在现有系统中,统计查询仅仅作为一种辅助功能,直接基于业务数据库进行简单的浏览查询和统计汇总。因此,如何将异构的数据资源集成在一起,实现跨系统、跨表、全面灵活的统计查询与分析,为基建工程精细管理与科学决策提供信息化手段支撑,成为目前的重要研究课题。本文提出了一种基于数据仓库的基建工程决策支持系统框架、搭建了自主集成的商业智能平台,在此基础上重点阐述基建工程数据仓库的建设,以及数据仓库之上的数据分析应用。通过构建数据仓库,有效解决数据不一致、冗余、异构等问题;同时,基于数据仓库的基建工程决策支持系统支持多维数据分析和数据挖掘,更好地支撑基建工程管理和决策[1]。

1 系统架构与平台构建

1.1 系统架构

基于数据仓库的基建工程决策支持系统框架主要包括:数据源层、数据处理层、数据存储层、应用服务层和用户访问层。

1.1.1 数据源层

数据源层是数据仓库系统的数据来源,基建工程业务涉及的数据源主要分布于工程计划、房屋土地、住房、两项普查等核心业务系统。

1.1.2 数据处理层

数据处理层采用统一的ETL调度平台,实现对原始数据抽取、清洗、转换、加载,消除数据间的不一致和冗余,按数据仓库模型结构重新组织数据并加载到数据仓库,形成能够对决策提供支持的多重粒度级的数据仓库标准化数据。

1.1.3 数据存储层

数据存储层主要包括操作数据层(ODS)、基础数据层(EDW)和数据集市层(DM)3层。ODS层与EDW层共同构成企业统一数据平台。ODS层主要实现企业数据整合、共享和准实时运营监控等功能,EDW层为中央数据仓库,将不同的OLTP数据集中到面向主题、集成、稳定、随时间变化的统一数据层中,主要为企业提供分析决策服务。DM层是针对各部门的特殊分析需要设计独立数据集市(即EDW的子集),建立维度汇总信息,为不同部门业务应用建立汇总数据区。

1.1.4 应用服务层

应用服务层是访问数据仓库信息的核心,它接收用户请求访问数据仓库,生成各种形式的复杂报表,并以多种方式展现,包括预定义报表、多维分析、即席查询、数据挖掘等。

1.1.5 用户访问层

用户访问层是数据服务与决策人员、管理人员、分析人员和业务人员等用户之间的接口,该层提供用户对数据仓库数据的浏览、请求、存取等服务,以及向用户的数据交付。

1.2 自主集成的基于Pentaho的BI平台

针对基建工程决策支持系统框架,在开源的商业智能BI(Business Intelligence)平台基础上构建自主集成的BI平台。构建平台分两步走:首先是开源商业智能BI平台选型,其次是自主集成商业智能平台。

1.2.1 开源商业智能平台选型

选择开源的商业智能BI平台的依据有:平台具有开放性、灵活性和功能全面。开放性是指源代码开放,在此基础上才能实现灵活性;灵活性是指平台小巧,可移植,可集成;功能全面是指具有通用商业智能平台的数据集成、数据存储、数据分析和数据展现功能。通过追踪权威咨询机构Gartner从2010-2016年的年度BI报告[3],开源BI平台Pentaho连续6年入围商业智能魔力四象限图,因此,我们选择Pentaho作为决策支持系统的商业智能平台。Pentaho满足通用商业智能平台数据集成、数据存储、数据分析和数据展现的功能[4],此外,Pentaho主要目标是和商业BI抗衡,市面上已经有一些基于Pentaho的决策支持系统研发的实例可供参考[5,6,7]。然而,Pentaho在页面框架设计的灵活性和报表展现的美观性两方面能力较弱,同时,考虑到对大数据存储与分析的需求,基于Pentaho平台我们提出一种自主集成的商业智能BI平台。

1.2.2 自主集成BI平台

自主集成的商业智能平台分为数据持久化层、服务层、控制层、表现层。数据持久化层集成了文件访问、Hibernate和JDBC,Hibernate是一个开源框架,是对象关联关系映射的框架,支持各种关系数据库,对JDBC做了轻量级的封装,因此,能够很好地支持对异构数据源的访问。数据持久层之下集成了Hadoop生态圈的HDFS、Hbase、Hive和Spark,支持批量数据、实时数据和增量数据的存储和访问[8,9,10,11,12,13,14,15,16,17]。服务层包含Pentaho的即席查询、多维分析展示、OLAP引擎、多维立方体构建等功能组件,并集成了数据挖掘构件Weka,大数据分析构件Mahout、MLLib,ETL构件Kettle、Sqoop等。控制层采用Spring MVC,分离了控制器、模型对象、分派器以及处理程序对象的角色,这种分离让他们更容易进行定制。表现层则采用基于Web前端开源框架Bootstrap的ACE页面框架模板,能够实现灵活的页面设计。平台对每一层都提供了相应的支持,系统开发时,可以方便访问已有的公共构件。上述技术均是基于Java实现,符合开放源码基础软件要求。

2 系统建设

本文以基建工程的“基本建设与房地产资源”两项普查数据和基建工程各处室在用的18个业务系统的业务数据为数据源建立数据仓库,在数据仓库之上建立多维数据模型,利用自主集成平台中Pentaho的OLAP引擎Mondrian对数据进行多维度、多层次分析,并通过Saiku将分析结果展现出来。利用ACE页面框架做报表展现。

2.1 数据仓库建模

数据仓库模型是针对特定的数据仓库应用系统的数据模型,在整个数据仓库的建模过程中,一般需要经历四个过程:业务建模,生成业务模型,主要解决业务层面的分解和程序化;领域建模,生成领域模型,主要是对业务模型进行抽象处理;逻辑建模,生成逻辑模型,主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化;物理建模,生成物理模型,主要解决逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题[1]。本节重点介绍基建工程数据仓库的业务建模、逻辑建模和物理建模。

2.1.1 业务建模

结合基建工程业务特点,将基建工程数据仓库内容规划为公共基础、工程建设管理、土地、住房管理、环保绿化和空余房地产等六大业务管理主线,在每个业务主线内,考虑相应的业务主线需要分析的业务主题(图1)。

公共基础主题:指地区、单位、坐落和分栋四类基础信息,公共基础主题是数据仓库中最基础、最核心的内容,所有的业务活动都是围绕地区、单位、坐落和分栋展开,与其他主题产生紧密联系。

工程建设管理主题:存放机场、地下工程、地面工程、人防工程等设施数质量情况,泵类、风机、柴油发电机组、配电屏(柜)、控制台、变压器、除湿机、空调、电加热器和锅炉等设备数质量情况。

土地主题:存放土地资源信息,包括土地资源总量,按城乡、按地域、按地势资源分布信息。

住房管理主题:存放公寓房、经济适用房、住用人员等相关实体,包括:住房数质量情况,住用情况。

环保绿化主题:存放污染治理、绿化资源、放射性污染源等相关实体,包括:污染源总体情况与污染设施总体情况,绿化资源总量与分布情况,放射源与射线装置的种类、用途、数量、分布、使用和管理状况。

空余房地产主题:存放空余房地产、租赁管理等相关实体,包括:储备房地产、整坐落空余房地产、成片空余营区数质量情况,租赁坐落、项目、审批、缴费办证情况。

2.1.2 逻辑建模

目前业界较为流行的数据仓库的逻辑建模方法主要有范式建模法,维度建模法,实体建模法等。对于本系统来说,ODS层模型的表结构与业务系统保持一致,因此,其逻辑模型采用与关系数据库相一致的实体关系模型。EDW层数据模型依据图3的主题划分建立统一的数据模型。同时,根据部门业务决策分析需求,采用维度建模法建立对应的数据集市(DM,Data Market)模型。例如,住房管理业务关注从不同地区、不同单位、不同人员类型、不同户型、不同住房性质等角度来掌握住房的面积、出售情况、套数、住用率,空置率等,因此,按照事实表,维表来构建住房星型数据模型(图2)。

2.1.3 物理建模

物理建模是将前面的逻辑数据模型落地的一个过程。首先是生成创建表的脚本,其次是针对数据集市的需要,按照维度建模的方法,生成事实表和维表等。在这里,我们介绍住房管理主题物理建模的方法。住房管理主题物理建模其实是建立住房管理多维立方体,该立方体为OLAP分析服务。本文借助Pentaho的Schema workbench来设计数据立方体,构建物理的事实表和维度表。如图3所示,该立方体包括一个住房事实表(图3的zffact表),多个维度表(例如,人员类别表见图3的rylb表,住房性质表见图3的zfxingzhi表等)。

2.2 数据ETL

将源数据加载到数据仓库的过程有两种形式,一种是进入数据库后再进行清洗和转换,另一种是首先进行清洗转换再进入数据库。自主开发的集成平台中已经集成了Kettle和Sqoop两个数据ETL工具。其中,Kettle是集成在Pentaho中的开源ETL工具,支持将源数据库(一般是关系数据库)中的数据进行清洗转换后再装载入数据仓库。Sqoop是用于Hadoop大数据存储和关系数据库数据存储相互转移的开源工具。目前主要是将业务数据库中的数据抽取到数据仓库中,因此,本文采用Kettle实现从源数据层到数据仓库层的数据清洗、转换和加载。图4是采用Kettle加载住房管理主题数据集市的过程。

2.3 数据分析应用实例

在数据仓库基础上,基建工程分析决策系统目前实现了:采用ACE页面框架实现统计报表功能,例如,采用文本描述与饼图展示相结合的方式统计住房数质量情况,为进一步优化配置住房资源提供科学的决策依据,如图5;采用Pentaho的Mondrian和MDX实现多维交叉分析功能,并利用Saiku实现多维分析展现,例如,从使用单位、户型分类、住房质量等多个维度掌握住房分布情况,支持下钻、旋转等操作,并支持自定义多维分析,为住房精细化管理提供数据支持,如图6。

3 结语

本文阐述了基于数据仓库的基建工程决策支持系统架构与商业智能开发平台构建,详细介绍了基建工程数据仓库的数据建模、数据分析与展现的技术实现。后续工作将在数据仓库及多维分析基础上,采用数据挖掘技术,在项目计划动态排序、工程建设“三超”评估、房地产资源配置优化、保障能力评估、基建工程管理制度辅助决策等方面进行更深层次的知识挖掘。

摘要：完整而规范的数据仓库既能解决异构数据源集成问题,也为多维数据分析和数据挖掘提供数据支撑。本文基于基建工程数据仓库研究和建设的实际做法,阐述了基于数据仓库的决策支持系统架构与相应的商业智能开发平台构建,系统建设中数据仓库的设计、数据收集的ETL设计、数据分析的OLAP设计和数据展示的报表设计,希望通过探索和研究,为基本建设工程领域构建规范化数据仓库提供参考和借鉴意义。

篇9：基于数字校园数据平台的数据仓库

[关键词]数字校园数据平台数据仓库工程

数字化校园建设中数据仓库的架构

数字化校园的构成可以用图1表示，计算机网络是数字化校园的基础设施；网络基本服务是数字信息流动的基础，包括电子邮件、文件传输、域名服务、身份认证、目录服务等；在此基础上要建立各类基于网络的数据仓库，包括职能信息库、课程资源库、数字化图书资源等；应用支撑系统包括办公自动化系统、各类管理信息系统、网络教学系统以及数字图书馆管理系统等等；在此之上的信息服务系统是校内用户的主要使用界面，为师生提供各种服务，如信息交流、信息查询、决策支持、电子商务等。五个区域分别表示数字化学习环境的功能领域：组织管理、教学活动、学术研究、公共服务和学校社区服务等，各个功能领域之间是密切相关、相互促进的。

图1

以选课系统为例解析数据仓库的构建与应用

数据挖掘，又称为数据库中的知识发现（Knowledge Discovery in Database，簡称KDD），是指从大型数据库中提取人们感兴趣的信息，提取的知识表示为概念（Concepts）、规则（Rules）、规律（Regularities）、模式（Pattems）等形式。数据挖掘可以应用于各个领域，包括商务管理、生产控制、市场分析、工程设计和科学探索等。利用数据挖掘技术，挖掘选课系统中积累的有用信息，可以使学校的相关部门有弹性地调节所开的课程，调整热门课程和冷门课程的人数，调节相关课程的学分，通过选课率及相关信息做出正确决策，鼓励和引导学生选择互补的课程，这有利于学生整体素质的提高，也有利于教师、教室等资源的合理分配。

1.确定数据仓库和OLAP模型

OLAP（Online Analytical Mining或OLAP Mining）是基于数据仓库的信息分析处理过程，其基本特点是能够从多种角度对从原始数据中转化出来的信息进行快速、一致、交互地处理，从中获得对数据更深入地了解。OLAM将二者结合起来，发展一种建立在OLAP和数据仓库基础上的新的挖掘技术，它兼有OLAP多维分析的在线性、灵活性和数据挖掘对数据处理的深入性，是数据库应用工具未来发展的方向之一。

通常要先分析原有业务数据库，确定待建的数据仓库主题。再根据用户的需求来确定各个级别数据仓库的存储主题。这里选取学生选课管理这一典型业务为主题。为了保证数据的正确性和一致性，还要确保这些数据是按同样的方法记录的同一件事情，需要对选课的原始数据进行预处理，转换成适合数据挖掘的数据。数据预处理（Data preprocessing）包括三个步骤：数据清理（Data cleaning）、数据集成（Data integration）和数据变换（Data transformation）。完成数据的预处理之后，便可确定待建的数据仓库模型，实现OLAP建模，生成多维数据集（CUBE）。可以建立以ROLAP方式存储的选课数目分析多维数据集（以时间维、学号维、院系专业维为维度，选课数目为度量值）、选课学分分析多维数据集（以课程类别维、课程开课部门维、学号学历维为维度，学分为度量值）等许多个不同的多维数据立方体。

2.数据挖掘关联算法的实现

关于关联规则的挖掘算法主要有循环式扫描算法、增量式更新算法、并行挖掘算法、元模式制导、基于约束挖掘等等。目前大多数研究集中在频繁数据项的挖掘方法上。其中比较典型的关联规则挖掘算法有Apriori算法和FP-growth算法。

Apriori算法可以产生相对较小的候选项目集，扫描数据库的次数由最大频繁项目集的项目数决定。因此，该算法适合于最大频繁项目集相对较小的数据集中的关联规则挖掘问题。针对Apriori算法框架的缺陷，Han.JW（韩家炜）等人提出了FP-tree结构和相应的P-growth算法。FP-growth算法采用的是分而治之的策略，即在经过了第一次扫描之后，把数据库中的频繁集压缩进一棵频繁模式树（FP-tree），同时依然保留其中的关联信息。随后再将FP-tree分化成一些条件库，每个库和一个长度为1的频集相关；然后再对这些条件库分别进行挖掘。当原始数据量很大时，也可以结合划分的方法，使得一个FP-tree可以放入主存中。实验表明，FP-growth对不同长度的规则都有很好的适应性，同时在效率上较之Apriori算法有巨大的提高。由于高校多年来存储的选课数据量较大，故选用FP-growth方法实现高校选课系统的关联规则挖掘较合适。

篇10：数据仓库工程师的主要职责

1.负责企业级数据仓库设计、规划、建设、实施、管理,数据仓库架构设计与数据开发，创建数据仓库、数据集市

2.熟悉数据仓库领域知识，从架构和技术层面参与建设数据仓库，包括元数据管理、数据质量、主数据管理、性能优化和调优。

3.负责数据仓库平台相关数据管理工作，如研发规范、质量规范、保障规范的制定与推动实施落地

4.配合和协助数据分析/数据挖掘形成底层/中间层的业务逻辑切片

任职资格:

1. 本科或硕士以上学历，计算机工程相关专业

2. 熟悉大数据相关技术能力(Hadoop/MapReduce/Hive/Hbase等),熟练进行数仓Hive建设和软件架构,较强的数据抽象能力

3.精通SQL，具备海量数据处理和Hive/Spark性能调优经验,3年以上大规模分布式数据仓库建设经验

4.熟练使用Druid/Kylin之一进行数据挖掘模型设计，熟练掌握Java/Scala之一，具备良好的coding素养和习惯,了解脚本语言，如Python、Shell等

篇11：数据仓库工程师的工作职责

1.负责数据ETL开发，优化ETL流程设计;

2.负责数据质量问题的分析、跟进、解决，进行数据质量监测、校验和提升;

3.负责ETL开发实施文档的编写;

4.负责梳理公司数据仓库/数据集市数据清单、数据映射关系，优化现有数据仓库模型;

5.完善和梳理数据指标体系，完成和维护数据字典的工作;

6.参与数据标准的制定、数据标准管理和数据安全管理工作;

7.参与公司大数据平台的建设，包括Sugar报表或神策接口配置，用户画像标签体系的开发等

任职要求：

1.有shell或Python脚本开发经验;

2.有传统数据库SQL Server和MySQL，有存储过程编写能力;

3.熟悉Hadoop生态相关技术并有相关实践经验，包括但不限于Sqoop、Hive、HBase、Kylin等开发经验;

4.有kettle、azkaban或oozie工作流调度经验;

5.熟悉Hive SQL或Flink SQL的开发;

6.有数据仓库模型设计，有使用kafka+Flink Streaming实时数据处理经验优先;

7.有Sugar、神策或Tableau使用经验,有用户画像或客户召回标签工作经验优先;

篇12：数据仓库工程师岗位的基本职责

1、深入理解业务，了解需求和痛点，为风控和业务部门提供数据支持;

2、针对业务需求，参与数据仓库需求分析，制定ETL相关设计方案和开发计划;

3、负责数据同步，数据整合清洗，以及数据质量的治理;

4、数据仓库模型设计，分层体系构建，元数据管理监控以及权限控制。

任职资格:

1、重点院校统招本科及以上学历，计算机基础扎实;

2、具有2年以上金融贷款类业务经验;

3、熟悉数据仓库理论和数据库建模，有redshift和AWS经验优先;

4、精通pgsql/mysql等数据库，精通sql语言，具有数据库优化/sql优化相关经验;

篇13：探讨数据仓库元数据的集成与转换

元数据是描述数据的数据,或者说是与数据有关的信息,是数字信息组织和处理的基本工具,是理解数据含义和如何使用数据的关键。所以,每一个软件产品和工具能够在数据层进行有效集成的前提是,它在元数据层就必须被有效集成。所以对数据仓库元数据集成和转换的研究是非常有意义的。

1 元数据集成与转换的设计

1.1 元数据的信息供应链

本文所设计的元数据集成与转换功能,是基于数据仓库的,该功能用来提取数据仓库中各部分产生的元数据,并应用某种策略对其进行综合管理。通过这些元数据,相关人员可以清楚地了解数据仓库中的数据结构、业务规则等,从而对决策支持产生巨大的战略价值。换句话说,元数据集成与转换管理工具的起点就是数据仓库的构建过程和业务使用过程。而数据仓库中信息流动的和处理过程常常用信息供应链(ISC,Information Supply Chain)来描述。

从数据源开始,信息经过多次处理,最终用于辅助决策支持。在整个流动过程中,顺序产生了四种数据,即源系统中的业务数据、ODS数据、DDS数据,以及OLAP数据,这几种数据的在粒度、抽象级别以及面向的应用等方面均存在不同[1]。为保证ISC的顺畅流动,并使参与此过程的软件产品都能够有效工作并基于数据层进行交互操作,就必须对描述各软件产品的元数据有一致理解。这是因为元数据定义了它们的内部处理逻辑和存储结构,通过元数据可以制定处理数据的策略。综上所述,构成ISC的每一个仓储产品和工具能够在数据层上进行有效集成的前提是,它们能在元数据层面进行有效的集成。

1.2 集成和转换的体系结构

本文以联邦式管理模式为基础提出元数据集成和转换功能的架构,主要分为元数据源、局部元数据仓储、全局元数据仓储、适配器、元数据抽取、元数据转换、元数据汇集等部分,如图1所示。

在上述架构中,所有元数据均来源于组成ISC信息供应链的软件产品。对于存储业务数据、ODS数据、DDS数据、OLAP数据的仓储软件产品,可以经过元数据抽取操作从中获得诸如存储结构等信息的元数据,存入各自的局部元数据仓储中;对于诸如ETL工具、报表工具等软件产品,产品内部往往会配备记录该工具使用规则等方面信息的局部元数据仓储,除此之外,还需对这些信息进行格式的一致性转换以提供元数据共享的途径[2]。

局部元数据仓储中是以关系型数据库的形式存放元数据的,其中的元数据可以分为两类,一类是仅为软件产品自身服务的私有元数据,另一类是需要在企业全局范围内共享的元数据,称之为共享元数据。对于前者,只需要存放在局部元数据仓储中,而对于后者,就需要进一步将其送入关系型的全局元数据仓储中保存和共享。

2 元数据集成与转换的实现

2.1 数据结构分析

本文所涉及的集成及转换工具,内部实现总共分为四个步骤。其中第一步就是将局部元模型导入到工具设计的数据结构中,利用这个数据结构,我们可以存储局部元模型的表结构以及冲突差异分析后产生的标记。本主涉及如下四个数据结构表。

1)数据结构l:记录表来源的数据结构,如表1所示。

2)数据结构数据结构2:记录列来源的数据结构,如表2所示。

3)数据结构3:临时记录一一对应的列的数据结构,如表3所示。

4)数据结构4:临时记录一一对应的表的数据结构,如表4所示。

2.2 集成与转换的流程

假设模型集成工具的两个输入模型分别为Ml和M2,目标输出模型为M3,则需要按照如下步骤完成模型集成:

Step1,将M1和M2中表的相应结构填入初始的集成工具的数据结构中。

Step2,针对数据结构中的数据进行如下流程实现模型的冲突和差异分析。

1)检查M1和M2中所有表,将无同名的表的标记Tag值设为TD(Table Difference),同名表的标记Tag值设为TS,并将同名的表Id对加入到数据结构4中。进入步骤2)。

2)针对每一对标记为TS的表,检查该表中列个数是否相同、名称是否相同。如果列一一对应则进入3),且将对应的列Id值对记录在模型集成工具的数据结构3中;否则进入步骤4)。

3)查询并记录数据结构3对应的表项个数N,即对应的列的个数,分别检查每对列的属性,开始列对检查的循环,查看其数据类型是否冲突。

4)首先将模型中无同名列的Tag标识为CDl(Column Difference1),说明这是某个输入模型的表中多出来的列。然后记录同名的列对的个数N作为循环次数,进入步骤5)。

5)检查剩下的同名列的属性,如果相同,进入步骤6):如果不相同,进入步骤7)。

6)检查同名列的数据类型。如果相同,则在数据结构2中,将该对应列的记录中Tag值设为CE,表示这两列的完全相同;如果不同,则在数据结构2中将这对列的Tag值设为CC,表示冲突。然后返回到步骤4)进行下一次的循环。

7)检查属性不同的列对。如果其中一个列的属性是默认值,则进入步骤8);否则将数据结构2中的相应两个列对应的记录的Tag值设为CC,表示属性值冲突。

8)继续检查该列对的数据类型。判断是否所有的同名列都已检查完毕,如果没有,则返回步骤4)进行下一次的循环。

Step3,针对分析过程中得到的不同种类的冲突和差异加以解决,并输出目标模型M3。在分析的流程中,我们得到了不同标记的表和列,针对不同标记有不同的冲突和差异解决方案。

2.3 列冲突差异的实现

1)列冲突CC

思路:生成列冲突的原因是列属性设置或者数据类型不同。这种情况下,本文的集成工具默认认为其不存在模型合并的必要,只需将两个输入数掘模型的表结构完全拷备,添加到输出模型中即可。但是,如果将来需要用户选择解决冲突方式的需求,也可以在本文设计的集成工具的基础上增加这个功能。

算法:遍历查询数据结构2所在表每条Tag值为CC的记录,获得该记录的OwnedTableId,到数据结构l中查找符合条件的记录,使得该记录的TableID值等于0wnedTableId,这样,就找到了相应模型中的表结构,从而添加到新模型中。

2)列差异CD

思路:CD表示某一输入模型的表较另一输入模型的表多了一些列,这种情况下,我们要将含有多余列的表结构加入到新模型中。

算法:遍历查询数据结构2所在表中每条Tag值为CD的记录,获得该记录的OwnedTableId,到数据结构1中查找符合条件的记录,使该记录的TableID值等于OwnedTableId,这样,就找到了相应模型中的表结构,将其添加到新模型中即可。

3 结束语

总之,数据仓库及其元数据是企业知识管理的重要组成,数据仓库的元数据管理终归是一个非常繁琐复杂的过程,其范围涉及数据仓库的整个环节,一个完整、通用的元数据管理系统的构建注定充满了迭代和不断反复,因此,对它的研究也应该是长期的、不断探索的过程。

摘要：该文基于对数据仓库系统本身的架构和数据模型特征研究,并结合元数据仓储架构的理论设计提出一种数据仓库元数据集成与转换功能的架构,并进行了系统实现,涉及到数据结构的分析、集成与转换的流程以及列冲突差异的实现。

关键词：元数据,集成与转换,数据仓库

参考文献

[1]黎建辉,吴威,阎保平.一种基于XML的元数据映射与转换方法.[J].微电子学与计算机,2008,(1).

篇14：数据仓库工程师的具体职责

摘要：文章从数据分析的目的和基础出发，以常熟理工学院校园卡、教务数据分析为例，具体阐述了数据分析在高校管理与教学中产生的实际效果和意义，并明确了下一步数据分析的努力方向。

关键词：大数据；数据仓库；数据分析；校园卡；教务

中图分类号：G434 文献标志码：B 文章编号：1673-8454（2015）10-0013-03

随着大数据时代的到来，各行各业都在利用大数据推动本领域的发展。常熟理工学院自2009年开展教育信息化建设以来，在数据分析方面进行了不断地探索与实践，目前广泛应用于教学和管理中。

一、数据分析的必要性和可行性

高校内部一般都建有：教务系统、科研系统、学工管理系统、人事管理系统、资产管理系统等独立业务系统。这些系统都各自记录着学校方方面面的数据，却都静静地躺在服务器硬盘里，犹如埋藏在地下的金矿，不能为高校全局决策提供支撑。

数据分析的目的就是要让数据发声，通过直观的数据图表来为高校管理提供辅助决策。例如：对教师的专业与学校开设专业的统计分析可以为人才引进提供参考；对学生的校园卡使用记录和校内上网认证记录结合起来，可以为判断学生的行为指明方向；对各二级学院的资产数据统计分析有助于学校对二级学院进行成本核算。

二、数据仓库的建立

数据库是数据分析的源头，数据仓库的建立是数据分析的基础。

建设过程中，首先要统一数据标准，只有准确的数据才是有价值的，如果各系统的数据标准不统一，就会造成不准确的数据分析结果，也就无法为高校管理提供真实有效的统计数据；

其次要建立公共数据平台，公共数据平台是指实现校园内各种信息系统的互通互连和数据共享，包括多个系统业务数据集中存储、备份、数据共享和数据管理的公共平台，为学校各应用系统提供基础数据；

三是要规范数据流程，把各业务系统中形形色色的数据按标准定期抽取到学校公共数据平台中。确保任何业务系统的添加和修改不影响其他系统的正常运行，同时新建应用系统应建立在统一的数据规范基础和统一身份认证基础上，调用公共数据平台的基础数据（如部门、教工、学生等基础信息），应用系统产生的数据也应成为公共数据平台的基础数据，可供数据平台共享访问。确保提供反映学校全面情况的数据信息，为整个学校提供决策支持所需的数据信息，为今后应用系统的建设和信息服务奠定良好的数据基础。

图1为数据架构图，最底层的是各业务系统，他们产生的数据按编码标准经过抽取、转换、加载到数据中心，数据中心再按需要把相关数据同步给相应的应用数据库或各数据集市，最后形成各类主题数据分析或综合决策系统。

三、基于数据仓库的数据分析

在统一数据仓库的基础上，我们利用数据仓库技术（ETL、OLAP、REPORT）和数据挖掘技术，对多种数据集市进行数据分析，建立了校情综合统计分析系统。该系统从学校基本情况、教职工信息、学生信息、教学信息、科研信息、资产与设备信息、图书资料信息与师生消费等八大方面进行统计分析，为学校管理提供辅助决策支撑数据。

该系统从学校全局出发，通过多元主题展开分析，以文字、报表、图表等多种形式展现分析成果。

该系统的推出实现了教学质量、学生学习、生活行为等各种信息的监控与分析，对高校资源配置优化、提高高校管理科学化等方面具有不可估量的重要意义。这里笔者将以校园卡和教务数据分析功能为例进行阐述。随着校园卡在校园生活中使用范围的日益扩大，在应用过程中产生了大量数据。校园卡仅仅一年的交易数据就有大约1000万条记录。

校园卡数据分析主要实现以下五大类的分析功能：

（1）各时间段消费情况分析

①从“月、季度、半年、年”的角度来查询消费总额、消费用户数和人均消费等，反映出用户消费支出的趋势，也可反映出物价的变化情况。

②从“几点几分”的角度查询消费人数可反映用户在时间点上的消费习惯，对于各营业部门来说可以合理地调整工作时间、工作人员等，以加强服务。还可根据教职工就餐时间点来分析他们是否严格遵守学校作息时间。

③从“早、中、晚”的角度统计分析学生早餐、中餐、晚餐的就餐率。

（2）各类消费人群消费情况分析

①对于学生工作管理层来说，从“个人、班级、院系”的角度来查询消费金额作为发放贫困补助的依据。

②通过查询一个时间周期内（三天）学生消费人数，起到了解学生是否在校的危机预警作用。

③从学生所属院系、专业、年级等角度来查询消费人数、消费金额和分布情况。

④从学生性别、来源地区（省、市、区）、年龄等人的自然属性来查询消费人数、消费金额和分布情况。

⑤分析教职工的消费水平。

（3）各营业单位消费情况分析

从各个营业单位角度来查询校园用户消费人数，消费金额和分布情况。

（4）各交易类型消费情况

从消费类型角度来查询用餐、购物、上网、上机、水电消费等情况。

（5）工作站、终端个数统计

为直观反映上述消费数据，我们除用表格形式将分析结果展现在用户终端外，还提供了柱状图、饼图、曲线图、点图等形式来展现。图2展示了我校2010年至2014年学生早、中、晚三餐平均价格，呈逐年稳步上升状态，这给餐饮部门提供准确统计数据的同时，也稳定了学生就餐消费水平的承受心理。

高校教学信息化建设积累了丰富的业务数据，根据需求，教务数据分析功能主要包括三大类：教学任务、学生成绩和教学评价。图3为教务数据分析数据源视图，围绕教师的教学工作量、学生取得的成绩以及学生对教师的评价等，我们做了一系列的报表。例如：教学场地信息、学生情况、任课教师情况、各学期教学任务情况、成绩信息、教学评价、历年各专业招生人数、各学院历年教学情况、各学院历年学生对教师评价。

另外，为满足各二级学院要求，做了学业预警方面相关报表，各二级学院可根据年级、专业，通过总学分排行、课程门数排行来关注排在后面的学生情况。

数据分析表明，教师平均教学任务逐年增多，教师总体比较年轻，平均年龄男教师比女教师高，年龄在30-39之间的教师平均课时最多。管理学院历年招生数比其它学院明显高出很多，其中财务管理专业的学生数百分比最高。我校学生的成绩也完全符合正态分布曲线要求。

四、结束语

大数据分析是一种发展趋势，我们目前也仅仅就单项主题进行了逐个分析，如果把这些主题串起来，进行关联分析，将会得出更有趣更有价值的结果，这也是将来我们努力的方向。

参考文献：

[1]戴红芳，冯翔，先晓兵等.商业智能在校园一卡通中的研究与实践[J].微电子学与计算机，2012，29（7）：175-179.

[2]戴红芳.基于多维数据模型的校园卡数据分析[D].上海：华东理工大学，2011.

[3]陈启买，贺超波，刘海.基于OLAP的高校教学协同决策[J].计算机应用，2009，29（1）：304-305.

[4]魏金强，高磊，李晋宏.利用OLAP工具建立教务管理多维分析系统[J].北京工商大学学报（自科学版），2006，24（4）：29-32.

篇15：数据仓库工程师的工作职责

1、负责数据源导入、清洗、集成等工作，优化ETL流程并解决ETL相关技术问题;

2、负责参与数据模型体系构建及数据主题设计和开发，数据仓库和业务数据集市的建设;

3、负责数据集市需求调研和需求分析;

4、基于阿里云Maxcompute，进行数据开发工作。

岗位要求：

1、3年或以上数据仓库开发和模型设计经验;

2、深入理解DW，BI相关的知识，包括：ETL、数据仓库、OLAP、多维数据模型等;

3、熟悉MapReduce、Hive原理;

4、精通SQL，能够熟练使用HiveSQL进行数据开发;

5、具有良好的团队协作精神和沟通能力，较强的逻辑思维，学习能力和解决问题的能力，可承担较大的工作压力;

6、熟悉阿里云大数据开发平台优先，如Maxcompute;

篇16：数据仓库工程师岗位的职责概述

1、参与公司数据仓库基础平台的建设

2、参与数据建模及数据仓库应用产品的设计和开发。

3、参与数据仓库ETL流程的优化及解决ETL相关的技术问题。

4、通过专项分析，输出专项分析报告，为业务模块的决策和产品方向提供数据支持

5、通过市场细分、同期群分析或者AB测试来分析数据，根据数据变化定位产品的运行现状;

6、其他工作，参与完成各类分析报告、报表等其他指定的工作。

岗位要求：

1.本科以上学历，有三年以上互联网数据仓库设计和实现经验。

2.熟悉数据仓库各类模型建模理论，了解数据仓库数据分层架构，熟悉3NF和多维数据模型设计。

3.具备Hadoop、Hive、Hbase，Spark，Kylin等大数据技术处理经验，并具有开发经验者更佳。

篇17：数据仓库工程师的岗位职责表述

1、负责建设数据仓库架构，包括元数据管理、ETL调度、数据集成、OLAP等子系统的设计和开发;

2、搭建和维护数据仓库表，解决业务人员在仓库系统流程、工具使用、数据处理等遇到的问题;

3、基于对数据的理解和业务需求，对数据进行整理、分析和挖掘。

任职资格:

1、做事耐心,有强烈的责任心;

2、计算机,数学,统计学相关专业本科及以上学历，

3、熟悉主流的关系型数据库及MPP数据库，至少精通一门数据库，熟悉Gbase优先;

4、熟练使用SQL语言，具有2年及以上数据仓库、报表系统等ETL开发、维护经验;

5、熟悉Hadoop/Spark/Hive/Hbase等大数据技术者优先;

6、逻辑清晰、对数据敏感，良好的沟通能力和协作能力，敢于接受挑战，能够承受压力;

篇18：基于数据仓库的试验数据管理系统

试验数据是分析飞机系统性能的重要依据之一。各种试验数据往往存在着种类繁多、容量较大等特点,在对其进行分类、管理和查询时存在条件混乱、读取速度缓慢和无法对数据进一步分析等困难。因此,设计一套基于数据仓库技术的数据管理系统就显得极为重要。系统通过友好的人机界面来管理试验数据,同时还可更深层次地分析这些数据,生成如报表、图像等更加直观的数据形式,方便设计人员分析飞机系统性能。

1 数据仓库技术在构建系统中的应用

1.1 数据仓库

数据仓库综合和合并多维空间的数据。它是语义上一致的数据存储,它充当决策支持数据模型的实现,并提供使用者决策所需信息的手段。数据仓库也常常看做是一种体系结构,通过将异构数据源中的数据集成在一起构造、支持结构化或专门查询、分析报告和决策制定[5]。

1.2 多维数据模型

多维数据模型又称之为数据立方体。该模型允许从多维对数据建模和观察,一般由维和事实定义。维是保存记录的透视图或实体。每个维都有一个表与之关联,称为维度表,用于进一步描述维。通常,多维数据模型围绕中心主体组织。主体用事实表表示,事实是数值度量的。把它们看作数量是因为用户想根据它们分析维之间的关系[5]。

1.3 数据仓库模式的比较和选择

由于数据仓库下存储的数据为多维数据模型,所以实体-联系数据模型广泛应用于关系数据库设计,其中数据库模式由实体集和它们之间的联系组成。这种数据模式适用于联机事务处理。然而,数据仓库需要简明的、面向主题的模式便于联机分析数据。目前流行的数据仓库的数据模型是多维模型,常常以星形、雪花形和事实星座形存在。

星形模式通常包含大批数据且不含冗余事实表,外加一组维度为一的附表。这种模式下的维表类似星光一样围绕在中心事实表周围。雪花形模式是在星形模式下进一步变化,区别是某些维表可能是规范化的,这样可以把数据进一步分解到附加表中,构成类似雪花形的结构。这种表相对容易维护且节省存储空间。而本文所述系统属于事实星座形的结构。该结构的特点是需要多个事实表共享维表。因此,这种构成形式可以看作星形模式的汇集。它能对多个主题建模,使系统更加有效。系统维表的关系如图1所示。

2 数据管理系统的组成

该系统是基于TCP/IP协议,并采用C/S模式组成整个系统。其中,系统的S端(指sever服务器端)将飞行数据清理、集成、变换后按一定的格式和关系维度表导入数据仓库。系统的C端(指clinet客户端)可根据需求调用数据仓库中的数据。系统构架如图2所示。

3 数据管理系统的开发环境

3.1 数据管理系统开发工具

系统采用Lab Windows/CVI8.5+SQL Sever 2008为系统的开发工具。

Lab Windows/CVI8.5是一个完全的ANSI C的开发环境,用于仪器控制、自动检测、数据处理等应用软件。软件本身含有丰富的常用控件,利用交互式的开发平台、交互式的编程方法使功能强大、使用灵活的C语言与用于数据采集、分析和显示的测控专业工具有机的结合起来[2]。

SQL Sever 2008是当前最流行的数据库操作软件之一,基于标准化查询语言(SQL)。当前,数据信息存储爆炸式增长。在耗费相同系统资源的情况下,用户可存储更多的数据供用户使用。而且,用户可在大量的数据中更加快速地寻找到所需要的信息。

当用户在安装好Lab Windows/CVI8.5和SQL Sever 2008后,再安装SQL Toolkit数据库系统应用软件工具包。该工具包会提供相应的关于数据库操作的面板库函数。此时,用户再结合SQL语言,便可以实现系统对SQL Sever 2008中数据库连接、添加、修改和删除等一系列操作。

3.2 开发工具所解决的难题

通常情况下试验数据容量都比较大,用传统的文件指针方式对其进行读写,速度非常缓慢,甚至会出现死机或者内存溢出等错误。为解决这一难题,该数据管理系统利用批量导入数据的方法先将飞行数据导入数据仓库中,再利用SQL语句对数据仓库中的这些数据进行查询和读取,不仅很好地解决了死机、内存溢出等问题,还大大提高了系统读取数据的速度。

4 数据管理系统的主要功能

1)服务器端将试验数据清理、集成和变换后按照一定的关系和格式导入数据仓库中。

2)客户端提供友好的人机界面,用户可方便快速的查询数据仓库中所需要的数据。

3)用户可对查询出的数据进一步分析,包括生成函数图像;动态捕捉关键点数据;局部图像放大;数据图像预览、打印和保存等功能。

5 结论

本系统已在分析试验数据中得到了具体的应用。事实证明该系统操作简单、实用,处理数据的速度快,进一步分析数据的功能全,极大减轻了设计人员分析飞机系统性能时的工作负担,很好的提高了工作效率。

参考文献

[1]史君成,张淑伟,律淑珍.LabWindows虚拟仪器设计[M].北京:国防工业出版社,2007.

[2]王建新,杨世风,等.LabWindows/CVI测控技术及工程应用[M].北京:化学工业出版社,2006.

[3]谭浩强.C程序设计(第二版)[M].北京:清华大学出版社,1999.

[4]孙晓云.LabWindows/CVI的虚拟仪器设计与应用(第2版)[M].北京:电子工业出版社,2010.

[5]Jiawei Han,Micheline Kamber,范明,孟小峰,译.数据挖掘概念与技术[M].北京:机械工业出版社,2008.