前言
我之前写过一篇文章叫如何按程序员思维写分析师脚本，这里主要是在两方面帮助分析师：
- 将程序员一些较为高效的工作模式转移到分析师身上，这包括脚本片段复用，脚本include,工程项目，视图等。
- MLSQL平台提供这些思维的功能支持。
迄今为止，在之前文章提到的所有功能点，都已经在MLSQL中实现。当然，拥有这些还是远远不够的，因为SQL语言自身的设计和用途上的限制，导致做很多事情还是会有点力有不逮，下部分内容我们会具体举一个例子。
父子关系计算
父子关系计算指的是什么呢？譬如有一张表，数据格式如下：
{"id":0,"parentId":null}
{"id":1,"parentId":null}
{"id":2,"parentId":1}
{"id":3,"parentId":3}
{"id":7,"parentId":0}
{"id":199,"parentId":1}
{"id":200,"parentId":199}
{"id":201,"parentId":199}
这里为了简单，我们省略了其他字段，只保留了id和parentId字段。 一般而言这种结构建模了什么呢？ 我们举个最简单的例子，就是运营的拉新，一般而言现在大家喜欢用拉人头模式，比如如果你邀请其他用户注册，你就能获得奖励，我们会建模这种关系，假设id是用户id, parentId是邀请该用户注册的用户。
对于后端研发而言，用这种关系表建模该模式是非常有效的。但是对于分析师而言，却有点蛋疼了。比如要实现如下诉求：
- 计算拉新层级。我想知道任何一个用户它的传播层级有多少。比如A拉了B,B拉了C,那么A的拉新层级就是2.
- 计算拉新数量。任一用户的拉新用户数（跨层级，也就是子用户的子用户的子用户都算进去）
如果用SQL只能用join来实现有限层次的计算，而且SQL代码会很ugly,并且计算量还不小。本质上，对于需要递归的计算，SQL其实不是非常适合的。 那怎么解决呢？
扩展SQL中的王者:ET
ET其实是MLSQL中 Estimator/Transformer里的缩写，我们借鉴了算法领域的Estimator/Transformer的概念，来描述解决一个特定抽象问题的模块。该模块可以使用MLSQL的扩展语法来完成。 假设我们有一个ET解决了父子计算问题，它的名字叫 TreeBuildExt，怎么在SQL中使用呢？
我们来看一个较为完整的示例：
-- 任何select SQL语句本质上都是一个Transformer,将原数据转化为一个新的形态的数据。这里，我们
-- 从originalTable 抽取了两个字段，并且将得到的新的SQL语句的结果命名为parentChildTable
select id,parentId from originalTable as parentChildTable;
-- 和传统SQL语句不通的地方是我们新增了一个run关键字，和select类似，我们使用ET TreeBuildExt
-- 对parentChildTable 进行处理，使用where条件语句设置处理他的条件
-- 处理后的结果，我们命名为result.
run parentChildTable TreeBuildExt.``
where idCol="id" and parentIdCol="parentId" and treeType="nodeTreePerRow"
as result;
select * from result as output;
最后显示的结果如下：
+---+-----+------------------+
|id |level|children |
+---+-----+------------------+
|200|0 |[] |
|0 |1 |[7] |
|1 |2 |[200, 2, 201, 199]|
|7 |0 |[] |
|201|0 |[] |
|199|1 |[200, 201] |
|2 |0 |[] |
+---+-----+------------------+
该ET会计算每个元素的层级以及所有子元素。这样分析师只要学会一个类似select语句的新statement，就能用一条语句完成以前很难完成的任务，是不是很酷？
研发可以开发非常多为分析师定制的ET模块，从而高效的提高分析师的工作效率，也让很多”不可能“变成”可能“。值得一提的是，分析师做不了的工作，不需转交给研发，而是由研发开发ET,从而然工作职责更加清晰，让分析师的边界更加宽广。
总结
关于设置本地开发环境，可参看MLSQL 开发环境配置指南。
关于ET具体开发指南，参看MLSQL-ET开发指南。
如果大家想体验MLSQL产品，可点击一键体验全套MLSQL产品，或者自助完成编译部署。
