如果数据处理的最终用户是人类岗位，往往需要多维度呈现数据，而如果数据处理的最终用户是agent人工智能产品，往往需要根据agent的要求对数据进行处理。正确处理数据，一方面要根据数据本身的价值来衡量，另一方面也要与数据的应用场景和不同阶段密切相关。
数据分析方法有哪些？
要看什么数据格式化数据近似的非格式化数据完全碎片化的非格式化数据。第一种，格式化数通常是直接数据库中提取出来的。从多个数据源抽离数据，然后建立多维度的数据分析模型。之后通过大数据加载的架构进行数据打卡，然后批量进行处理。在数据了较大都时候会多线程，数据处理进度和过程处理数据的保存就显得格外重要。目前也有将关系型数据库转换为图数据库的分析方式。
处理过的数据通常会经过最后的数据呈现，图表，以方便最后行程报告。第二种，近似的格式化数据通常来自互联网爬虫。这种数据操作方式基本与第一种类似，只是在进行第一种的数据分析前，需要洗数据。删除重读和无效数据，梳理后形成格式化数据。第三种，完全碎片化的非格式化数据。这种数据的形式很多，可能是纸质的资料等一大堆需预先处理的资料。
这个部分如果数据量很大的情况下，就需要使用考虑使用人工智能领域。现在的人工智能通常是简历基础算法，然后通过大量的真实数据进行训练，训练到了一定的准确率就进行实际应用。这个时候的数据可能包含大量都图像信息，也许是人脸，也许是物体移动，也许是文字OCR然后建立数学模型，最后完成数据分析与第一种类似，再行程最后的报告。
我是做JAVA后台开发的。到目前为止，我最多每天处理600万左右的数据！数据不算太多，但也算是被淹没了。来说说你和你的团队是怎么做到的吧。后台架构:前端部门:负责接收其他公司推送的数据。由于日常数据量大且分布不均匀，所以采用每十分钟推送一次消息的方法，利用批处理框架进行数据落地，将成功落地数据的某一字段返回给调用者，让调用者验证是否所有成功落地的数据都已落地，从而保证数据的一致性！核心处理:采用springcloud作为微服务架构，feign用于客户端负载均衡，采用子数据库、子表的数据库架构。子数据库和子表的数据库中间件是公司自己开发的，通过fieldNO分布到8个数据库，每个数据库有128个表。为了避免数据重复，满足幂等性，会使用redis进行锁操作，因为redis是单线程处理，保证数据不会重复存储！遇到的问题:，数据不落地:虽然通过主叫端和服务端的确认方式保证了一致性，但是由于网络延迟、服务宕机等原因，还是会出现数据重复或者数据不落地的情况。第一，保证服务的稳定性的同时让接口和数据幂等，通过统计等方法保存没有再次登陆的数据！，日志爆炸:因为要求打印接口调用的输入、输出、中间数据的日志，一个月的硬盘实际占用450g，运维直接打电话问怎么回事？因为参与，参与通常作为数据开源和数据返回证明，日志只能通过压缩和动态删除前一个月的日志来保留！、缓存故障:在使用redis的过程中，redis服务经常出现挂起和延迟，可能导致数据丢失。这种情况尤其严重。很多时候，前期的数据只能通过后期的人为干预来检索进行数据保存。同时，缓存数据必须持久化，保证数据丢失时损失最小！缓存:期间遇到了一个问题。运维打电话说数据超过1000万。问了一下怎么回事，通过查代码发现很多数据没有过期时间，导致数据积压。简直就是一次失败的经历！，数据库:我们的数据库还是以子数据库、子表的方式稳定，没有超过峰值时数据库性能监控的阈值。最重要的是，我们害怕数据库中间件宕机导致数据丢失，所以中间件通常以集群的方式部署。同时，子数据库和子表还需要生成全局唯一ID，使用了淘宝的一套sequnce生成组件，避免了使用子数据库和子表字段(no)作为查询条件和连接查询。、消息中间件堵塞:有时候消息中间件的延迟会导致几十万或者几百万的数据积压。你害怕什么？在保证中间件稳定的情况下，最重要的是添加报警邮件，及时处理积压(50%概率是重启，哈哈)！其实我遇到过很多坑，一时半会想不起来。如果还有，请补充。你有什么问题吗？欢迎评论分享更多技术，敬请关注。
