本文正在参与「金石计划 . 瓜分6万现金大奖」
联系数据库供给了SQL，因而有较强的核算才干，但很惋惜的是，这个核算才干是关闭的。所谓核算关闭性，是指要被数据库核算和处理的数据，有必要事先装入数据库之内，数据在数据库内部仍是外部是很清晰的。与之相对，核算敞开性是指数据无需进入内部就能够直接处理多种来历的数据。
数据库有元数据，运用前要先定义表，数据要通过收拾满意束缚才干入库运用，关闭也就成了自然而然的作业了。反过来，什么样的核算才干是敞开的呢？数据在运用之前无需收拾就能够直接核算，没有任何束缚束缚，运用起来很灵敏。
现在有许多这样的敞开数据核算引擎，Spark便是比较闻名的一个。但esProc SPL更好一些，相对Spark不只更轻，代码完结也更简略，核算功用也更高。
SPL除了具有简练的语法和高核算功用以外，具有很强的敞开核算才干，不只能直接对接多种数据源核算，还能够进行混合核算。
那么核算才干敞开与关闭究竟哪种更具优势呢？因为SPL和SQL经常被一起比较，这儿咱们无妨从敞开性的视点来看看二者的不同，以及敞开性对数据运用体系建设本钱的含义。
处理多样性数据源直接核算
多样性数据源在现代企业信息化建设中非常常见，除了最常用的RDB，还有NoSQL、CSV/Excel、WebService等等。作为综合性质的数据分析，数据来历或许散布在多种数据源中，要运用就触及跨数据源核算。
SQL（数据库）在完结跨源核算方面体现较差，比如以DBLink为代表的跨库查询方案，不只稳定性和功率很差，还只能依据数据库。因而在实际运用中经常会将多源数据先统一再核算，行将其他数据源数据通过ETL导入同一个数据库再运用，这样就避免了跨源核算的问题。但这种方法也会带来一些问题，首要体现在三方面。
首先是数据实时性问题。假如数据需求通过ETL入库才干运用，数据收拾和入库都需求时刻，而且数据库写入是一个很慢的动作，这个进程的时刻损耗势必会导致数据的实时性差。除了时刻本钱，添加的这些进程就会添加开发本钱，究竟这些作业也需求人来完结。
其次是存储本钱。多源数据存储到一个数据库中要占用宝贵的数据库存储空间，添加存储本钱，增大扩容压力。事实上，许多数据并不需求持久化到数据库，尤其是一些暂时查询。而数据库的“关闭性”要求只有进来才干算，不存不可。
再次，无法运用多样性数据源本身的优势。咱们知道，之所以会出现多样数据源的状况便是因为各类数据源都有自己独特的优势，能在不同的运用场景下发挥作用。如RDB的核算才干较强，但IO功率较低，因而会承担更多的核算使命；NoSQL恰好反过来，IO功用高，并且能够选用多种/多层的动态结构非常灵敏，但核算才干往往较弱；文本/JSON等文件则彻底没有核算才干，但运用和办理愈加灵敏，也更容易施行并行核算提高功用。假如数据都统一到RDB中将无法再运用这些数据源本身的优势，导致运用本钱添加，一起也需求花费更多的硬件本钱来补偿同库带来的丢掉。
再来看SPL。
SPL具有更强的敞开性，供给了多种数据源支撑，这些数据源能够直接拿来运用核算。更重要的是，SPL还能够针对数据源进行连接混合核算。
支撑多样数据源（混算）今后，就能够节省“入库”带来的开发与时刻本钱，多源实时核算能够充沛保证数据的实时性，完结数据分库后的T+0查询也不再是问题。一起，数据不再无脑入库，数据库的存储本钱也将大大下降，扩容压力减轻。
SPL还能够充沛保存各类数据源的优点，RDB的核算才干较强，在许多场景下就能够让RDB先完结一部分核算后再由SPL接收；NoSQL和文件的IO传输功率高SPL就能够直接读取核算；MongoDB支撑多层数据存储，SPL直接运用会很便利…… 这些都将大幅节省人力与软硬件本钱。
延伸阅览： 多数据源混合核算用什么技能？
规避存储进程的坏处
运用SQL处理杂乱核算问题时，存储进程是常见的技能。运用存储进程将SQL进程化，将杂乱核算通过分步的方法完结，这样能够应对满意杂乱的核算场景。但存储进程的缺陷也很明显：没有移植性，不同数据库对存储进程的支撑程度不同，几乎无法进行移植，更难以进行扩展。而且存储进程难以开发调试，开发本钱也高。一起，多个运用共用存储进程还会造成运用间紧耦合，导致运用本钱添加。此外，存储进程还存在办理和安全性方面的问题，数据库的扁平结构无法像文件体系的树形结构办理存储进程，多了今后就会陷入办理混乱带来办理问题；存储进程的创立和修改需求较高的数据库权限，这就带来安全隐患，全体使得运营本钱添加。现在许多企业现已清晰制止运用存储进程了，由此可见存储进程的缺陷确实很难容忍。
那么如何处理这个问题呢？咱们稍加考虑就会发现，之所以运用存储进程是因为要凭借数据库的核算才干，SQL纵有千般不好，但总比Java这些高级语言简略乃至高效得多，因而依赖数据库成了自然而然的作业。假如在库外核算也能达到相同的作用，当然能够代替存储进程。将存储进程移到库外，运用SPL完结“库外存储进程”就能够处理这些问题。
SPL供给不依赖数据库的敞开核算才干，数据库更换不需求更改SPL核算脚本，处理存储进程的移植性问题；简练易用的IDE环境编辑调试功用齐全，算法完结愈加简略； “外置存储进程”不依赖数据库，可随运用寄存处理耦合性问题；凭借文件体系的树状结构进一步处理办理问题；SPL独立数据库运转，更不会带来安全问题。
因而，即便咱们放下存储进程的难写和功用低下（参阅： SPL 比 SQL 更难了仍是更容易？ ）的问题不谈，单从敞开性的视点来看，SPL就能够带来非常多好处。
延伸阅览：爱恨交加的存储进程该往何处去
消灭中心表削减不必要的数据库
数据库中心表一般是为了便利后续核算生成的中心成果，在数据库中以表的方法存储，即形成中心表。有的杂乱核算无法一步算完会先存储中心表再算，有时为了提高查询功用会事先将查询成果加工成中心表再用，前面提到的多样数据入库同样会形成中心表。中心表一旦创立往往很难删去，因为不确定这个表是否还有其他运用在用，因而会越积越多，有时竟高达数万张。中心表过多会带来容量和功用两方面的问题。
中心表存储需求空间，占用过多的数据库空间就会提高存储本钱，带来扩容压力；中心表过多也会带来办理困难，添加办理本钱；中心表的生成和维护都需求守时核算才干完结，即便中心表不再运用也常常因为不知道耦合联系而不敢删去，这些无用的中心表依然会消耗数据库核算资源导致数据库资源紧急，带来功用问题，提高硬件本钱。
其实，中心表之所以存储在数据库中是因为依然要运用数据库（SQL）的核算才干，因为中心表后续还要运用（核算），假如存成文件就只能（用Java）硬编码比较SQL要杂乱得多，因而会极度依赖数据库和SQL。
SPL具有满意的敞开核算才干，能够依据文件直接核算，这样中心表就能够搬到库外存储，再凭借SPL施行后续核算处理中心表的问题。
有了SPL的库外核算支撑，原本数据库中心表带来的各种问题就能得到有效处理。文件存储不再占用数据库存储空间，数据库扩容压力下降，数据库更便利办理；库外核算不再占用数据库核算资源，数据库减负能够更好服务其他事务。库外运用文件存储和SPL核算本钱更低。更进一步，运用SPL供给的高功用私有文件存储还能够大幅提高核算功用，下降硬件本钱。
延伸阅览：开源SPL消灭数以万计的数据库中心表
数据路由完结冷热分层
有时为了及时满意前端运用的数据恳求，会在贴近运用端建立前置数据库，将常用数据移到前置库中，由前置库负责核算，这样不只能够很好为运用服务，还能下降中心数据仓库的压力，可谓一箭双雕。
但运用传统数据库作为前置库时会遇到一些问题。因为前置库中存储的是少数较热数据，就无法满意运用查询全量数据的要求。假如把数据都从数据仓库搬出来放到前置库中，不只工程量巨大，还触及重复建设，本钱昂扬；但假如仅有部分数据，因为缺乏路由功用（无法识别数据位置）和跨库查询才干，就需求在运用端针对数据查询范围进行束缚，非常繁琐。
SPL不只供给了跨源（库）的核算才干，还支撑数据路由，能够用来充当时置数据库处理这些问题。
详细完结时，咱们将数据分为三层。极高频运用的热数据通过SPL加载到内存中，用于高速拜访和核算；高频运用的温数据选用SPL供给的高功用文件格式进行存储，运用时直接读取文件进行核算；而极少运用的大量冷数据依然存储在中心数据仓库中。SPL能够依据前端查询恳求将数据处理使命别离路由到数据所在地进行核算（SPL供给了相应SQL解析和转换功用），即热数据和温数据由SPL核算，冷数据由中心数据仓库核算，最后由SPL进行归并回来给运用端。这样大部分（高频数据）核算都由SPL来完结，只有少数查询会转发给中心数据仓库处理，不只处理了本来面对的数据查询范围问题，还能有效下降中心数据仓库的压力，前端查询体会更佳。
延伸阅览： 完结数据冷热别离用什么技能适宜？
处理HTAP需求
HTAP（混合事务和分析处理）期望通过一个数据库满意AP和TP两种需求，从根本上期望在满意TP的基础上还能够应对全量大数据查询，即T+0查询。不过，AP和TP两个场景有明显不同，这注定HTAP需求选用不同的技能完结。
当时依据数据库体系完结HTAP有两种方法，一种选用多副本的方法，多份数据选用行列不同方法来应对TP和AP的不同需求。另一种底层依然将两个场景别离，别离选用TP和AP范畴成熟的技能进行封装，一起规划统一的对外拜访接口。
不管选用何种完结方法，当时HTAP都会面对以下几个问题。
搬迁危险大本钱高。 假如本来的事务数据库不是（大概率）选用HTAP数据库就要触及数据库搬迁，这将面对巨大的危险和本钱。
无法取得多样源的优势。 现代事务体系触及的数据源种类许多，都要搬迁到新数据库非常不易，而且无法运用多样数据源本身的优势，这与咱们前面讨论的多样数据源问题一致。
功用不合格。 完结高功用只有列存是远远不够的，有些杂乱核算需求针对核算特色专门规划数据存储方法（比如有序存储、数据类型转换、预核算等）。简略“自动化”地行存转列存功用往往无法合格。
其实，咱们能够在原有独立TP和AP体系的基础上引入SPL，凭借其敞开的跨源核算才干、高功用存储和核算才干、灵敏开发才干来完结HTAP。
SPL通过与现有体系融合的方法完结HTAP，这样原有体系的改动很小，TP部分几乎不动，乃至原有的AP数据源也能够持续作业，逐步运用SPL接收AP事务。SPL部分或全部接收AP事务后，历史冷数据运用SPL高功用文件存储，本来针对事务库到数据仓库的ETL进程能够直接移植到SPL上。冷数据量大且不再变化运用SPL高功用文件存储能够取得更高地核算功用；热数据量小依然寄存在原有TP数据源中，SPL直接读取核算，因为热数据量并不大，直接依据TP数据源查询也不会对其造成太大影响，拜访时刻也不会太长。再运用SPL的冷热数据混合核算才干，就能够取得针对全量数据的T+0实时查询。咱们只要定期将变冷的数据固化到SPL的高功用存储中，原数据源只需求保持少数近期新产生的热数据即可。这样不只完结了HTAP，而且仍是高功用的HTAP，且对运用架构冲击很小。
延伸阅览： HTAP 数据库搞不定 HTAP 需求
循序渐进的湖仓一体
数据湖和数据仓库的联系很亲近但着眼点不同，前者更注重原始数据的保存和存储，而后者更侧重于核算。因而将二者融合在一起完结“湖仓一体”是个很自然的主意。
现在一般的做法是在数据湖上敞开数据拜访权限供数据仓库拜访，详细完结时需求在数据仓库中首先创立外部表/schema映射RDB的表或schema，或许hive的metastore，这个进程与传统的DBLink等数据库拜访外部数据的完结方法并无太大差别，缺陷非常明显。这仍是因为数据库的关闭性造成的，数据只有通过收拾、满意束缚后才干入库核算，这个收拾的进程就会导致大量原始信息丢掉，数据湖的价值损失。束缚束缚，体系关闭，不够灵敏是当时数据湖技能面对的首要问题。
假如数据库具有满意的敞开性，能够直接核算数据湖上未经收拾的数据，乃至能够依据多种不同类型的数据源混合核算，一起供给高功用机制保证核算功率那湖仓一体就能够很好完结了。
凭借SPL就能够完结这样的目标。
SPL能够针对数据湖的原始数据直接核算，没有束缚，无需入库。一起SPL还供给了多样性数据源混合核算的才干，不管数据湖运用统一文件体系构建，仍是依据多样性数据源（RDB、NoSQL、LocalFile、Webservice）运用SPL都能够直接混合核算，快速输出数据湖价值。此外，还能够运用SPL供给的高功用文件存储（数仓的存储功用），在SPL施行核算的一起，收拾数据能够镇定自若地进行，将原始数据收拾到SPL存储中能够取得更高功用。运用SPL存储收拾后数据依然寄存在文件体系中，理论上能够与数据湖寄存一处，这样就完结了真实含义的湖仓一体。
在SPL的支撑下数据收拾与数据运用能够一起进行，循序渐进地建设数据湖，逐步收拾，有序建设。还在建设数据湖的进程中就完善了数据仓库，让数据湖也拥有强核算才干，完结真实含义的湖仓一体。
延伸阅览：现在的湖仓一体像是个伪出题
综合来看，敞开核算体系的SPL能够带来愈加灵敏、高效、低运用本钱的作用，相对关闭的SQL（数据库）更有优势。
SPL资料
- SPL下载
- SPL源代码
