精华内容
下载资源
问答
  • 需求综合需求综合的含义是:收集并且理解所有已知的将会影响ETL系统的需求、现实和约束等。需求的列表可能会很长,但在开始ETL系统开发前,都已经收集到了表中。需求一:业务需求用户的信息需求。用户用于制定明智的...

    需求综合

    需求综合的含义是:收集并且理解所有已知的将会影响ETL系统的需求、现实和约束等。需求的列表可能会很长,但在开始ETL系统开发前,都已经收集到了表中。

    需求一:业务需求

    用户的信息需求。用户用于制定明智的商业抉择所需要的信息内容。因为商业需求直接驱动对数据源的选择以及选择的数据源在ETL系统中转换的结果。

    在项目支持业务需求定义期间,必须维护一个揭示关键性能指标的列表,以及业务用户需要研究某个关键指标为什么发生变化时,所需要的下钻和跨钻目标。

    需求二:合规性

    6df5d4a9d945f1984e4b5648bb3018c1.png

    合规性

    列出所有数据以及最终报表主题需要遵守的法律限制。列出这些数据输入和数据转换的步骤,需要维护“监管链”,现实并且证明最终报表是来自发布的数据源的原始数据。

    对于合规性,我工作还没有这方面严格的要求。

    需求三:数据质量

    202acd2e7cc0b0259e1e0b1ae834611d.png

    数据质量

    需要将那些已经知道的不中意的数据元素记录下来,是否与源系统达成共识以便在获取数据之前进行更正。

    列举数据分析期间发现的那些需要在ETL过程中持续监控和标记的数据元素。

    需求四:安全性

    2ff3e967f9bf0722d28003991d7eb540.png

    安全性

    1,对于大多数DW/BI小组来说,安全通畅处于时候考虑的位置且被视为负担而不受欢迎。

    2,应该将合规性列表扩展,使其包含熟知的安全和隐私需求。

    3,数据应该被限制发送给那些需要知道的那些人。

    4,物理备份也需要做安全性的检查。

    5,在需求综合期间,DW/BI小组应该寻求高管层的明确指示,指明DW/BI 系统的那些方面应该运用额外的安全措施。如果没有明确指示,也没有安全管理员参与的时候,使用最小扩散范围。

    需求五:数据集成

    80791652a01f7f989d10eb77235959b1.png

    数据集成

    1,对于数据集成来说,我们的最终目标是做出 企业的全景视图

    2,全面的数据集成很难实现,除非企业具有全面的、集中式的主数据管理系统(Master Data Management ,MDM)系统,即使有的话,也仍然可能会有一些重要的数据并没有进入到主 MDM 中。

    3,一致性维度意味着跨不同的数据库系统建立公共维度属性。一致性意味着对公共业务度量达成一致,公共业务度量包括跨不同数据库的关键性能指标KPI,只有这样,才能使用这些数据通过计算差异和比率开展数学比较工作。

    4,应当充分利用业务过程的总线矩阵建立一致性维度的优先列表,对每个总线矩阵的行进行标注,知明参与到集成过程中的业务是否有明确的执行需求。

    需求六:数据延迟

    af39662a0075e68b2d803063a84d8b46.png

    数据延迟

    1,标注每个需求,明确业务团体是否了解与他们特定选择相关的数据质量的权衡。

    2,数据延迟需求对 ETL 架构具有较大的影响。高效的处理算法、并行化以及强大的硬件系统可以加快传统的面向批处理的数据流,但是在有些情况下,如果数据延迟需求非常紧迫,ETL 系统的架构必须从批处理方式转换为微批处理方式或者面向流处理的方式。

    需求七:归档与世系

    9d4bd6fba2d4b8cf25504a3ba05516a6.png

    归档与世系

    1,每个数据仓库也都需要有以往数据的各种副本,要么与新数据比较以便建立发生变化的记录,要么重新处理。

    2,建议在每个ETL流水线的主要活动发生后暂存数据(将其写入磁盘):在数据被获取、清洗和一致化、发布后 暂存数据。

    3,那么什么时候将暂存转入归档,我喜欢将所有暂存数据归档。除非有专门的定义明确认为特定的数据集合将来不在需要。

    4,每个暂存/归档数据集合都应该包含描述来源和建立数据的处理步骤的元数据。按照某些合规性需求的需求,对该世系的跟踪是明确需要的,应该成为每个归档环境的一部分内容。

    5,应当记录数据源和归档的中间数据步骤以及保留政策、安全和隐私方面的约束。

    需求八:BI发布接口

    1,数据的内容和结构能够是BI引用简单而快速。以模糊的方式将数据推到BI应用是不负责任的表现,将会增加应用的复杂性,减缓查询或报表的构建,不必要地增加了商业用户使用数据的复杂性。

    2,列出BI工具需要的所有OLAP多维数据库和特定的数据库结构,列出所有您已经打算建立用于支持BI性能的已知的索引和聚类。

    需求九:可用的技能

    1,查清所在部门的操作系统,ETL工具,脚本语言,编程语言,SQL,DBMS以及OLAP技能,这样可以理解如何暴露出所缺乏的技能。

    2,列出需要支持当前系统以及未来可能有的系统的那些技能。

    需求十:传统的许可证书

    1,目前我们大多使用的是开源软件。还没有遇到许可证书的问题。

    2,列出现有操作系统 的许可证书,无论他们是独家使用授权还是仅仅被建议使用的情况。

    3,当打算更换目前的正在使用的许可证书时候,需要做出充分的准备。


    数据仓库-读书笔记一

    数据仓库-DW/BI架构对比-读书笔记二

    数据仓库-事实表/维度表技术-读书笔记三

    数据仓库-维度处理-读书笔记(四)

    数据仓库-高级事实表技术-读书笔记五

    数据仓库-高级维度表技术-读书笔记六

    数据仓库-零售业务举例维度模型设计4步骤-读书笔记(七)

    数据仓库-零售业务举例维度表设计细节-读书笔记(八)

    数据仓库-零售业务举例如何提高仓库扩展能力-读书笔记(九)

    数据平台建设整体思路阐述和总结

    数据仓库-零售业务中库存如何设计-读书笔记(十)

    数据仓库中如何使用缓慢变化维技术


    数据僧 (公众号,头条号,简书号)参考资料

    数据仓库工具箱

    展开全文
  • 我们知道ETL核心功能即是从数据源获取数据,经过清洗过滤、字段投影、分组聚合等各种运算然后汇聚到指定库表,然后提供给其他业务系统或者直接对接BI报表系统。常见的ETL工具有Kettle、Talend等。由于Kettle开源使得...

    我们知道ETL核心功能即是从数据源获取数据,经过清洗过滤、字段投影、分组聚合等各种运算然后汇聚到指定库表,然后提供给其他业务系统或者直接对接BI报表系统。常见的ETL工具有Kettle、Talend等。由于Kettle开源使得广泛应用在各类IT系统中,它能对接关系数据库、Excel、Csv等数据源,然后应用数据筛选过滤、增加字段、字段投影等组件功能写入目的地。

    大数据广泛应用的今天,需要处理的数据呈现爆发式增长,单纯数据源就可能来自公司IT系统,来源各类交易数据,用户行为数据,或者是来源于物联网各类传感器数据。海量数据对ETL处理系统提出了更高的要求。传统ETL工具已经很难胜任海量数据处理,没法做到分布式并行处理。

    传统ETL面临的难题:

    1. 以Kettle为例,数据接收、数据加工、数据写入都在同一进程内,虽然能够部署成集群模式,但同一个ETL作业它没法切分成小任务并行地运行在多个Kettle实例上。像Kafka这类天然需要并行消费的数据源,Kettle对其支持就显得不那么友好

    2. 传统ELT工具没有map-reduce支持,没有DAG优化,没办法支持海量数据的分布式计算任务。比如根据用户浏览行为统计热门商品,ETL工具需要根据商品Id把数据分配不同的计算节点,然后执行reduce汇聚得出结果。

    大数据平台ETL工具

    联想大数据平台LeapHD包括数据集成、离线计算、流式计算、即席查询、数据服务、数据治理等各类开发工具。ETL工具涵盖离线计算、数据集成和流式计算3个模块,其中离线计算基于Hive、Spark批处理引擎而开发的,数据集成和流式计算是构建在Flink之上的流式计算引擎而开发的。数据集成和流式计算共用底层公共逻辑。流式ETL工具支持从传统关系数据库同步数据到大数据平台,比如mysql、oracle、sqlserver、db2、postgre等,目的地支持hive、spark、hbase、hdfs、关系数据库等。同时也支持本机Excel、Csv文件同步,支持远程FTP/SFTP、AWS S3等系统同步数据到联想大数据平台LeapHD。流式计算引擎模块支持时间窗口、分组聚合、过滤清晰、字段投影、累积去重等各种丰富组件。

    基于Flink的ETL工具开发实践

    Hadoop普及加速了大数据应用落地,计算引擎由最初的map-reduce模型也逐渐过渡到以Spark、Flink为主的DAG内存式计算引擎。由于hadoop map-reduce只能应用的离线批计算,Spark Streaming微批处理模式不能在及时性和高性能做好调和,联想大数据平台LeapHD最终选择在Flink流式计算引擎上构建ETL

    1. 传统编码过程是根据业务需求逐行书写代码去实现它,最终以B/S、C/S模式交付给用户。完成编码后,我们把代码打包部署到Tomcat等应用服务器。应用服务器内运行的就是我们的ETL处理程序。但是Hadoop、Spark或者Flink他们都只能以JAR包的形式提交给它们运行,这个JAR包需要按照Hadoop、Spark、Flink API去编写数据源读取、数据加工处理、数据写入的代码,并且这个过程不能包含Web部分。意味我们需要把用户端的页面输入在应用服务器内接收并组成转换成flink-jar。当然不需要每次作业都生成flink-jar,而是一个flink-jar能处理所有的ETL作业流程,只是它们运行的参数不一样。

    传统B/S架构和基于Flink架构的ETL对比图 841072e8b645d25561c6b0b131e07ebc.png

    1. Flink采用Java编写,Java是强类型语言,所以Flink API都需要传递数据类型。在ETL工具对接数据源的时候,我们不能把数据类型硬编码到源码中,只能动态传递进去。Flink提供强大的类型推断功能以及在泛型擦除的时候也提供了方法重新动态注册数据类型。

    1. 我们知道不同的数据库有不同的数据类型。ETL从源端到目的端的导数过程中,我们很难准确判断用户期望的目标数据类型。比如在mysql中有的同学喜欢用字符'Y'、'N'来表示true、false,有的同学喜欢用1、0来表示true、false,有的同学喜欢bit来表示true、false,用户期望这类数据同步到hive都是布尔型。联想大数据LeapHD ETL在Web页面提供最佳的默认类型匹配,同时开放类型设置给用户选择,用户可以在任意步骤调整输入、输出数据类型。并且LeapHD ELT会一直记录数据源最原始的类型来解决数据源到Java类型,Java再转换到目的类型的信息缺失问题。比如用户把Mysql包括bit类型的字段数据迁移到另外一个mysql库。如果是新增表,它会自动识别需要创建bit类型字段,而非int、bool。 5c290c95245b859d60300f5719bae554.png

    联想大数据平台LeapHD ELT工具支持任意数据源、目的地和转换组件,增加一个源意味着您可以对接已有的数据处理组件、调用目的地组件。可以灵活可配置的类型转换,自动推荐最佳匹配类型。甚至您可以整库迁移数据到联想大数据或者其他第三方系统。使用联想流式ETL,可以把你大部分离线计算任务直接在迁移过程中完成计算,把以前T+1的计算变成近实时计算,用效率赢得机会,用数据驱动业务决策。

    展开全文
  • 其实对于这个议题,需要从客户需求本身说起,...如果我们能往前再进一步,很多时候,日志中心的建设,不仅仅为运维监控负责,也为业务运营负责,所以一个日志中心产品具备基本的大数据ETL能力是很有必要的。交代了...

    其实对于这个议题,需要从客户需求本身说起,比如在日志中心建设中经常碰到的业务拓扑分析,事务合并,关键业务链路追踪,或者业务数据统计分析等等,这么来看,也许超越了只是一个日志产品本身的边界范围,但其实日志中心和大数据中心建设很多时候是如此的接近,如果我们能往前再进一步,很多时候,日志中心的建设,不仅仅为运维监控负责,也为业务运营负责,所以一个日志中心产品具备基本的大数据ETL能力是很有必要的。

    交代了大背景,我按照数据清洗端分为两大类:

    1、采集客户端ETL

    这个作为`传统`的日志产品的常见手段,比如filebeat7.x开始支持javascript做一些简单的数据清洗动作了,在比如阿里的日志服务产品logtail的基本数据清洗工作也是在客户端完成的,包括七牛logkit也是这么做的,当然除此之外,比如logstash的filter也支持部分数据清洗转换动作在服务端进行,其实总结下来,客户端做清洗,分担了服务端压力,提高了整体系统处理能力,时髦点讲,和目前的边缘计算沾边,把部分计算逻辑转移到离数据最近的地方,特别对于比如在银行或者金融客户中常见的事务日志合并场景有特别优势,具体案例详见:点击

    • 优势:
    提高了系统数据处理吞吐能力,分担了日志系统服务端压力。
    由于离数据更近,对于日志事务合并等要求数据顺序的场景,更易处理。
    • 劣势
    客户采集端过重,升级不方便。
    不支持分布式数据处理,只支持`单行`日志处理分析

    2、服务端ETL

    对于服务端做ETL,很明显和客户端的优劣势相反,离数据更远了,对于要求数据顺序的计算场景有时显得有点有心无力,同时对于日志海量数据全部集中到服务端来处理,对于服务端压力是巨大的,然而,在一些关联计算,全景业务链路分析等分布式计算的场景,自然是服务端ETL的天下,抛开业务本身,再回归到ETL技术本身,因为我们面向的是log/metric/trace的数据,更多是时序流式数据,我也做了一些相关技术框架的选型,大家也可以结合市面上的一些商业产品来看看,比如阿里日志产品,听闻背后olap引擎采用的时prestoDB,etl部分是采用python开发的dsl+微任务调度的方式,其实sls产品可以对接Flink/Strom等外部计算框架,但单论他们ETL功能来看,我不敢苟同,适用单日志事件的处理,对于多行日志或者window的场景无能为力,而日志易+七牛,背后都采用了Spark作为数据预计算的框架,而七牛更是把pipeline产品化了,比较接地气,最后再说到Splunk/Sumologic等厂商,由于拥有一套强大的spl,在产品层面上没有过多强调ETL步骤,很多数据ETL的工作都融于到SPL里了,不得不说强大啊,但背后猜测应该是olap+微任务+数据缓存吧。

    3、ETL框架

    下面就这块来列举一些常见的处理框架和大家分享一下:

    1、Flink job + sql

    2、Spark streaming + sql

    3、Kafka stream + ksql

    4、apache NIFI/StreamSets/product-sp

    5、airflow etc

    以上的一些技术框架,都是作为大数据领域的一些比较知名的数据处理工具,有针对流计算,也有针对批计算的,同时也有一些已经集成的比较好的数据流工具,但大致上我把他们分为两类,实时ETL和离线批计算,而且以上的工具我都有尝试使用过,而Flink/Kafka/product-sp使用得比较多,目前关于sql体系下并没有比较体系化可视化的集成工具,需要企业根据自己的需求去开发,但从目前调研的结果来看,使用sql来做数据开发能覆盖80%的场景业务需求,还有一部分工作需要写udf/udaf/mr来实现,但即便如此,开发一套完整的可视化的web ide是很有必要,目前Flink被很多公司尝试过,但由于官方缺乏一个rest gateway的sql交互方式,业界基本都是hack的实现方式,比如flinkStreamSQL sylph 等,Spark/Kafka对于这种提交job以及开发connector的支持上就相对简单了,官方也提供了比较好的rest api,Flink roadmap上说尽快支持,但如果论轻量级上来看我觉得kafka stream + ksql更合适,也可以参考下Landoop开源方案,对于希望能快速拥有一个不错的ETL框架的用户来说,ksql是一个不错的尝试,如果希望是生产环境,对性能和稳定性有更高要求,可以使用Flink/Spark,业界也提供了一些带有一站可视化的解决方案,商业化方面可以参考下阿里实时计算产品。

    说完了Sql实时ETL方案,再来说下可视化pipeline的ETL方案,目前NIFI/Wso2+StreamProcess/StreamSets等提供了比较成熟的DataOps支持,都提供了丰富的插件,以及可拖拽的数据流程开发视图,这里我重点说下Wso2的product-sp产品,作为wso2的流数据处理开源产品,它集成了siddhi 类库,并借助kafka提供了分布式运行时环境,支持多数据中心的数据处理,同时集成了丰富的插件,也允许用户开发自己的插件,笔者也花了一些时间研究过他的源码,整个架构+代码还是很漂亮的,同时也拥有不错的性能和稳定性,如果非得说一些问题就是大量依赖并使用了自家osgi框架来做模块开发,导致想要完整把项目run起来,真是费了不少时间,而且调试和二次开发成本都比较大,但正是由于使用了osgi,才使得整个工程有很大的灵活性和可扩展性,有可能正是这个原因,才导致在市面上的普及度不是很高吧,但它背后siddhi类库作为cep的经典实现也功不可没,而且cep作为像日志这种复杂的数据结构,或者在一些复杂规则的计算场景,正是它的用武之地,大家也可以发散一下flink+cep的搭配会产生什么,其实目前flink在cep这块支持度并不好,开源社区也有flink+siddhi的一些尝试,大家感兴趣的话可以去看下。

    上面两种更多都是一些实时ETL的方案,但还有一些场景是离线计算的场景,更多的侧重点是讲究DAG+调度,业界也有很多对应的方案,比如刚晋升apache顶级项目的airflow,还有国内EasyScheduler都是这方面的方案。

    其实讲了这么多,再回到日志的话题上来,对于非结构化的海量时序数据来说,客户端ETL+服务端ETL相互结合,客户端轻,服务端重,如果对于数据计算不是非常重的业务场景,可以配合ksql做一部分计算,毕竟是预计算,背后再结合olap引擎,基本上可以满足大部分的业务计算,对于一些比较重的关联计算报表场景,搭配airflow等dag调度框架吧,总之,技术框架我都摆在这儿了,知识量还是比较大的,很多点往里深入都能挖出很多东西,各位看官请结合具体场景和自身能力选择便是。

    这些只是自己研究ETL的一部分,更多的一些实操会陆续分享出来,可以关注联系微信:vip13486111091,一起来交流,也可以关注NoFootBird公众号找到我。

    展开全文
  • 从流程上可能似乎没什么问题,但用过开源ETL的都懂,这个反馈处理需要付出无法预估的时间成本。但如果商业智能BI自主研发专用ETL,主动权掌握在用户手里,问题的发现、解决效率都将获得极大的提升。商业智能BI自带...

    a81233f3244ba401cde51ec0c1483f53.png

    一般的商业智能BI软件习惯运开源ETL,但随之而来的却是后续服务的滞后性。如当出现问题时,用户需将bug反馈到开源社区,等待对方处理。从流程上可能似乎没什么问题,但用过开源ETL的都懂,这个反馈处理需要付出无法预估的时间成本。但如果商业智能BI自主研发专用ETL,主动权掌握在用户手里,问题的发现、解决效率都将获得极大的提升。

    商业智能BI自带ETL将更利于个性化开发

    随着企业发展,分析需求也会有所变化,因此一款实用的商业智能BI软件不仅要满足眼下的数据分析需求,更需要具备良好的个性化开发能力,而自带ETL的商业智能BI无论从操作还是效率上来说都更利于企业做个性化开发。

    f547f83098170f65840b6909923d5cf7.png

    商业智能BI报表效果截图

    奥威BI一直包含一个自主研发的、简单而强大的ETL工具,这样用户无须采取第三方开源ETL工具来进行数据仓库的构建。使用第三方开源ETL工具构建数据仓库,表面上不需要付出货币成本,但因为与BI是两套不同的系统,一旦数据不准,就需要反复在两套系统中进行校验核对,而且,一旦开源的工具有bug,需要反馈到开源社区,无人负责,这样,将会给用户带来巨大的维护成本与风险。奥威BI商业智能BI软件实现了ETL全面可视化:每一个节点的任务定义,来源表与目的表的匹配,任务的流程定义,运维的日志等,都可以可视化,极大的方便了开发人员,从而提高开发与运维效率。

    奥威BI:具备基础SQL能力即可快速完成ETL开发

    与奥威BI系列其他商业智能BI软件一样,奥威BI自主研发的ETL工具操作难度低,响应快。用户只需具备基础SQL能力就能快速完成ETL开发。同时奥威BI系列的商业智能BI软件还可直接搭配预设对接各主流ERP的ETL方案,甚至能做到零开发。

    目前奥威BI已针对主流ERP,如金蝶、用友等制定标准化数据分析解决方案,同时也为不同行业量身打造系统化数据分析模型,基本满足80%通用行业需求。

    展开全文
  • ETL ETL模块:统一调度管理、统一监控管理、ETL出错管理、ETL回溯处理等。 ETL设计原则:模块化的系统。将管理控制类模块与具体数据模块严格分开。统一的调度与管理。高效的ETL加载策略。安全的数据管理与用户管理。...
  • 什么是数据同步工具(ETL、ELT)数据同步工具ETL或者ELT的作用是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程,目的是将企业中的分散、零乱、标准不统一的数据整合到一起,为企业的决策提供分析依据。...
  • 不了解BI的企业经常会有这样的疑问:别人家的报表分析为什么分分钟便能做出可视化的效果?看着也就就几张图表啊。为什么自家做报表分析在视觉效果上就不如人家?于是紧跟时代潮流也上线了某BI产品,视觉效果是有了,...
  • 3、明细数据 针对明细数据,需要更加谨慎 明细数据会让业务同学无所适从,养成什么数据都想看,看了却不知道干什么的境地,无形中增加了双方的工作量。对明细数据要深入聊业务方的具体需求,想要做什么最终实现,...
  • 3、明细数据 针对明细数据,需要更加谨慎 明细数据会让业务同学无所适从,养成什么数据都想看,看了却不知道干什么的境地,无形中增加了双方的工作量。对明细数据要深入聊业务方的具体需求,想要做什么最终实现,...
  • 想分析什么,想分析哪些数据,数据间有怎么的关联关系,这些我们自己都知道,就想要在BI报表平台上开发出最适合自己的BI报表。问题是,这些BI报表工具能不能支持用户自行开发BI报表,如果支持的话有没有什么要求限制...
  • ETL什么鬼???来自百度(ETL,是英文Extract-Transform-Load的缩写,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。) 第二、数据仓库建模能力,具有大中型数据仓库...
  • ETL

    2018-03-07 15:06:00
    ETL是做什么的?ETL是建立数据仓库是数据抽取转换加载的过程。ETL工作的实质就是从各个源数据表中提取数据,对数据进行转换,最终加载填充到数据仓库维度建模后的表中的一个过程。只有当这些维度/事实表被填充好,ETL...
  • 没有压力的维度建模》以及《报表自动化: 薅出数字背后的价值》两篇文章分别提及了维度建模中的事实、维度,以及指标三种表,那么他们之间具体有什么关系呢?前面都零星提到了一些,现在让我们来具象化的了解一下这...
  • ETL 过程中常常会涉及到数据库的数据,正常的 ETL 过程应当是 E、T、L 这三个步骤逐步进行,也就是先清洗转换之后再加载进数据库,最后在数据库中的只是合理的结果数据。但是,E(清洗)和 T(转换)这两个步骤中会...
  • ETL技术入门之ETL初认识

    千次阅读 2019-01-16 20:38:05
    ETL什么 ETL是Extract Transform Load三个英文单词的缩写 中文意思就是抽取、转换、加载。说到ETL就必须提到数据仓库。 先说下背景知识: 信息是现代企业的重要资源,是企业运用科学...
  • 数据仓库之ETL

    2017-08-29 19:26:07
    ETL什么 ETL是Extract Transform Load三个英文单词的缩写 中文意思就是抽取、转换、加载。说到ETL就必须提到数据仓库。 先说下背景知识: 信息是现代企业的重要资源,是企业运用科学管理、决策分析的基础。...
  • ETL技术入门之ETL初认识,数据仓库

    千次阅读 2017-11-08 17:01:18
    ETL,是英文 Extract-Transform-Load 的缩写,用来描述将数据从来源端经过抽取(extract)、转换...ETL是Extract Transform Load三个英文单词的缩写 中文意思就是抽取、转换、加载。说到ETL就必须提到数据仓库
  • ETL什么 ETL是Extract Transform Load三个英文单词的缩写 中文意思就是抽取、转换、加载。说到ETL就必须提到数据仓库。 先说下背景知识: 信息是现代企业的重要资源,是企业运用科学管理、决策分析...
  • ETL面试题

    2020-08-07 17:24:39
    数据质量检查的四大类是什么?为每类提供一种实现技术。 答:数据质量检查是ETL工作中非常重要的一步,主要关注一下四个方面。 1.正确性检查(Corret) 检查数据值及其描述是否真实的反映了客观事务。例如地址的...
  • 一味的解释 数据仓库 概念可能没意思,我们从不同角色出发吧 老板:我是一家手机公司的老板,今天要向去董事局汇报,我要准备一份介绍过去三年的用户增长、用户留存、用户活跃度、手机里面每个APP使用率等情况的...
  • ETL]渐变维度Slowly Changing Dimension及其处理方法 收藏 渐变维度Slowly Changing Dimension及其处理方法 要讨论什么是渐变维度或者缓慢变化维度就要先说说什么是维度虽然经常挂在嘴边的词但解释起来确实有难度更...
  •  数据质量检查是ETL工作中非常重要的一步,主要关注以下四个方面。 1.正确性检查(Corret) 检查数据值及其描述是否真实的反映了客观事务。例如地址的描述是否完全。 2.明确性检查(Unambiguous) 检查数据值...
  • 介绍:  Kettle简介:Kettle 是 PDI 以前...Kettle这个ETL工具集,它允许你管理来自不同数据库的数据,通过提供一个图形化的用户环境来描述你想做什么,而不是你想怎么做。Kettle中有两种脚本文件,transformation和j
  • 1. 五种主流的大数据架构1.1 传统大数据架构之所以叫传统大数据...可以看到,其依然保留了ETL的动作,将数据经过ETL动作进入数据存储。 优点:简单,易懂,对于BI系统来说,基本思想没有发生变化,变化的仅仅是技术...
  • 我们平时提到的0维的点,一维的线,二维平面,三维的立体空间已经挺复杂了,撇开不提,我们看看BI领域的维度是什么意思。 个人的理解,维度就是观察数据的不同角度。比如有一个魔方,我们从一个面看是...

空空如也

空空如也

1 2
收藏数 38
精华内容 15
关键字:

etl什么意思