|
关键词：大数据、ETL、集算器 ETL（ Extract-Transform-Load），用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL一词常用在数据仓库，但其对象并不限于数据仓库。 大数据的痛点：抽取，转换，加载 伴随着大数据项目的频频产生，Hadoop、Hadoop、Hadoop，这个名词这些年天天都会听到。虽然企业部署Hadoop大数据系统的最终目的是为了有一个非常“性感”的分析应用，但是，结果通常是大多数企业建立起来的大数据平台距离这一目标还很远很远，甚至很多都是失败的。 根据IDC的Hadoop-MapReduce软件生态系统预测报告，Hadoop市场正在以60%的年复合增长率高速扩张。但是，同时该报告也揭示了一个有点儿惊悚的事实，作为大数据分析应用的代名词，流行的Hadoop其实与数据分析并无直接的关系。 实际上大多数采用Hadoop的公司都没有将Hadoop用于大数据分析，而是把Hadoop作为一种廉价的海量存储和ETL（抽取、转换、加载）系统。 451研究所的分析师Matt Aslett在Hadoop峰会指出，企业采用Hadoop需要经历三个发展阶段，从一开始用来存储海量数据，到对数据进行处理和转换，到最终开始分析这些数据。我们还处于Hadoop市场和技术生命周期的早期阶段，Rainstor的调查显示，即使是最高级的Hadoop用户，也认为Hadoop最大的挑战是时间（26%）和编程（25%）。根据Gartner的调查，目前只有6%的企业开始部署大数据项目，企业还需要更多成功案例指路，同时也需要更多时间消化相关技术。 目前确实有个别企业将Hadoop用于运行激动人心的分析工作，但这只是个案。Cloudera曾提出Hadoop的三大应用模式：Transform、Active Archive和Exploration，但是业内人士分析，目前至少有75%的部署Hadoop的企业还都只是停留在前两个模式中：将Hadoop作为廉价的ETL方案，或者用作垃圾数据填埋场。 ETL是每个大数据项目当中悄无声息的预约的沉默杀手。我们都很清楚自己到底需要利用大数据技术做些什么，但相较于将注意力集中在业务需求身上，现在我们首先得搞定Flume、Oozie、Pig、Sqoop以及Kettle等等。之所以面临这样的情况，是因为我们的原始数据往往处于冗余的、混乱的状态。 这个问题不够性感，但是却是大问题。解决这类问题没办法让你拿到诺贝尔奖，但却能够切实帮助到广大大数据技术用户。 大数据平台需要什么样的ETL? 大多数据仓库的数据架构可以概括为：数据源-->ODS(操作型数据存储)-->DW-->DM(data mart) ETL贯穿其各个环节。 从10年前的数据仓库到当前的大数据平台，ETL也需要与时俱进！ ETL作为传统数据仓库的底层技术组件，主要是服务于数据采集的，因此，一般数据流动往往是单向的，但在新的时期，我们需要拓展其概念的内涵，从ETL升级到交换，以适应更多的应用场景。 但在大数据时代，业务为王，技术为辅。 从业务角度讲，数据应用的日益丰富，不同平台、系统间相互大量数据交互成常态，仅满足于采集数据已不适应业务需要了。还需要能够为数据的目的端落地提供支撑，这就需要一个端到端的更适应业务需要的交换系统，而不是仅仅传统意义上的ETL系统。 从技术角度讲，未来大数据平台组件将异常丰富，相互之间的数据交换将是常态，必须要有个PaaS级的交换工具满足这种要求，这是个趋势性的东西。ETL做一定的扩展可以升级为兼具交换能力，两者有传承，可以实现平滑过渡。 从运维角度讲，无论是ETL，还是数据交换，管理的对象都是接口，升级ETL是最好的方案，很多企业采集的ETL工具存在交互的接口管理一塌糊涂的问题。比如繁多的FTP搞晕了运维人员，付出的运维成本很大。 大数据平台下的交换平台 交换平台除了传统ETL功能，分布式动态可扩展是必须的。特别强调以下几点：
在客户需求理解能力上是大多数公司难以项背的，客户大多数时候并不需要你的技术有多牛逼，快速解决问题就行，但此类产品经常陷入拼性能，列功能，强升级的场景，而忽视本质的东西。 任何一个点的需求即使要进行确认，投入的精力也是蛮大的，不全面考虑，死磕到底，最后吃亏的终将是企业自己， 一个小功能的缺失就可能导致ETL的效率的大幅降低，甚至可能推倒重来，留给运维团队的也将是无尽的痛苦。 常用的ETL工具 在传统的数据仓库项目中，大多会采用一些现成的ETL工具，如Informatica、Datastage、ODI ,OWB、微软DTS、Beeload、Kettle、久其ETL…… 这些工具的优点有：图形界面，开发简单，数据流向清晰； 其缺点：局限性，不够灵活，处理大数据量比较吃力，查错困难，昂贵的费用； 选择ETL工具需要充分考虑源系统和数据仓库的环境，当然还有成本。 在大一点的互联网公司，由于数据量大，需求特殊，ETL工具大多为自己开发，或者在开源工具上再进行一些二次开发，在实际工作中，一个存储过程，一个shell/perl脚本，一个java程序等等，都可以作为ETL工具。 在数据集成中该如何选择ETL工具呢？一般来说需要考虑以下几个方面： (1) 对平台的支持程度。 (2) 对数据源的支持程度。 (3) 抽取和装载的性能是不是较高，且对业务系统的性能影响大不大，倾入性高不高。 (4) 数据转换和加工的功能强不强。 (5) 是否具有管理和调度功能。 (6) 是否具有良好的集成性和开放性 ETL工作看起来并不复杂，特别是在数据量小、没有什么转换逻辑的时候，自己开发似乎非常节省成本。的确，主流的ETL工具价格不菲，动辄几十万；而从头开发无非就是费点人力而已，可以控制。至于性能，人大多是相信自己的，认为自己开发出来的东西知根知底，至少这些程序可以完全由自己控制。 就目前自主开发的ETL程序而言，有人用c语言编写，有人用存储过程，还有人用各种语言混杂开发，程序之间各自独立。这很危险，虽然能够让开发者过足编码的瘾，却根本不存在架构。 有位银行的朋友，他们几年前上的数据仓库系统，就是集成商自己用c语言专门为他们的项目开发的。单从性能上看似乎还不赖，然而一两年下来，项目组成员风雨飘零，早已物是人非，只有那套程序还在那里；而且，按照国内目前的软件工程惯例，程序注释和文档是不全或者是不一致的，这样的程序已经对日常业务造成很大阻碍。最近，他们已经开始考虑使用ETL工具重新改造了。 试想一下，你作为一个新人接手别人的工作，没有文档，程序没有注释，数据库中的表和字段也没有任何comment，你是不是会骂娘了？业务系统发生改变，删除了一个字段，需要数据仓库也做出相应调整的时候，你如何知道改这个字段会对哪些程序产生影响？ 过去，真正令人惊讶的是没有人会对使这链接更加无缝有太多的愿景。也没有哪家厂商愿意拿出一套无缝化处理方案来。 今天我们欣喜的看到有这么一家企业，在历经17年的默默辛苦工作下，给出了一个和好的解决方案。容我先卖个关子，暂时先按下这家企业的名字不表，先来看看他们的一个实际的案例吧。 【集算器助力某省信访局信访大数据】 Hadoop大数据平台是某省信访局2017年的重点项目，该平台以数据采集、数据存储、数据计算为中间件，下接信访系统、数据接口文件、外部数据等数据源，上接即席查询、统计报表、管理驾驶舱等数据应用，从而实现关键指标展示、社会治理预警、网络舆情分析等具体业务。 项目难点 该大数据项目是各省信访局的参照标杆和国家级项目的孵化器，其战略意义深远。但本项目在实施过程中存在着数据源多样，性能要求高、业务逻辑复杂等难点，具体如下： 1. 数据源多样 本项目数据来源各式各样，按业务渠道的不同，可分为信访系统、数据接口文件、外部数据；按数据类型的不同，可分为结构化数据（信访资源编目库、信访公共基础库）、半结构化数据（文件、Http流）、非结构化数据（信访图片、监控视频）。按访问接口可进一步细分，文件可分为日志文件、Excel文件、xml文件；Http流分为Json、 WebService；数据库分为支持ANSI新标准的Oracle、SQLSERVER，支持旧标准的MYSQL，以及非ANSI标准的HIVE（外部大数仓）。 非结构化数据可直接复制到平台的非结构化大数据仓库（HDFS），不存在难点。但结构化和半结构化数据要经过ETL加工过程，存储在结构化大数据仓库（HIVE）之后，才能被外部应用统一调用，这就要求ETL工具具备丰富的访问接口。现实情况是：大数据ETL工具（如Sqoop、kettle）接口有限，对日志和关系型数据库支持较好，其他数据源只能用高级语言访问（如JAVA API），或导入临时库再ETL（即LETL）。 数据源之间存在业务关联，比如资源编目库要根据公共基础库过滤，或者Excel文件要和数据库关联，符合条件的合法数据才会存入HIVE，这就要求ETL工具具备多数据源混合计算的能力。现实情况是：大数据ETL工具缺乏直接混算能力，只能用JAVA硬编码间接混算。 2.性能要求高 大数据平台的特点就是数据量大、计算量大、访问量大，性能自然是核心指标之一。在整个平台中，非结构化数据虽然占据95%，但这类数据只需以文件为单位原样复制，几乎没有计算要求。相反，HIVE中的结构化数据虽然只占5%，但这类数据需要以记录字段为单位进行计算，粒度比文件小得多，因此总体计算量反而占到95%。 不论即席查询还是统计报表，不论数据分析还是监控预测，所有的外部应用都要基于结构化数据进行计算。如果计算性能太差，无疑会大大降低用户体验，比如长时间的查询等待，比如延迟推送统计结果，或者只能查看预生成的死数据，有时还会造成系统崩溃。 采用HANA、Teradada或OracleTimesTen可有效提高性能，但投入成本是天文数字，而GreenPlum稳定性太差，不适合政府行业，这里都不做讨论。要想提高结构化数据的计算性能，切实可行的方法有三种：分布式计算、多线程计算、算法优化。 现实情况是：大数据计算工具（比如SPARK on Hive）拥有良好的分布式计算能力，但在多线程计算和算法优化上还做得远远不够。在单机多线程计算方面，大数据计算工具性能只有传统数据库（Oracle）的十分之一到五分之一。在算法优化方面，大数据计算工具一直在模仿传统数据库，而传统数据库的算法依据关系代数理论，自上世纪七十年代起就已经不再变化，优化空间早已走到尽头。 3.业务逻辑复杂 源数据ETL到大数据平台，大数据平台对外提供数据服务，这两处涉及到大量计算，部分业务逻辑比较复杂。 根据业务逻辑由易到难的程度，大数据ETL工具分别提供了SQL\存储过程\Perl\java等方法，工作量也按这个顺序由小到大排列。其中SQL\存储过程内置结构化计算函数，工作量不大，但后两者要自己实现底层函数，工作量比前两者大百倍。传统数据平台（数仓）之所以建设工期漫漫无期，主要就是因为后两者导致的。大数据ETL工具更多涉及半结构数据和多源混算，只能用Perl\java解决，因此工作量更大。 大数据平台对外提供十余种数据服务，每种服务包含几十（分析应用）到几百（报表应用）种不同的算法，其中业务逻辑较复杂的算法约占10%，典型的比如：根据信访态势、社会环境、网络舆情三方数据，先计算风险因素的变动趋势，再计算各种风险状态偏离预警线的强弱程度。此类算法在传统数仓中需用新标准SQL（比如支持ANSI2003的Oracle）实现。但大数据计算工具计算能力较差，尚达不到旧标准SQL，更加不支持新标准，只能用工作量巨大的JAVA代码实现。事实上，以往的大数据平台遇到复杂业务逻辑时，通常会把数据抽到Oracle中计算，这也是大数据平台华而不实难以落地的根本原因。 运用集算器的解决方案 数据源多样，性能要求高、业务逻辑复杂，这三大难点如同暗藏的冰山，一旦解决不好，就会使大数据平台这艘旗舰之作沦为泰坦尼克。为了规避风险顺利实施，项目组引入了集算器。集算器是针对大数据平台的优化利器，支持多样数据源，可提高计算性能，并降低复杂算法工作量，适合解决本项目的难点。 集算器在结构图中位置如下： 集算器解决方案的价值 1.支持多样数据源 集算器接口丰富，不仅支持日志和关系型数据库，也直接支持WebService和json流，以及MongoDB、HBASE、阿里云OTS这类NOSQL数据库，还有HDFS文件、elasticSearch全文搜索引擎。对于尚不支持的小众数据源，只需自行开发新接口就能直接计算，而不必导入数据库再计算，更不必用JAVA实现计算过程。 集算器支持直接跨库跨源的混合计算，不再依靠JAVA硬编码。不论单源计算还是混合计算，集算器都提供了一致的计算语法，无需为迁移切换做改变。 2. 提高计算性能 像其他大数据计算工具一样，集算器也支持分布式计算，但集算器的独到之处，在于多线程计算和算法优化。基于自主可控的多线程计算，集算器比其他大数据计算工具性能高50-100倍。基于新型离散数学理论，集算器对传统算法进行了大量优化，其计算性能超越传统数据库。 3.降低复杂算法工作量 对于半结构化计算和多源混算，其他大数据ETL工具需要硬编码完成，而集算器可直接支持，其中难度消弭无形，开发工作量因此大幅降低。 对于真正的复杂业务逻辑，由于集算器基于新型离散数学理论而构建，其计算能力强于新SQL标准，因此比Oracle或其他大数据工具更易实现。以往需要用JAVA实现的复杂算法，现在只需用集算器轻松解决，不仅比SQL更易书写，还具备分步调试的优点。 总结： 集算器如同破冰船，装备三大破冰利器：支持多数据源、提高计算性能、降低复杂算法工作量。有集算器的保驾护航，本项目的三座冰山被一一击破，大数据平台这艘旗舰之作才得以顺利航行。 说到这里大家可能已经猜出这家公司的名字了，那就是“北京润乾信息系统技术有限公司”。 |
|
|
来自： ICT_League > 《最佳实践》
