ETL杂谈

我感觉我可能完成不了领导让我写的PPT了。

上周领导和我分享了一下他的etl的一些知识，说实话，我不太懂为什么要做这样的分享。

总之，我整个听了一遍。

最后，领导收要我从产品的角度来写个ETL的PPT。

其实，这个要求还是很明确的。

但是，我还是不知道怎么写。

第一，说实话，我对ETL的了解也仅限于领导的分享和我自己上网的查询的一些东东。实际工作中，我几乎和他打不上交道。

第二，我有一个不太清楚的，我写完这个PPT是要给谁看呢？

我做了几个假设。

第一，是给其他部门的需要使用ETL的人看的。

第二，按照领导的意思，他做这个分享其实是为了给后面组内的新人当培训资料的。

第一个的角度，偏向于我自己的角度。第二个角度，我其实是整不明白的。为啥，我们部门都是开发的人，我并不知道进入我们部门需要对这个了解多少，

不过从分享的过程来看，他们的了解也并不是特别多。

当然，中间我想了一个最好的办法。

就是出2份PPT，可是我的时间不够了，我觉得我还是先做个ETL知识的分享处理。最后抛几个问题，还要扔一些看上去是产品问的问题。

我一个产品，还要假装是一个产品一样去思考，真是个假产品，那你是真什么呢？

好了，我们先来列个提纲。

 

ETL是什么？

ETL能帮你干什么？

不对，这样的思路有些脑残。为啥呢？我又不是教科书，要讲究大而全。

 

应该从需求出发。

假设我要做个数据分析，我想要一份明细的订单数据来做分析，我该怎么办呢？

我找到业务数据所在的服务器，然后远程连接上他，然后执行的我的分析代码。

这个思路并不可行，因为线上是oltp的架构，并不是支持你来做分析的。

你要做分析，不要在线上的数据库搞。

好，那我就需要把线上的数据复制一份到我自己这边来，然后在我自己这里做分析。

那么，这时候会出现一个业务选择问题。

我自己这边来，应该怎么做选择？

这就涉及到一个场景问题了。

你需要这份数据做什么用？

你可能需要做一个查询系统？通过订单号，或是啥的。

或者你需要做一个分析系统，需要可能统计，和计算，和逻辑。

或者你需要啥啥啥的。

建立在你的数据场景需求上，你会面临一个选择。用什么样的形式存储你的数据？

我们会给你提供一些简单的选型，但最终决定权还是在你自己手里。

所以，我们对你提出了一些要求。

你必须知道你自己在你这里可以部署什么形式，根据我们互相讨论的结果，选择这个形式。

其实，你在刚刚就完成了一个ETL。

你不必知道ETL具体的学术上的定义。你需要知道你在这个过程中要做什么就好了。

你看，你要知道什么。

第一，你要知道你的源头数据在哪？

第二，你要知道你要这些数据做什么用？

第三，你要决定用什么形式存储你的数据库（我们也会来帮你）

第四，其实我们忘了说，你要知道sql。

为什么要第四点？

是因为，你要用我们给你提供的sql。

其实，你要自己做，当然也完全可以。但是我们已经为你实现了一套，你何必重复造轮子呢？

我们部门本身就帮你实现了从源数据到目标数据的一套ETL任务工具。

你直接用我们这套数据就好了。

那怎么用我们这套数据呢？

你还是一样，在你知道你上面这些的基础上，你要做的是，就是通过写sql代码来告诉我们怎么做？

但是这中间，其实你也可以完全不写sql代码的。为什么？

因为我们的ETL任务本身就提供了一些默认的选项。

你要是完全按照我们的默认选项来，你可以一句sql都不用写。

 

但是，当然这在实际上并不会发生。

因为，我们并没有给你提供一个默认的选项。

即使，你是完全的把一个数据库的数据，完全同步到另外一个数据库去。我们还是会让你填一大堆东西。这点其实可以吐槽的。

我们应该要对这类形式的使用，做一个简化的模板。

让用户直接选择。

 

另外一个是，我们是不是只提供这样一个工具就完了呢？

当然不是。

既然你都把数据迁移做完了，何不再多做一些事情？

 

比如啥？

 

要不分析也在我们这里做吧？

本来我们的路径是，把数据从源头扔到你自己那里去，你自己在你那里分析。

那这一步，干嘛我们不也提供一个工具给你用呢？

你想一下你数据分析出来是要干啥用呢？

无非就是，用可视化的图表来展示你的分析结果。或者你不想可视化，你也可以用表格的形式来展现数据。

这一点，我们其实可以帮你实现。

这样的话，你会简单什么呢？

你不需要再在excel里的图表里花几天的时间整理你的分析报告，而是直接用我们的工具，直接展示你的分析结果。

当然，这一点，我们也没有做到这么理想。

我们是提供了一些工具给你来用，但是这些工具怎么说呢？并不好用。

因为他会强加你要去学习一套Jason的语法。

你还是通过这些代码来告诉我们怎么做？这肯定很不友好。

如果我们真的要做的话，其实我们还是应该提供可视化的操作界面来让你告诉我们来做什么。

 

当然，你用一套工具，也会有工具本身的限制，这就是和框架做斗争。

当我们的框架不知道某类操作时，你只能等我们去优化这种。

但你对这个无能为力，我们很可能不接你这个需求，后者排期到很晚。

当然，也许我们框架的指定者可能会很自负的说到，你这个不符合科学的数据流程？其实你可以通过我们这样的一个流程也能达到同样的目的。不过你可能需要按照我们的标准多填一些信息。

相信我们，我们也是为你好，因为我们自己就是知道原来这么坑过来的。（我乱猜的）

另外一个，我想提的一个重要的点是，为下期做个预告。

其实，你配置好你的ETL任务后。

你就会产生一系列的问题。说实话，我以前是不是那么清晰这样一些问题的。

你在配置的时候，你会想先测试一下是不是有用？我们是否给你提供了这样的工具？这些工具是否能真正的完成这样的一些任务？

你测试发现任务莫名其妙的出问题了，这时候应该怎么办？直接问我们的开发同学或者产品经理？我们是否应该做个QA？或者更应该的是，我们知道这样一些问题，而这些问题暂时无法解决的情况下，是否可以自动的提示一些挽救的措施？这个事情总可以挽救的吧？不然你流程就算没走通。

还有一个是，你是否能准确的知道你的任务是否在运行阶段是正常的？有没有一种方式，在实际我使用数据前，就告诉我任务运行的是否正常？

由于需求方会很多，这里就会产生很多细节问题了。

其实上面所说的都是基于离线的一些假定，现在很多的可能都强调一个实时的分析。

如果是实时的分析，那难度就高很多了。

我们是否还是可以把复杂度降低到还是这样，用户只要思考它上面考虑的一些问题呢？这个说实话，我具体不是那么清楚。因为中间的关键节点，是否真的可以做成黑箱不让用户感知，我是没底的。

不过，这肯定是一个目标，即使达不到上面这种程度，降低用户使用的门槛，这就是我们的目标。