探索Equalum的处理能力吗？

基本上，在本次的一系列驗證中，我們將使用約1秒 (使用Python的睡眠功能設定) 的間隔，通過Python將數據發送到MySQL作為上游CDC設置的一部分，然後執行操作。然而，在這裡，我們打算進行一個名為0-400m的小挑戰計劃。

设定环境

作为环境

（１）Equalum服务器：Core i7处理器（4核8线程），32GB内存，256GB SSD硬盘，搭载CentOS7操作系统。
（２）MemSQL服务器：Core i7处理器（4核8线程），32GB内存，256GB SSD硬盘，搭载CentOS7操作系统。
（３）MySQL服务器：Core i7处理器（4核8线程），32GB内存，512GB SSD硬盘，搭载Windows10操作系统。

使用Windows版MySQL，在相同环境下运行Python。
计算机是由零部件组装而成的自制机器。
网络使用GbE（同时兼容WiFi的市售通用设备）。

成为。

我使用的Python脚本是基于之前的版本，除去了时间提高的处理，并设置了生成1000个数据并进行连续插入操作到上游数据源，并以原样（与复制相同）将其处理为Equalum中的目标数据源进行验证。

请给出验证结果。

MySQL端的处理结果

  1|2020-07-03 14:47:04.167946|2020-07-03 14:47:04.0|泡盛     | 1980|    5|佐島  |
  2|2020-07-03 14:47:04.171034|2020-07-03 14:47:04.0|泡盛     | 1980|   10|一丁目 |
  3|2020-07-03 14:47:04.173314|2020-07-03 14:47:04.0|スコッチ   | 3500|    6|旭町  |
  4|2020-07-03 14:47:04.175366|2020-07-03 14:47:04.0|ビール    |  490|    5|一丁目 |
  5| 2020-07-03 14:47:04.17785|2020-07-03 14:47:04.0|泡盛     | 1980|    2|五本木 |

>>> 途中省略

498|2020-07-03 14:47:05.363334|2020-07-03 14:47:05.0|日本酒    | 1980|    8|一丁目 |  
499|2020-07-03 14:47:05.365319|2020-07-03 14:47:05.0|テキーラ   | 2000|   10|三丁目 | 
500|2020-07-03 14:47:05.367315|2020-07-03 14:47:05.0|テキーラ   | 2000|    3|住吉町 |  
501|2020-07-03 14:47:05.369285|2020-07-03 14:47:05.0|テキーラ   | 2000|    6|佐島  |
502|2020-07-03 14:47:05.371346|2020-07-03 14:47:05.0|芋焼酎    | 2000|    7|住吉町 |

>>>　途中省略

 996|2020-07-03 14:47:06.487793|2020-07-03 14:47:06.0|テキーラ   | 2000|    6|五本木 |
 997|2020-07-03 14:47:06.489917|2020-07-03 14:47:06.0|泡盛     | 1980|    2|二丁目 |
 998|2020-07-03 14:47:06.491941|2020-07-03 14:47:06.0|日本酒    | 1980|    9|古橋  | 
 999|2020-07-03 14:47:06.493771|2020-07-03 14:47:06.0|バーボン   | 2500|    8|西新町 |
1000|2020-07-03 14:47:06.495692|2020-07-03 14:47:06.0|スコッチ   | 3500|    7|旭町  |

MemSQL的处理结果

  1|2020-07-03 14:47:04.167946|2020-07-03 14:47:04.0|泡盛     | 1980|    5|佐島  |
  2|2020-07-03 14:47:04.171034|2020-07-03 14:47:04.0|泡盛     | 1980|   10|一丁目 |
  3|2020-07-03 14:47:04.173314|2020-07-03 14:47:04.0|スコッチ   | 3500|    6|旭町  |
  4|2020-07-03 14:47:04.175366|2020-07-03 14:47:04.0|ビール    |  490|    5|一丁目 |
  5| 2020-07-03 14:47:04.17785|2020-07-03 14:47:04.0|泡盛     | 1980|    2|五本木 |

>>> 途中省略

498|2020-07-03 14:47:05.363334|2020-07-03 14:47:05.0|日本酒    | 1980|    8|一丁目 |
499|2020-07-03 14:47:05.365319|2020-07-03 14:47:05.0|テキーラ   | 2000|   10|三丁目 | 
500|2020-07-03 14:47:05.367315|2020-07-03 14:47:05.0|テキーラ   | 2000|    3|住吉町 | 
501|2020-07-03 14:47:05.369285|2020-07-03 14:47:05.0|テキーラ   | 2000|    6|佐島  | 
502|2020-07-03 14:47:05.371346|2020-07-03 14:47:05.0|芋焼酎    | 2000|    7|住吉町 |

