對(duì)RegisterDataFrameAsTable的分析

通過(guò)單個(gè) regiserDataFrameAsTable 項(xiàng)進(jìn)行分析，SparkSQL 并不是把source 的數(shù)據(jù)立即計(jì)算把數(shù)據(jù)放到內(nèi)存，而是每次執(zhí)行 source 時(shí)只是生成了一個(gè) Logical Plan，只有遇到需要提交的算子（Action），SparkSQL 才會(huì)觸發(fā)前面所依賴的的 plan 執(zhí)行。

總結(jié)

這是一個(gè)開(kāi)發(fā)框架，不是一個(gè)成熟的產(chǎn)品，也不是一種架構(gòu)。他只是基于 SparkSQL 整合了大多數(shù)的外部系統(tǒng)，能通過(guò) XML 的模板配置完成數(shù)據(jù)開(kāi)發(fā)。面向的是理解數(shù)據(jù)業(yè)務(wù)但不了解 Spark 的數(shù)據(jù)開(kāi)發(fā)人員。整個(gè)框架完成了大多數(shù)的外部系統(tǒng)對(duì)接，開(kāi)發(fā)者只需要使用 type 獲得數(shù)據(jù)，完成數(shù)據(jù)開(kāi)發(fā)后通過(guò) target 回寫(xiě)到目標(biāo)系統(tǒng)中。整個(gè)過(guò)程基本無(wú)須程序開(kāi)發(fā)，除非當(dāng)前的 SQL 函數(shù)無(wú)法滿足使用的情況下，需要自行開(kāi)發(fā)一下特定的 UDF。因此本框架在對(duì) SparkSQL 做了二次開(kāi)發(fā)基礎(chǔ)上，大大簡(jiǎn)化了 Spark 的開(kāi)發(fā)，可降低了開(kāi)發(fā)者使用難度。

精選提問(wèn)：

問(wèn)1：和Fink平臺(tái)有什么優(yōu)勢(shì)么？

答：Flink 應(yīng)該對(duì)標(biāo) Spark Streaming 的解決方案，是另一種可選流數(shù)據(jù)引擎。Flink 也采用了 Scala 語(yǔ)言，內(nèi)部原理和操作數(shù)據(jù)方式頗有相似之處，是 SparkStreaming 之外流數(shù)據(jù)處理一種選型�；�于 SparkSQL Flow 的架構(gòu)主要側(cè)重批量數(shù)據(jù)分析，非實(shí)時(shí) ETL 方面。

問(wèn)2：這些應(yīng)該是源數(shù)據(jù)庫(kù)吧，請(qǐng)問(wèn)目標(biāo)數(shù)據(jù)庫(kù)支持哪些？

答：目前的實(shí)現(xiàn)目標(biāo)數(shù)據(jù)基本支持所有的源。

問(wèn)3：你們產(chǎn)品是軟件開(kāi)發(fā)平臺(tái)，spark和你們開(kāi)發(fā)平臺(tái)啥關(guān)系？

答：普元針對(duì)部分成熟場(chǎng)景提供了一些開(kāi)發(fā)平臺(tái)和工具，也在參與了一些大數(shù)據(jù)項(xiàng)目建設(shè)。對(duì)于大規(guī)模數(shù)據(jù)的數(shù)據(jù)報(bào)表，數(shù)據(jù)質(zhì)量分析也需要適應(yīng)大數(shù)據(jù)的技術(shù)場(chǎng)景，Spark 作為Hadoop 內(nèi)比較成熟的解決方案，因此作為主要的選型工具。在參與部分項(xiàng)目實(shí)施過(guò)程中，通過(guò)對(duì)一些開(kāi)發(fā)中的痛點(diǎn)針對(duì)性的提取了應(yīng)用框架。

問(wèn)4：對(duì)于ETL中存在的merge、update的數(shù)據(jù)匹配、整合處理，Spark SQL Flow有沒(méi)有好的解決方法？

答：merge 和 update 在數(shù)據(jù)開(kāi)發(fā)過(guò)程不可避免，往往對(duì)數(shù)據(jù)庫(kù)造成較大壓力。大數(shù)據(jù)場(chǎng)景下不建議逐條對(duì)數(shù)據(jù)做 update 操作，更好的辦法是在數(shù)據(jù)處理階段通過(guò) join 把結(jié)果集在寫(xiě)入目標(biāo)前準(zhǔn)備好，統(tǒng)一一次性寫(xiě)入到目標(biāo)數(shù)據(jù)庫(kù)。查詢操作通過(guò)換庫(kù)使用新庫(kù)，這中操作一般適合數(shù)據(jù)量比較大，數(shù)據(jù)更新頻率較低的情況。如果目標(biāo)庫(kù)是 HBase 或者其他 MPP 類基于列式的數(shù)據(jù)庫(kù)，適當(dāng)?shù)目梢愿�新。但是�?dāng)每天有 60％ 以上的數(shù)據(jù)都需要更新時(shí)，建議還是一次性生成新表。

問(wèn)5： blink和flink 應(yīng)該如何選��？

答：blink 是阿里巴巴在 flink 基礎(chǔ)上做了部分場(chǎng)景優(yōu)化（只是部分社區(qū)有介紹，并不明確）并且開(kāi)源，但是考慮到國(guó)內(nèi)這些機(jī)構(gòu)開(kāi)源往往是沒(méi)有持久動(dòng)力的。要看采用 Blink 是否用了比較關(guān)鍵的特性。也有消息說(shuō) Blink 和 Flink 會(huì)合并，畢竟阿里 Dubbo 前期自己發(fā)展，后期還是捐給了 Apache，因此兩者合并也是有可能。建議選型 Flink。

問(wèn)6：etl 同步數(shù)據(jù)中主要用哪些工具？

答：這個(gè)要區(qū)分場(chǎng)景。傳統(tǒng)數(shù)據(jù)庫(kù)之間，可采用日志同步，也有部分成熟的工具；

傳統(tǒng)數(shù)據(jù)庫(kù)和Hadoop 生態(tài)內(nèi)（HBase，HIVE） 同步可使用 apache sqoop。 SparkSQL Flow 可以作為數(shù)據(jù)同步的另一種方案，可用在實(shí)時(shí)性不高的場(chǎng)景。SparkSQL Flow 更側(cè)重大數(shù)據(jù)工具，偏向數(shù)據(jù)分析和非實(shí)時(shí) ETL。