3、可视化呈现要好一点，就是图表要高大上的。数据分析报告得拿出手，图表的展现就是第一门面。包装的意识还是要有的。所以结论就是找一些操作容易、功能强大、图表颜值还得好的工具了。我就是照着这个思路找的，也用过几个，可以给大家说说。像东软做的Dataviz，是用着比较顺手的了。具体介绍我就摘抄下，自己懒得码那么多字DataViz数据可视化分析工具，不需要编写代码，也不需要任何程序设计基础，用户可以通过简单的拖拽就可以实现数据可视化展示与分析。
DataViz使用简单，但是实现的功能却不简单，上百种丰富的炫酷图表，可以实现数据的多维度多层次分析。上图先，先看些基本图各种数据分析好后，可以做成组合图册：重点就是操作起来简单，拖拖拽拽的，看起来特别复杂的图表，其实拼贴一下就能搞定了。操作面板基本本国人都可以分分钟用起来。如果是专业人士或者计算机大拿的，估计可以寻找更复杂的工具进行尝试了。
图数据库是用于做什么的？
图数据库是下一个大趋势。首先，图数据库是一个产品，但成为产品前，经历了很长时间的理论期。比如欧拉图其实已有超过 200 年历史，数学理论很完整，在图中有很多经典算法，像这两个点之间最短路径是？物流该怎么去优化？社区该怎么划分？它已有很多现成、成熟的算法和科学理论，但从理论到工业界的产品，这里一直存在巨大空白。
直到 2002 年时，出现一家公司，做了第一代“图数据库”，但他们不想把数据打乱，放到几个表里，而就想存成一个真正的图，所以一个词叫 Native（汉语翻译成“原生图”），就是说：我就是真正用一种图的数据结构来存图，这样我性能会好很多。但因为是 2002 年前的老技术，那时还没有大数据概念，还没有分布式系统的进展，这家公司做的就是单机版，数据只能在一台机器里跑，你数据量一大，它就没办法。
但这个公司十几年来就做这么一件事，然后不断教育市场，它现在还很有名，叫 Neo4j。这是图数据库一代，也叫图 1.0。然后大概 6、7 年前，因为有 hadoop/MapReduce 和其他开源的分布式系统，又有人做了些开源工具，做了些分布式图数据库，相当是有了一个捷径：你不用从头到尾做一个图数据库了，我用现有分布式存储系统来存数据，但在上头，我做个中间件，模仿一下图的 API，然后给终端用户终端开发者一个图的 API 概念。
比如说：我朋友的朋友是谁？朋友是谁有哪些类型的节点？有哪些类型的边？这样就号称可以存很多数据，不受一台机器限制，但缺点是性能差，整个过程很慢。也就是说：第一种性能好，但数据量一大，就没办法；第二种是多机版，它跑得过来，但性能差，没实时处理数据的能力；之后是图 3.0，像全球首家实时图分析平台 TigerGraph 在干的事。
图 3.0 需要设计既是分布式、又是原生图，跟第一代一样，存储全是自己做，这样性能好，但设计时又是分布式的，所以数据量大也没问题，1 台或几十台机器去跑，没有限制，你都可以跑，这样就可以解决一些数据量超级大的公司，比如以前像支付宝，“单机版”不可能有能力处理，因为数据量实在太大，但是如果你突破到“多机版”，性能还非常好，就解决了很多以前根本没法用图数据库的一些应用场景。
数据仓库和数据库有什么区别？
说点大家都能懂的干货。请点赞收藏。先讲讲来龙去脉很久以前是没有数据仓库这个概念的，只有数据库，数据库就是很多数据表的集合，这样把存放不同内容的表放在一起，就能满足一些基本的查询了。比如提取2019年6月18日在淘宝购买Bose耳机的用户，只要几张表关联一下查询就出结果了。后来在实际工作中人们发现当你在海量数据中做非常复杂的分析的时候，效率就很低了：比如找到2019年双11和2018年双11这两天，在淘宝下单超过500元且购买了Bose耳机的用户，这两拨用户在最近2两年的平均消费能力差异。
要完成这个查询，首先要关联查询很多表，其次要查询2018和2019年两年的数据，最后你还要从海量的数据中找到符合要求的消费金额和消费者，这三点加起来就让数据提取变成了非常复杂的事儿，而且不一定能立刻查到，往往一个查询任务就要跑好几个小时。所以随着数据体量增大，查询条件越来越复杂，大家一看不行啊，需要提高效率。
所以数据仓库出现了。数据仓库和数据库相比，有啥特点1.数据仓库有主题性，有作业流的概念上面的例子告诉我们，数据仓库是为了某一个/某一类特定的分析任务将数据重新聚合起来的，而数据库只是数据存储表的集合，所以数据仓库有主题性。同时也因为有主题的概念，数据仓库会根据你预设的逻辑，自动化的完成各个作业之间的调度，最终自动化的把结果输出给你。
所以数据仓库也会有数据流和作业流的概念。2.数据仓库让「查询」效率最大化数据库本质就是很多数据表，所以数据表嘛，就要兼顾增删改查这些操作，但是数据仓库将数据重新组合，是为了让你更高效的查询并且支持你的分析工作的，所以数据库一般只让「查询」的效率最大化，「增删改」的效率不做主要考虑。3.数据仓库有历史数据，而数据库一般只有近期数据上面举的例子中，要查询淘宝2018年和2019年两年的双11数据，所以跨度很大。
一般数据库只能存近期的数据，太久远的数据放不下，效率也低。但是数据仓库可以将某些维度的历史信息统一抽取出来以更合理的存储结构放到数据仓库中，这样查询跨年的数据时直接查询就行了，效率极大的提升。4.数据仓库是基于数据库层面的升级一家公司，一般是现有几张数据表，后来数据表集合成了数据库，再后来数据库不满足需求了，才有了数据仓库。
所以数据表，数据库，数据仓库之间是有依赖关系的，不是割裂的。怎么建立数据仓库1.需求分析分析你为了哪个目的建立数据仓库，数据仓库需要哪些维度的数据，这些数据表都在哪里是否能访问。2.ETL 将你所有需要的数据表都找到，然后根据你的需求将需要的字段都提取出来并对数据格式进行清洗加工转换。保证数据原料是合格可用的3.数据结构设计包括维度表，事实表的设计，是否要用列式存储代替行式存储，是否需要将数据分层（详细可查询OLAP方面的数据模型），总之就是要保证数据查询的效率4.作业调度每一个你看到的数据背后，都是多个数据表被一系列脚本调用最终计算而成，所以多个作业之间肯定涉及调度关系，过程监控，结果监控等。
关系型数据库和非关系型数据库有什么区别？
先说说关系型数据库和非关系型数据库有什么区别这里的关系型和非关系型，主要是数据存储格式的区别，我们常见的关系型数据库有Mysql、Oracle、DB2、SQL Server等，都是通过关系模型来组织数据，也就是二维表格模型。而非关系型数据库，就不是按照这个二维表格来存储数据了，例如Redis是使用键值对（key-value）来组织数据，MongoDB是采用BSON的格式（可以想象成JSON）；并且不局限于固定的结构。
关系型数据库和非关系型数据库之间的关系，也不是有你没有，二者选其一，通常都是配合起来使用的。各自的优缺点关系型数据库，容易理解，使用方便（通过SQL语言操作），易于维护；但是因为数据在磁盘上存储，I/O会成为一个很大的瓶颈，如果在高并发的场景下，性能降低的很快；另外，对于关系型数据库，当单表数据量增加到一定程度的时候，表的操作效率也会很低；表结构固定，当数据量比较大的时候，对表结构的扩展会是灾难性的。
非惯性数据库因为数据结构的“随性”，用户可以根据需要增加字段，关系型数据习惯设计成多张表，然后通过表关联查询，而非关系型数据库（文档性）会把所有字段放到一个集合中，避免多表的关联。不过缺点也非常明显，“随性”也就意味着没有标准，单集合有好处也有坏处，没有完整性约束，对于复杂的业务场景支持比较差。至于MongoDB和Redis怎么选择，两者差别还是很大的，适用场景也不同Redis的数据存储格式是key-value，支持持久化、 支持事务，经常用于缓存、高并发下的读写（计数器、最新列表、秒杀），因为单线程的机制也会用于分布式锁。
MongoDB的数据存储格式为BSON（类似于JSON），支持快速读写，特别是大吞吐量的写操作；如果表结构不明确，未来可能会发生很大的变化，非常适合使用MongoDB。架构中可以同时包含关系型数据库、Redis和MongoDB，各司其职。我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
