1）数据在不同的系统中存储多份，空间浪费，数据一致性的问题难以解决；
2）整个数据链路由多种引擎和系统组合而成，开发和维护成本高，学习成本高；
但现有的大数据运维分析手段依旧存在着原子工具繁多，上手成本高、工具之间的衔接困难，Monitoring(监控)、Logging(日志)、Tracing(定位追踪)无法互相依存发挥更大价值、真实业务中收益完全取决于使用者的架构能力等明显问题。
另外一面，大数据产品开始将SQL能力全部融合进来，甚至将事务ACID等特性集成进去，这使得大数据技术和数据库技术两个领域快速融合，因此未来所需要考虑的事情是如何朝着这个趋势演进，提供更多更优秀的产品。
IOPS是指存储堆栈每秒可以处理的离散读写任务的数量。存储堆栈是一种允许过程调用的数据结构。这意味着将多个过程彼此存储在堆栈中，然后在调用和返回的基础上一个接一个地执行所有过程。
AI可以监控存储以检测多种工作负载的模式和性能。这里的工作负载是由各种输入/输出特征或应用任务生成的数据流。通过检测这些工作负载模式，AI可以帮助存储管理员洞悉哪些工作负载可能使他们面临最大化存储阵列的风险。
对于运维而言也是一样的，开发的时候也需要考虑到可运维性，比如在开发的时候就需要考虑如何在服务实际上下线的时候做到平滑且不丢失数据，同时这样的设计也需要和运维系统进行深刻的对接，这样才能非常可靠、非常安全地连接起来，提升运维的效率。
云计算产生了大量的服务，在效能的角度来看，这些云服务是在更高层次抽象的 Serverless 形态，这就变得非常有意义了。如果从云编程模型的角度重新来审视云产品体系，能够看到最底层是基础设施层，这一层包含两部分，分别是 IaaS 和容器。
但CR场景或者轻量级的代码浏览场景，这种方式就显得时效性比较低了，几分钟后或许用户已经完成了代码浏览，而且缺少持久化的存储会导致资源过度消耗。于是，LSIF就在这样的背景下应运而生，秉承用空间换时间的思想，提前计算好语法分析结果以特定的索引格式存储在云上，从而快速响应不同用户的多次请求。
根据库大小的区别，LSIF的索引构建时间为10秒至数分钟不等，而用户对同一个代码仓库的提交操作峰值可能会达到每分钟近百次，即使我们采用了增量技术也很难满足高频的构建请求，并且提交事件触达和调度任务执行无法保证精准的时序性。综上所述，我们需要一个分布式时序锁来保证任务调度的顺序和尽量减少重复调度。
他们是怎么理解，怎么来思考的，他们认为什么地方有问题。我再找他们要一些建议：我应该怎么去做。跟他们聊的过程中才知道我们需要做什么样大促，要把握什么是关键点，这都是一些宝贵的财富。
