① 数据ETL是指什么
对于做过 BI 开发的朋友，ETL 并不陌生，只要涉及到数据源的数据抽取、数据的计算和处理过程的开发，都是 ETL，ETL 就这三个阶段，Extraction 抽取，Transformation 转换，Loading 加载。
从不同数据源抽取数据 EXTRACTION ，按照一定的数据处理规则对数据进行加工和格式转换 TRASFORMATION，最后处理完成的输出到目标数据表中也有可能是文件等等，这个就是 LOADING。
再通俗一点讲，ETL 的过程就跟大家日常做菜一样，需要到菜市场的各个摊位买好菜，把菜买回来要摘一下，洗一洗，切一切最后下锅把菜炒好端到饭桌上。菜市场的各个摊位就是数据源，做好的菜就是最终的输出结果，中间的所有过程像摘菜、洗菜、切菜、做菜就是转换。
在开发的时候，大部分时候会通过 ETL 工具去实现，比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微软 sql SERVER 里面的 SSIS 等等，在结合基本的 SQL 来实现整个 ETL 过程。
也有的是自己通过程序开发，然后控制一些数据处理脚本跑批，基本上就是程序加 SQL 实现。
哪种方式更好，也是需要看使用场景和开发人员对那种方式使用的更加得心应手。我看大部分软件程序开发人员出身的，碰到数据类项目会比较喜欢用程序控制跑批，这是程序思维的自然延续。纯 BI 开发人员大部分自然就选择成熟的 ETL 工具来开发，当然也有一上来就写程序脚本的，这类 BI 开发人员的师傅基本上是程序人员转过来的。
用程序的好处就是适配性强，可扩展性强，可以集成或拆解到到任何的程序处理过程中，有的时候使用程序开发效率更高。难就难在对维护人员有一定的技术要求，经验转移和可复制性不够。
用 ETL 工具的好处，第一是整个 ETL 的开发过程可视化了，特别是在数据处理流程的分层设计中可以很清晰的管理。第二是链接到不同数据源的时候，各种数据源、数据库的链接协议已经内置了，直接配置就可以，不需要再去写程序去实现。第三是各种转换控件基本上拖拉拽就可以使用，起到简化的代替一部分 SQL 的开发，不需要写代码去实现。第四是可以非常灵活的设计各种 ETL 调度规则，高度配置化，这个也不需要写代码实现。
所以在大多数通用的项目中，在项目上使用 ETL 标准组件开发会比较多一些。
ETL 从逻辑上一般可以分为两层，控制流和数据流，这也是很多 ETL 工具设计的理念，不同的 ETL 工具可能叫法不同。
控制流就是控制每一个数据流与数据流处理的先后流程，一个控制流可以包含多个数据流。比如在数据仓库开发过程中，第一层的处理是ODS层或者Staging 层的开发，第二层是 DIMENSION维度层的开发，后面几层就是DW 事实层、DM数据集市层的开发。通过ETL的调度管理就可以让这几层串联起来形成一个完整的数据处理流程。
数据流就是具体的从源数据到目标数据表的数据转换过程，所以也有 ETL 工具把数据流叫做转换。在数据流的开发设计过程中主要就是三个环节，目标数据表的链接，这两个直接通过 ETL 控件配置就可以了。中间转换的环节，这个时候就可能有很多的选择了，调 SQL 语句、存储过程，或者还是使用 ETL 控件来实现。
有的项目上习惯使用 ETL 控件来实现数据流中的转换，也有的项目要求不使用标准的转换组件使用存储过程来调用。也有的是因为数据仓库本身这个数据库不支持存储过程就只能通过标准的SQL来实现。
我们通常讲的BI数据架构师其实指的就是ETL的架构设计，这是整个BI项目中非常核心的一层技术实现，数据处理、数据清洗和建模都是在ETL中去实现。一个好的ETL架构设计可以同时支撑上百个包就是控制流，每一个控制流下可能又有上百个数据流的处理过程。之前写过一篇技术文章，大家可以搜索下关键字 BIWORK ETL 应该在网上还能找到到这篇文章。这种框架设计不仅仅是ETL框架架构上的设计，还有很深的ETL项目管理和规范性控制器思想，包括后期的运维，基于BI的BI分析，ETL的性能调优都会在这些框架中得到体现。因为大的BI项目可能同时需要几十人来开发ETL，框架的顶层设计就很重要。
② ETL工具有哪些
几种 ETL 工具的比较(DataPipeline，Kettle，Talend，Informatica等)
四种工具的比较主要从以下几方面进行比对：
1、成本：
软件成本包括多方面,主要包括软件产品, 售前培训, 售后咨询, 技术支持等。
开源产品本身是免费的，成本主要是培训和咨询，所以成本会一直维持在一个较低水平。
商业产品本身价格很高，但是一般会提供几次免费的咨询或支持，所以采用商用软件最初成本很高，但是逐渐下降。
手工编码最初成本不高，主要是人力成本，但后期维护的工作量会越来越大。
2、易用性：
DataPipeline： 有非常容易使用的 GUI，具有丰富的可视化监控；
Kettle： GUI+Coding；
Informatica： GUI+Coding，有GUI，但是要专门的训练；
Talend：GUI+Coding，有 GUI 图形界面但是以 Eclipse 的插件方式提供；
3、技能要求：
DataPipeline：操作简单，无技术要求；
Kettle： ETL设计, SQL, 数据建模 ；
Informatica： ETL设计, SQL, 数据建模；
Talend：需要写Java；
4、底层架构：
DataPipeline：分布式，可水平扩展；
Kettle：主从结构非高可用；
Informatica：分布式；
Talend：分布式；
5、数据实时性：
DataPipeline：支持异构数据源的实时同步，速度非常快；
Kettle：不支持实时数据同步；
Informatica：支持实时，效率较低；
Talend：支持实时处理，需要购买高级版本，价格贵；
6、技术支持：
DataPipeline：本地化原厂技术支持；
Kettle：无；
Informatica：主要在美国；
Talend：主要在美国；
7、自动断点续传：
DataPipeline：支持；
Kettle：不支持；
Informatica：不支持；
Talend：不支持；
③ etl工具怎么把数据库里的表写入到文本文档里
如果没用专门的ETL工具，而是在数据库中使用SQL完成所有的etl任务，那么就需要创建DBMS表来存储所有的集结数据。
如果是用的ETL工具，那么可以在文件系统中使用简单的文件来存储集结数据。 当集结数据像数据库表那样按照行和列存储在文件系统中的时候，我们称之为平面文件或者顺序文件，ETL工具或者脚本语言可以像是操作数据库表一样方便的操作ASCII平面文件，而且某些情况下处理速度更快。
④ ETL基本常识是什么
对于做过 BI 开发的朋友，ETL 并不陌生，只要涉及到数据源的数据抽取、数据的计算和处理过程的开发，都是 ETL，ETL 就这三个阶段，Extraction 抽取，Transformation 转换，Loading 加载。
从不同数据源抽取数据 EXTRACTION ，按照一定的数据处理规则对数据进行加工和格式转换 TRASFORMATION，最后处理完成的输出到目标数据表中也有可能是文件等等，这个就是 LOADING。
再通俗一点讲，ETL 的过程就跟大家日常做菜一样，需要到菜市场的各个摊位买好菜，把菜买回来要摘一下，洗一洗，切一切最后下锅把菜炒好端到饭桌上。菜市场的各个摊位就是数据源，做好的菜就是最终的输出结果，中间的所有过程像摘菜、洗菜、切菜、做菜就是转换。
在开发的时候，大部分时候会通过 ETL 工具去实现，比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微软 SQL SERVER 里面的 SSIS 等等，在结合基本的 SQL 来实现整个 ETL 过程。
也有的是自己通过程序开发，然后控制一些数据处理脚本跑批，基本上就是程序加 SQL 实现。
哪种方式更好，也是需要看使用场景和开发人员对那种方式使用的更加得心应手。我看大部分软件程序开发人员出身的，碰到数据类项目会比较喜欢用程序控制跑批，这是程序思维的自然延续。纯 BI 开发人员大部分自然就选择成熟的 ETL 工具来开发，当然也有一上来就写程序脚本的，这类 BI 开发人员的师傅基本上是程序人员转过来的。
用程序的好处就是适配性强，可扩展性强，可以集成或拆解到到任何的程序处理过程中，有的时候使用程序开发效率更高。难就难在对维护人员有一定的技术要求，经验转移和可复制性不够。
用 ETL 工具的好处，第一是整个 ETL 的开发过程可视化了，特别是在数据处理流程的分层设计中可以很清晰的管理。第二是链接到不同数据源的时候，各种数据源、数据库的链接协议已经内置了，直接配置就可以，不需要再去写程序去实现。第三是各种转换控件基本上拖拉拽就可以使用，起到简化的代替一部分 SQL 的开发，不需要写代码去实现。第四是可以非常灵活的设计各种 ETL 调度规则，高度配置化，这个也不需要写代码实现。
所以在大多数通用的项目中，在项目上使用 ETL 标准组件开发会比较多一些。
ETL 从逻辑上一般可以分为两层，控制流和数据流，这也是很多 ETL 工具设计的理念，不同的 ETL 工具可能叫法不同。
控制流就是控制每一个数据流与数据流处理的先后流程，一个控制流可以包含多个数据流。比如在数据仓库开发过程中，第一层的处理是ODS层或者Staging 层的开发，第二层是 DIMENSION维度层的开发，后面几层就是DW 事实层、DM数据集市层的开发。通过ETL的调度管理就可以让这几层串联起来形成一个完整的数据处理流程。
数据流就是具体的从源数据到目标数据表的数据转换过程，所以也有 ETL 工具把数据流叫做转换。在数据流的开发设计过程中主要就是三个环节，目标数据表的链接，这两个直接通过 ETL 控件配置就可以了。中间转换的环节，这个时候就可能有很多的选择了，调 SQL 语句、存储过程，或者还是使用 ETL 控件来实现。
有的项目上习惯使用 ETL 控件来实现数据流中的转换，也有的项目要求不使用标准的转换组件使用存储过程来调用。也有的是因为数据仓库本身这个数据库不支持存储过程就只能通过标准的SQL来实现。
我们通常讲的BI数据架构师其实指的就是ETL的架构设计，这是整个BI项目中非常核心的一层技术实现，数据处理、数据清洗和建模都是在ETL中去实现。一个好的ETL架构设计可以同时支撑上百个包就是控制流，每一个控制流下可能又有上百个数据流的处理过程。之前写过一篇技术文章，大家可以搜索下关键字 BIWORK ETL 应该在网上还能找到到这篇文章。这种框架设计不仅仅是ETL框架架构上的设计，还有很深的ETL项目管理和规范性控制器思想，包括后期的运维，基于BI的BI分析，ETL的性能调优都会在这些框架中得到体现。因为大的BI项目可能同时需要几十人来开发ETL，框架的顶层设计就很重要。
⑤ 用SQL脚本写ETL
学好SQL就行了，DML/DDL. ETL可以用很多工具来实现，比如Shell, Perl, Informatica, Ab Initio等等, SQL本身的逻辑和处理工作就是ETL的过程. 如果是用SQL来实现ETL调度管理，可以先创建数据库表，然后，通过SQL实现Insert/Update/Delete来控制ETL脚本的被调度。
⑥ ETL抽取与SQL语句抽取比较
首先，使用SQL 语句可以代替SSIS在ETL中的大部分工作。
1、两者比较ETL的好处，基础入门简单，操作界面化，使用一个很复杂的SQL 完成一项工作时，这个时候用ETL就会比SQL 方便很多。
2、维护查看比SQL直观， 比如执行过程，SSIS可以很好通过界面去查看现在ETL的过程执行到什么状态。
3、SSIS日志方面本身比SQL完善。
4、SSIS工具本身性能会略优于SQL，同样的千万级数据用SSIS比SQL快很多。
5、你可以反过来想，SQL 一直都存在，那为什么还要在SQL之后专门搞一个ETL开发工具SSIS呢？
其实，在项目中可以根据需要将两者结合一起进行使用。数据量小、数据流程清晰可以使用SQL代替SSIS，如果复杂时数据量大还是用SSIS本身的插件好。
⑦ ssis是什么级别的etl工具市场占有率高吗
SSIS 是微软BI产品的ETL工具，占有率要比大众化hadoop的HIVE占有率低很多，这个就像是orcale和微软的sql server的占有关系差不多，如果你是才开始入门去学，能选择hadoop去学最好，就业方向宽广。
但是如果你已经入门了ssis，只是找一份工作还是容易的，而且从事SSIS方面的人要比上面人少很多，有时候待遇反而会更高。
我现在就是从事这方面的工作，对这个很有体会，之前参加很多面试都是需要hadoop的，但是面试ssis方面基本上能通过。
------------------------
sql server 2014，vs 2014 ，data tools 2014 ，SSIS SSAS SSRS都用