누구나 ETL/Datawarehousing 작업에 REST 기반 접근 방식을 사용 했습니까? 즉, REST 웹 서비스 호출을 통해 ETL 및 OLAP/데이터베이스 새로 고침 작업을 호출하는 것은ETL/Datawarehousing을위한 REST 웹 서비스 사용
입니다. REST는 매월 작업을 모델링하기위한 매우 적합하고 깨끗한 건축 양식처럼 http://company.com/cube/123523 (새 데이터로 특정 OLAP 큐브를 새로 고칩니다) 또는 POST http://company.com/view/patients/123123이 (환자를위한 새로운 데이터베이스보기를 만들 수 있습니다)
나에게 보인다 PUT. ...
ETL은 데이터베이스에 행을 매우 빠르게 (또는 때로는 매우 융통성있게 데이터가 약간 위험하고 자동화 된 정리가 필요할 때) 삽입하는 것에 관한 것입니다.
REST는 HTTP를 모두 사용하므로 모든 동사와 일반적으로 유니 코드 방식의 생활을 사용합니다.
프로토콜로 HTTP가 매우 빠르지 않습니다. 그것은 바이너리가 아닙니다 (모두 바이너리 페이로드를 가질 수 있습니다).
ETL 문제는 실제로 데이터 소스에 의존하는 솔루션을 찾고 있습니다. 데이터 소스에 원시, 바이너리 프로토콜이 있습니까? 그것을 사용하십시오, 그것은 일반적으로 가장 빠릅니다.
모두 포트 80 뒤에 잠긴 데이터 소스가 있습니다. Microsoft의 ADO.NET Data Services (Astoria)와 같은 것들은 이미 REST 기반 데이터 액세스 API의 세부 사항을 연구하고 있습니다. 고성능이라면 놀랍 겠지만 확실히 유연한 것처럼 보입니다.
응답 주셔서 감사합니다. 나는 실제로 ETL 태스크를 실행하는 측면에서 REST를 구현하고 있지는 않습니다. ETL 프로세스는 PL/SQL 스크립트와 패키지입니다. 제 접근 방식은 REST 호출을 통해 ETL 스크립트 시퀀스를 실행하는 워크 플로우를 구현하는 것입니다. 이미이 작업을 수행하는 제품이 있습니까? – wsb3383
그런 경우, ETL 태스크를 시작한다는 사실은 부적합합니다. ETL 도구에 대한 타사 UI를 구입하는 경우 왜 구현되었는지 중요하지 않습니다. REST는 COM, COM +, CORBA 또는 웹 서비스와 비교하여 상당히 쉬운 API이기 때문에 일반적으로 흥미 롭습니다. 따라서 REST API에 대한 프로그래밍은 훨씬 작은 프로젝트입니다. – MatthewMartin
다음 링크를 고려해 보겠습니다. 웹의 목적을 무마하기 때문에 여기에 내용을 반복하지 않습니다. https://blog.apigee.com/detail/from_etl_to_api_a_changed_landscape_for_enterprise_data_integration – btiernay