这次我们尝试设计一个执行多个处理步骤的FLOW。

介绍这次的新设定初次登场。

由于我们之前已经对几个设置项进行了验证，所以现在我们将会确认本次验证中新成员的设定选项。

拆分与合并

这两个是用成对的形式使用的。而且设置项目只存在于Split一侧，负责所谓的”条件分岐”工作。这次我们决定给泡盛和啤酒分别分配个别的点数，并且对其他商品统一追加点数进行”后付加”。

转换设置

请提一下稍微重要的要点…

根据之前的验证得到的信息和本次新添加的部分，我认为在这之前的设计所需时间大约只需要15分钟。（调整设计工具的外观所需的时间要长一些……）
另外，关于最终设置收录表格，由于本次流程中会出现一些新的设置列（原始数据通过整数数据的ID进行引用数据转换等），所以需要对将数据写入MemSQL的表格设置进行谨慎确认。
从操作上来说，这将是将新添加的数据设为活动状态的操作，所以需要按以下设置进行操作，不要忘记。

好，现在行动！

这是流入到上游数据源的数据的情况。

以下是本次处理的流程定义所生成的数据情况（本次已经重新审查了时区设置）。

而且，值得特别注意的是，上游的MySQL与Equalum的流程操作后的下游MemSQL都附加了时间戳…..（汗）

记录在上游MySQL中的数据（围绕时间戳值的数据）

1|2020-06-25 13:17:45.931682|2020-06-25 13:17:45.0|         8|    5|      7|Discover                   
2|2020-06-25 13:17:46.939816|2020-06-25 13:17:46.0|         8|   10|      5|Cash                       
3|2020-06-25 13:17:47.948469|2020-06-25 13:17:47.0|         6|    6|      0|Cash                       
4|2020-06-25 13:17:48.954642|2020-06-25 13:17:48.0|         2|    5|      5|American Express           
5| 2020-06-25 13:17:49.96037|2020-06-25 13:17:49.0|         8|    2|      8|Cash                       
6|2020-06-25 13:17:50.966644|2020-06-25 13:17:50.0|         5|    6|      2|Mastercard                 
7|2020-06-25 13:17:51.974966|2020-06-25 13:17:51.0|         7|    4|      4|VISA 16 digit              
8|2020-06-25 13:17:52.984687|2020-06-25 13:17:52.0|         8|    8|      5|Cash                       
9|2020-06-25 13:17:53.992869|2020-06-25 13:17:53.0|         3|    9|      4|Diners Club / Carte Blanche

下游MemSQL中记录的数据（时间戳值附近）

1|2020-06-25 13:17:45.931682|2020-06-25 13:17:45.0|泡盛        | 1980|    5|佐島   |Discover      
2|2020-06-25 13:17:46.939816|2020-06-25 13:17:46.0|泡盛        | 1980|   10|一丁目 |Cash        
3|2020-06-25 13:17:47.948469|2020-06-25 13:17:47.0|スコッチ    | 3500|    6|旭町   |Cash         
4|2020-06-25 13:17:48.954642|2020-06-25 13:17:48.0|ビール      |  490|    5|一丁目 |American Exp
5| 2020-06-25 13:17:49.96037|2020-06-25 13:17:49.0|泡盛        | 1980|    2|五本木 |Cash        
6|2020-06-25 13:17:50.966644|2020-06-25 13:17:50.0|白ワイン    | 2500|    6|本町   |Mastercard  
7|2020-06-25 13:17:51.974966|2020-06-25 13:17:51.0|ブランデー  | 5000|    4|西新町 |VISA 16 di
8|2020-06-25 13:17:52.984687|2020-06-25 13:17:52.0|泡盛        | 1980|    8|一丁目 |Cash        
9|2020-06-25 13:17:53.992869|2020-06-25 13:17:53.0|芋焼酎      | 2000|    9|西新町 |Diners Club

此外，处理将从最初插入MySQL的初始数据起点开始，并随后以流式处理的方式进行连续处理，因此与数据量没有太大关系（批处理类型的累积处理不会发生…），因此并行处理多个流也没有问题。

这次的总结

这次我们进行了稍微复杂的FLOW定义验证，延续了上一次的内容。关于能够轻松处理最新数据动态的点上，Equalum的零编码技术非常引人关注，确实您一定能够理解它对数据民主化的大力支持。

将最新的消息控制技术Kafka和高速高效的处理能力提供的Spark与传统的CDC技术相结合，Equalum作为一个无需编程即可使用的环境，它将带来对这一领域的巨大影响，同时也是一个非常便利的产品，可以在数据为基础上创造新的思路。

只要了解基本的SQL和数据意义（列的内容），就能够在非常高级的实时性中进行数据流处理……这不仅可以提高对AI/BI等应用类解决方案的投资回报率，还可以通过数据驱动的方式获得新的思路和解决问题的线索……

在Dx时代，以数据驱动为核心的转变将由Equalum引领…

我们是先积累数据再考虑呢？还是边传输数据边适时对应处理呢？

这是一个非常重要的点，同时也意味着在实现“具有强大适应能力的高速数据驱动环境”时，不放弃数据是否在积累后进行思考？还是在数据积累的同时进行及时应对？这是一个新的二选一选择，需要考虑的时代。

下一次，我们将以番外篇的形式为Equalum新增一项简单的验证内容，以此结束上半场。

Equalum接踵而至！继续（暴走篇）.

感谢词

我們在Equalum公司的特別許可下進行此驗證。感謝Equalum公司提供這個寶貴的機會，同時，如果本文內容與Equalum公司官方網站上公開的內容有所不同，請儘量遵從Equalum公司的資訊為準。