类似于读后感－－－－基于大数据的金融数据挖掘章节

今天本来想写scala的 后来感觉今天没有摸到门道与核心 明天再去集群里试试。

——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－——－

近20年来在TD的帮助（剥削下）银行信息系统的信息化存储水平有一定的提高。

近5年来大数据的技术逐渐稳定，书中总结如下：

大数据的应用与之前数据的应用的不同点在于 规模、速度、多样性、价值密度。

就我行而言，规模上系统存储勉强达到TB级的数据，源文件的保留策略是删除而不是存档，有利于节省空间。

未来的hadoop数据仓库发展逻辑在于以下几点：

1、历史源数据的保存策略－－－不仅可以选择将可结构化的数据结构化进入仓库报表、也可以选择直接将不可结构化的源文件存储进入集群hdfs，待后续技术发展到一定阶段进行应用。（比如很多文本数据，目前没有结构化方案的）

2、数据的分区查询功能是作为仓库对外接口的保证。也是稳定运行的保证。这里边的要求就应当包括速度上的要求。最近业务经常反应的SAS与hadoop通过libname方式直连缓慢的问题如何彻底解决？因为SAS本身就并非分布式、对应大数据集的处理能力不够，然而impala能够处理这些但是不能够很方便的进行导入导出（比如二进制文件和大文件），未来的趋势一定是建立在hadoop集群上完成现有SAS分析功能的组件。

3、基于数据仓库级别的建模，之前已经思考过。无论是星型也好雪花也好，维度主题更重要的是反应全局，集市层的数据应当保留所有从贴源层录入信息，而不是和现在一样进行拆解后需要使用时再复原。这也是符合分析角度多样性的基本要求的。同时跨表、跨库的多种数据维度的关联分析是集市层面最主要的分析方式之一

4、价值密度是针对大数据才会有的新鲜词汇，大范围的数据中以发现数据间的关联为主，以理论解释为辅。

我们如何从海量的数据中挑选出有意义的数据并用之来分析一件事情？是做数据分析需要考虑的最直接的内容。

大数据的金融数据挖掘思维

第一步就是通过采样，告别采样。我们之前的所有对数据的要求都是先采样再分析，再应用到全集，现在不合适，就如同没有人愿意被代表一样，没有一条数据希望自己被其他数据代表。（不然就是重复数据咯）

第二步是允许错误数据的加入。如同大数据平台对冗余的容忍一样，我们也需要在分析阶段容许错误数据的加入。

这边特别说明一下（数据没有对错之分，只是如果在不恰当的场景出现，并且会影响我们对于整体的把控的内容，姑且称之为错误数据）。

第三步 就是关联，为何一再强调关联，就是因为数据体量提升，不仅仅是2-3张表几十万条数据之间的相互关系，而是需要集成多个系统的所有相关表的最少千万级别的数据关联。一旦无法把控关联逻辑，就意味着需要花超过百倍的时间进行相关处理。

晚点开始写架构上的内容。