小弟在国外银行做BI,刚好最近导入Hadoop刚做完PoV
Big Data的部分先放在后面,先来谈谈为什么要用Hadoop
最主要的原因还是在银行有太多不同的系统和资料来源,甚至有的老到几十年都有
加上我们银行上面又有别的国家的母银行,十几年前就发展了一套 Global Data Warehouse
这种GDW顾名思义就是管你来源是什么最后都进到一个统一的数据库
然后下面再根据需求做ETL等等工作,为了资安和效率,GDW下面还有很多不同的数据库
然后presenatation level再根据不同的需求去用这些资料
这样行之有年也没什么问题,但是慢慢这几年就出现瓶颈
最简单的例子就是ETL中的storage table因为太庞大,许多像是历史交易资料如果
join其他table就常常跑到超过一个小时,还有其他许多需求就不再赘述
另外一个瓶颈就是即时性,GDW的架构让下游数据库只能用到前一天的资料
因为所以外部系统都要在营业日结束后才汇集资料,
所以最近我们就准备在未来几年慢慢把GDW这种架构淘汰,慢慢转换成Hadoop
搭配Informatica当作data quality 和 ETL 工具, presenation layer的最后通通
通过API取在Hadoop中被Informatica处理好的资料
Big Data直觉上就是资料庞大,不过复杂资料来源,时间性和输出的效率都是其特性
至于用什么Analytics tool去分析我反而觉得那已经是Big data很末端的事情
Hadoop也不是传统数据库的替代品,我们目前也只评估20%现行的程序可以被取代
然后慢慢地提升也许到50%,同时间改善现行Sql Server的效能和空间问题
这样各发挥各的优点,小弟最近做了一套程序,把银行十几年上百万Excel档案
根据不同的类别扫描变成JSON格式然后进Hadoop,好处就是不需要依赖任何数据库
新的资料只需要一直append在档案尾端,只要换一个schema就可以在Hive里面有新的view
Informatica做任何ETL也不会用到任何多余空间当staging table,结果直接写回hive
别的部门可以直接用像是SAS VA看到最新的资料
你说会Hadoop重不重要,我会说重要,我们通常称这种role是 big data engineer
尤其在银行这种注重架构,流程,正确性,效率的环境必须要仰赖这种人来确保
整个机器运转的顺畅,某种程度像是传统 DBA 和 System Administrator的综合
至少在我们银行些用ML只要我们BI生的出资料,他们其实不太管前面怎么搞
大概是这样,理性讨论勿战 :)
※ 引述《deo2000 (800IM)》之铭言：
: 最近看到一些公司在找人，把会用Hadoop认定是有大数据处理能力，
: 甚至会看研究所做的题目是不是Hadoop？
: 例如这篇
: https://goo.gl/0cTk60
: 还有这篇
: https://www.facebook.com/thank78/posts/630689647078714
: 但我对这种现象感到疑惑。
: 我认知的处理Big Data核心能力，是一些资料探勘、机器学习相关的算法，
: 以及相关应用（例如挖掘特定领域的资讯）。
: Hadoop是一个分散档案系统的软件工具，或许符合"Big Data"字面上的意义，
: 但我们都知道data无用，information才有用，
: 因此这个时代谈的"Big Data"大多含有"挖掘、自动智慧"等意义，
: 而不是单纯的资料管理。
: 更何况论文研究出来的知识，不应该绑定在特定工具。
: 或许研究者本人只熟悉Hadoop或某种套装软件，这难免的。
: 但研究贡献、他人欲重现研究过程等，都不应该绑死在特定软件工具上。
: 或许因为我非资讯本科系、也不熟数据库，
: 请问，是不是我对 Hadoop 或 Big Data 有什么误解？
: 为什么 Big Data 的核心能力会是某种工具，而不是方法？