>>> 途中省略

 996|2020-07-03 14:47:06.487793|2020-07-03 14:47:06.0|テキーラ   | 2000|    6|五本木 |
 997|2020-07-03 14:47:06.489917|2020-07-03 14:47:06.0|泡盛     | 1980|    2|二丁目 |   
 998|2020-07-03 14:47:06.491941|2020-07-03 14:47:06.0|日本酒    | 1980|    9|古橋  | 
 999|2020-07-03 14:47:06.493771|2020-07-03 14:47:06.0|バーボン   | 2500|    8|西新町 |
1000|2020-07-03 14:47:06.495692|2020-07-03 14:47:06.0|スコッチ   | 3500|    7|旭町  | 

在各个点上的数值比较

# 最初のデータに関するタイムスタンプ情報
MySQL     1|2020-07-03 14:47:04.167946|2020-07-03 14:47:04.0
MemSQL    1|2020-07-03 14:47:04.167946|2020-07-03 14:47:04.0

# 中間データに関するタイムスタンプ情報
MySQK   500|2020-07-03 14:47:05.367315|2020-07-03 14:47:05.0
MemSQL  500|2020-07-03 14:47:05.367315|2020-07-03 14:47:05.0

# 最終データに関するタイムスタンプ情報
MySQL  1000|2020-07-03 14:47:06.495692|2020-07-03 14:47:06.0
MemSQL 1000|2020-07-03 14:47:06.495692|2020-07-03 14:47:06.0

1000個のデータ処理時間　2.327746秒   MySQLとMemSQL間の平均TIMESTAMP(6)の差　0.000000秒

在TIMESTAMP(6)中，时间差为0.000000秒的震撼…

在使用Faker创建数据时，首先将精确到秒的日期时间信息转化为字符串，并将其写入Demo表的dt列中的上游MySQL，然后将其传递给Equalum，此信息将传递到目标MySQL，因此与之前的验证不同，这部分在1000个数据中几乎占据了相同秒数的dt信息连续出现。因此，在当前”没有限制”的情况下，可以认为Equalum核心中的kafka协作性能直接展现了出来（由于排除了中间计算处理等的关系，似乎不需要深入使用Spark引擎…），确切地说明了任何人都可以在不需要编写程序的情况下构建出以超高速度执行1000个连续处理的机制，具有潜力的事实。

不需要编写程序即可在约2秒内处理1000个数据的功能实现。

此外，我认为这次对于汽车界来说，可以进行类似0-400米的竞速或者拖车赛的验证。正如我多次强调的，尽管放弃了速度的优势，但同时也将实现原本被放弃的规格的可行性大幅提高，并创造出新的数据计算思路。这一点是以数据为中心的思维方式，以数据驱动的数据计算，以及Equalum拥有提升其潜力的可能性明确而直观地证明了。

这次的总结

这次我们以暴走篇的形式，对Equalum进行了0-400米的基准测试验证。结果显示，无论是设计复杂的处理流程并将其嵌入其中，还是简单地进行复制并利用（例如，在不影响业务的情况下，将AI、BI和各种数据解决方案与复制品协同，实现在同一时间段内进行更高级的数据协同工作（可以通过后端主动支持现场工作来实现））都能明确地展示出数据驱动的时间轴极其接近现在！从而使我们能够在现在非常明确地进行实施。

我认为，由于现场正在运行的现有业务数据库相关的机制在设计阶段就已经被充分考虑过，所以将近期备受关注的“事后添加的交易制造机”式数据计算解决方案与之协同，可能会给现场增加很大负担，最终可能只能在现场业务的后期或空闲时使用。

在现场繁忙的时候，利用这些数据进行即时支持和拓展的工作也会变得繁忙。

或许，这正是数据驱动的ＤＸ时代中可能出现的“一种困境”。

此外，我认为通过巧妙地设计数据流程，我们也能够改善传统的批处理方式，不再像以前那样需要进行大量的回溯，而是能够缩短处理间隔。因此，我们可以进行良好的“小计”确认，并采取适当的措施来应对。

顺便提一下，至于Equalum方面关于此次基准测试时间测量的设置……最后我要报告的是，在这项工作中没有发生任何编程工作。

任何人都可以成为kafka/Spark的使用者，而无需进行编程。

数据是结果的一部分，但结果之后很快产生了新的数据。
通过积极利用与数据相关的时间轴的灵活性，可以实现更具战略性的驱动。

在中国除了一个选项外将以下内容用中文表达：

不是以年为基础的大型在线系统，而是对于数据科学家和会编程但理解公司内业务相关数据库表和列的人来说，也许可以看到在一连串的Equalum验证中，现在已经进入了能够构建基于kafka的高级实时数据系统的时代。

下次，想要添加一个简单的专门用于Equalum的批处理验证作为番外篇，并结束上半场。如果有新的话题，可能会变成暴走篇2。

紧随着Equalum的到来！（疾驰篇？）

感谢词

本验证得到了Equalum公司的特别许可进行。我们对Equalum公司提供这个宝贵的机会表示感谢，并且请您理解，如果本内容与Equalum公司官方网站公开的内容等有所不同，请以Equalum公司的信息为准。