你是否也遇到过这样的问题？
在设计和实现监控系统时，因为在数据存储上过于依赖Kafka、Spark和HBase等大数据组件，导致大数据处理链路越来越长，不仅运维和使用成本越来越高，系统的可靠性保障也出现了更多的挑战。一旦监控系统本身出现漏洞，业务系统存在的问题便将难以定位，进而就可能会造成巨大的实际业务损失。
此前顺丰科技便被以上问题所困扰，他们使用OpenTSDB作为全量监控数据存储方案，不仅运维和使用成本很高，性能上也越来越难以满足需求——日常大跨度和高频次查询方面已经无法满足当前业务发展的需求，查询返回结果甚至需要十几秒。此外，随着用户量的增加，支持较低QPS的OpenTSDB非常容易崩溃，一旦崩溃将导致整个服务都变为不可用状态。
顺丰科技并不是独一例，睿信物联网平台同样遭遇了此类问题。为了解决这个问题，两家企业都开始重新进行数据库选型，但为什么最终它们都选择了TDengine？TDengine又带给了它们哪些改变？
以顺丰科技为例，他们分别调研了IoTDB、Druid、ClickHouse、TDengine等几大市面流行的支持时序数据处理的产品。
在调研时发现，单机性能不错的IoTDB尚不支持集群模式，单机模式在容灾和扩展方面无法满足需求；性能强大的Druid却过于依赖ZooKeeper和Hadoop作为深度存储，整体复杂度较高；性能算是最好的ClickHouse却由于运维成本太高扩展特别复杂。最终，性能、成本、运维难度都满足且支持横向扩展的TDengine脱颖而出，成为了顺丰科技的最佳选项。
改造成功后，顺丰科技智慧物流服务系统发生了四个显著变化：
- 在稳定性方面，大数据监控平台摆脱了对大数据组件的依赖，有效缩短了数据处理链路
- 在写入方面，理想情况下集群写入速度最高能达到90w条/s
- 在查询方面，在使用预计算函数情况下，查询p99都在0.7秒以内
- 在成本方面，服务端物理机由21台降至3台
无独有偶，睿信物联网平台也收获了这些惊喜效果，但是他们还遇到了一个问题，就是如何将历史数据顺利迁移，为此他们还自发做了一个迁移工具。
为了更加方便企业从OpenTSDB等产品顺利迁移至TDengine，TDengine研发团队专门开发了解决方案。
今天的公开课分成了：（1）TDengine技术演进规划、（2）TDengine 技术内幕分享——兼容 OpenTSDB、（3）全面超越OpenTSDB——TDengine的能力、迁移方案与行业案例，三部分来多角度、全方位解读TDengine的核心功能与最佳迁移路径。
（1）TDengine 3.0 的技术演进规划
（2）TDengine 技术内幕分享——兼容 OpenTSDB
（3）全面超越OpenTSDB——TDengine的能力、迁移方案与行业案例
欢迎大家扫描下方二维码，关注 TDengine 视频号，观看每周的微课堂以及直播活动。
