2. 上海大学-上海城建建筑产业化研究中心, 上海 200072
2. Shanghai University-Shanghai Urban Construction Group Research Center of Building Industrialization, Shanghai 200072, China
城市基础设施管养是指充分利用信息化和大数据技术对城市道路、桥梁以及隧道等各类市政设施进行智慧化管理和养护, 它涵盖了交通建设运营、设施设备管理、项目资产巡检以及养护合同收益等多项业务。随着智慧城市建设的推进, 城市基础设施管养精细化的需求日渐突出, 海量历史和实时数据需要有效的大数据技术进行融合, 才能为决策分析提供有力的支撑。运维大数据涵盖了视频、文本、流数据、建筑信息模型(Building Information Model, BIM)和地理信息系统(Geographic Information System, GIS)等多种数据组织形态, 具有数据维度高、形式多样化以及价值密度低的特征, 数据变化迅速、时空性和冲突性都比较强。既有的平台虽然在一定程度上实现了状态监控和故障记录等功能, 但由于缺乏有效的大数据融合技术, 数据融合效率低下, 同时导致数据统计和决策分析性能较差[1]。如何通过大数据融合方法把数据转换为信息和知识成为实现智慧管养的主要瓶颈。
国内外针对大数据融合方法的研究主要聚焦于抽取-转换-加载(Extract-Transform-Load, ETL)建模与ETL架构设计。文献[2]提出可编程和可扩展的ETL框架以支持ETL转换重用, 但在缺乏GUI的建模环境下以编程方式自定义ETL流程的开发过程效率较低。文献[3]提出基于模板的ETL开发方法, 它允许导入来自源或目的端存储的元数据, 添加映射或缓慢变更维度定义, 并生成可执行的ETL包, 有助于减少数据仓库各阶段的开发和维护工作。文献[4]提出基于ETL元数据模型批量更新数据仓库表的方法, 通过避免数据源未发生改变时产生不必要的负载, 减少数据仓库系统资源的消耗, 但其缺少对增量加载过程的考虑。文献[5]提出基于脚本技术的自动化ETL流程以减少ETL手动运行任务。文献[6]提出基于模型驱动架构的方法, 开发了基于多代理模式的ETL过程以整合外部数据到数据仓库, 并且自动地产生代码, 它们的局限性在于灵活性和可重用性较低。文献[7]以用户需求为中心引入端到端的ETL过程设计方法, 通过使用目标建模技术以提高ETL概念建模的抽象水平, 能较好地解决概念模型质量问题。文献[8]利用工具MaSSEETL设计了企业数据ETL和数据质量解决方案。文献[9]则设计了基于Web的ETL原型工具为用户提供完整的ETL流程指导, 但它们在处理大规模数据时会产生性能瓶颈问题。文献[10]通过使用Geokettle设计ETL情景并进行ETL建模, 将数据源中的属性与数据仓库表的属性进行映射, 有助于自动执行数据预处理, 并在插入和更新数据时不产生大量的查询。
目前, 大数据融合技术研究与应用领域主要为电信和邮政行业。文献[11]针对Teradata数据仓库设计ETL模型, 重点阐述了ETL实施流程中的ETL Automation无故障处理机制和异常处理机制, 但缺少基于ETL模型的数据融合的具体实现方法。文献[12]通过归纳自动化流程对ETL各类作业进行设计和命名规范, 具体实现了ETL功能, 但该方法无法适用于城市基础设施管养领域中具有多源、异构、时变和高维特征的数据融合。而城市基础设施管养领域内对于大数据融合技术的研究比较欠缺。许多既有的管养平台没有真正地将其各业务模块与大数据融合技术进行整合, 以实现管养智慧化。
因此, 本文对面向城市基础设施管养的大数据融合方法进行了探索, 并针对性地设计了数据仓库系统架构和数据融合ETL框架, 提出一种基于多层次任务ETL(Multilevel Task Scheduling ETL, MTS-ETL)框架的大数据融合方法。该方法将完整的ETL过程划分为ETLⅠ、ETLⅡ、ETLⅢ和ETLⅣ这四个层次, 并根据数据源不同的标准化程度分别设计了顺序工作模式和非顺序工作模式两种ETL工作模式。通过对ETL执行过程的概念建模、逻辑建模和物理建模, 实现数据源属性与数据仓库表属性之间的语义映射和ETL业务情景的定义; 最后利用Pentaho Data Integration实现了基于MTS-ETL框架的大数据融合方法。该方法的新颖之处在于, 根据数据仓库系统所划分的4个存储区划分ETL过程拆为4个层次的任务调度, 以提高ETL过程的容错性; 将异构数据首先放入数据临时区中, 再进行数据标准化操作, 以提高ETL抽取阶段的数据加载效率; 设计基于不同频率运行ETL任务, 允许用户根据业务访问需求确定ETL运行频率, 以提高ETL调度的灵活性; 将ETL面向的对象进行扩展, 代替传统的存储过程开发, 以提高ETL框架的适用性。
1 数据仓库系统架构为实现诸如设备统计分析和设施管养辅助决策这类商业智能(Business Intelligence, BI)分析业务功能, 必须通过数据仓库构建管养大数据的统一视图以支撑综合性的数据融合技术。数据仓库的特点在于高度集成与管理城市基础设施管养过程中产生的多源结构化或非结构化的静态数据、动态数据和实时数据。本文面向城市基础设施智慧管养需求, 设计了如图 1所示的由数据源、数据集成、数据仓库存储、元数据管控、用户访问框架、技术架构与环境以及基础设施平台所构成的数据仓库系统。
基于Hadoop分布式集群的数据仓库作为整个系统的物理实现部分, 分为数据临时区、数据仓储区、数据分类区以及数据分析区。其中:临时区存放各业务系统的源数据; 数据仓储区则针对数据整合和数据历史存储需求组织集中化和一体化的数据存储区域, 并覆盖多个数据主题域; 粒度最细的实时数据及时性要求最高, 因而数据分类区面向操作型分析, 存储粒度更为详细的实时业务系统多变数据; 而数据分析区则采取星型模型结构存储汇总数据。Hadoop所提供的Hadoop分布式文件系统(Hadoop Distributed File System, HDFS)可以为ETL提供技术支持, 而数据仓库管理技术Hive则可以对HDFS上的文件进行转换处理操作。由图 1可以看出, ETL作为数据源和数据仓库之间的桥梁, 确保数据能够进入数据仓库。
2 ETL框架设计 2.1 MTS-ETL框架ETL将日常业务操作的数据转化为数据仓库存储的决策支持型数据, 在逻辑上分为数据的抽取、清洗、转换以及加载四个过程, 其框架设计的好坏最终决定了数据仓库系统性能的高低。传统的ETL架构存在以下局限性:1) 将ETL包含在一个完整的过程中执行, 没有对ETL流程进行更加细粒度的划分;2) 缺少数据临时存储区域以存储来自异构数据源的数据, 当全量抽取或增量抽取的数据量很大时, 容易造成多源并发抽取的性能瓶颈, 加重数据仓库存储区的负担;3) 没有考虑数据源的数据频度、量级以及对业务访问的需求来确定数据抽取频率。这种传统的ETL架构不能很好地适应于基于管养业务需求所划分出的数据仓库四个数据存储区域。所以, 本文在对传统ETL框架进行改进的基础上, 结合城市基础设施智慧管养需求和数据仓库系统架构, 设计了如图 2所示的MTS-ETL框架, 其中圆角矩形表示ETL各阶段的执行任务, 矩形表示各阶段所存储的数据。
MTS-ETL框架设计的核心思想在于把整个ETL过程分为不同层次ETL任务调度和不同频率的ETL运行调度。如此改进后的MTS-ETL架构优点在于:1) 根据数据仓库系统所划分的数据临时区、数据仓储区、数据分类区以及数据分析区, 将完整ETL过程拆分为4个层次的任务调度, 每个存储区域都能够通过执行ETL任务对数据进行处理以组织所需的数据形态。而且由于数据源并不是一次性直接加载到数据仓库, 进行元数据管控、数据质量审计以及错误数据的定位与排查也相对容易。2) 将ETL的数据抽取、转换和加载分割开来, 将抽取到的大批量异构数据首先放入数据临时区中, 再进行数据标准化操作, 然后加载至数据仓储区和数据分类区, 提高了数据加载效率。3) 由于运维大数据的数据频度和不同数据类型的量级差异性均较大, 基于不同频率运行ETL任务相对于传统的ETL架构而言, 更加适应基于不同频率的数据分类和数据分析需求, MTS-ETL允许用户根据业务访问需求确定ETL运行频率, 因而MTS-ETL是面向用户需求的, 具有更大的灵活性。4) ETL对象并不限于数据仓库, 而是将ETL适用的范围扩展为由数据源到数据仓库目的端再到展示端数据库的过程, 具有更大的适用性。下面阐述MTS-ETL的四个任务调度环节:
① ETLⅠ负责异构数据源抽取并存放在数据临时区。数据源获取优先选择数据库直连方式, 即通过开放数据库互连(Open Database Connectivity, ODBC)或数据库Native连接方式, 直接连接到源数据库; 其次选择文件传输方式, 按约定的接口文件格式导出数据, 以文件方式批量传输数据; 对少量且实时性要求较高的数据采用企业应用集成(Enterprise Application Integration, EAI)方式, 通过EAI平台定义的接口服务进行传输; 而对于无源系统支撑的数据源采取手工录入方式。该阶段临时区数据与数据源基本保持一致, 且临时区存储的数据被处理后不会被保留, 其功能在于缩短多数据源融合时间, 减轻数据源和数据存储中心的负担。
② ETLⅡ是MTS-ETL框架的关键环节, 首先实现数据类型的标准化, 即尽量在源系统侧提升数据质量, 再做清洗和转换操作, 以方便后续数据校验。第二层次的核心工作在于对来自临时区的数据执行过滤、解析、修正、去重、分类、聚合、排序以及匹配等清洗和转换操作后装载入数据仓储区和数据分类区。其中, 数据仓储区采用3NF存储结构形成统一的数据模型, 而数据分类区则按不同粒度对数据仓储区的数据进行分类存储。
③ ETLⅢ负责将来自数据仓储区和数据分类区的数据进行汇总, 目的在于按照不同BI技术手段的功能定位进一步组织数据实体, 比如利用关键绩效指标(Key Performance Indicator, KPI)和固定报表满足决策层和管理层需求; 而实时查询、动态报表、联机分析处理(Online Analytical Processing, OLAP)分析用于实现数据的深层次多维分析。
④ ETLⅣ逻辑上不属于基本的ETL过程, 而是结合了管养平台自身特点和现实需求, 专门为各目标系统数据库而增设的处理环节。基于不同的粒度, 将数据仓库累积的数据增量装载至数据库, 以便于系统更加高效地调用融合后的数据, 从而支持多种数据可视化方案以及系统分析结果的展示与呈现。
MTS-ETL框架中不仅包含四个层次的ETL任务调度, 还包括多个频率的运行调度。ETL定时任务作为多频率运行调度中必不可少的环节, 取决于抽取各业务系统数据的频率程度(年、月、日、小时)。在默认情况下, MTS-ETL通过指定日期参数抽取数据源。
2.2 MTS-ETL工作机制MTS-ETL框架采用如图 3所示的分级与依赖机制, 分为以下三个步骤:
1) ETL参数初始化工作。主要配置资源库和运行目录等ETL参数文件, 其中ETL控制表记录了每个ETL工作流的运行状态和运行批次日期。如果ETL控制表有未执行完的流程, 则根据ETL控制表与配置参数生成运行所需的参数文件;否则还需要生成运行数据的批次日期。
2) ETL执行工作。从ETLⅠ到ETLⅣ依次执行各ETL目录内的工作流。
3) ETL收尾工作。等待工作流成功结束后更新ETL控制表状态, 并获取资源库和生成运行日志。
由于数据源的标准化程度不同, MTS-ETL框架设计了两种工作模式:顺序工作模式和非顺序工作模式。顺序模式如图 4所示。图 4中,Step 4的临时区目标表保存了与源系统一致的业务数据, 为数据加载进入数据仓储区作为临时存储数据, 临时区数据存储与源系统表名称保持一致, 增加源系统名称作前缀形式命名, 数据表采用增加LOAD_DATE标识方式区分不同时段的加载数据。
但是对于稳定的标准维度定义或者个别源表, 包括主要用于实时查询的字典表, 都可以通过逗号分隔值(Comma-Separated Value, CSV)文件格式数据直接装载入数据分类区, 该过程为标准的增量装载过程, 这种非顺序工作模式如图 5所示。图 5中,Step 3通过Mapping Group实现对于外键的代理键的匹配过程, Step 5根据数据源的字段比如XX_CODE等联合主键查询目标表, Step 6至Step 8描述了标准的增量装载过程, 对于变化的数据采取更新操作, 未发生历史变化的数据可以更新时间戳, 而新数据则在生成序列后插入目标表。
本节以通行流量主题为例来阐述数据仓库模型的设计。通过组建多维数据模型, 从各个角度分析数据, 得到通行流量的环比和同比、车型分类流量以及通行流量预测等信息。
数据属性选择包括:从项目基础数据中选择项目编号(PROJECTID)、公司编号(CORPORATIONID)和项目名称(PROJECTNAME)3个属性; 从区段数据中选择区段编号(SECTIONID)、区段名称(SECTIONNAME)、行车方向编号(DIRECTIONPKID)3个属性; 从通行流量数据中选择记录编号(RECORDID)、流量编号(IDX)、日流量(FLOWOFDAY)、区段流量(SECTIONFLOWS)、总流量(TOTALFLOW)、发生日期(OCCURDATE)6个属性。在此步骤, 通过流量事实表(FACT_DAYFLOW)、项目维度表(TB_PROJECT)、区段维度表(TB_SECTION)和日期维度表(TB_DATE)组成的星型模型来构建数据仓库多维方案, 其星型模式结果如图 6所示。
ETL概念建模旨在为ETL过程创建一个概念模型, 以描述数据源中的字段与数据仓库表中的字段之间的映射关系。流量数据是存储于数据库的完全结构化数据, 标准化程度和实时程度较高, 它不需要在数据仓库的数据临时区进行缓存。基于这种高度标准化的数据特征, MTS-ETL框架允许采取非顺序工作模式, 选择性地跳过ETLⅠ将异构数据源抽取并存放在数据临时区的环节, 而是从源数据库抽取数据并增量装载入数据仓库的数据仓储区和数据分类区。
非顺序工作模式的优点不仅在于降低了ETL抽取工作的开发难度, 同时提高了部分标准数据源的集成效率, 特别是MTS-ETL展示层对实时数据访问要求较高的情况下, ETL工作效率直接影响数据可视化和动态报表服务的性能。它与顺序工作模式的主要差别在于, 首先需要通过ETLⅠ将数据加载进入数据仓储区作为临时存储数据, 之后再从临时区加载所需数据到数据仓库表。
流量事实表(FACT_DAYFLOW)的概念模型如图 7所示。图 7展示了从数据库映射数据源的属性到数据仓库表。其中, 数据源为日流量表(T_DAYFLOW), 数据仓库表为流量事实表(FACT_DAYFLOW)。基于非顺序模式, ETLⅡ直接对来自源数据库的数据执行清洗和转换操作, 然后装载入数据仓储区和数据分类区。
日流量表和流量事实表之间的映射通过以下几个转换步骤实现, 具体包括数据字段选择、数据类型转换、数据的属性值映射与过滤、数据计算与排序、数据分组与聚合, 根据数据源编号等字段查询目标表以获取维度表的外键、映射字段以匹配流量事实表与数据源的字段, 以及将数据增量装载入数据仓储区的流量事实表中以形成统一的运营主题数据模型。数据分类区则会根据运营、管养、资产以及收益等分类将数据仓储区的流量数据存储到运营主题域中, 并且数据分类区的流量数据将会基于不同频率通过ETLⅢ进行汇总存储, 充分体现了MTS-ETL的多层次数据处理特点。概念建模是数据映射以及以后的ETL和前端的开发工作的基础, 下面将基于概念模型对ETL逻辑建模进行流程分解描述。
3.2.2 逻辑建模逻辑建模关注的是从数据抽取开始直到数据存储结束这一过程中从数据源到数据仓库的数据流, 它是概念建模的延伸。它将概念建模上的文字描述转换为逻辑建模符号, 并按照所抽取的数据和数据流逻辑组织转换流程, 以达到清洗数据的目的。流量事实表(FACT_DAYFLOW)的逻辑建模结果如图 8所示。
物理建模是根据逻辑模型对应到具体数据模型的机器实现, 以对真实的数据库和数据仓库进行描述, 所以需要为数据仓库表的每个属性明确物理模型的数据类型, 才能将转换的结果映射到数据仓库中的已存在的表中, 流量事实表(FACT_DAYFLOW)的物理建模结果如图 9所示。
图 9显示了流量事实表(FACT_DAYFLOW)的物理建模过程, 该过程与概念和逻辑建模中的转换过程一致。其中, 流量事实表(FACT_DAYFLOW)包含PROJECTID, SECTIONID和DATEID属性作为外键FK, 这些属性为字符串数据类型。其余的属性还包含数值类型的总流量, 以及字符串类型的流量信息编号、区段流量和流量发生日期。
4 基于MTS-ETL的数据融合方法实现本文使用开源的ETL工具Pentaho Data Integration来实现基于MTS-ETL框架的数据融合方法, 核心包括:转换模块(Transformation Module)和工作模块(Job Module)。Transformation Module完成针对数据的基础转换, Job Module则完成整个工作流的控制。
4.1 转换模块Transformation Module是基于MTS-ETL框架的数据融合方法的基础, 具体包含:引入数据源、引入目的数据源、开发中间转换以及引入增量全局参数等步骤。以第3章对流量事实表的ETL建模结果为例, Transformation Module实现过程如图 10所示。
从图 10来看, Step1是使用表输入控件从数据库源中抽取数据, 数据源即日流量表(T_DAYFLOW), 这里采用增量抽取的方式, 参照系统时间(SYSDATE)抽取上月20号到本月19号的流量数据并进行了排序。Step 2是通过字段选择控件对基于使用星型模式创建的数据属性名称进行选择和调整, 该步骤可以将DATE属性的数据类型转换为日期类型, 而不需要的属性则可以被筛选掉。Step 3通过过滤记录控件过滤掉FLOWOFDAY为NULL的记录。Step 4的值映射控件用来计算字段前面步骤传递来的属性, 并映射出新的属性。Step 5通过JavaScript控件进行属性拼接。Step 6选择需要进行分组统计的属性名称, 执行聚合操作的前提是必须对数据进行排序以生成有效的数据流。Step 7进行分组, 同时将各区段方向的日流量值进行拼接。Step 8利用JavaScript控件首先将字符串类型的属性转换为整型, 接着计算各区段方向的日流量总和, 然后Step 9再通过创建字典的方式将各区段方向属性值和对应的日流量值进行匹配, 空属性赋值NULL并拼接上逗号分隔符后得到新的字符串。经过Step10的字段选择控件基本上就得到了数据仓库目标表所需的主要属性, 接着在Step11中基于不同分组从1开始生成编号。由于事实表需要每个维度的主键ID以及度量值, Step12至Step14使用数据库查询控件, 以获取每个维度表的主键ID, 维度表由项目信息维度表(TB_PROJECT)、区段信息维度表(TB_DISTRICT)和日期时间维度表(TB_DATE)组成。在获取每个维度的ID之后, 将属性从数据源映射到FACT_DAYFLOW的属性表还需要使用Step15的字段选择控件, 最后一步是使用插入或更新控件增量加载转换结果到数据仓库目标表。
4.2 工作模块Job Module用于控制和调度各个转换模块之间的执行顺序, 它还可以通过电子邮件发送通知和写日志等, 如图 11所示。Job Module以START控件作为初始化来启动作业, 这里使用Pentaho Data Integration内置的时间调度方式设置Job Module执行定时任务, 作业启动后依次加载Transformation Module、LOAD_TIME、LOAD_PROJECT、LOAD_SECTION、FACT_DAYFLOW。若Transformation Module均成功执行, 则成功控件将显示执行成功; 否则将通过发送邮件控件发送通知, 接着通过设置变量和写日志控件将ETL运行记录写入资源库日志, 以便迅速查找错误信息和判别执行效率较低的Transformation Module, 从而进行定位优化。
本节的测试主要是验证MTS-ETL设计方案的执行效率和处理性能。下面通过将源数据库的2015年9月20号到10月19号的136754条交通流量数据抽取、转换并加载至数据仓库目标表, 以证明MTS-ETL的可行性。MTS-ETL测试结果可以在如图 12所示的执行结果面板的步骤度量标签中看到, FACT_DAYFLOW表生成3776行数据并且状态已完成, 这意味着整个转换成功执行且无任何错误, 且该方法融合136754条数据的时间仅为28.4 s。
为了对比不同数量级下传统ETL与MTS-ETL过程的执行效率, 证明基于MTS-ETL框架的数据仓库系统的高效性, 本文对千量级小规模流量数据融合进行了测试, 传统ETL和MTS-ETL的任务执行时间与测试数据量的关系如图 13(a)所示。当数据量小于5000条时, 传统ETL与MTS-ETL执行时间开销差别极小; 但随着数据量继续增加, 传统ETL执行时间随着数据量的增加而明显递增, 而MTS-ETL执行时间依旧维持在较低水平的增长率, 且其总平均执行时间开销比传统ETL降低了6.51%。为进一步证明MTS-ETL对百万量级的大规模数据依然具有稳定的融合性能, 本文对大规模流量数据融合进行测试发现, 400万条交通流量数据融合仅需349.5 s, 如图 13(b)所示的MTS-ETL任务执行时间与测试数据量的关系。
上海城市基础设施管养平台是集工程管理、资产管理、养护管理、收益管理和运营管理为一体, 能够为城市基础设施运维提供综合展示、管理分析、养护分析、运营分析以及报表分析等辅助决策信息的智慧管养平台。以实现流量报表分析服务为例, 通过基于MTS-ETL框架的大数据融合方法对上海嘉浏高速公路2012年—2015年约400万条的交通流量数据进行了融合与集成。
由于运维大数据的层次非常深且零碎, 会给数据库存储过程和触发器开发带来相当大的编写难度, 导致开发效率不高。MTS-ETL框架相对于传统ETL架构的优势在于:首先MTS-ETL是同时面向数据仓库和数据库的, 它将ETL架构从数据仓库端延伸到了平台展示层的数据库端, 通过ETL转换和工作模块取代大部分存储过程开发, 解决了存储过程对深层次数据统计和转换能力较弱的问题。其次, MTS-ETL是面向管养数据分析的, 传统ETL架构并没有对数据仓库系统目标区域作详细划分, 导致系统内部数据存储逻辑不够清晰, 而MTS-ETL根据数据仓库系统不同存储区域规划了ETL调度任务, 特别是针对不同主题域分类存储数据, 使系统具备更加快速响应的数据分析能力, 改善了ETL架构数据处理的性能。最后, MTS-ETL是面向用户需求的, 针对运维大数据形式多样化的特点开辟了数据临时区和两种工作模式; 并且针对运维大数据多频率的特点设计了四个频度的ETL运行调度环节, 增强了传统ETL架构的实用性。
基于4.1和4.2节的Transformation Module和Job Module开发, 通过Pentaho Data Integration从源数据库抽取数据并增量装载入数据仓库的数据仓储区和数据分类区之后, 接着在ETLⅢ进行数据汇总, 最后在ETLⅣ将数据分析区的数据抽取至报表数据库, 使得报表分析数据可以动态实时同步而不再需要二次处理过程, 如图 14所示的数据融合过程。
为了对城市基础设施智慧管养平台构建开源的ETL方案, 本文采用Pentaho Report Designer进行报表设计, 原因不仅在于它具有易于访问广泛的数据源和易于发布报表到Web端, 还在于它有易于导航的GUI和与插件, 比如使用Ctools组件生成平台报表所需要的图形和仪表盘。通过对流量报表进行设计, 再将报表部署到Pentaho BI Server上, 最后集成到平台报表分析模块后, 可以得到如图 15所示的上海嘉浏高速公路2015年度车流量报表分析结果。
本文面向城市基础设施智慧管养需求, 研究了大数据环境下的智能融合方法, 提出多层次任务调度ETL框架; 基于MTS-ETL框架下ETL工作模式, 详细阐述了数据融合方法的概念建模、逻辑建模和物理建模过程; 利用Pentaho Data Integration实现了数据融合方法并将其应用于上海市城市基础设施智慧管养平台, 为城市基础设施养护辅助决策分析奠定了基础, 为适应快速发展的养护管理工作和促进养护信息共享作出了贡献。未来工作重点在于, 研究支持半自动化抽取建筑信息模型(BIM)数据的ETL过程:利用基于本体的语义网技术构建BIM本体库, 通过识别与数据仓库模式相关的部分数据源模式, 半自动化地定义属性间的语义映射以支持抽取过程, 从而可以快速插入和管理新数据源。
[1] | ZHAO J, DENG W. Fuzzy multiobjective decision support model for urban rail transit projects in China[J]. Transport, 2013, 28(3): 224-235. DOI:10.3846/16484142.2013.829119 |
[2] | SILVA M S, TIMES V C, KWAKYE M. A framework for ETL systems development[J]. Journal of Information & Data Management, 2012, 3(3): 300-315. |
[3] | STUMPTNER R, FREUDENTHALER B, KRENN M. BIAccelerator-a template-based approach for rapid ETL development[C]//ISMIS 2012: Proceedings of the 20th International Symposium on Methodologies for Intelligent Systems. Berlin: Springer, 2012: 435-444. |
[4] | RAHMAN N, MARZ J, AKHTER S. An ETL metadata model for data warehousing[J]. Journal of Computing & Information Technology, 2012, 20(2). |
[5] | RADHAKRISHNA V, SRAVANKIRAN V, RAVIKIRAN K. Automating ETL process with scripting technology[C]//Proceedings of the 2012 Nirma University International Conference on Engineering. Piscataway, NJ: IEEE, 2013: 1-4. http://ieeexplore.ieee.org/document/6493217/ |
[6] | SADIQ A, FAZZIKI A E, SADGAL M. An Agent based ETL system: towards an automatic code generation[J]. World Applied Sciences Journal, 2014, 31(5): 979-987. |
[7] | THEODOROU V, ABELLÓ A, THIELE M, et al. A framework for user-centered declarative ETL[C]//DOLAP 2014: Proceedings of the 17th International Workshop on Data Warehousing and OLAP. New York: ACM, 2014: 67-70. http://dl.acm.org/citation.cfm?id=2666178 |
[8] | GILL R, SINGH J. An open source ETL tool-medium and small scale enterprise ETL (MaSSEETL)[J]. International Journal of Computer Applications, 2014, 108(4): 15-22. DOI:10.5120/18899-0190 |
[9] | NOVAK M, RABUZIN K. Prototype of a Web ETL tool[J]. International Journal of Advanced Computer Science & Applications, 2014, 5(6): 97-103. |
[10] | ASTRIANI W, TRISMININGSIH R. Extraction, Transformation, and Loading (ETL) module for hotspot spatial data warehouse using Geokettle[J]. Procedia Environmental Sciences, 2016, 33: 626-634. DOI:10.1016/j.proenv.2016.03.117 |
[11] | 王可欣. ETL技术在电信数据运营中的应用[J]. 电脑知识与技术, 2016, 12(24): 256-257. (WANG K X. Application of ETL technology in telecommunication data operation[J]. Computer Knowledge and Technology, 2016, 12(24): 256-257.) |
[12] | 张建兴. 中国邮政速递数据仓库系统ETL的设计与实现[D]. 北京: 北京交通大学, 2014. (ZHANG J X. Design and implementation of ETL for China post data warehouse system [D]. Beijing: Beijing Jiaotong University, 2014.) http://d.wanfangdata.com.cn/Thesis/Y2734973 |